Areas of focus​

Issue	Status
Implement legacy mode for UTxO-HD to keep baseline performance	✅ Done
Assist mainnet node release with initial Conway capabilities	✅ Done
Assist with test, benchmark, and improvements to CIP 1694	✅ Done
Assist with P2P IOG relay network shut down	✅ Done
Assist with repo transfer to Intersect	✅ Done
Support vendors to deliver contracts	✅ Done
Operation serenity Q4 2023	✅ Done

Highlights​

Implement legacy mode for UTxO-HD to keep baseline performance​

• ✅ We managed to run a UTxO-HD capable node in legacy mode, maintaining the baseline memory usage while keeping all the ledger state in memory.
  • While the legacy mode is not production-ready (it requires further integration and testing), it remains as a plan B should the need arise to release UTxO-HD if our stakeholders so demand it.
• ✅ We pivoted to redesigning the Ledger DB API because:
  • This is needed for integrating the LSM-tree backend.
  • The redesign opened the possibility of implementing an in-memory backend that would keep the same performance and resource requirements as the baseline version (which needs to be confirmed by benchmarks).
• ✅ We created a more general Ledger DB API.
• 🛠️ We are integrating (into the feature branch) the existing Ledger DB implementations with the new API.
• 🛠️ We are implementing the new in-memory backend.

Assist mainnet node release with initial Conway capabilities, test, benchmark, and improvements to CIP 1694​

• ✅ We recognized that Conway introduces a new challenge in the versioning of NTC queries, and we resolved it (see 864 and 4770).

Assist with P2P IOG relay network shut down​

• ✅ We created a prototype for the pre-Genesis State Machine for bootstrap peers, which is currently under test (see this PR).

Assist with repo transfer to Intersect​

• ✅ We transferred the ouroboros-consensus repository to the Intersect GitHub organization.

Support vendors to deliver contracts​

• Genesis
  • ✅ Interacted with the Consensus team and addressed resulting feedback on past deliverables.
  • ✅ Finished implementation of the testing infrastructure of Genesis
  • ✅ Started to refine the Proof of Concept demo into an actual implementation of the core components of the Genesis design.
• 💾 LSM-tree implementation. Well Typed:
  • ✅ Finished the design of the public facing API.
  • ✅ Defined the LSM-tree database file-type formats.
  • ✅ Implemented property and model-based tests.

Operation serenity Q4 2023​

• 🎉 We welcomed our newest team member @RenateEilers and assisted with her (ongoing) onboarding.
• ✅ We implemented a simplification in the ChainSync mini-protocol that is also a step towards Ouroboros Chronos.
• ✅ We added tests to check Consensus emits valid CBOR, which prevents the generation of invalid binary encoding.
• ✅ We established and implemented an interface between Consensus tooling and P&T tooling, which constitutes a step towards incorporating component level benchmarks in our development process.

2023-10 - 2023-12​

Main achievements​

In addition to ongoing general maintenance and support of cardano environments, main SRE achievements for this quarter include:

• Cardano-parts support was added for cardano-db-sync, cardano-smash, cardano-faucet, cardano-metadata, grafana monitoring along with a number of other features

• Completed migration of testnets from cardano-world to the cardano-playground cluster

• Completed migration of the cardano book from cardano-world to the cardano-playground cluster

• Completed migration of pools from cardano-ops to the cardano-mainnet cluster

• Creation of a mainnet p2p bootstrap cluster

• Cardano sanchonet environment respins during the quarter for testing new cardano-node pre-release Conway era functionality

• All environments were upgraded to cardano-node 8.7.2 or 8.7.3 by the end of the quarter

• Completion of a govtool backend deployment for Voltaire chain testing

• Creation of a cardano-monitoring repository, cardano-monitoring:

  • A new repository enabling agile deployment of EC2 monitoring servers, compatible with OpenTofu grafana and mimir providers

Next steps​

• Scale down the mainnet non-p2p legacy cluster

• Add deployment support for new network services, such as Mithril

• Continue cardano-parts and operations improvements

2023-07 - 2023-09​

Main achievements​

• Release benchmarking
• Developing and running UTxO-HD benchmarks - in-memory flavour
• P2P benchmarks, facilitating rollout
• Production-readiness of the new Nomad cluster has been reached
• Optimization of and introspection capability for the new tracing system
• GHC9 performance investigation (and possible remedy)
• Conensus QTAs: first real-world application of prototype

Release benchmarking​

Ongoing release benchmarking is a crucial safeguard to cardano-node's release cycle from a performance perspective. We've performed and analyzed benchmarks for node versions 8.2.x to 8.5 throughout Q3.

UTxO-HD benchmarks​

Targeting a specific new feature in benchmarks requires development effort and fine-tuning the machinery. In Q3, we achieved that for the in-memory flavour of UTxO-HD, enabling benchmark delivery.

P2P benchmarks​

In Q3, we performed additional P2P benchmarks to facilitate the comprehensive rollout of that feature.

New nomad cluster​

The new hardware cluster for benchmarks, which is controlled through the new nomad backend, has received various rounds of validation and adjustments in Q3 - in addition to finalizing integration with the rest of our pipeline. The confidence in metrics gathered on the cluster is now sufficient for us to consider it ready for production use.

New tracing system​

Our new tracing system has received various rounds of optimization in Q3. We could verify in our benchmarks that it is roughly on par with the legacy system while offering a richer feature set and greater flexibility.

Additionally, in Q3 we equipped the system with an introspection capability. This is now used for generating end user documentation that stays in-sync with definitions in code, and for automated consistency checking of the entire system.

GHC9 performance​

In Q3, a joint investigation with DevX into GHC9's behaviour revealed where and how GHC9 misses opportunities for optimization of generated code. This led to an approach to annotate our codebase accordingly to re-enable those optimizations - which is still being validated.

Consensus QTAs​

In collaboration with Consensus and DevX, we advanced the Consensus QTAs prototype capturing ledger operations' performance characteristics. It's now applicable, and being applied, to a real-world task - namely gathering evidence of the effect of aforementioned changes allowing for performant GHC9 builds.

Next steps​

Benchmarking:​

In Q4, the focus will be on:

• facilitating the next mainnet release
• benchmarking runs in the Conway era
• developing benchmarks / workloads for Conway-exclusive actions
• implementing a specialized benchmark setup for the UTxO-HD on-disk variant
• developing new Plutus benchmarks to safeguard Plutus V3
• benchmarks regarding the rollout of P2P

Performance​

For certain blocking performance issues we've located the cause, or even found a solution in a cross-team effort. In Q4 we'll advance that work to ensure the ongoing release cycle for mainnet, as well as make GHC9 become a viable release platform.

New tracing system​

For the new tracing system, we'll finalize optimization - current results are already on par with the legacy system. Furthermore, we will finish up comprehensive documentation, as well as description of a recommended setup, for which we can provide initial support.

UTxO-HD monitoring​

We'll augment our analysis pipeline so it can process monitoring data from UTxO-HD nodes connected to mainnet in a meaningful way.

Nomad backend​

From Q4 on, this backend will be in production use. We plan on adding various UX and flexibility improvements, and further fine-tuning some profiles for nomad.

Workbench​

We will prepare for a future move of our performance workbench into a separate project. This entails restructuring, refactoring and reimplementation of certain few components that currently assume to always be in sync with cardano-node.

Consensus component QTAs (co-development)​

In Q4 there will be ongoing work with and support for the existing prototype. We plan to identify a fixed set of input data that yields results of high informative value, and to formalize the process to a point that enables future automation.

2023-07 - 2023-09​

Main achievements​

In addition to ongoing general maintenance and support of cardano environments, main SRE achievements for this quarter include:

• Completion of mainnet relay networking conversion to p2p topology
• Cardano sanchonet environment respins for testing new cardano-node pre-release Conway era functionality
• Stabilization of cardano-explorer in cardano-world using high IOPS bare metal machines
• Creation of a nix content addressed packages repository, capkgs:
  • To provide lightweight release binaries thereby avoiding sluggish nix flakes and devShells
• Creation of a cardano performance benchmarking cluster, cardano-perf:
  • To replace legacy cluster benchmark tooling
• Creation of a cardano cluster composition repository, cardano-parts:
  • For enabling multi-cluster, multi-role cardano network deployments
• Creation of a cardano testnets repository, cardano-playground:
  • Utilizing cardano-parts for testnet deployments
• Creation of a sanchonet demo repository, sanchonet-demo:
  • Utilizing cardano-parts for fast sanchonet test environment and demo purposes

Next steps​

• Continue with migration of cardano-world testnets to cardano-playground
• Proceed with spinup of mainnet p2p bootstrap cluster
• Scale down mainnet non-p2p legacy cluster at the appropriate time

2023-04 - 2023-06​

Main achievements​

In addition to ongoing general maintenance and support of cardano environments, main SRE achievements for this quarter include:

• Expanding the darwin CI cluster and adding aarch64 builder support
• Adding bare metal capability to bitte clusters
• Creating a devx-ci cluster containing a Hydra build server and Linux build farm which is intended to replace Cicero functionality
• Creation of pool performance analysis queries and scripting
• Migration of testnet metadata server to cardano-world
• Cardano shelley qa migration to cardano-world
• Cardano sanchonet environment spin up to test Conway era functionality
• Mainnet relay conversion to p2p topology usage is progressing with 50% of mainnet relays now using p2p topology and networking feature

Next steps​

• Continue with the conversion of mainnet to using p2p topology

2023-04 - 2023-06​

Main achievements​

Eclipse Evasion​

We finalised the design of eclipse evasion and implemented its mechanism which relays on connectivity to big ledger peers. Big ledger peers are the largest ledger peers which accumulate 90% of stake (currently there are less than 1000 of them). The outbound governor has new targets for known, established and active big ledger peers which work in a similar way that such targets work for ledger peers. The ouroboros-network#4662 PR is currently in review.

As part of this work we also identified a bug which would prevent a node to connect to itself. Such connections are not easily detectable and are expected to be dropped by the churn mechanism, nonetheless they should not be buggy. The failure was discovered thanks to our e2e simulation of diffusion using io-sim & property based testing.

The PR also refactors the heart of the ouroboros-network interface reducing technical debt that would otherwise accumulate.

We also identified a possible improvement in the churn mechanism, which will be implemented in Q3. Churn needs to await for peers to terminate, we can improve the synchronisation. [ouroboros-network#4617]

Ecosystem P2P Deployment Progress​

We reached 50% of stake in hands of SPOs who run at least on P2P relay. Now also Emurgo and CF are running some P2P relays. Also 20% of IOG relays are running in P2P mode.

Peer Sharing​

We implemented bootstrapping for peer sharing (also known as light peer sharing). New downstream (inbound) peers are now added to the known peers of the outbound governor. Together with peer sharing this allows for non registered relays to propagate through the network. ouroboros-network#3596

Please note that peer sharing is disabled by default and is not considered safe until Bootstrap Peers (see below) or Genesis is implemented.

Diffusion (P2P)​

• We designed a feature which will reduce the load on IOG relays (in future also run by CF & Emurgo). The feature consists of two parts. A new source of peers called bootstrap peers (obtained from via an https request), the ability to switch from bootstrap peers to ledger peers if the node is synced (we are collaborating with the consensus team on the interface Bootstrap Peers IER). This feature will be completed in Q3. ouroboros-network#4530

• We published a blog post about P2P design & implementation.

• Karl Knutsson (CF) fixed an issue observed on a relay with a lot of outbound connections: ouroboros-network#4559.

• We merged changes which allow the consensus layer to start / stop block forging thread. This will allow to deploy P2P block producing nodes which serve as a live backup node. ouroboros-consensus#140

• We fixed a few bugs in local root peers DNS resolution service: ouroboros-network#4583, ouroboros-network#4571.

• We limited concurrency of DNS name resolutions: ouroboros-network#4596.

• Galois Inc implemented query option for Handshake: ouroboros-network#4256.

• We fixed handshake query timeout: ouroboros-network#4608.

• We implemented warm valency for local root peers. This can help when using DNS names in local root peers which resolve to many IP addresses. ouroboros-network#4575

• We merged handshake changes which allow query protocol versions. Thanks to James Parker from Galois Inc.: ouroboros-network#4256, cardano-cli#30.

Other Improvements & Developments​

CDDL​

• We added node-to-node and node-to-client CDDL specs / tests for encoding of NodeToNodeVersionData and NodeToClientVersionData.

• We clarified an inconsistency between CDDL spec and implementation which is highly polymorphic. We designed and implemented a fix for tx-submission and local-tx-submission mini-protocols. Specs for other mini-protocols will be improved at a later stage. ouroboros-network#4580

Cardano Ping​

• cardano-ping command was deprecated in favour of cardano-cli ping (the transition was done by the node team).

• Support for node-to-client protocol using Unix sockets. ouroboros-network#4601

• Support for NodeToNodeV_11 and NodeToClientV_16, ouroboros-network#4587

• cardano-cli ping is now using ISO8601 format for timestamps. Formatting of messages was improved. ouroboros-network#4593

• cardano-cli ping has a new --query-versions flag which allows to query supported versions by the remote node. This is supported by cardano-node-8.1.0. ouroboros-network#4589, cardano-node#5313, cardano-cli#30

IOSim​

• We fixed timeouts & delays in io-classes in a series of PRs: io-sim#81, io-sim#82, io-sim#86, io-sim#87.

• We released strict-stm-1.1.0.1 on Hackage which fixed a bug in package description file: io-sim#101.

Typed Protocols​

• We published haddocks of typed-protocols at https://input-output-hk.github.io/typed-protocols

Cardano Client​

• We fixed a bug in cardano-client-0.1.0.2 release which results in clients (e.g. db-sync) negotiate an experimental protocol version.

Technical debt​

• After the split between consensus & network, we made cardano-client independent of ouroboros-consensus-diffusion: ouroboros-network#4526.

• We wrap all exceptions in DiffusionError: ouroboros-network#4537, cardano-node#5356.

CI improvements​

• We switched to use GitHub merge queues in ouroboros-network, io-sim and typed-protocols repositories; typed-protocols#30, ouroboros-network#4546.

• We cleaned & updated scripts which run on CI.

• We implemented a script to verify & release packages on CHaP; ouroboros-network#4542, ouroboros-network#4573.

• We implemented a new CI script and cleaned existing ones: ouroboros-network#4572.

• We don't install cryptographic libraries on CI anymore as none of our packages requires them; ouroboros-network#4539.

• Improved caching of dependencies: ouroboros-network#4553.

• We made it possible to trigger building haddock manually: ouroboros-network#4549.

GHC 9.4 & 9.6​

We made all repositories under our control compile with ghc-9.4 and ghc-9.6 which includes ouroboros-network, io-sim, typed-protocols and Win32-network.

Next steps​

We will continue towards our aspirational roadmap.

• We will continue reviewing eclipse evasion.
• As ouroboros-consensus#140 was merged, we are making progress towards releasing P2P on block production nodes. We hope to analyse performance regression on such nodes observed on the benchmarking cluster. roadmap-3887
• We are also focused on roadmap-3969. Note that it was expanded in Q2.

2023-04 -- 2023-06​

Main achievements​

UTxO HD​

• We finished a major prototype refactoring, which includes:
  • A better and finer grained DB lock mechanism.
  • Elimination of race conditions.
  • Support for configuring batch query size and flushing rate. This is crucial to allow node users to tweak performance.
  • Architectural simplifications and performance improvements.
• We implemented a new package to support db-sync integration with UTxO-HD.
• We ran another set of ad-hoc benchmarks:
  • We uncovered a performance regression on the Network component when using GHC-9.2/9.4.
  • The synchronization and replay speed are as expected.
  • However, we uncovered memory consumption issues (see figure below).
    • The in-memory backend is consuming more memory than the baseline.
    • The LMDB backend shows an unexpected memory usage peak.
    • Investigation on these issues is ongoing.
• We integrated the latest changes in main branch.
  • This required a re-design of the mempool to include the mempool fairness improvement.

Genesis​

• The Genesis work for this PI focused on an high-priority issue from the IOG Researchers' feedback on the proposal.
  • This particular question was not anticipated when the Q2 PI was planned.
  • As a result, the chain generators work, the ChainSync Jumping performance work, and the Genesis node prototype work were deprioritized.
  • That work has accordingly been rolled over into the Statement of Work for the first Genesis vendor work package.
• The IOG Researchers' feedback on the design was very valuable. It had two primary effects.
• Outcome 1: We re-introduced distinct behaviors when the node is "syncing" versus when it is "caught up".
  • This eliminated a DoS vector introduced by the proposal, instead of having to argue that it was well-mitigated.
  • The additional design complexity is relatively small.
• Outcome 2: The issue that was unanticipated is whether the Cardano chain is consistently dense enough to rely on Genesis without any checkpointing.
  • The determination so far is that---assuming the adversary never controls more than four of the seven genesis keys---the most vulnerable segment is in the pure Praos era.
  • All the preceding windows are significantly more robust, including the entire Byron and Transitional Praos eras.
  • Thus checkpointing is not necessary for the initial Genesis release, though it still may be a reasonable addition later.
  • The primary invention was a model for bounding how much benefit the adversary's long-range attack could possibly gain from Praos's natural short forks.
• Relevant questions that the IOG Researchers are still assessing.
  • These do not block the Genesis implementation, but do affect the ultimate values of specific parameters.
  • Question 1: what is the upper bound on the duration of an eclipse that a healthy Praos node will survive?
  • Question 2: what is the upper bound on how much grinding can improve the adversary's leader schedule within some Genesis window?

Support​

• We performed an analysis on number of file descriptors used by Consensus, this information can be used by the node operators to check if the number of file descriptors they want to support are enough, thus improving the user (eg node operator) experience.
• We implemented a mempool fairness improvement, by which transactions are guaranteed to be processed irrespective of their size.

Technical debt​

• We fixed a bug in followers logic, which was discovered by our QuickCheck property tests.
• We created an immutable DB server. This tool allows to serve blocks from the immutable DB to a node that connects to it. This has a remarkable value for testing and benchmarking purposes. For instance, by using this component, we can benchmark the performance of different aspects of Consensus, such as syncing from scratch, without adding Network interference in the performance results.
• We created a db-truncater tool, which can be used in disaster recovery and benchmarking scenarios.
• We created a benchmarks comparison tool that we plan on using for comparing the performance of two Consensus releases. This will allow us to catch performance regressions early on in the process, before they make it to the node (and show in the system level benchmark tests), thus greatly saving development costs. As an example, the graph below shows the performance improvements introduced by the Ledger team in version 0.6.0.0 of Consensus wrt version 0.5.0.0.

Fostering collaboration​

• We released fs-sim as open-source repository. This lowers the barrier to entry for external contributors, which will indirectly benefit the Cardano project.
• We migrated the consensus code to a new repository, splitting it from the ouroboros-network repository. This will save development effort for both the Network and the Consensus teams, since there will be less interference (for instance when making releases).
• We made several improvements to our release processes, which will translate in time savings. As an example, we went from 16 to 4 packages, which makes the release process simpler and smother. Our release process now makes it easier to align versions and make releases (both for us and for our downstream users).
• We added an explanation of the hardfork-combinator forecast horizon, that will benefit not only our team, but future external contributors.

Next steps​

UTxO HD​

• We will get UTxO-HD ready for handover.

Genesis​

• We will regularly liaise with the vendor(s) satisfying the Genesis Statement(s) of Work.

Consensus Quarterly Update​

2023-01 - 2023-03​

Main achievements​

UTxO HD​

• We finished the testing activities for the prototype, which involved adding new tests, and fixing and enabling temporarily disabled tests.
• We spent a substantial amount of effort refactoring and cleaning the prototype.
• We audited the UTxO HD prototype to make sure it can accommodate the migration of other tables (eg stake-keys registration) from memory to disk. The result of the audit was positive.
• We ran ad-hoc benchmarks for reading keys and flushing values to disk. No unexpected costs found.
• We ran the first system level benchmarks. The performance regressions reported were due to an unrealistic snapshotting rate. We need to re-run them again after we design a more fine grained locking mechanism.

Genesis​

• We elaborated a roadmap of the remaining work for Genesis.
• We presented the design to the IOG Researchers and PNSol on February 20. The design was well received. We updated the Genesis design with the researcher's feedback.
  • We plugged the new DoS vector identified during the aforementioned presentation.
• We developed a generator for adversarial leader schedules that satisfy key Ouroboros properties, which will be used to test the Genesis design.
  • The generator enables use of smaller Ouroboros parameters, which makes extrema more likely and counterxamples easier interpret.
• We wrote up the latest design iteration.
• We continued benchmarking the Chain Sync Jumping prototype. In particular:
  • We debugged the prototype's performance regression, and unmasked the actual cause by patching our initial theory (bad queuing behavior)
  • We identified and validated the actual cause (a pathological case in BlockFetch tiebreaker).

Support​

• We created two new tools. One for dumping CBOR encoded blocks to JSON. Ahother to serve a local immutable DB.

Conway era​

• We integrated the Conway era into consensus.

Technical debt​

• We fixed a bug with followers, which was discovered by property tests.
• We developed a DSL for specifying and running ChainDB test cases.
• We fixed failing tests with iterators.
• We created micro-benchmarks for adding transactions to the mempool.

Fostering collaboration​

• We released a new technical documentation site for consensus.
• We factored out several packages to external repositories. Some of this work originated in the UTxO HD workstream.

Next steps​

UTxO HD​

• https://github.com/input-output-hk/ouroboros-consensus/issues/28

Genesis​

• https://github.com/input-output-hk/ouroboros-consensus/issues/33
• https://github.com/input-output-hk/ouroboros-consensus/issues/32
• https://github.com/input-output-hk/ouroboros-consensus/issues/31

Support​

• Design Consensus side of hardfork-enactment in the Voltaire phase (#4180).
• Estimate the number of file descriptors Consensus needs #20.

Tech debt​

• Identify Quantitative Timeliness Agreements (QTAs) metrics that we can define for consensus. Pick one and implement benchmarks for it.

Fostering collaboration​

• Onboard a new team member.

2023-01 - 2023-03​

Main achievements​

Gradual dynamic P2P release on mainnet​

We released two version of cardano-node with dynamic P2P capabilities:

• 1.35.6
  • we found and fixed a bug in exception handling in peer-state-actions pull-4357
  • we found and fixed a busy loop when demoting a peer from hot to warm pull-4385
• 1.35.7
  • includes interoperability in the legacy non-p2p network stack pull-4467
• we fixed a busy loop of demotion & promotions: warm -> hot -> warm [pull-4485] /it will be included in cardano-node-8.0.0 release/.

Currently there are more than 200 P2P relays on mainnet.

Peer Sharing​

We implemented /peer sharing/ pull-4019 which will be available as an experimental feature in one of the future cardano-node releases.

We implemented /light peer sharing/, e.g. adding inbound connections to the set of known peers of the outbound governor, which allows to bootstrap relays not registered on chain. This complements peer sharing. The pull-4277 is in late review stages.

Eclipse Evasion​

We finalised design of eclipse evasion and we started implementing it. We have an initial implementation (not merged). We are in the process of extending our test suite to cover new implementation details: issue-3886, pull-4462.

Cardano Network Service Assurance​

Galois has been making progress on Cardano Network Service Assurance project.

• In cardano-node, they have developed a datapoint abstraction that creates a queue of (existing) log events, they now have two such datapoints (of log events) implemented.

• They have developed a datapoint client executable that can connect to a node which serves the "new tracing".

• They have been exploring approaches for the consolidation and analysis of datapoint data to extract actionable network health status.

Cardano-Node​

• We made it possible to configure accepted connections limit pull-4902.

Testing improvements​

• We fixed a bug in network simulation implementation of TCP simultaneous open pull-4265.

• We introduced header-body split in the diffusion simulation pull-4419 (in review).

• We introduced initiator only nodes in the diffusion simulation pull-4280.

• We fixed a connection-manager test failure issue-4370.

Technical Debt​

• We refactored Snocket interface decoupling it from the multiplexer pull-4260. This simplified some aspects of the KES agent implementation.

• We introduces a record for CBOR codecs which are used for various data structures by mini-protocol codecs pull-4430.

Documentation​

• We explained some limitations of CDDL in our technical report pull-4351.

IO-Sim​

• We fixed implementation of MVar's pull-70.

NoThunks​

• We published a new version of nothunks library to Hackage.

Next steps​

• Finish implementation & testing of eclipse evasion issue-3886.
• Optimise connectivity to peers behind firewall issue-4381.
• Finish the work on enabling block production dynamically to allow using P2P on block producers issue-3159.
• If time permits we would like also to reserve some time for finishing publication of io-sim to Hackage.

Ledger Quarterly Update​

2023-01 - 2023-03​

Main achievements​

CIPs​

• Entering the Voltaire phase - CIP-1694 received a major update after participation in the design has expanded to more and more people, including those who attended the Colorado workshop. See CIP-1694.
• Ledger CIP category - The ledger team continues to embrace the CIP process, and has begun the process of registering the ledger as an official CIP category. See CIP-84.
• Ledger serialization - A CIP for the ledger serialization deprecation cycle has been accepted. See CIP-80.

Formal ledger model​

Our new formal specifications backed by Agda have seen a lot of progress. The majority of the ideas in CIP-1694 are now present, and we have made enough progress that we can now safely say that the PDF produced by the Agda model will be the official ledger specification for the Conway ledger era. See the repository.

Conway ledger era​

Progress on the Haskell implementation of CIP-1694 has gone hand in hand with the formal model. The major component still missing is the DRep stake distribution, which still presents some technical challenges.

[pull-3176] [pull-3216] [pull-3226] [pull-3291] [pull-3326] [pull-3330] [pull-3339]

DRep stake distribution computation​

Adding another large stake distribution to the ledger state must proceed with caution. We do not want the memory used by the node to increase too much, and performance problems can lead to reduced block production. We have prototyped, tested, and benchmarked several approaches that could give us the current DRep stake distribution at each epoch boundary. This has very important implications, since we want every ADA holder to be able to at any time (such as during a contentious vote) register themselves as a DRep and still have time to vote themselves on the issue.

[pull-3344] [pull-3353] [pull-3364]

Integration work​

The ledger has made some wonderful improvements over the past six months, but which entail a significant amount of integration efforts:

• Our new versioned CBOR schemes
• Individual deposit tracking
• An improved cross-era interface utilizing lenses
• A new ledger API
• Re-arranging the ledger stake in preparation for CIP-1694
• Versioning our Haskell packages using CHaPs.
• Consistent conventions for variable names

[pull-3279] [pull-3282] [pull-3288] [pull-3289] [pull-3292] [pull-3297] [pull-3298] [pull-3299] [pull-3300] [pull-3302] [pull-3303] [pull-3308] [pull-3342] [pull-3345] [pull-3356] [pull-3357] [pull-3360] [pull-3361] [pull-3363] [pull-4349] [pull-378] [pull-376] [pull-373] [pull-370] [pull-361] [pull-4976] [pull-5013]

Deposit tracking​

Individual deposits (for stake credential and stake pool registrations) were not tracked by the ledger. Deposits were returned according to the current protocol parameters. When the values of these two protocol parameters change, the deposit pot is adjusted by adding to, or removing from, the reserves.

This has several problems:

• Most people expect a deposit to be paid back exactly.
• We cannot increase the deposit amount once the reserves hits zero.
• If it becomes known that the deposit amount is going to be increased, free Lovelace can be earned by registering credentials.
• Because of the problems above, it is going to be incredibly hard to ever change the values.
• There is a serious issue involving hard forks. The consensus layer makes the decision about whether or not to enact a hard fork based on the protocol parameter update state two stability windows before the end of the epoch. However, the ledger will reject a protocol parameter update on the epoch boundary if the deposit pot adjustments cannot be reconciled with the reseve pot. This means that if quorum is met regarding changing the major protocol version, but the update is rejected on the epoch boundary, consensus will change the era but the ledger will not change the major protocol version, leaving the ledger in a split-brain state.

Because we never actually changed the values of the two deposits amounts in the protocol parameters on mainnet, we were able to retroactively change the behavior. We made the following changes:

• Individual deposits are tracked in the DState.
• The amount deposited is always returned.

[pull-3195] [pull-3202] [pull-3217]

New ledger API​

We have significantly built up the ledger API. We will eventually replace much of the cardano-api in the node repository with this ledger API.

[pull-3242] [pull-3248] [pull-3328]

Constraint-based generators​

Our largest scale property tests generate an initial ledger state and a long sequence of valid blocks which span several epochs, mimicking a real network. These tests are, in theory, excellent for checking properties. They are, however, very difficult to maintain and are not as random as we would like (a lot of bias has to be introduced to keep the ledger state in enough order to keep generating blocks).

We have a new declaritive infrastructure for building constraint-based generators, which instead generate a random ledger state representative of not just an initial state, but also those representative of the end result of a long sequence of valid blocks. Moreover, these generators are very fast and are much more random than our old generators. Before we can start using them for our existing property tests, however, we still need to expand them to generate a valid block for a given ledger state.

[pull-3219]

Technical debt​

We continued to address technical debt as much as we can.

[pull-3167] [pull-3170] [pull-3172] [pull-3175] [pull-3184] [pull-3205] [pull-3208] [pull-3210] [pull-3212] [pull-3218] [pull-3222] [pull-3223] [pull-3224] [pull-3225] [pull-3229] [pull-3239] [pull-3241] [pull-3244] [pull-3245] [pull-3249] [pull-3260] [pull-3263] [pull-3264] [pull-3268] [pull-3269] [pull-3270] [pull-3274] [pull-3276] [pull-3277] [pull-3286] [pull-3290] [pull-3295] [pull-3296] [pull-3306] [pull-3307] [pull-3310] [pull-3311] [pull-3316] [pull-3320] [pull-3323] [pull-3327] [pull-3331] [pull-3332] [pull-3333] [pull-3338] [pull-3341] [pull-3347] [pull-3350] [pull-3351] [pull-3352] [pull-3354]

Critical fixes​

We fixed two critical issues:

• Growing block production delay on the epoch boundary: [pull-3209]
• Unexpected node shutdown from balanceR: [pull-3343]

Next steps​

• Conway spec - Complete the first version of the conway formal specification.
• DRep stake distribution - Have the ledger compute the DRep stake distribution with acceptible performance.
• Devnet ready - Have the Haskell implementation of the conway era in sync with the formal specification, and integrate the changes with consensus and node. All the details might not be finalized, but the wire specification and the API should be stable so that conway can be placed on a devnet for tool builders to start integrating with.
• Plutus V3 - Integrate Plutus V3 into the ledger, including a new script context which supports DReps.

More details​

This quarterly report was based off of the following fortnightly ones:

• 2023-01-05
• 2023-01-19
• 2023-02-02
• 2023-02-17
• 2023-03-03
• 2023-03-17
• 2023-03-31