Cardano Updates

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

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

Signed-off-by: Arnaud Bailly <[email protected]>

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

  It makes more sense for this logic to live in the ledger since it's about ... decoding the ledger state (albeit, the Haskell's one).  I've extracted some of the base types to the Kernel, though.

  Also, moving this piece of code to either the ledger or the store would introduce undesirable dependencies there (i.e. 'indicatif'). So we now have to add an indirection through a trait, to ensure that we only introduce shiny progress bars when executing this in the terminal. For testing, we can simply display no progress whatsoever (other than what the test runner provides).

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

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

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

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

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

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

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

Signed-off-by: William Hankins <[email protected]>

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

  The logic was a bit all over the place, to the point where we juggled between inconsistent data-structures and felt to clearly show the validations. Putting chunks of validations into smaller functions help making those incoherences more visible, makes the code more readable and also, more efficient as we can avoid re-doing the same steps multiple times.

  Note that I didn't touch the part that's collecting the redeemers, because I know someone else is currently touching part of this code, and it would create needless conflict at this point, but I intend to.

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

  This is only pushing the problem to later, but the 'end' bound of the
  last era summary is actually dynamic and changes every time we gain
  confidence that there will be no hard fork in the next epoch.

  We'll need some logic to handle this ever evolving era boundary. For
  now, I am simply bumping this manually to get the synchronization
  further than epoch ~207, where time horizon errors start occuring.

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

This is weird. Let's talk. Here's a simplified version of the situation:

To verify witnesses, the Haskell node creates two sets:

1. One contains all "public key hashes" collected from looking at addresses.
2. The other contains all "public key hashes" collected from the both the (normal) verification key witnesses, and the bootstrap witnesses.

However, Byron addresses do not contain public key hashes; but a "root", which is a double-hash of some CBOR structure (which somewhere inside, has a public key; but it is impossible to retrieve it from a 'root').

Also, when collecting witnesses, what's being collected in the case of bootstrap witnesses aren't public key hashes, but those re-computed roots.

Now the problem is that this puts in a set (in either case), two objects that have different semantic, and treat them uniformly; all because they are structurally equivalent (28 bytes of data).

Yet, one can now artifically craft a Byron addresses that holds a public key hash instead of a root; and still spend from it by providing a normal verification key witness. From the outside, the transaction appears as missing bootstrap witnesses, but internally, since both witnesses types are conflated, this is approved by the node.

This phenomenon can be witnessed ( :D ! ) on the following PreProd transaction:

- 0c22edee0ffd7c8f32d2fe4da1f144e9ef78dfb51e1678d5198493a83d6cf8ec

which is spending from what looks like Icarus addresses (i.e. gen 2 bootstrap addresses), but doesn't contain any bootstrap witness whatsoever. It does however contains a normal signature witness (even though it's not spending from any standard pub key address). If we hash the key for that witness, we indeed find the root within the address.

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

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

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

Signed-off-by: William Hankins <[email protected]>

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

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

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

  Funny enough... this doesn't solve the problem I was originally chasing. I wrongly assumed that was the cause, but looking further into the transaction, it seems that there's simply no script being executed in the transaction. So, there shouldn't be any required datum to begin with.

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

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