Cardano Updates

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

  The proposals and therefore, their roots, must be the most recent ones. This is because we need to keep the resulting state free of any orphan proposals resulting from pruning. So if a new proposal was submitted in the epoch that just passed but referenced a proposal that is pruned; it must also get pruned. It is "safe" to have those proposals in the forest as well because, they can't possibly have any votes (they did not exists at the moment the snapshot was taken). So they will only be present in the forest to get discarded when needd.

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: etorreborre <[email protected]>

Signed-off-by: etorreborre <[email protected]>

Signed-off-by: KtorZ <[email protected]>

  Somehow, few fields were missing or ignored in the encoder / decoder. Plus, I've also adjusted some of the names to reduce the inconsistency with the ProtocolParamUpdate that lives in Pallas.

Signed-off-by: KtorZ <[email protected]>

  Somehow, few fields were missing or ignored in the encoder / decoder. Plus, I've also adjusted some of the names to reduce the inconsistency with the ProtocolParamUpdate that lives in Pallas.

Signed-off-by: KtorZ <[email protected]>

Embracing ComparableProposalId throughout the store interace.

Signed-off-by: KtorZ <[email protected]>

  The core idea is to stash store updates as we go, while mutating the
  RatificationContext we operate in. The data in the store that we use
  can in fact only be changed following those ratification updates; so
  we need not any kind of re-synchronisation and can apply updates
  directly on top of the snapshot we operate from.

  Because we need to immutability traverse the forest, while also
  occasionally allowing local mutations; we introduce a `Compass`, that
  acts as mutable iterator but without holding any reference on the
  forest (so it needs the forest each time it needs to access the next
  element).

  This allows to traverse the forest while remaining capable of
  borrowing an immutable reference to it on enactment.

  Now, we must also makes sure that the forest is getting properly
  pruned; which involves multiple steps:

  - Any impacted sub-tree must promote the enacted proposal as its new
    root, and prune all its siblings and their children. Those proposals
    are now unreachable / unvotable, and will be cleared from the state.

  - Any of the pruned proposal must be removed from the forest's lookup
    table;

  - The proposal sequence must be amended accordingly;

  - And finally, in case where a:

    - `hard_fork`; or
    - `constitutional_committee`; or
    - `constitution`

    proposal is ratified; then no other proposal can be ratified in the
    same epoch boundary. So any new cursor on the forest will yield
    `None`.

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

  This prevents clashes between those special keys and any of the columns. I just bumped into a case where the 'proposal-roots' key would show up in the iter_proposals iterator, because it filters based on the 'prop' prefix. So, to fix this one and avoid future issues, it's best to prefix them with a character we do not use in columns' prefixes.

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>

Signed-off-by: KtorZ <[email protected]>