Operators Directory Properties. #
The properties listed in this file are not optimistic. The invariants listed here are invariant/properties of the Operator Directory module.
List Invariants. #
After detecting possible violations on one of the basic building blocks: key-unordered singly linked lists. Here we proposed a new property checking that the list is kept connected
Connected means that there is a path from root to last involving all tokens in existence. In particular, this property prevents operators to be left as dangling nodes. Dangling nodes cannot recover their bonds.
The following definition states the desired property.
Equations
- OperatorDirectory.Properties.ListConsistency.ConnectedList opdir = ∃ (ls : List Tokens.Elem.TId), Paths.Traversals.CompleteTraversal ls opdir.registered = true
Instances For
To prove it, we used a trace generation to find counter-examples.
See FMMidgard.DataStructures.List.SimProp+160.
In this case, it means that a reachable OperatorsDirectory state, contains
reachable states on each of its lists.
Actions Pre/Post condictions and Properties. #
Activate Properties. #
Activate opDir ! .Activate tkn anch ↝ opsDir' conditions are:
Tokens exists. In Cardano is proved by showing them, in our representation, it is enough by /presenting/ their ids.
Token
anchis anchor fortknproven byopDir.registered.is_anchor tkn anch. For this to be a valid proof,tknandanchmust exists (first bullet.)Because we use the Activated queue, and activated is sorted, we known that the key of
tknwas not activate and now is. In symbols, we haveopDir.registered.get_key tkn ∉ opsDir.activeand⟨opDir.registered.get_key tkn , .none ⟩ ∈ opDir'.active.
Equations
- One or more equations did not get rendered due to their size.
Instances For
After activation we insert a node in the active list with the same key
Activating a node removes it from the registered list
We cannot activate operators using themselves as anchors.
Activation of no-retired operators.
Activation does not modify retired operators.
Activation removes a registered operator, modifies it's anchor properly, and all other registered operators remain the same.
Retiring Properties. #
Retiring removes an operator from the active list.
Retiring operators adds the retiring operator to the retired ops list.
Retiring operators do not modify the registered list.
Register Operators #
Registering operators do not modify the active list.
Registering operators do not modify the retired list.
Registering operators add an operator to the end of the list, all other registered operators remain the same but the last, now leading to the just added operator.
Registering operators prepend operators into the registered operators list.
Deregister Operators #
Deregistering operators do not modify the active list.
Deregistering operators do not modify the retired list.
Deregistering removes an operator from the registered list, all but the anchor remains the same, the anchor node is updated properly.
Remove Duplicate Propes #
Removes Duplicate operations do not modify the active list.
Removes Duplicate operations do not modify the retired list.
Removes Duplicate operations remove a regiseterd operator.
Active Remove Bad Operator #
An active operator is removed.
Registered list is not modified.
Retired list is not modified.
Update Bond #
If we updated the bond of an operator, then transaction infomation i has
it's transaction interval upper bound defined and we updated the bond hold
variable properly: upper_bond + maturity_duration.
Update pond does not modify the active members. It does not add nor remove members, just modify the data of one of them.
Update pond does not modify the registered operators list.
Update pond does not modify the retired operators list.
Recover Bond #
Active operators list remains the same.
Registered operators list remains the same.
The operator recovering it's bond is removed from the retired operators list.
Remove Bad Retired Operator Props #
The active operators list remains the same.
The registered operators list remains the same.
The bad retired operator is removed from the retired operators list.
Registered Operators Queue #
Inv Registered Operators time is GT #
From the spec document, it seems the Midgard designers assume time increases when operators are registered. This is false, since within a certain range, users can set the transaction validity interval bounds of each transaction.
In particular, this affects the activation criteria. See issue Registered Operators Eligible for Activation Criteria and Scheduler Rewind
The scheduler only checks the time of the oldest operator registered (by it's position in the registered list.), but there may be operators eligible for activation.
Operators can register themselves.
Provided: operator sends bond and sets a valid transaction validity upper bound. Inv: [](Enabled(∀ op, <op>.Register))
This is part of Register and Activer Operators invariant in the spec.
Registered node can be activated if its waiting activation time has passed.
Requires: Operator is not already activated nor retired. Inv [](ActivationTimePassed(t) -> Enabled(.Activation t))
Registered operators can de-registerd whenever they want.
Inv: []( p ∈ Registered -> Enabled(Deregister(p)))
Activated operators list is decr-sorted.
Active operators can retire whenever they want.
[](p ∈ active ∧ p ∉ retired -> Enabled(Retire(p)))
We proved that if we are in a reachable state Active and Retired lists are disjoint lists.
We detected that there are no restrictions when it comes to retire operators. See issue Anyone can retire active operators.
Active and Retired ops lists are disjoint.
Equations
- One or more equations did not get rendered due to their size.
Instances For
There are not active and retired nodes