Layer2 First Design
TL;DR CREATE2 can fix the Ethereum New User Flow (ENUF). It also sets the stage for a scalable layer2 first design with the added bonus of unlocking new payment flows.
When is ENUF Enough?
A previous post outlined how solving the Ethereum New User Flow (ENUF) using CREATE2 reduces user friction by removing the need to create keys during the on-boarding process. However, a successful new user flow will only make network congestion worse. So, developers need to also simultaneously implement scalability solutions. While we are still in the early stages of building out lower-level protocols and infrastructure like ETH 2.0, there are layer2 solutions available now that allow users to transact instantly and securely at scale.
Increasing off-chain transactions is the responsibility of every developer and as noted in a previous post, “reserved addresses” allow an efficient deposit mechanism that sets the stage for a layer2 first strategy. This provides a scalable approach that allows users to immediately interact with apps. It may be instructive to review the early days of social networking and understand how that played out — as Mark Twain said, “History doesn’t repeat itself, but it often rhymes.” Friendster failed because it could not scale.
This does mean that current on-chain-only apps will need to be refactored. For better or worse, they will be architected more like traditional web2 systems with explicit trust boundaries and user initiated exits. Crypto payments, whether on or off-chain, will find less technical abstractions. More importantly, there are second-order effects that have significant impact on capital requirements.
Deferred Deployment
CREATE2 allows for new designs that were not previously obvious. For example, take hash timelock contracts. Current constructions assume a capital requirement. Now with “deferred deployments,” contracts can be deployed after funds have been delivered, which alleviates the capital requirements of multi-hop payment channels.
Pull Payments
Assuming users have funds stored in contracts instead of keys, developers can now implement “pull” payments. Yes, these are just subscriptions in disguise. The added benefit is that it also simplifies non-custodial payment channels. With Perun style virtual channels, current non-custodial constructions require a state channel hub to capitalize with matching funds.
With funds held in smart contracts instead of keys, state channel hubs can pull payments from users while remaining non-custodial. The design space here is wide open!
Meta Transactions
Layer2 first pairs well with on-chain transactions through design patterns like meta transactions (a transaction that is submitted on behalf of another account, more here). For example, a user with a reserved address that has yet to deploy her contract can have a payment channel hub submit a meta transaction on-chain. The hub could recoup funds after the user contract has been deployed.
A Network of Network Effects
As a syndicate of open networks, we can take advantage of wider consumer trends and work together to standardize user on-boarding techniques, share scalability platforms and act as a decentralized collective for data, traffic and best practices.
The upcoming hard fork will unlock new possibilities that allow Ethereum app developers to not only solve user on-boarding but also start at scale using layer2 first designs. We can learn from history and apply a PayPal-like growth hack to crypto. However, solving for on-boarding and scalability is not enough — PayPal needed eBay. A future post will explore what it means for the ecosystem to come together once scalability and user on-boarding have been standardized.
