In my last post I discussed the design of Arwen’s smart contracts. That description is now out of date. In the run up to the Arwen Ethereum launch we continued to evaluate our design and came to the conclusion that we should use the
create2 call rather than the
create call for smart contract address creation. Here I will discuss the problem and why we moved to
At a high level the problem is this: Ethereum’s
create call doesn’t guarantee that a smart contract address will not change if a reorg occurs. Thus setting up an escrow safely using
create requires twice the number of block confirmations normally required for a transaction. We show how we fixed this in Arwen by using Ethereum’s
tl;dr We deployed
create2 in our Ethereum smart contracts before our Ethereum smart contract launched. Therefore the issues discussed in this blog entry have no impact on Arwen. These additional changes have been audited by Zerotrust.
How smart contract addresses work
In Ethereum when an smart contract, SC1, creates another smart contract, SC2, using
create the address of SC2 is calculated as
SC2.Address = KECCAK(SC1.Address, SC1.nonce)
SC1.nonce is the counter that increases by
1 each time SC1 creates a new contract address. Notice that the address of the new smart contract SC2 is completely independent of the code or parameters of SC2.
The woes of
create1-based smart contract addresses
To illustrate the problem consider the following scenario. There is a smart contract
WalletContractMaker at address
0x1234 which is used to create smart contract-based multisig wallets.
- Alice wants a new multisig wallet so she posts a transaction
CreateAliceWalletTxnwhich calls the
WalletContractMakersmart contract and tells it to create a smart contract
AliceWalletContractcontrolled by Alice’s keys
- Eve also posts a transaction
CreateEveWalletTxnwhich calls the
WalletContractMakersmart contract and asks it to create a smart contract
EveWalletContractcontrolled by Eve’s keys
CreateEveWalletTxnis confirmed on Ethereums blockchain. The current nonce of
1so the address of Eve’s wallet is
0xABCD = KECCAK(WalletContractMaker=0x1234, 1)
CreateAliceEveTxnis confirmed on Ethereum’s blockchain. The current nonce of
2so the address of
0x3456 = KECCAK(WalletContractMaker=0x1234, 2)
- Alice receives an Ethereum event that
AliceWalletContracthas been created and that the address is
0x3456. She inspects the blockchain and confirms that the smart contract at
0x3456is solely under the control of her two keys
- Foolishly Alice does not wait until
AliceWalletContractis sufficiently confirmed and sends 100 ETH to her multisig wallet at address
- A reorg occurs and now
CreateEveWalletTxnon the Ethereum blockchain. This means that the
2when Alice’s wallet contract is corrected. Thus the address of
- This also means that Eve’s
0x3456. Becasue Alice’s transaction to fund
AliceWalletContractis sent to
EveWalletContractEve can steal Alice’s 100 ETH.
This problem is sometimes phrased as “Ethereum doesn’t provide safely under reorgs”. To prevent this from happening Alice should not take any actions until a sufficient number of confirmations have occurred. That way it is very unlikely a reorg will give her smart contract address to another party.
This fix, while safe, makes the user wait longer. Consider the case of setting up an Arwen escrow. Assume that a reorg of N confirmations is very unlikely. Alice must post a transaction to create her escrow then wait for N-confirmations. Then she must come back on online and fund her escrow. After another N-confirmations her escrow will be able to be used for trading. That is, safely using this pattern requires two times the number of confirmations as just sending a transaction. Furthermore the it requires that the user come back online a second time. We decided that Arwen should not make users do this.
Fixing this with create2
Create2 call gives us the tools to safely confirm the funding transaction at the same time or even before the transaction which creates the smart contract. To understand how we need to look at how
Create2 generates a smart contract address.
If a smart contract SC1 creates a smart contract SC2 using
Create2the address of SC2 will be calculated as:
SC2.address = KECCAK(0xff, SC1.address, salt, KECCAK(SC2.init_code))
This has a number of advantages. First, the address depends on the
init_code so that smart contracts with different constructor code will have different addresses. Second, unlike
create the address doesn’t use a nonce thus reorgs will not change the address.
However out of the box
create2 doesn’t completely solve our problem. This is because while the constructor of the new smart contract can’t be changed without changing the address, the parameters to the smart contract can be changed. For instance
Contract(owner=Eve) both use the same constructor/init_code, namely
Contract(). Thus, we need to ensure that the address commits to both the parameters passed to the constructor as well as constructor itself. To commit to the constructor parameters we just calculate the salt as the parameters i.e.
salt = KECCAK(param1, param2, ...).
Thus in Arwen we calculate the address of an escrow as:
salt = KECCAK(factory.address, escrowAmount, timelock, escrowerReserve, escrowerTrade, escrowerRefund, payeeReserve, payeeTrade)KECCAK(0xff, factory.address, salt, KECCAK(SC2.init_code))
This allows Alice to fund her escrow before she even posts her create escrow transaction. This property is typically discussed with the context of “counterfactual instantiation”. This allows us to change the design of Arwen Ethereum escrows so that rather than “create-then-fund’ we have “fund-than-create”. That is, Alice determines what the address of her escrow will be, she funds it and then posts the transaction that creates the smart contract for her escrow.
Note that there are conditions under which
create2 would not be safe. For instance a constructor can be designed to have behavior which is dictated by other data on blockchain. If a smart contract created from
create2at an address that was self-destructed and then created again the smart contract at that address could change. This doesn’t impact Arwen’s ETH escrows. When we moved to
create2 we removed self-destruct from our contract.