bh2smith
commented
5 years ago In your opening paragraph;
Withdraws requested on a state s_1, will only be able to be processed once the finalization for s_1 has happened. If the system would process them before that and then a fraud-proof reverts the state s_1, the withdrawal might no longer be eligible as the account might not have sufficient balance for it.
I believe we should use the term "claimed" since the state transition is the act of "processing" a batch of requests.
fleupold
Motivation:
Any snapp/roll up implementation based on fraud proofs will have a finalization period. During the finalization period, any state transitions can be proven incorrectly by submitting fraud proofs on-chain. Withdraws requested on a state s_1, will only be able to be claimed once the finalization for s_1 has happened. If the system would allow to claim them before that and then a fraud-proof reverts the state s_1, the withdrawal might no longer be eligible as the account might not have sufficient balance for it.
In general, we do want to have preferably longer finalization periods in order to increase the security of the system. However, for rebalancing traders accounts and for the user experience faster withdrawals are needed.
Description of current withdrawals: Currently, any registered user in the snapp base contract can request a withdraw with an ethereum transaction. Once his withdrawal request is registered in the contract, it is required to be processed by the snapp-system. Once it is processed, the balance of the user is adjusted by his withdraw amount and a withdrawal-Merkle hash is stored on-chain. This withdrawal-Merkle hash is the root-hash of the tree with leaves constituted of the (withdraw-address, withdrawal amount). Then after the finalization period, the person withdrawing can make a Merkle proof of for this withdrawal amounts and withdrawal address and thereby claiming his withdrawal request.
Fast withdrawals:
The following concept can reduce trustlessly the waiting time between the withdraw-hash submission from the operator and the end of the finalization period.
A withdrawing person willing to pay a small fee for a faster withdrawal will be matched with a lender. The matching will happen via a so-called fast-withdraw-contract.
While there are many concepts possible, here is the description of one concept, which does not require any changes to the current snappbase, and can be deployed completely orthogonal to the current infrastructure.
Users are depositing first their coins into the fast-withdraw-contract and then this contract will do the deposit into the snapp base contract. Then the users can do their usual trading. Once they do the withdrawal requests, the withdrawal requests are pointed towards the fast-withdrawal-contract. If their withdrawal is confirmed by a withdrawal-Merkle hash, then they can request a fast withdrawal at the fast-withdraw-contract. In case they do not request any fast withdrawal, they will just later be able to withdraw their coins from the fast-withdraw-contract. In the case they are willing to pay for a fast withdraw, they will trigger the fast-withdraw-contract with a specified fee. Now, any lender can check whether
In case both checks are valid and the fee is high enough, the lender will provide the coins for a quick withdraw by sending the coins to the user withdrawing through the fast-withdraw-contract. As an exchange, the fast-withdraw-contract will make sure that exactly the amount of lent coins plus a small fee will be directed to the lender, once they can be withdrawn from the snappbase. This concept does not assume any trust, as the lender knows for sure that the fast-withdraw-contract will receive the coins requested for withdrawing after the finalization period, because he can trigger the withdraw on his own.
Ideas for improvement: -It would be favorable if there would be a market price and not just individual prices for each withdrawal. This could be reached by lending pools similar to compound pools. (not yet thought through)