Cardano Updates

searchutxos

* Fix the FloatDelay compiler optimization pass

* Changelog

  This allows to properly encapsulate those fields which MUST NOT be accessed directly inadvertently. Given that it is very easy to so (and effectively hard to keep track of), moving them in a separate module encapsulated as private field in a struct gives us the strong compiler guarantees needed. Defining Deref and DerefMut also makes it transparent to use from the parent module; yet preserves the encapsulation we need.

  Note that this made apparent an inconsistency in terms of protocol parameters and governance activity between validation and block application. This is now properly handled.

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

Co-authored-by: bora <[email protected]>
Co-authored-by: Tommy 🐙 <[email protected]>

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

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

Local mode wallet listing failed to parse newer stake-address vote delegation output.

  This is large because it touches quite many parts and I had to
  untangle store side-effects in the middle of various places. The
  general idea is rather simple, though:

  - The epoch transition no longer mutates the store directly;

  - Instead, the transition is entirely read-only; and produces three
    distinct 'pending' updates:
    - rewards payouts
    - pools updates (i.e. de-registration & parameters changes)
    - governance results (ratified & expired proposals, withdrawals, ...)

  - These updates are not immediately applied since they cannot be
    considered stable until later in the epoch. Instead, they're stashed
    in the ledger state object;

  - Later, once the results from the previous can be considered stable
    (cf stability window); we can flush the updates and begin the
    rewards calculations for the next epoch.

  What's left TODO from there:

  - We must ensure that access to various moving parts of the ledger
    state (e.g. protocol parameters, governance activity, etc...) are
    not done directly on the struct fields; but rather go through
    helpers that take care of applying the transient state if there's
    any. So for example a `.protocol_parameters()` will first look at
    any available governance update, and if any, use that in priority.

    Similarly, when consulting the balance of an account, we would first
    have to look for any unapplied rewards.

  - Refunds and withdrawals from governance are not checking that
    accounts still exists. They simply stash the update. But in
    practice, like for pools; we would also need to send uncollected
    money flow to the treasury. Same for pool refunds.

  - More importantly, updates are not currently flushed to disk. That
    crucial part is missing and will happen in a future commit. The plan
    for now is to do it "naively" and flush all updates at once as soon
    as we enter the stable part of the epoch. Later, we can split the
    update over multiple slots to avoid keeping the ledger busy for too
    long.

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]>