search

OpenST / mosaic-contracts

Mosaic-0: Gateways and anchors on top of Ethereum to scale DApps
https://discuss.openst.org/c/mosaic
MIT License
114 stars 31 forks source link

⭐️ StarGateway #720

Open schemar opened 5 years ago

schemar commented 5 years ago

stargate.gif

This main section will be updated based on the discussion below.

schemar commented 5 years ago

Goal

The goal of the StarGateway is a gateway where message transfer is cheaper than with the current EIP20 gateway -- without a reduction in security.

Why a new gateway

The options were to

  1. update the current EIP20 gateway or
  2. create a new gateway contract.

Updating the current gateway would lead to a situation where there are different versions of the EIP20Gateway with potentially very different interfaces. Any interaction with any EIP20 gateway would mean figuring out the version first and then interfacing with it appropriately, based on that version. This wouldn't necessarily be a big issue in the case of two versions, but it is easy to see how this could spiral into a mess of versions and interfaces.

The downside of option 1 is so big, that we decided to go with option 2. The main challenge of this option is to keep the number of different gateway implementations minimal so they remain maintainable. We believe there is a bigger natural mental hurdle to creating new contracts as to updating existing contracts with interface-breaking changes. The massive benefit of approach 2 is that you will know what kind of interface you are facing based on the name of the contract.

Design

Design decisions for a simpler, cheaper gateway based on a security analysis.

Security

Security assumptions based on the current state of 💠Mosaic:

Reasoning of the EIP20 gateway: There are two ways of transferring messages with an EIP20 gateway:

  1. Using a 4-step process involving 3 (6) MerklePatricia proofs.
  2. Using a 3-step process involving 1 (2) MerklePatricia proofs and 2 hash lock secret reveals.

The reason for the 4-step process was originally to be able to revert the decision to stake or unstake. In order to revert, auxiliary must still be alive so that the "revert intent" can be confirmed on auxiliary. Otherwise, a revert can not be carried out.

The hashlock option was introduced to make message transfer cheaper, as it requires much fewer MerklePatricia proofs.

In case auxiliary halts, it can halt at any stage of the process:

  1. Auxiliary halts before staking on origin.
    • If staking has not taken place yet, no value is sent anywhere and the staker doesn't need to claim anything back.
  2. Auxiliary halts after staking on origin, before proving the stake on auxiliary.
    • In this case the stake is lost. It can neither be completed (to prove ownership) nor can it be reverted.
  3. Auxiliary halts after proving the stake on auxiliary.
    • At this stage and any later stages, the staker can always prove ownership of the value on auxiliary and should be able to redeem the value (stake was proven on auxiliary and can be completed on origin).

Simplicity

Granted the hash lock procedure's use-case is making the 4-step process cheaper, we claim that if we solve for an easier general process, we do not need a hash lock procedure at all. Therefore, we will not discuss the hash lock procedure from here on out and instead assume it doesn't exist. It won't be required as shown below.

Instead, we will focus on the improvement of the general staking (and unstaking) process. We claim that it is sufficient to have a 2-step process with 1 (2) MerklePatricia proofs and 0 hash lock secret reveals without the loss of security or convenience. This procedure does not offer any way of revoking a stake (or redemption) intent.

The StarGateway would work as follows:

  1. Step one is the staking on origin.
  2. Step two is the proof on auxiliary with 2 MerklePatricia proofs (one for state and one for storage).

After 1., the value is immediately locked on origin like it would after step 3 of the original process. After 2., the value is immediately minted and granted on auxiliary like it would after step 4 of the original process.

General security after the change: We claim security still holds entirely. If a stake or redemption was initiated, it is always possible by anyone to complete the process by doing MerklePatricia proofs, granted that auxiliary is still alive (same as before). That the stake is immediately locked on origin is not a loss. Either the staker can progress the stake, or auxiliary halts. If auxiliary halts, the properties are the same as they were before.

In case auxiliary halts:

  1. Auxiliary halts before staking on origin.
    • Same as before: if staking has not taken place yet, no value is sent anywhere and the staker doesn't need to claim anything back.
  2. Auxiliary halts after staking on origin, before proving the stake on auxiliary.
    • Same as before: in this case the stake is lost. It cannot be proven on auxiliary and therefore ownership cannot be proven for redemption.
  3. Auxiliary halts after proving the stake on auxiliary.
    • Same as before: at this stage, the staker can always prove ownership of the value on auxiliary and should be able to redeem the value.

Inability to revert:

The ability to revert is gone. However, we do not see any benefit in having a reversion in the first place. The staker (redeemer) either wants to stake (redeem), or not. If not, then don't stake (redeem). Reversion does not provide any additional security guarantees. Any stake (redeem) can always be carried through. The only case where it can't be completed is case 2. of "if auxiliary halts." However, in that case reverting is also not possible any more.

Benefits

This section is brief, but the mentioned benefits are very, very big in our opinion.

Staking (and redeeming) is cheaper. It only requires one stake (redeem) message and 2 MerklePatricia proofs.

No bounty. Any facilitator completes the process by proving the source on target. Therefore it is not required to lock-in any bounty.

Less front-running. Since proof only requires public knowledge, front-running by repeating the secret reveal is not possible. It is also no longer possible to steal the bounty. However, it is still the case that facilitators would compete for proof to earn the reward. 🔬One possibility could be: the staker provides a "preferred facilitator address" when staking at block number b. For a set number n of blocks, only the "preferred facilitator" can make the proof on auxiliary. It would be enforced by the block number of the latest finalized origin block on auxiliary. If the highest finalized origin block on auxiliary is between b and b + n, the contract would only accept the "preferred facilitator". Maybe this is not required at all?

Open set of facilitators. Since there is no bounty and no hash lock, any facilitator can pick up any stake or redeem message.