Documentation

FMMidgard.ProofProtocol.Tokens

Proof Protocol #

Proof protocol is simply a mechanism converting /Successful Fraud Proof Computations/ into /Fraud Proof Tokens/ checking names and policies to guarantee that computations belong to the same Midgard instance.

We simplified the model a bit. Although Computations were implemented, we preferred to implement the logic first and then the interactions between the different models..

I added information to the FraudProof Tokens that are not in the spec.

In the spec, the Midgard protocol checks the computation hashes to get the correct block, here we use block identifiers. The main reason is that hash functions are not implemented.

FPData are simply block ids replacing the hash checking mechanism in the Midgard protocol.

Instances For
    @[reducible, inline]

    FPTokens are tokens carrying this information.

    Equations
    Instances For

      Computation Thread Simulation #

      To generate tokens, we should go through the process of generating a computation thread token, splitting the fraudproof computation into several steps, and if the computation ends properly, then we can generate a FraudProof Token.

      Since we value more checking the logic of FraudProofs than the interaction with the computation threads, we simplified the computation threads and implemented the FP logics directly in Lean.

      We simplify the implementation by using inductive types. These steps need to be implemented using computation threads splitting big computations. In this model, we skip the computation splitting and define them straight in the logic of the protocol.

      Actions #

      We only have one action which is to mint a new token. We need to provide a valid computation_thread (something we check in the relation.)

      Relation #

      Computation #

      StepMachine #

      Product Relation #

      I define the following machine trying to keep the other two as clean as possible.