[DO-NOT-MERGE] Leios prototype#5626
[DO-NOT-MERGE] Leios prototype#5626bladyjoker wants to merge 7 commits intobladyjoker/tag/cardano-ledger-core-1.17.0.0from
Conversation
bladyjoker
changed the base branch from
lehins/use-mempack-newest-10.2
to
bladyjoker/tag/cardano-ledger-core-1.17.0.0
Why do we need a separate PR, instead of merging individual features needed for Leios one at a time? |
This PR is for Leios prototype transparency and as such it's not intended to be merged and end up in production code. Similar to IntersectMBO/cardano-node#6386 and IntersectMBO/ouroboros-consensus#1793. Does that make sense? |
No, not really. What is the end goal of all the changes in a PR like this: IntersectMBO/ouroboros-consensus#1793 Is it going to be used only for prototyping and doing demos and later scrapped and reimplemented from scratch as a sequence of many more smaller PRs? If that is the case, then it is totally fine. However, if the goal is to prototype for a year and then create from that prototyping work one massive PR that is impossible to review, then it definitely does not make sense. Feel free to keep it opened, it does not get in a way of anything. I just want to make sure we do not get in a situation where Leios is implemented in one spaghetti PR, cause that is not how we develop features in Ledger! |
Exactly this! |
Wow so much type hell, was catching missing instances for half a day, note to self: try not to mess with instance decls
input-output-hk/ouroboros-leios#774 DONE - [x] **Ledger**: IntersectMBO/cardano-ledger#5626 - [x] New `Block` fields `blockMayAnnouncedEb :: Maybe EbHash` and `blockCertifiesEb :: Bool`(NOTE: Currently we keep this in the **body** and not the header) - [x] `ShelleyLedgerState` in OuroborosConsensus is tracking the **last announced EB** - [x] [applyBlock](https://github.com/IntersectMBO/cardano-ledger/blob/b1a015328e5f33c0ae6f9a4ef181b77234251bb2/eras/shelley/impl/src/Cardano/Ledger/Shelley/API/Validation.hs#L59) for ConwayEra handles a Certificate Body. - [x] **Forge**: Issues a Block with EB announcement and Certificates - [x] When the EB was produced it's marked in the forged LedgerBlock (`blockMayAnnouncedEb`) - [x] When the previously announced EB is fully downloaded (entire tx closure is available) and (mock) certified, the use of that EB is marked in the new LedgerBlock (`blockCertifiesEb`) - [ ] **!!! Mempool Partitioning !!!** - We currently split the transactions in the Mempool in 2 parts, first part is for a Block with **inlined transactions** and second for an EB. However, that's a problem! When a Leader tries to forge a Block with a Certificate **AND** additionally wants to announce a new EB, the transaction in that EB are likely to be invalid wrt to the Ledger state induced by the application of the Certificate. Instead, when a Certified EB is available during Forge, Mempool needs to be "rebased" to a Ledger state after the Certified EB application (and the surviving transactions can go to an EB and be announced) - [x] Skip announcement when certifying as an interim solution (see 02ef504) - [x] **ChainDB**: When the `blk` contains a Leios Certificate we must resolve its transaction closure in order to `applyBlock` - [x] `resolveLeiosBlock` call (`ResolveLeiosBlock blk` class method) was introduced in a call chain to `applyBlock` to resolve the transactions if the `blk` contains a Leios Certificate - [x] Shelley `resolveLeiosBlock` resolves the transaction closure and provides it to the Ledger - [ ] **Test** - [x] Test new LeiosDB queries - [ ] Test that a Certificate has been forged - [ ] Test that a Certificate has been adopted/applied - [x] Old ouroboros-consensus tests are passing? - [x] **Sqlite implementation** - [x] Get tx closure by EB Point - [x] Get certificate by EB Point
2 participants
This PR hosts changes to cardano-ledger changes related to Leios. I'm opening a PR for easier management and transparency to make changes visible at a glance.
More importantly, this branch will be tagged and sourced for Leios demos.
IT IS NOT INTENDED TO BE REVIEWED OR MERGED!