Optimistic Network
A Network of a Warrantor (Collateralized) Node & Detector Nodes
In the Threshold Network section, Muon's first security strategy is discussed. A second network that Muon offers its users is its Optimistic Network.
Optimistic Oracles
In an optimistic network, the signed data is obtained from a single oracle, called Initiator, and is then published on-chain. One has to wait for a predefined period of time (for instance 15 minutes) to see whether other nodes in the network disapprove it. No oracle’s disapproving the data means all oracles have actually verified it. This way, with the cost of verifying only one signature, we gain the same security level as the verification of the whole network.
To guarantee the validity of the data and to make sure other nodes have sufficient time to check the signed data and disapprove it if they find something malicious, the Initiator is required to lock an amount of collateral. This way, the data published by the initiator can be immediately used, but other oracles have the waiting time to place disputes and request slashing the collateral in case of any malicious activity.
Muon's Optimistic Network
Muon's Optimistic Network is still under development and will soon be released. It is made up of two components:
Warrantor Nodes: These nodes lock collateral, and respond to users' data requests. The amount of the locked collateral should correspond to the value of requests.
Detector Nodes: These supervise Warrantor Nodes' activities and place disputes if they spot something malicious. To place a dispute, a Detector is required to lock collateral.
The node that places the dispute needs to lock an amount the same as the locked collateral. Until the dispute is resolved, neither of the parties can unlock their locked collateral.
NB: This network can only be applied by dApps whose requests have two characteristics:
The requested data should be deterministic; that is, the data can be reevaluated over time. This is essential for Detector Nodes to be able to access and assess the data signed by the Warrantor Node.
The request should be of the kind which can be valuated. This is because the value is needed to determine the amount of the required collateral so that in the case of a malicious activity, the user’s loss can be refunded.
Requesting Data from Optimistic Network
Here are the technical details of how Muon’s Optimistic Network works:
A user initiates the process by entering the necessary input into the dApp client. Based on the user’s request and input data, for instance amount of a requested loan or tokens to bridge, the dApp client calculates the value of the request. After the request is evaluated, the dApp client sends a query to Muon Monitor Service.
The job of Muon Monitor Service is to provide an API for clients to be able to know how much available collateral each node holds. It collects this information from Muon’s Collateral Contract on different chains and sends it to the dApp client.
When the dApp client receives the list of nodes with sufficient collateral to respond to the request, it chooses one of them and sends the request to it. The node returns the signed response to the dApp client which, in turn, sends the transaction to its smart contract to execute the request.
At this stage, the dApp’s smart contract calls a lock-collateral function on Muon’s collateral contract. The lock-collateral function’s parameters include the address of the node that is to lock the collateral, the token and the amount to be locked, and the node’s signed response. The amount of collateral to be locked is determined based on the user’s request received by dApp’s contract. For example, if the user requests a $10k loan to a lending platform, the amount of collateral to be locked is $10k.
If the node has sufficient available collateral, the collateral contract locks the corresponding amount. Then it emits a review-request event including all the info in the signed response so that all other nodes can review the info. The response on whether or not the collateral has been locked is then returned to dApp’s smart contract. If the response is true, the dApp’s smart contract finalizes the user’s request.
The following sequence diagram demonstrates these steps visually:
In the next phase, in order to make sure the data is valid, Detector Nodes have a predefined amount of time to review the event and check the parameters that the node has signed. If they detect a malicious activity, they place a dispute which triggers a dispute-resolution process.
Last updated
