Disclaimer: This post is for informational purposes only, and the author is not liable for the consequences arising from any investment or legal decision based on information contained in this post. Nothing contained in this post suggests or recommends investing in any particular asset. Making any decisions based only on the information or content of this post is NOT advised.
Authors: Ryan Park(@ryanology045), Doug Kim(@doug_k1m), Steve Kim(@a41_steve)
With shifting demands in dApp development, L3s will become an attractive choice
2021 in crypto has indisputably been the year of composability. Dozens of applications were integrated at great scale with each others’ liquidity and userbase, showing what economies of scale could generate in the blockchain field.
Unfortunately customizability and sovereignty has largely been neglected. Represented by the increase in institutions and enterprises eyeing to build their own blockchains and dApps, these two could become the foundations for a plethora of new dApps.
Here are some of the rising key demands for dApps:
- Cost effectiveness: network usage fees for the app are not prohibitively expensive
- Sovereignty: the app has full control over network state
- Customizability: the network can be optimized for the app’s utility
- Security: the app enjoys a network secure from attacks
- Ease of deployment & maintenance: app development is as easy as deploying a smart contract
The preferred mode of deployment has been the one of the three: deploying as a smart contract on a monolithic general-purpose L1/L2, deploying as a separate appchain, or more recently, app-rollups.
Existing options have clear pros and cons
Monolithic L1/L2 smart contracts
A widely accessible first choice is to deploy as a smart contract on a generic L1 or L2. Their strengths being the relative ease of deployment and maintenance (deploy and forget works), and easy access to the rest of the ecosystem’s liquidity and userbase (crucial for composability).
The major drawdown of monolithic smart contracts is restricted customizability. Developers must comply with the rigid framework of a chain’s virtual machine or smart contract language.
Other limitations include lack of sovereignty. As the dApp resides on a neutral network, network state or liveness cannot be altered to accommodate emergency situations such as hacks (controversial, but enterprises may find this useful). The dApp is also subject to network congestion from other popular apps, hurting fluid usage.
Pros:
- Easy deployment and maintenance
- Aggregated liquidity and userbase
Cons:
- Limited customizability
- Lack of sovereignty
Going full-on independent with appchains
For apps with greater emphasis on sovereignty and customization, an alternative is to deploy as a custom appchain. Appchains add significant flexibility, enabling custom optimizations suited for the app, or even revert network state during dire situations.
Security is a primary concern for such networks. Appchains are hosted by an independent validator set and could easily be subject to censorship or even 51%/liveness attacks. Biased governance could also become an issue, where influential parties could alter the network to fit their personal interests.
Pros:
- Better scalability
- Added customizability
- Sovereignty
Cons:
- Security
- Governance collusion
Delegate security to a L1, retain customization via app-rollups
A third and most recent option is to build as a L2 app-rollup. App-rollups delegate their security to a L1, while conserving the ability to customize the network. Sovereignty is also given, the network state able to be altered in dire conditions.
App-rollups are easier to maintain, but there exists extremely few frameworks and SDKs for deploying a custom version of them. This is contrary to the success of monolithic smart contracts, thanks for their simplicity in deployment and maintenance. The lack of L2 bridges also leads to fragmented liquidity and userbase, hurting adoption.
An additional, not well-known restriction is its low cost-effectiveness. L2 app-rollups must see considerable usage in order to balance out the costs needed for L1 proof/commit transactions. Together with liquidity/userbase fragmentation, this makes L2 app-rollups only suited for extremely well-established applications.
Pros:
- Customizable
- Sovereign
Cons:
- Difficult to build
- Need significant usage for cost effectiveness
- Fragmentation
The best of all worlds: app-specific L3 rollups, with a shared utility L2
Current-day platforms (monolithic L1/L2 smart contracts, appchains, app-rollups) all require developers to find compromise between their pros and cons. However, with a novel triple-layer architecture, where each layer is divided into different responsibilities, we believe the best of all worlds could be achieved.
L1 assumes full charge of network security with L2s and L3s entirely inheriting its security. L1 is also positioned as a governance-minimized layer, lessening external human influences and thus increasing the long-term stability of the entire architecture.
L3s are app-specific rollups which are scalable and customizable, developed using SDKs or frameworks for easily deploying custom L3 app-rollups. dApps could execute custom logic during block generation and have full control over network state, optimizing the network to maximize application utility. This is explained later in the post as event-driven smart contracts and app-centric governance.
L2 acts as an aggregation and bridging layer for L3 rollups. L2 aggregates the rollup proofs from L3 and commits them to L1, enabling L3 rollups to enjoy a cheaper gas cost. L2 can also serve as the common utility layer for L3 dApps, such as supporting bridgings between L3s, wallet naming services (e.g. ENS), smart contract software versioning, etc.
Advantages of the L3 architecture are explained in-depth in the sections below:
Economies of Scale
Rollups are generally efficient as multiple transactions are batched into a single proof or commit transaction. L2 app-rollups, while favorable in customization and security, only create batches of app-specific transactions. This degrades the economies of scale enjoyed by rollups as smaller batches result in more L1 gas consumed per L2 transaction.
This is improved by moving app-rollups to L3 and adding an aggregation layer on L2, as also mentioned by Vitalik in this post. App-specific proofs/commits of L3s are first batched on L2, which is then submitted to L1. All L3 apps now share the costs the L1 commit transaction, achieving economies scale and cheaper transaction costs.
Stable Gas Costs
Since L3 transactions are first aggregated by L2, the influence of a single popular dApp swarming the gas costs of other applications is much reduced. This may prove useful for applications needing uninterrupted usage, especially for enterprises.
Optimized governance; sovereign but also credibly neutral
“Governance minimization is important because it supports the primary value proposition of protocol: credible neutrality. Minimizing governance tends to make protocols more credibly neutral.”
Governance minimization is to reduce the influence of governance wherever possible, giving developers better assurance that the base layer will not change. Credible neutrality is a main benefit of minimized governance — no interest groups are favored with on-chain governance manipulation. These neutral characteristics allow stakeholders to trust the protocol with confidence, a core reason why governance-minimized protocols will be the most widely adopted.
A downside of minimizing governance is lack of customizability. Applications, both centralized or decentralized, need the ability to adapt. There are specific governance optimizations that can maximize dApp utility, but protocols with minimized governance do not satisfy this as they are general-purpose and not optimized for a single dApp. Builders on the other hand prefer a framework through which they can establish the best optimizations for their dApp.
Monolithic L1 smart contracts are not suitable candidates as they have to preserve credible neutrality and limit preferential governance features. General-purpose L2 smart contracts are a bit better as network security related governance is delegated to L1, but still suffer from inability of application-optimized governance.
Other options, such as appchains and app-specific rollups, with application governance controlling network state, cannot have minimized governance as they are target for manipulation by particular interest groups. Even with interchain security, appchains would still have governance reliance on Cosmos Hub validators. Interoperability with other dApps is also a critical bottleneck for app-specific L2 rollups.
L3s could be the most optimal choice for acquiring both minimized governance and customizability. L2 could act as the “neutrality zone” between minimized L1 governance and customized L3 governance, where L3 rollups initially have full control over network state (e.g. when a dApp is first launched and may be subject to bugs) but later transfer authority over network state to L2 governance once things look stable.
L3 rollups as event-driven smart contracts
L3 rollups with developed interoperability is indistinguishable from monolithic smart contracts. Together with auto-execution of certain logic achieved via app-specific rollups, they can be considered as smart contracts with added (predefined) event-driven logic.
This is contrary to modern-day smart contracts, where every logic execution requires external callers (or keepers). When each dApp is its own network, predefined code can be added to be automatically executed during block generation (or when certain events are triggered). Labeled as event-driven smart contracts, these added logic could simplify routine chores and make logic execution in dApps more efficient.
Event-driven logics are a unique aspect, infeasible in monolithic smart contracting platforms. If implemented, a single monolithic network should be able to support event-driven logic for any arbitrary number of dApps as they should be universal & general-purpose for all supporting dApps. This leads to computation complexity, dragging block production.
L3 networks on the other hand exist per application — computational load from event-driven functions are distributed amongst multiple networks, bringing them down to manageable levels.
Event-driven logics make smart contracts more efficient and flexible. Functions that repeat over time such as subscriptions and payroll can easily be replaced as event-driven logic. Event-driven smart contracts also provide a stable execution environment as the accomplishment of certain high-importance tasks are guaranteed.
For example, this event-driven rebase function is automatically executed once per epoch. The conditional statement evaluates to either true or false on each block generation and updates will be pushed only if the conditional statement is true.
The Multi-Rollup Future
The future of blockchains could be a multi-rollup one, comprised of a vast array of independent L3 app-rollups on top of a handful of utility-purpose L2s. Smart-contract-like app-rollups could be closely intertwined with each other via L3 bridges, essentially replicating the current advantages of composability but with added customizability previously unthought of.
The addition of event-driven functions to smart contracts will enable a more web2-like experience, opening up new types of possible dApps. Development tools and frameworks for app-rollups could also be widely available, making app-rollup deployment as easy as deploying a smart contract in the present day.
With the combination of all above, a rich and diverse ecosystem of novel dApps could arise, each of them being cheap to use, highly customized, sovereign, easy to build, and highly secure.
About Blix
Team Blix has delved into building the future of dApp platforms using event-driven smart contracts and the layer3 architecture together with talented engineers from UC Berkeley, International Olympiad in Informatics (IOI), and a top-tier ZK-rollup company. If you are interested in our project, please reach out to us via contact@blix.dev!
