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:
- Agents can detect when the system reaches an undesired (but valid) state
- Agents can submit a valid witness
- The system accepts the witness and (partially) corrects the state
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:
- If there are no detectable witnesses, then the system is completely correct.
- After submitting a witness
wand the systems is (partially) corrected, then the witnesswis not a witness of the new system. - It is always possible for agents to detect when the system state is not valid.
- It is always possible for agents to submit witnesses.
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.
- registered_id : OperatorId
- registered_nd : Tokens.Elem.TId
- anchor : Tokens.Elem.TId
- duplicated : OperatorDirectory.State.WitnessStatus
Instances For
Valid witnesses:
- Duplicated registered elements are actually different tokens. In the case we have duplicated registered nodes. When we have a registered and retired or active, it is not necesary since they belong to different lists.
Equations
- OpsDir.OptimisticWitness.valid_witness_dup w = match w.duplicated with | OperatorDirectory.State.WitnessStatus.Registered dup_tid => w.registered_nd != dup_tid | x => true
Instances For
- And anchor is valid anchor (tokens cannot be anchor of themselves.) We cannot remove nodes that are anchor of themselves.
Equations
Instances For
Fraud Detection function #
The goal of this section is to define a procedure such that it returns:
.noneif no fraud was detected, orsome Witnessin the case of founding duplicates or intersection between the lists.
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.
- opId : OperatorId
- reg1 : Tokens.Elem.TId
- reg2 : Tokens.Elem.TId
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
- One or more equations did not get rendered due to their size.
- OpsDir.OptimisticDetection.find_duplicate_register [] = none
- OpsDir.OptimisticDetection.find_duplicate_register (none :: rest) = OpsDir.OptimisticDetection.find_duplicate_register rest
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.
Equations
Instances For
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
- One or more equations did not get rendered due to their size.
- OpsDir.OptimisticDetection.find_witness_cross dup [] = none
- OpsDir.OptimisticDetection.find_witness_cross dup (none :: rest) = OpsDir.OptimisticDetection.find_witness_cross dup rest
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.
The following procedure, find_witness, does the following.
- Check for duplicated Keys in Registered Ops Dir. 1a. If True, .DupReg ...
- If False, Checks Act ∩ Regs 2a. If True, .InterAct ...
- If False, checks Ret ∩ Regs 3a. If True, .InterRet ...
- If False -> .none
Equations
- One or more equations did not get rendered due to their size.
Instances For
The result of finding a witness is a valid witness.
The witness we found has a valid anchor and thus we can eventually remove the fraudulent operator.
The witness we found shows membership of the duplicated key.
The witness is a valid token in the registered operator directory and has a valid anchor.
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.