[Protocol3] Generic Extension for Request Validation (GERV)

[Brechtpd]

This is interesting:

• https://medium.com/starkware/starkexchange-fast-withdrawals-using-cookie-jars-88eefea6a11a

This allows withdrawals before a block is proven.

I think we can do something similar like this with minimal changes:

• The user does a withdrawal (on-chain/off-chain) like usual
• The withdrawal is included in a block and the approved withdrawal data is stored on-chain (but the block is not yet proven)
• The user wants to do a fast withdrawal so requests the withdrawn tokens through the cookie jar contract, the contract checks the approved withdrawal data for the user (accountID, tokenID, amountWithdrawn), if the cookie jar has enough funds to do this transfer:
  • The cookie jar immediately sends the tokens to the user using the funds stored in the cookie jar contract.
  • The accountID in the approved withdrawal data is changed to the account of the cookie jar contract so once the block is proven the cookie jar contract receives the tokens it 'borrowed to the user

The cookie jar contract is operated by the exchange so of course the exchange trusts itself to submit a valid proof for the block. If not, the exchange loses the funds (and the user is happy because he can withdraw the funds again! User funds remain safe.).

The user probably needs to approve this somehow because this could be a security risk for users if the cookie jar contract is malicious. The approved withdrawal data could maybe include a single bit if the user allows these fast withdrawals. Or the cookie jar contract cannot be changed easily for an exchange/needs to be approved by the Loopring contract/...
EDIT: the token transfer from the cookie jar contract to the user can be done in the exchange contract which makes it secure for users even without having to trust the cookie jar contract, no approval from users needed. The only change for users is that they get their tokens earlier than they would otherwise, which is only a benefit.

Could be useful, though the number of withdrawals we can do in a single block is very limited by the approved withdrawal data because we need to store that onchain (which is expensive), currently max ~1800 withdrawals/block so the time to prove a block like this will be quite low to begin with.

[dong77]

This is a great idea. Let me write down my understanding so @letsgoustc and @kongliangzhong can understand it well.

For on-chain deposits and withdrawals, the handling of these requests can be included in blocks for ZKP when and only when there are corresponding requests on-chain. This means the on-chain requests are the "conditions" for including these Merkle tree updates in blocks, if these conditions are not satisfied (meaning there are no on-chain requests), then the Merkle tree updates cannot be created and then included in a block. we then realize: the on-chain requests need to be created first, then the offchain tree updates are created (by the operator) afterward.

The idea behind the fast withdrawal is as follows: first, a user creates and authorizes off-chain requests that represent the transfer of X tokens from the user account to the operator's account; but this off-chain requests can only be included in blocks under the condition that there is an on-chain transfer of at least X token from the cookie jar address to the user. The cookie jar address is a smart contract owned by the DEX and holds some tokens/ether just for fast withdrawals. It should also maintain a flag for each transfer to indicate if the transfer has been used. In this scheme, the conditions will always need to happen FIRST on-chain before the circuits can actually handle the requests.

The fast withdrawals are triggered by the user's request off-chain and the operator can handle it ASAP without any delay (but probably need to stop matching orders for that user) by broadcasting a tx to transfer money from the cookie jar address to the user.

Shared conditions

The above scheme requires each off-chain request to have its own on-chain condition, e.g, there is a 1-to-1 mapping. A condition either needs to have a unique id associated with the off-chain request or it should have a mutable flag managed by a smart contract to indicate if the condition has been used by an off-chain request.

It may be useful to allow multiple off-chain requests to use the same on-chain condition. For example, if we support binary options, then all the same option positions can share the same on-chain price oracle as the shared condition (it should also have a unique id associated with all positions or a flag to indicate usage). When the price oracle is not available, the corresponding positions will have to stay outstanding (open).

@letsgoustc we may be able to build a derivative sub-protocol based on such a Conditional-Inclusion of Circuits -- I like this terms better.

[dong77]

@Brechtpd, If my understanding is correct. It seems from the user's perspective, requesting fast withdrawal doesn't have to involve any on-chain transaction, but only a "conditional" off-chain request. This will make a fast withdrawal take only 1 block time.

[Brechtpd]

Yes, this will allow withdrawals in 1 block time.

There's a couple of ways this can be implemented, I'm not sure yet what's the best way. Only an off-chain request could work.

The way I described it in my first post allows any withdrawal request (on-chain or off-chain) to be a fast withdrawal without any changes to the circuits, only some additional on-chain logic to modify the approved withdrawal data. But this was just my first idea to get this to work with minimal work.

[dong77]

I see. But if we want to provide fast withdrawal, let's make it truly fast :) The idea fascinates me.

[dong77]

For fast withdrawals, one party may not have enough tokens of various types, maybe we can design the cookie jar so that anyone can create an account then create his own cookie jar...

[Brechtpd]

If you have access to extra funds, why would you put them in a cookie jar contract to get them out of the exchange faster? You already have access to those tokens, you don't get access to more tokens using this?

I think it could also be risky if the cookie jar contract is managed by someone else than the DEX itself. Let's say the off-chain balance of the user is only 1ETH, but the user requests a withdrawal of 10ETH. The DEX will not allow a fast withdrawal of 10ETH because the DEX's offchain balance can only be increased by 1ETH, so the DEX would lose 9ETH (this money is already gone with an on-chain transfer before it can be checked against the offchain state). If the DEX doesn't pay this fast withdrawal then he doesn't really need to care about this. The exchange may have to go into withdrawal mode because of this (depends on how this is implemented) but there's a risk for the cookie jar contract owner to lose money (instead of a very small risk for the DEX itself which it has complete control of).