The CREATE2 OpCode and DApp Onboarding in Ethereum

The Ethereum network’s next major upgrade is the Constantinople upgrade (was meant to be January 16th but has since been delayed). The upgrade introduces several new features, one of which seems unexciting on the surface but enables a range of possibilities for scalability and user onboarding. This feature is the introduction of a new opcode for the Ethereum Virtual Machine: CREATE2. This article will briefly outline what CREATE2 does and how it could drastically improve the adoption cycle for decentralised applications.

What is CREATE2?

The important thing about CREATE2 is it allows DApp (Decentralized Application) developers to generate contract addresses without having to actually deploy a contract. Previously there was no way of “reserving” a contract address without deploying it. We’ll discuss why this is a problem for adoption later.

The actual CREATE2 opcode behaves virtually identically to the current CREATE opcode with 1 slight change. Both attempt to deploy some EVM bytecode as a new contract. However, whilst the contract address that a CREATE call deploys to is dependent solely on the sender and nonce, the new contract address for CREATE2 is dependent on extra input data.

In simple terms, you can think of it as allowing developers a level of “control” over the new contract address generated.

The Onboarding Process Before CREATE2

Think of some DApp that we’re trying to build and to market to the general public. At some point in the process of users interacting with our DApp, we likely want to give them some on-chain reward; maybe ether, tokens, or some non-fungible token. To do this, of course, the users need their own address, despite this application being their first interaction with the Ethereum blockchain.

There are a couple of options here.

We could maintain a list of private keys on some centralised server behind the scenes of the DApp. This would allow us to cheaply distribute new addresses to all of our users. However this is a significant security burden for us, and really takes the “D” out of “DApp”.

Another option is to create a wallet-like contract for every new user. Initially, our DApp will have full rights to all of the operations on this contract. Users can still receive everything they need, and whenever they do create their own Ethereum address, we can easily transfer full ownership over to them, removing the rights of our DApp. In theory, this works great. In practice, it’s very expensive. Contract deployments cost gas, and as the developers of this DApp we have to continually fund the creation of new contracts — even for cases where the users never come back. Sunk cost.

If only we could know about these contract addresses without having to spend the gas to create them!

Enter CREATE2

With CREATE2 our DApps can now know a contract’s address before it’s created. In the case above, we can easily generate wallet contract addresses for all of our users. Off-chain. For free.

We can send all of the tokens and in-game items that we need to to this address, and when the user is ready to commit and claim their new property, we can require that they send a small amount of ether to the contract address. Which will allow our DApp to go and create the contract for free, taking some of the funds to cover gas costs!

Concluding

This is just one possible brainstormed workflow, but hopefully gives you an idea of the kinds of things we can start doing when we are able to reserve contract addresses for currently unidentified users.

Let me know if you have any thoughts, or if this high-level explanation can be improved in any way.

Find me on Twitter: https://twitter.com/codingupastorm