[review] MIP-58: Lock/Mint-type Bridge Design

[Primata]

Summary

MIP-58

[andygolay]

Looks like a good start. I agree a simpler design could be better. Adding more technical details include code samples and diagrams would make this more of a proper MIP and help reviewers evaluate the design.

[andygolay]

One great thing about this design from a product perspective is that it removes refunds (cc @rolandoesparza). Because we've changed the HTLC bridge to have only the relayer be allowed to refund, we might as well simply have the relayer complete transfers as a matter of obligation. Refunds are inherently negative and something essential for businesses to minimize. Not offering refunds at all, but instead guaranteeing a successful swap, will result a more net positive user experience in general.

[0xmovses]

Thanks for linking this and cool to see, but I only see one con in the HTLC protocol :

This method is trust minimized, but requires both parties to stay online for the duration of the swap in order to withdraw funds on the other side, which can cause friction for end-users.
It seems that each design has some pro and some con.

Again this was known from the very start. Agree tho that block confirmation time was not fully considered. I do remember discussing with Boy, some limit of a few blocks to wait before continuing.

[Primata]

yes, but it still has to be indicated. I don't think a lot of people knew what it entitled as we were developing it.

[apenzk]

please write out what is the problem of this example (what is being demonstrated). the reader (us) should not need to go to the link to learn about the TLDR

[apenzk]

As per committee agreement, merging will go ahead without addressing this comment. Please consider to raise an issue if this is of concern @Primata

[0xmovses]

Bar my nits with some of the motivation points, I think this MIP has value and we should consider shipping it for mainnet.

Without block-confirmation-wait HTLC was working well. With that wait, because of the signing required on the L2 it adds significant bad UX hurdle, which I think users wont like. I've been thinking about this a lot and I think it may be worth shipping this soon.

The changes proposed are not dramatic and are just removals of functionality and with some new testing.

cc @musitdev & @franck44

[andygolay]

Bar my nits with some of the motivation points, I think this MIP has value and we should consider shipping it for mainnet.

Without block-confirmation-wait HTLC was working well. With that wait, because of the signing required on the L2 it adds significant bad UX hurdle, which I think users wont like. I've been thinking about this a lot and I think it may be worth shipping this soon.

The changes proposed are not dramatic and are just removals of functionality and with some new testing.

cc @musitdev & @franck44

Regarding bad UX with the HTLC model, if Movement is completing refunds on Ethereum, then that's bad for Movement financially and users still won't be happy, because they lost their L1 fee to initiate their transfer and they didn't get to play on L2.

Given that the decision has been made for the HTLC model to restrict refunds (and transfer the fee) to the relayer, and because users refunding themselves on L1 would also be a bad experience due to losing an Ethereum transaction fee twice, it makes sense to eliminate refunds completely and instead guarantee successful transfers and a positive user experience.

The trust assumption of the relayer not being compromised is present in both the HTLC and Simplified Bridge Design models. So there doesn't appear to me to be much difference, security-wise, other than this design having fewer potential variables such as needing to relay Locked events.

[apenzk]

please provide a more descriptive title. E.g. "whatever-type-of-bridge this is" or "Non-HTLC-based Native Bridge"

[Primata]

I would simply call this a Rate Limited Relayer

[apenzk]

I would simply call this a Rate Limited Relayer

I see you accepted trusted-relayer focused Bridge.. Lets run with that until better name.

The relayer is also limited in the HTLC-type bridge.. it is not descriptive of this solution.

[apenzk]

it makes sense to eliminate refunds completely and instead guarantee successful transfers and a positive user experience.

@andygolay refunds cannot be eliminated. consider the L2 is down for an extensive time and Mvmt would have to accept to refund.

However with this design it is in Mvmt's decision space to call it when refunds can be issued rather than timeouts. Moreover, the refund can be selected to happen when gas price is reasonable n L1.

[andygolay]

it makes sense to eliminate refunds completely and instead guarantee successful transfers and a positive user experience.

@andygolay refunds cannot be eliminated. consider the L2 is down for an extensive time and Mvmt would have to accept to refund.

However with this design it is in Mvmt's decision space to call it when refunds can be issued rather than timeouts. Moreover, the refund can be selected to happen when gas price is reasonable n L1.

If the L2 is down for an extensive time, then there is no Movement network for that time. If that were to happen, then bridging should be halted until the network is back up.

When the Movement network is back up, swaps can resume, including completing, on L2, the backlog of transfers initiated on L2.

If refunds are not offered by a business, then the business is not obligated to process refunds as long as they deliver the product that they have offered according to the associated Terms and Conditions users agree to.

Unless the Product team aka @rolandoesparza and @bhenhsi have decided this, then it's not a research or engineering decision whether to eliminate refunds or not. It is a business decision.

If the L2 is down for an extended time, then that would mean the business is obligated to keep a record of transfers initiated on L1 which have not been fulfilled on L2. When the L2 is up again, then transfers must be completed on L2.

To be clear, there are no refunds in MIP #58. So yes, if Movement chooses a model that eliminates refunds, and operates ethically and faithfully as a business, then refunds can be eliminated, assuming eventually the L2 will be up again. If the L2 is never up and usable again after some downtime, then that's a much more catastrophic event, beyond the ability of any bridge design to fix.

[apenzk]

referencing from different conversation channel regarding refunds:

I propose we only complete, because once a bridgeTransferId has been done, it cannot be redone.

Regarding refunds, here are two paths forward:

1. Do not refund. The user has to wait until the relayer and/or the L2 chain are live again and the transfer can be completed. This is clearly pointed out in the UX: "No refunds!". Transfer will be handled eventually. For this the relayer has to make sure that a bridgeTransferID was successful. Hence bridgeTransferId should increase +=1 . We will have to keep track on L2 what is the lowest bridgeTransferId that has not been processed. Need to 100% ensure the relayer CANNOT forget any bridgeTransferId and that it can read from the L2 chain (on-chain!) where the oldest non-completed bridgeTransferId is. This is because the relayer does NOT have memory (it can crash).

2. Refund but do so conservatively. This is risky! the relayer MUST send a cancel message to the target chain. It cannot trust itself so it must know that the L2-cancel-message is recorded on-L2-chain BEFORE it can refund on L1. If this is not possible (L2-chain is excessively dead) we MUST ensure that the relayer will not send a L2-complete message on L2 nor that there is a L2-complete message in the L2 mempool. This is hard.

Note that the bridgeTransferId +=1 works because we only consider L1-final blocks. If reorgs would happen this does not work and it could lead to double spends.

All of the above is symmetrical for L2->L1 transfer.
Consequently, we must have the same non-reorg requirement for L2.

[andygolay]

referencing from different conversation channel regarding refunds:

I propose we only complete, because once a bridgeTransferId has been done, it cannot be redone.

Regarding refunds, here are two paths forward:

1. Do not refund. The user has to wait until the relayer and/or the L2 chain are live again and the transfer can be completed. This is clearly pointed out in the UX: "No refunds!". Transfer will be handled eventually. For this the relayer has to make sure that a bridgeTransferID was successful. Hence bridgeTransferId should increase +=1 . We will have to keep track on L2 what is the lowest bridgeTransferId that has not been processed. Need to 100% ensure the relayer CANNOT forget any bridgeTransferId and that it can read from the L2 chain (on-chain!) where the oldest non-completed bridgeTransferId is. This is because the relayer does NOT have memory (it can crash).
2. Refund but do so conservatively. This is risky! the relayer MUST send a cancel message to the target chain. It cannot trust itself so it must know that the L2-cancel-message is recorded on-L2-chain BEFORE it can refund on L1. If this is not possible (L2-chain is excessively dead) we MUST ensure that the relayer will not send a L2-complete message on L2 nor that there is a L2-complete message in the L2 mempool. This is hard.

Note that the bridgeTransferId +=1 works because we only consider L1-final blocks. If reorgs would happen this does not work and it could lead to double spends.

All of the above is symmetrical for L2->L1 transfer. Consequently, we must have the same non-reorg requirement for L2.

As someone who owned and ran a successful web2 business for 4 years without offering refunds, I'm biased, but strongly in favor of option 1. Do not refund. With very clear messaging upfront as you mention. It results in a more positive experience all-around, when the end result is pre-determined to be a successful outcome.

Refunding is a failure outcome in this context, of bridging from an expensive L1. It still means users lost fees on L1 and didn't get to play on L2. So I think guaranteeing a successful bridge outcome is a better option.

[Primata]

| src/NativeBridge.sol:NativeBridge contract |                 |         |        |         |         |
|--------------------------------------------|-----------------|---------|--------|---------|---------|
| Deployment Cost                            | Deployment Size |         |        |         |         |
| 1076243                                    | 4822            |         |        |         |         |
| Function Name                              | min             | avg     | median | max     | # calls |
| batchCompleteBridgeTransfer                | 8323            | 1213444 | 58500  | 5167717 | 512     |
| completeBridgeTransfer                     | 3057            | 13236   | 3305   | 63101   | 1535    |
| initialize                                 | 123865          | 123865  | 123865 | 123865  | 3       |
| initiateBridgeTransfer                     | 2531            | 56637   | 10385  | 157151  | 768     |
| noncesToIncomingBridgeTransferIds          | 524             | 524     | 524    | 524     | 12104   |
| outgoingBridgeTransfers                    | 970             | 970     | 970    | 970     | 256     |

[0xmovses]

@apenzk

I'd go with option 1.

Do not refund. The user has to wait until the relayer and/or the L2 chain are live again and the transfer can be completed. [...]

[franck44]

HTLC is used for atomic swaps. Chainlink has an explainer for atomic swaps.
HTLC-bridges are used to implement atomic swaps between parties that do not trust each other.
HTLC is not largely abandoned (see the link above).
The problem is that we have used an atomic swap architecture RFC-40 to guide the implementation of the bridge.
But a bridge (transfer) is different to a swap: in a swap parties can withdraw from the deal before the end of an agreed period. They also have to escrow funds.
In a bridge, one party wants to transfer assets from one chain A to another chain B.
Most bridges implement a lock/mint or mint/burn mechanism, not an atomic swap.

[franck44]

I don't see how the first link demonstrates the pitfalls of such approaches.
The first link is outdated (in fact it was not used by Consensys, but rather GPACT was considered, and then abandoned).
The second link Crosschains, where are we now is an overview of the cross chain solutions and their main features. It does not demonstrate the pitfalls of the Consensys HTLC bridge.

This method is trust minimized, but requires both parties to stay online for the duration of the swap in order to withdraw funds on the other side, which can cause friction for end-users.
It seems that each design has some pro and some con.

This applies to an atomic swap. It is unclear to me why there was a decision to use a swap architecture to implement a bridge. I mentioned it 3 weeks ago here.