Open yondonfu opened 5 years ago
One way to implement a reserve for a set of committed subregistries is to have a contract keep track of a reserve per subregistry. I'll refer to this as the "multi-reserve approach" For example, if B commits to us-east
and us-west
, then the contract would keep track of the reserve for us-east
and us-west
separately. Then, when B wants to withdraw the reserve for us-east
(perhaps because it no longer wants to use this subregistry), it will initiate an unlock period of N blocks and after this period completes it will be able to withdraw the us-east
reserve without affecting any interactions B is having with members of the us-west
subregistry.
Another way to implement a reserve for a set of committed subregistries is to have a contract keep track of a single reserve which is sliced into allocations for each committed subregistry. I'll refer to this as the "single reserve approach". Below is a sketch of each of the operations involving the reserve:
Commitment
(subregistryAddr, subregistryMaxFloat)
Payment authentication
us-east
us-east
was included in B's on-chain commitmentsubregistryMaxFloat
for us-east
Reserve liquidation
us-east
) a set of winning tickets with a cumulative face value of X < orchestratorMaxFloat
us-east
was included in B's on-chain commitment along with the winning ticketsus-east
This construction would be simpler if we disallowed partial reserve withdrawals - if B wants to withdraw its reserve, it has to withdraw its reserve for all of its committed subregistries. This comes at the cost of worse UX. Below is one way to do partial reserve withdrawals:
us-east
us-east
was included in B’s on-chain commitmentsubregistryMaxFloat
amount for us-east
for N blocks by storing the hash of the Merkle proof as withdrawalID
and the withdraw block for the amountwithdrawalID
to withdraw subregistryMaxFloat
amount for us-east
. The TicketBroker marks withdrawalID
as completedIf this type of partial reserve withdrawal is allowed, then the payment authentication protocol would need to be modified to have O also check with the TicketBroker that a given Merkle proof was not already used to initiate a partial reserve withdrawal.
The upside of the single reserve approach is improved on-chain efficiency (less tx costs due to minimal storage operations) for committing to multiple subregistries. The downsides are increased protocol complexity especially with partial reserve withdrawals and possible increased latency in the end workflow if O has to not only verify a Merkle proof and also check if the Merkle proof was used for a withdrawal [1].
[1] This downside might be mitigated if O is caching data. Ex. O can cache the Merkle root for B's reserve and cache Merkle proofs used by B to withdraw as they are submitted on-chain. Then, O would just need to execute local database reads for verifying the Merkle proof and checking if the Merkle proof was used for withdrawal instead of sending network requests to do contract reads.
Based off of discussion with @ericxtang and @j0sh
Suppose Os can be grouped into bundles based on a category such as geographic location. From a global registry of Os we can derive a number of subregistries for each of these categories. Each of these subregistries would have a fixed number of slots for Os. If we define a global
orchestratorMaxFloat
as mentioned in #18 then we can derive the max float for the entire subregistry assubregistryMaxFloat = max subregistry size * orchestratorMaxFloat
.A B can commit to subregistries (the word "subscribe" has also been used, but I'll stick with the terminology from the recipient set commitment construction for now) in order to work with Os in the subregistries. B does not have to worry about the actual membership changes in the subregistry as long as the subregistry has a fixed number of slots - if this is the case then
subregistryMaxFloat
will always remain the same given a constant globalorchestratorMaxFloat
.B's reserve is sliced into allocations for each committed subregistry. Then each committed subregistry allocation is further sliced into allocations for each O in the subregistry.