High level summary
The ledger team completed some preliminary ground work in preparation for CIP-1694 (restructuring the ledger state), fixed the PDF hosting problem (mostly the formal specs), built out more of the new user-friendly ledger API, finished a proof of concept for constraint-based generators for property tests (with the hopes of being able to replace our trace generators one day), and addressed technical debt.
Lower level summary
Restructuring the ledger state
The existing governance structures will be replace in the conway ledger era, as described in CIP-1694. In particular, the ledger rules will be restructured as follows:
BBODY
|
|-------------------------------|
v v
TICK LEDGERS
| |
|---------| |
v v v
RUPD ~NEWEPOCH~ ~LEDGER~
| |
|----------| |--------|-------------------|-----------|
v v v v v
~EPOCH~ +ENACTMENT+ DELEGS UTXOW +TALLY+
| | |
|---------|------------| v |
v v v DELPL v
SNAP POOLREAP -UPEC- | UTXO
|--------| |
v v v
POOL DELEG ~UTXOS~
-..- Removed
+..+ Added
~..~ Modified
Moreover, the ledger state will also be restructured in accordance with the new rules. In the conway code, we have now removed UPEC, added TALLY, and stubbed ENACTMENT. We have also adapted all the data structures in the ledger state.
See:
PDF hosting
We now build all of our PDFs using a GitHub action which is triggered by pushing a tag
with a specific form, cardano-ledger-spec-YYYY-MM-DD.
The action creates a GitHub release containing the PDFs.
The links in the main ledger README now point to the PDFs in the latest release.
See:
Powering the new ledger API
We have now removed all the HasField instances from the protocol parameter data types,
and replaced them with lenses.
This is probably the last major restructuring that the ledger team will do on the code base
for the API for a while
(the Plutus tools team will be working on it next, see here).
We also added a new helpful function ensureMinCoinTxOut.
See:
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 would like to switch to tests which instead generate a random ledger state representative of not just an initial state, generate a single random valid block, and then test our properties. The hope is that these will be much more random and easier to maintain.
We have finished a proof of concept are encouraged that this approach could work!
See: