Documentation

FMMidgard.OperatorDirectory.Props.OptimisticRegProps

Registered Operator Queue No duplication and No Intersection with Retired and Active. #

Properties listed here are optimistic: operators can brake the invariant, but they must pay the price for it.

The methodology we use to prove these properties is:

The system may not be fully but partially correct, i.e. there may be several ways to correct the system and there may be several duplicated nodes.

However, we would like to prove the following properties:

The last two properties are assumptions here, but should be checked somewhere else.

Optimistic Properties. #

Since we cannot directly prove liveness properties as agents actually submitting proofs, we just prove that the such actions are always enabled. For example, the action of submitting a valid witness is always enabled.

def List.filter_cons_p {α : Type} {l rs : List α} {p : α → Bool} {r : α} (h : filter p l = r :: rs) :
p r = true ∧ r ∈ l
Equations
  • ⋯ = ⋯
Instances For

    A Witness presents a registered node whose key (opId) also appears in one of the other lists:

    Valid witnesses:

    Fraud Detection function #

    The goal of this section is to define a procedure such that it returns:

    This procedure defines what we mentioned earlier as the possibility to detect fraud.

    Duplication Detection. #

    Duplicated register operator witness. A valid duplicate it is different from the previous one.

    Instances For

      Definition of finding duplicates by finding the first duplicated key in the registered operator directory starting from the beginning. Returns two Token ids and the key they both share.

      Equations
      Instances For

        The definition of find_duplicate_register as a property. This is valid for well-built lists, i.e. lists holding the reachable predicate RechableUList.

        If we do not find anything, then all tokens have different key.

        Intersection Detection. #

        We use this to detect when a registered node is also in either of the other two lists.

        The following procedure finds if there is a token in the two list with the same key. We use it to find elements belonging to the intersection of to Midgard Lists.

        Equations
        Instances For

          Correctness of find_witness_cross . The finding is composed of to two tokens each one showing membership of the same operator's id opId on both lists.

          If we cannot find a witness, the two lists do not share any key. We write it as: all keys alive in dup, do not have a token in rem

          If we cannot find a witness, the two lists do not share any key. This is the symmetric of the above.

          Computation of the Optimistic Properties #

          We check the try in one go. We could also have split it into different procedures.

          Instances For

            The following procedure, find_witness, does the following.

            1. Check for duplicated Keys in Registered Ops Dir. 1a. If True, .DupReg ...
            2. If False, Checks Act ∩ Regs 2a. If True, .InterAct ...
            3. If False, checks Ret ∩ Regs 3a. If True, .InterRet ...
            4. If False -> .none
            Equations
            • One or more equations did not get rendered due to their size.
            Instances For

              The witness we found has a valid anchor and thus we can eventually remove the fraudulent operator.

              If we found a duplicated in the registered op list, then the duplicate also belongs to the registered list.

              If we found a witness pointing to an active operator, the the operator is a member of the active list.

              If we found a retired witness, then we can also show membership in the retired list.

              However, if we do not find any witness, then there are no duplicated keys in the registered list, nor there is any intersection between the registered and active; and the retired and active lists.

              Generate FraudProof from detected fraud. #

              Once we detected fraud, we found a witness, we generate the corresponding action.

              Agents are enabled to submit fraudproof. #

              Fixed After FP. #

              We cannot say that we reached a valid state after submitting a FP. But we should be able to prove that we cannot generate the same FP (or witness.) In other words, the state is invalid in a different way.

              If condition is not met, then it is not possible to submit a FP. #

              [Alternative] Monitors. #

              The above approach computes the possiblity of detecting witnesses at any state. However, we can write a monitor detecting when new operators register, activate or retired.

              In other words, we can write a monitor checking keeping track of the evolutino of the system, analyzing actions as they come, detecting duplicates, generating witnesses and submitting them to Midgard.

              We leave this approach for future implementations, although all components required to define such monitors should be here.