SPO Call Notes for March 6th, 2025 New Node 10.2.1 Currently marked as pre-release. So far all regression-tests successful, will likely become mainnet release soon. Please do keep testing until then. Does include first integration of Ouroboros Genesis, will be rolled out fully over the next few months. When Ouroboros Genesis is fully integrated, no bootstrap nodes will be required anymore to sync from genesis. This will add more load requirements on registered pool relays (as they will help others to sync from genesis). New Tracing System For the current EKG service the node has a full fledged web server inside the node. The new tracing system will remove this complexity / dependency. New node will "just" provides Prometheus metrics and Cardano Tracer processing service will do the rest. You can still debug the node with the tracing system, node will still emit traces (just without a web server), you can still see all traces without forwarding to the new Cardano Tracer service via TCP. When the connection between node and Tracer is lost, a reconnection timeout defines when to try to reconnect, this will be made configurable. Some community testers have reported more CPU usage with the new Tracer, doesn't seem to manifest with build configuration and hosts team tried to reproduce this. There is a hunch though this might be related to a bunch of serialisation and deserialisation happening right now which could be excluded from the forwarding. Optimisations like these are in the works. After successful roll-out, and the new tracing system is settled and adopted, the Cardano Tracer will evolve to a working group managed by the community. RTView Realtime View was moved to experimental status and is thus discontinued. Interest within the SPO community is low for this, as Prometheus and Grafana with additional supportive tools like Zabbix are perfectly fine for most. Node 10.3 Improvements to Ledger. Performance improvements can be expected with this node release. Nodes after 10.3 UTXO-HD LSM solution next. Should control memory usage much more tightly. Parameter Committee - Proposal to cut tax from 20% to 10% CF has commissioned a report with Massimo Morini on Cardano economic parameter insights, this link plus other considerations for decision making collated here: docs.google.com/document/d/1… Parameter Committee - Plutus Scaling - Memory Limit Analyzed various scaling options with benchmarking, e.g. exhausting memory and step limit independently, DApps can exhaust just one and keep the other intact. Tests confirmed increase in memory would have linear effects. So Plutus memory limit could thus be increased. In reality memory limit not really on memory but total CPU usage. Some DApp developers want to run larger scripts with more CPU demand. Timing budgets during times like block forging are considered, security guarantees must always be met, so increase must be within these constraints, if the community wants to move forward with this. If an SPO ever has an issue which can be improved with a parameter change, please do raise a PCP (Parameter Change Proposal) Building Delegator Communities - Clarity DAO Stake-weighted delegator voting for your community, see xitter.cf/clarity_dao/status/189… Happy to receive feedback. Building Delegator Communities - Ryp.io Connect with delegators, SPOs etc. via various communication channels New Calidus Pool-Key for SPOs and Services interacting with Pools See forum.cardano.org/t/new-cali… Calidus is a new ed25519 standard hot key you can generate as an SPO with your cold pool secret key to provide proof of pool ownership to interact with various services (authorization, identification, login, voting, sign documents like governance actions rationals, etc.). You can use this key as a standard CLI key, as a mnemonic to import into any light wallet (recommended) or also on a hardware wallet. You can generate one Calidus key per pool, you can also use one Calidus key for multiple pools, if you are a Multi-SPO. Wide support for this new key in the works with CNTools, Koios, Blockfrost, Ryp.io and more all looking into supporting this. Previous pool ownership proofs were based on the signing with the vrf.skey, which pool owners do not like to use that often. Or SPOs had to put some token in the pool metadata or send a transaction with a specific lovelace amount etc. The new mechanism is leveraging CIP8/30. Calidus is supposed to be your new daily-usage key. Registration is simple via tx_metadata and can be updated at any time.