Ledger Quarterly Update
2023-01 - 2023-03
- 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.
- 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.
- Ledger serialization -
A CIP for the ledger serialization deprecation cycle has been accepted.
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
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.
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
- Consistent conventions for variable names
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
- The amount deposited is always returned.
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.
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.
We continued to address technical debt as much as we can.
We fixed two critical issues:
- Growing block production delay on the epoch boundary: [pull-3209]
- Unexpected node shutdown from
- 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.
This quarterly report was based off of the following fortnightly ones: