[Protocol 3] Discussion on https://github.com/Loopring/protocols/wiki/L2-Vaults

[dong77]

Brecht, lets have some discussion here regarding your L2-Vaults.

Regarding idea number 2, do you assume the join/exit prices are controlled by us during one Loopring block time. If so, the deficit/surplus idea make sense to me. In my option, I think we have two approaches to handle defict/surplus. The first approach is batching it on L1 with flash loans; the second one is automatically cancel all pending joins/exits requests on L2 (after 1 or 2 Loopring blocktime) to zero out the defict/furplus. This is helpful when we believe batched L1 join/exit with flash loan will fail.

By "controlled", I mean the relayer will use the realtime L1 price as an oracle, then adjust join and exit prices accordingly. This will have to be done case-by-case. Some pool's token/vtoken price depends on the join/exit amount, our relayer will have a mirror implementation to simulate the price calculation, the more precise the better.

Regarding flash loan, this is my understanding:

• if we need 100 vETH on L2, we can take a flash loan of 100ETH on L1, join the pool to get 100vETH, deposit the vETH before submitting blocks; then we have a withdrawal of 100 ETH directly to the flash loan to pay back the loan.

• if we need 100 ETH on L2, we take a flash loan of 100ETH on L2, deposit to L2; then we withdraw 100vETH and exist on L1 and pay the flash loan back after block submission.

I believe a loan of Token is much easier of a loan of vToken.

Btw, I don't really get the term "Flash deposits". My understading is still a layer-1 flash loan used by deposits, but "Flash deposits are basically flash loans on L2" confuses me. Could you please clarify.

[dong77]

Now I have read your PR and I know what you mean by "flash deposits" - mint some token out of the thin air then deposit to L2, then on L1 pay it back after submit blocks.

This is great, as we don't have to borrow real asset from L1 flash loan.

[Brechtpd]

Regarding idea number 2, do you assume the join/exit prices are controlled by us during one Loopring block time. If so, the deficit/surplus idea make sense to me.

For 2) we check the actual on-chain price each time somebody does join/exit to the L2 vault. If we can directly match the deposit/withdrawal with a deposit/withdrawal in the queue we just do it immediately at the latest on-chain price. If that's not possible and we support flash deposits, we can then indeed batch settle all the remaining ones in the queue at some fixed price.

the second one is automatically cancel all pending joins/exits requests on L2 (after 1 or 2 Loopring blocktime) to zero out the defict/furplus. This is helpful when we believe batched L1 join/exit with flash loan will fail.

Cancelling is definitely the way to go when the request is impossible, but it can't hurt to leave it in the queue as long as the "slippage" the user allowed still makes it possible to ever settle. Letting the requests stay in the pool like that is always beneficial because it provides extra liquidity for the opposite operation.

If we don't do flash deposits we could still internally have "market maker orders" for joining and exiting the pool so both could be possible instantaneously instead of a single queue. So basically 2 "market maker" queues instead of single one where LPs could earn a fee by adding to these queues.

By "controlled", I mean the relayer will use the realtime L1 price as an oracle, then adjust join and exit prices accordingly. This will have to be done case-by-case. Some pool's token/vtoken price depends on the join/exit amount, our relayer will have a mirror implementation to simulate the price calculation, the more precise the better.

Yes, it will be the relayers job to match the orders at the price that is most "correct". I think for almost all pools either the token/vToken price changes very slowly (price only drifts further apart because of the interest accrued in the vault), and if that's not the case we can make an intermediate vault to make it work like that (which would also allow us to fully control when the price changes, but because we then use another token it creates extra friction so I think we should avoid doing that if not necessary). I think in most cases the token/vToken does not change depending on join/exit amounts because that should just increase/decrease the total supply.

This is great, as we don't have to borrow real asset from L1 flash loan.

A benefit of L2 where each token can basically have a flash mint built in. :)

[dong77]

Brecht, I have this idea. We can create a new L2 transaction type called Token_Convert, unlike trade and transfer, it will remove x token X and add y token Y on a user’s L2 account. Conceptually it functions like a deposit + a withdrawal but without the actual deposit withdrawal requests.

When a user, or a group of users collectively, want to convert x X token to y Y token on L2, The operator will use x Token X from the deposit contract to convert to Y tokens on L1 and credit the Y tokens into the deposit contract. In the same transaction, an onchain Token_Convert request is created. This request must be processed with a time window, otherwise the dex goes to withdrawal mode. The way to process the request is to have matching TokenConvert requests (1-to-many) on L2. If the operator did not collect enough these requests on L2, he must be the taker to do the convert.

Some pools such as uniswap will user two tokens for a lpToken, in this case, there will be two onchain TokenConvert requests with equal amount of lpTokens. On L2, the user will also have to sign two TokenConvert requests as well.

If the above transaction fail due to slipperage, nothing changed. The operator simply wasted some gas.

What the operator can do with the deposit contract fund, and to what extent, should be whitelisted and make public before it takes effects.

The benefit of this approach is that we don’t have additional cross layer transfers. Another benefit is that we will not be attacked by someone who frontruns our transactions to make our block submission fail. If that happens, we will have to stop the operator to manually recover the merkle tree. We can certainly automate this, but this is hard and we don’t have a plan to do so.

If the dex goes to withdrawal mode because of this feature, we still need a way to handle the token converts. If people claim their token X using proofs, if there is not enough x, the protocol should check all pending onchain TokenConvert requests and do the reverse conversion.

it will be even better to modify spot trade to support token convert. The only different is that token convert doesn’t have a counter party user.

[Brechtpd]

By wrapping the L1 vault in an additional intermediate vault we can be sure the block can never fail. There's a couple of ways to do that, but basically the idea is that the user first gets his share in this intermediate vault, and this intermediate vault either contains the expected tokens if the L1 conversion worked within the expected slippage or the original tokens which can then be reclaimed. This step 2 is just another simple L2 trade which can be signed together with the initial trade (at expected conversion rate or 1:1 original token), so still efficient and user friendly. Or some variant on this, I think there's multiple way to do this in practice (and there's some interesting implementation details to make this step 2 possible). The same idea also works to support multiple tokens <-> single token vaults by having multiple of these intermediate sub-vaults that work together.

It looks like funds in the deposit contract are some time at risk which I don't think is a good idea. It also looks we would have to run over these TokenConvert transactions on L1 to verify that they do what is expected which could make them quite expensive as well (similarly to how AMM joins/exits are quite a bit more expensive than simple L2 things).

In the case we have a "small" amount of funds we can freely use we can just do the requests in multiple batches if needed and would make things a lot simpler (no special cases) and safer for users in comparison.

Anyway, I'm sure we'll discuss this more today/tomorrow. :)

[Brechtpd]

More worked out example with intermediate vaults that never risks blocks being invalid:

An example with ETH <-> yETH. 100 ETH needs to be swapped to 100 yETH because users want to enter the yETH pool. So we know there are X orders open that trade between ETH <-> yETH and 100 ETH <-> 100 yETH is the batched result.

The user signs the following trades, with a/b being the ratio with the max slippage the user tolerates:

• a ETH <-> b yETH (for trading immediately on L2)
• a ETH <-> a iETH (for batching, step 1)
• a iETH <-> b yETH (for batching, step 2 and L1 conversion successful)
• a iETH <-> a ETH (for batching, step 2 and L1 conversion failed)

Block 1:

• Flash deposit 100 iETH to an account on the exchange
• Process all trades between ETH <-> iETH
• We now have 100 ETH in our account
• Withdraw 100 ETH
• Use the 100 ETH to mint 100 iETH in the intermediate vault, always a fixed 1:1 ratio
• The vault now tries to do the 100 ETH <-> 100 yETH operation using some constraints (e.g. minimum ratio is achieved with some fixed max hard-coded on-chain slippage users can count on):
  • If successful: the vault now contains 100 yETH
  • If not successful: the vault still contains 100 ETH

The pool now contains funds which can be redeemed directly by burning iETH tokens. This needs to be possible to make sure users can in all cases withdraw their funds, but is of course not the normal method to get the tokens back.

Block 2:

• Flash deposit 100 yETH/100 ETH depending on what's needed
• Depending on the success of the L1 operation:
  • If successful: use the user's orders to trade iETH <-> yETH.
  • If unsuccessful: use the user's orders to trade iETH <-> ETH.
• In all cases all minted iETH is collected.
• Burn ALL iETH at the same time so reclaim all funds in the pool (this makes sure the intermediary vault is "reset" and can be reused without any legacy failed L1 operations).
• Pay back ETH/yETH flash deposits

In theory this 2nd step isn't really needed and users could just keep their iETH, but that would unnecessarily fragment markets and could have some other problems as well I think.

Vaults with multiple tokens:
LRC+ETH -> LP-LRC-ETH:

• LRC -> iLRC
• ETH -> iETH
• L1: LRC+ETH -> LP-LRC-ETH (or not if not successful)
• iLRC -> 0.5 LP-LRC-ETH
• iETH -> 0.5 LP-LRC-ETH

LP-LRC-ETH -> LRC+ETH

• LP-LRC-ETH -> 0.5 iLRC
• LP-LRC-ETH -> 0.5 iETH
• L1: LP-LRC-ETH -> LRC+ETH (or not if not successful)
• iLRC -> LRC
• iETH -> ETH

[dong77]

I like the idea of an intermidiate vault. But the issue with the above design is that there are too many L1 or cross layer transactions per batched defi-interaction. What if we can redesign the default deposit contract to support multiple vaults without the need of moving tokens across different address?

[dong77]

How about we introduce a new tx type called Convert, its a tuple: [tokenA, amount, tokenB, minAmount, sig] which has to be validated on both L2 and L1. For example: `[ETH, 100, yETH, 100, sig] means converting 100 ETH to at least 100 yETH. Assuming the sig is valid. Now when this tx is submtted on chain, the contract will find a matching converter to process such a Convert request, the end result is either a deposit of 100ETH to the user (refund) or a deposit of at least 100yETH. On L2, we always remove substract 100ETH from the user's balance.

There is only one DeFi integration, no other token transfers needed.

The Convert request is basically an order, so this is another way of processing orders without an conterparty, or the converter can be seen as a counter party.

We do need to aggregate all such orders into one single DeFi integration onchain.

Maybe we can call it Reverse Deposits

[Brechtpd]

I like the idea of an intermidiate vault. But the issue with the above design is that there are too many L1 or cross layer transactions per batched defi-interaction. What if we can redesign the default deposit contract to support multiple vaults without the need of moving tokens across different address?

Too many L1 transactions? The overhead with the intermediate vault is very minimal because all the batching is done on L2. Ignoring the cost of an L2 trade, there's a fixed cost on-chain which I think will be 100k-200k gas for the 2 phases no matter how many users are in the batch! I think L1 costs are close to the absolute minimal possible, because there will always be some L1 overhead to correctly distribute user funds back at the correct ratio.

What if we can redesign the default deposit contract to support multiple vaults without the need of moving tokens across different address?

The tokens on L1 need to sent and received somehow to do the swap. There could be a way so that the deposit contract can do ERC20 withdrawals by doing an approve instead on the swap contract instead of a normal withdrawal transfer so funds can then be directly taken from the deposit contract without an additional intermediate transfer (if the defi contract supports something like this). Could be an optimization but would have to try it out if it's worth the extra complexity for creating these special cases.

How about we introduce a new tx type called Convert, its a tuple: [tokenA, amount, tokenB, minAmount, sig] which has to be validated on both L2 and L1

Isn't this exactly a trade but with extra work on L1? Work on both L2 and L1 always pretty expensive, just look at AMM joins/exits. Sure, just a single call and batching will help but it's hard to beat doing nothing at all on L1 for each user separately. We can batch 1000s of users at the cost of 2 trades (or 1 trade in the cases the 2 phases are unnecessary). Most things users want to interact are likely very time insensitive I think we should do everything possible to minimize costs for large batches.

the end result is either a deposit of 100ETH to the user (refund) or a deposit of at least 100yETH

Doing a deposit for each user separately would be very expensive of course. So we would have to be able to do batch deposits very efficiently. And this is actually exactly what the intermediate vault allows us to do. By giving the user a IOU or a "pending deposit" on L2 if you will in the form of a token, representing the user's share of the total batched funds. Having to process actual deposits using some on-chain mechanism will be more expensive, and because we also have to somehow know on-chain which user owns how much of the total batch makes things more complex and expensive. Seems to make sense to me to keep all of that on L2 because it's very hard to beat cost-wise, and we have all the data we need there.

The Convert request is basically an order, so this is another way of processing orders without an conterparty, or the converter can be seen as a counter party.
We do need to aggregate all such orders into one single DeFi integration onchain.

Flash deposits allow us to do this aggregation on L2 at a fixed L1 overhead cost, which will be low compared to doing the aggregation on L1. Sure, if there's only a couple of users in the batch the costs of both will be close, but once we're talking about 10s, 100s or even 1000s of users we can batch the L2 solution will be much more efficient.

[dong77]

Lets discuess it in our next meeting.

[dong77]

@Brechtpd , will this design enable another scenario: A user deposits x LRC, after only 1 confirmation, the relayer credits this deposit to user's L2 balance, hoping that when the block is ready to be submitted, the deposit has enough confirmations onchain; if the deposit was overriden by the user (cancelled), the relayer has the option to make a deposit of x LRC for the user using its own L1 assets to make sure the block doesn't have to be reverted (the relayer will only want to do it if x is small).

A variantion is that the user transfer x LRC directly to the relayer, the relayer flash-deposit x LRC to the user's L2 account, then when the block is submitted, the relayer pays back the loan using the LRC received from the user.

[Brechtpd]

will this design enable another scenario: A user deposits x LRC, after only 1 confirmation, the relayer credits this deposit to user's L2 balance, hoping that when the block is ready to be submitted, the deposit has enough confirmations onchain; if the deposit was overriden by the user (cancelled), the relayer has the option to make a deposit of x LRC for the user using its own L1 assets to make sure the block doesn't have to be reverted (the relayer will only want to do it if x is small).

Yes, this is certainly possible, a flash deposit looks the same as a normal deposit so on L2 the deposit can be processed the same way regardless of the type. In practice if the deposit already has 1 confirmation, looking at https://etherscan.io/blocks_forked, it's pretty much a certainty it won't be reorged after just 2 confirmation. The reorg depth the last days is mostly 1 and sometimes 2, and if higher ever happens it will be very rare. Of course if there are no confirmations yet anything is possible.

A variantion is that the user transfer x LRC directly to the relayer, the relayer flash-deposit x LRC to the user's L2 account, then when the block is submitted, the relayer pays back the loan using the LRC received from the user.

So a custodial way to deposit? The only benefit here is that the deposit would be ~25k gas cheaper right? But yes, certainly possible, a couple of different ways this could be done depending on what ends up being cheapest.