58 posts tagged with "ledger"

High level summary​

The Plutus tools team at IOG has started helping the ledger team to build out a user friendly cardano-ledger-api package! A GitHub project will be filled out in the days ahead, people interested in the API can use it to follow along and join in on the conversations.

The ledger team has started using architectural decision records to leave a record of important decisions that the team makes. We will retroactively go back through past decisions and make ADRs for them.

The logic to track individual deposits is now nearly in place. We are prioritizing correctness with our first pull request, and will follow up with performance optimizations and general cleanup next.

Pointer addresses are being deprecated with the Cardano major protocol version 8. See CPS-0002 for more context.

Lower level summary​

Cardano ledger API​

The Plutus tools team has taken our minimal cardano-ledger-api package and started filling it out and adding much needed documentation. They have also added doctests! In the days to come, the Plutus tools team will map out a lot more work for the API and record it in this GitHub project.

See

• pull-3182
• pull-3188

Architectural Decision Records (ADRs)​

We are now providing more context and leaving a record of important decisions that are made in the ledger. The first ADR explains the very lightweight process.

See

• pull-3177 (rendered here)

Tracking individual deposits​

See ADR-3 for background. We now have the logic in place to track individual deposits, and a host of property tests to make sure that the logic is correct. The current implementation uses more memory than it needs to, and we will address that next, with our hope being to only use one word (8 bytes) per registered stake credential. There is a fair amount of other cleanup needed for general maintainability.

See

• pull-3127
• pull-3195
• pull-3202

Removing pointer addresses​

Pointer addresses, which have never seen any real use (there are something like eleven on mainnet), are being deprecated starting at Cardano major version 9. CPS-0002 gives the context. We are disabling them by first preventing transaction outputs containing them from being serialized by the node at the moment we switch to version 9. At the hard fork after that, we will translate the existing few pointer addresses to enterprise addresses.

See

• pull-3174

Technical debt​

• pull-3162 - Sometimes we have to put safeguards in place for hard forks which may never be exercised. After we have passed the given hardfork, we are able to clean up the code and simplify our logic. We removed all of the ones that we are currently easily able to.
• pull-3165 - We improved the type safety of our code while also discovering and fixing a serialization bug.
• pull-3172 - We removed dead code.
• pull-3175 - The Allegra and the Mary code used to be coupled in a particular way the we grew to dislike. We made these two ledger eras now uniform with the rest of our code base.
• pull-3184 - We organized our property testing code.
• pull-3200 - The Plutus tools teams fixed an outstanding bug in the translation from the ledger state to the Plutus script context.

High level summary​

We released CIP-1694, our proposal for entering the Voltaire phase. Please come join the discussion, this will be an incredibly exciting transition for Cardano and we want everyone to participate!

We now have a sensible way to version all of the serialization schemes used in the ledger. The draft pull request was polished, reviewed, and merged this week. This solves many problems that have vexed us since the beginning of the Shelley ledger era.

Everyone working on the Cardano node is working together to improve our release process, and the ledger team in particular dedicated one engineer to help with these efforts for the next release.

Lower level summary​

The Conway ledger era​

The current proposal in CIP-1694 encompasses two new ledger eras. The first era will be called Conway, after the English mathematician John Horton Conway. The community facing aspects of the Conway ledger era will be very minimal, but it will pave the way for introducing liquid democracy. The details can be viewed here. We do not yet have a formal specification for the Conway era. Our plan is to debut the formal ledger model. Briefly, the Conway ledger era will:

• introduce SPO voting for hard forks (in the spirit of the now abandoned CIP-47)
• provide an on-chain mechanism for rotating the governance keys
• re-plumb the ledger rules involving governance to be in line with CIP-1694

Versioned CBOR​

We now have the ability to easily tie our serialization schemes to the Cardano major protocol version. We still aim to preserve backwards compatibility as much as possible, but we now have a principled plan for resolving problems (see CIP-ledger-cbor). In particular, we can now address several long standing issues, such as issue-2444, issue-2965, and issue-3003.

The final (and massive!) pull request which brought us the versioning is pull-3138.

Deposit tracking​

The draft pull request which was exploring how best to track individual deposits is much closer now to being ready to take out of draft (pull-3127). For background on the issue, see issue-3113. This is quite an invasive change which effects many of our tests, which we are now addressing.

Technical debt​

As always, we keep working on technical debt. We have deduplicated a some things: pull-3129, pull-3162. We have memoized a problematic computation (though more due diligence is needed before we can merge): pull-3141.

Node release​

We have been helping with the node release efforts. See pull-4608.

High level summary​

I am extremely excited to say that we now have a pull request up which introduces our new versioned CBOR serialization. This was an enormous effort, but it will solve a host of problems that we have had since the Shelley phase. It will take time to properly review it, and we will need to put in a lot of effort to integrate it with the downstream components, but this is a huge milestone. Additionally, we have a new CIP proposing a deprecation cycle for the transaction serialization schemes.

We also have a draft pull request that reworks how deposits are tracked. Users of the system will not notice any difference, but it is a necessary change needed to prepare the way for decentralizing the governance of Cardano.

Finally, we continued to address technical debt. In particular, we continued to make progress on bringing coherency and consistency to the code base with a common naming convention, and improving some error messages.

Lower level summary​

• We have a pull request up for our new versioned CBOR serialization. When we encounter a problem with our deserializers, it can be very difficult to implement a fix. It is difficult because we can only fix such issues during a hard fork, and leading up to the hard fork we must maintain two serializations for the same type in order to not cause unintended network splitting (the problematic version must be used before the hard fork, and the fixed version is used afterwards). This can be especially tricky with the FromCBOR typeclass, since it is not always easy to search for where all the problematic uses are located. The new versioned CBOR serialization allows us to gracefully handle this transition. See [pull-3138].
• We proposed a CIP for backwards compatibility of the transaction serialization schemes. See [pull-372].
• We have draft for the new deposit tracking. This draft is not as memory efficient as the final version will be, but it is a sufficient proof of concept that we can write property tests against, ensuring that we have not changed the semantics. We will optimize after we are sure of the correctness. See [pull-3127].
• We now provide better support for debugging failed Plutus scripts in an important helper function, named evaluateTransactionExecutionUnits. In particular, it now returns all the information needed to rerun the script with exactly the same arguments. This feature will end up appearing in the CLI and other tools from the Plutus tools team. See [pull-3135].
• We did a lot more renaming to bring coherency and consistency to the code base. See [pull-3126], [pull-3120], [pull-3118], and [pull-3116].
• We have added a few things to the ledger repository to make it conform to the Cardano Engineering Handbook See [pull-3139].

High level summary​

We have made the decision to use the formal ledger repository in place of a LaTeX spec for the next ledger era, and have added a lot of basic infrastructure to the model. In particular, we now have a lot of support for axiomatic set theory. While the next ledger era is still in the design phase, most of the team remains working on technical debt. In particular, we have moved a lot more code out of the Shelley specific modules and into a ledger core module, we have finished up our benchmarking around the problematic TICKF ledger transition (while improving the performance), made conveniences to the development environment, cleaned up all the recent changes to the cost model, added a lot of documentation, fixed some flaky tests, and deleted some dead code.

Lower level summary​

Axiomatic Set Theory​

The formal ledger model now has support for much of the set theory that we make use of in the formal ledger specifications. See [pull-20].

Completed Technical Debt​

• We have addressed issues with two of our most problematic and flaky tests. See [pull-3039] and [pull-3093].
• We have added more documentation and tests to the Twiddler module. This is a module which makes our CBOR serialization round-trip tests much more robust, and will also hopefully help enforce the mandate for downstream libraries to never re-serialize data that needs to be hashed. See [pull-3073] and [pull-3095] (we cannot merge 3095 just yet, due to a preference for merging other features).
• We have finished our long analysis of the problematic TICKF transition. We now have a lot of benchmarks surrounding this code, and have added performance improvements. See [pull-3068] and [issue-3035].
• We have restored support for ghcid in our repository. This is a tool for developing with Haskell that many of us find greatly improves our productivity by providing us with constant feedback from the type checker. See [pull-3112].
• After much activity on the cost model, we have done some final clean up of the code. See [pull-3075] and [pull-3101].
• We moved a lot of the existing user facing documentation regarding native tokens into the ledger repository, and cleaned it up (most of the heavy lifting was done by our amazing technical writers). See [pull-3091].
• We removed dead code. See [pull-3089].
• We moved a lot of code from the Shelley specific libraries to the ledger core library. See [pull-3109] and [pull-3110].
• We've removed more of the awkward legacy template Haskell names. See [pull-3108].

High level summary​

The ledger team is still primarily focused on addressing technical debt. We now have the infrastructure for versioning our serialization schemes, which we continue to put into action. We have made first steps towards getting proper support for the formal ledger repository (in particular, we've added nix builds and continuous integration support). We are wrapping up an investigation of the performance of a critical function used by the consensus layer for leader checks. Finally, we are improving the packaging and versioning of our code.

Lower level summary​

Completed Technical Debt​

• Because the Shelley ledger era was a complete re-write of the Byron ledger era, a lot of our code lives in the cardano-ledger-shelley package, though with hindsight we can say that much of it should live in cardano-ledger-core. We continue to move things to cardano-ledger-core, and have much more to come. [pull-3059]
• We now have the infrastructure to support versioned serialization schemes. The inability to do this has caused us a lot difficulties, such as [issue-3003], [issue-2965] and [issue-2444]. We are still in the process of switching to the versioned serialization scheme (such as [pull-3078]), but the infrastructure was completed in [pull-3063].
• We now have proper nix and CI support for the formal ledger project. [pull-19]
• A separate team is helping bring support for CHaP to all the cardano-node repositories. We have been helping out with this effort.

• A separate team continues working on upgrading all the cardano-node repositories to work with ghc 9.2.4. We have been helping out with this effort.

In-progress Technical Debt​

We also have several fairly large pull-requests in review that we are working on.

• In an on-going attempt to build out a more user-friendly API, we continue to remove HasField instances in place of using micro-lenses. The protocol parameters, in particular, are being worked on. [pull-3045]
• We are also renaming record fields to be consistent across the repository. [pull-3062]
• We are now cleaning up all the work we did to understand the performance of the TICKF transition. We have some improvements to the computatation as well. [pull-3068]
• We are adding more documentation, in particular to our Twiddler functionality. [pull-3073]
• The formal ledger is adding support for finite set theory. [pull-20]