Documentation

FMMidgard.StateQueue.State

State Queue Module State #

It keeps a key-unordered list of block.

The key of each node is the block header hash, so keys are basically unique for each block. Since each block refers to the previous one, we cannot/shouldn't have the same block hash. In the spec, this field is added for simplicity, but it may be crucial?

Since it interacts with the operators directory, we need to keep track of the ops dir state too.

Structure ConfirmedState is a temporal fix? for when merging confirmed states to the history of Midgard. When merging, the spec leaves unspecified some fields, mainly the root of txs/withdrawals/deposits merkle trees. It makes sense, but it is not very nice to leave them unspecified.

Instances For
    Equations
    Instances For

      Blocks with an additional identifier id. Identifiers serve as a temporal replacement for hashing functions (which we are trying to avoid for now.)

      Instances For

        Hashing is just returning the hash in the structure. This way we keep it local.

        Equations
        Instances For

          To hash a block, we generate a new unique identifier.

          As internal state, we have the state queue as an heterogeneous key-unordered list. Block header keys are the hash of their headers.

          We shouldn't have duplicates. We can have duplicates, because we can duplicate entire blocks. Duplication is due to duplicating block contents, i.e. utxos, transactions, deposits, withdrawals. In this case, we should submit the corresponding FP.

          List of committed blocks starts empty. [Only root node is initialized.] Only the genesis (empty?) /ConfirmedState/ is defined.

          Actions #

          Instances For