Understanding the “Enshrine vs. Extend” Debate

Insights into Vitalik’s Enshrinement Philosophy

Vitalik Buterin recently published a blog titled “Should Ethereum be okay with enshrining more things in the protocol?” In this blog, he shared his thoughts on the protocol features required to enshrine upper-layer applications in Ethereum, and proposed a framework for enshrining certain features into Ethereum dApps. This proposal highlights a critical issue faced by blockchain platforms in 2023: Should protocol features be “enshrined” in the base layer, or should external developers be open to “extend” new features at the application layer?

Ethereum is the only latest to grapple with the “enshrine vs. extend” dilemma. Over the last six months, a few major protocols have introduced technical upgrades with a focus on allowing external developers to extend core functionality: Uniswap introduced “Hooks” to support the extension of the pools function, and the MetaMask wallet introduced Snaps to allow user-created extensions.

As Web3 infrastructure evolves toward mass adoption, the “enshrine vs. extend” debate will become increasingly vital in determining how this industry matures.

The Challenge for Ethereum: Enshrine vs. Extend

Extending Ethereum faces challenges

Ethereum’s design philosophy is rooted in Unix. It aims to create a minimal, versatile kernel space and allow users’ needs to be implemented in the application space by external developers. The key technology supporting this approach is the Ethereum Virtual Machine (EVM). This Turing-complete smart contract language enables developers to customize their dApps at the application space.

While this developer-focused model has many benefits, it faces challenges — notably, the so-called “Turing complete” EVM is not actually complete. On EVM, the limited opcodes and mechanism to handle gas fees require external programs to complete tasks within a finite number of steps. This limitation significantly hinders the ability of Ethereum dApps to scale, perform flexibly, and include advanced functionality like the Unix user layer in Web3 applications. Despite proposed solutions like Rollups and AA wallets that can run on Ethereum without modifying the L1, there has not yet been a true breakthrough that achieves the efficiency and user experience goals that developers demand.

Enshrining seems inevitable

As “decentralized Unix” hosts more applications and innovations, the challenge Ethereum faces is how to better accommodate universal features. Simply extending functionalities at the EVM level isn’t enough. Ethereum also requires enshrining. Some advanced application features, which might not function optimally within the EVM, need to be enshrined into protocol layer.

However, enshrining upper-layer protocol features in decentralized infrastructure isn’t as straightforward as it may first appear. Integrating a piece of code is only the beginning; the far more significant challenge in modifying existing decentralized systems is governance. Enshrining new features in the context of protocols like Ethereum refers to the core team taking on the responsibility of not just developing and maintaining these features, but also governing them. Before major changes can take place or new features can be introduced, they must reach a wide consensus within the community. Ultimately, due to all of these factors, the number and complexity of new features that the Ethereum core team can enshrine is limited.

Enshrining isn’t the silver bullet

The Ethereum Improvement Proposal (EIP) is, as of the time of this writing, the only way to enshrine specific features into the base layer. However, this proposal introduces a major obstacle: all new features need to be reviewed, and ultimately merged, by the Ethereum core team before they can be accessed by developers.

It has several limits:

1. The core team can only enshrine a limited number of features
2. These features’ significance must be universally recognized and agreed upon by the broader community
3. The efficiency of their implementation may be less than optimal, potentially taking several years

In the “enshrine vs. extend” dilemma, Ethereum is stuck between a rock and a hard place. Due to these limitations, the practical reality will be that any feature that does not qualify as a widely agreed-upon necessity will likely never be enshrined. In many cases, developers may have to build their own AppChain instead, which bears high development and operational costs while losing the composability of Ethereum smart contracts. How to “enshrine” more features progressively, as Vitalik pointed out, is still being explored by himself and the Ethereum team, and an apparent framework to determine these features — and to ostensibly reach some kind of community consensus for development priorities — is in the works.

Learning from Unix: Native Extension

Despite a philosophical history that leans heavily toward the “extend” side of the debate, Ethereum is now leaning back toward “enshrine” due to the limitations of EVM. However, one can’t help but wonder: What if we could address this problem by increasing the application layer’s extensibility? What if dApp developers could define the underlying features they need for their applications without waiting for the infrastructure team, and the greater community, to enshrine them?

We know that Ethereum has drawn many design philosophies from Unix. So, let’s go back to basics and learn from the success of the Unix design. Commercial operating systems based on Unix, aimed at the PC market, face a more diverse set of needs at the application layer. This includes, but is not limited to, extension needs from large-scale enterprise usage scenarios. However, these commercial operating systems don’t carry the high burden to enshrine new features that Ethereum does, such as governance. These systems provide sufficient extensibility for applications, enabling most user feature needs to be resolved by users themselves.

For example, consider Mac OS X, a general operating system that distinguishes between kernel space and user space. User applications typically run in user space, utilizing features provided by kernel space programs. A simplified (though not entirely accurate) comparison is that smart contracts on top of the EVM are equivalent to user space applications, while the Ethereum protocol layer is equivalent to kernel space. Mac OS X allows application developers to deploy programs in kernel space autonomously, extending kernel features without needing the core Mac OS X team to enshrine these features on a case-by-case basis. Mac OS X provides core mechanisms known as “kernel extensions” and “system extensions.” These extensions allow developers to create kernel extensions in a secure mode, use higher-level features, and implement features that user space applications cannot accomplish.

This inspired design philosophy leads us to wonder: could the “Kernel Extension” model work with “decentralized Unix”? If so, the model could look like this:

In addition to supporting smart contracts, we propose another type of program on the blockchain protocol layer called “native extensions” with the following characteristics:

1. Greater access to underlying protocol APIs than smart contracts.
2. An order of magnitude improvement in execution environment efficiency compared to EVM.
3. Security isolation from the underlying protocol, ensuring system stability.
4. No maintenance requirement by the underlying infra team; independent application teams can maintain and deploy.

If a new model can meet these four conditions, it would solve many, if not all, of the issues discussed earlier in this article. Application developers could use Native Extensions to define their desired low-level features as they see fit, without waiting for the core team to enshrine them.

Let’s see if there are any traces of this “Native Extension” paradigm in existing Web3 infrastructures.

Hook, Hook, Hooks…

In the software world, great inventions most often arise from great need. Uniswap, as a DeFi infrastructure, is at a critical stage of becoming a “platform.” In the “enshrine vs. extend” debate, Uniswap has firmly planted its flag on the side of “extend” with Hooks. Hooks allow developers to add extensions to Uniswap Pools without requiring permission, achieving a diversified pool experience without the core team continually upgrading features through enshrinement.

The Hook mechanism shares several similarities with the aforementioned Native Extension paradigm:

1. Hooks can integrate logic into the execution lifecycle of pools and access runtime data, providing a higher level of access.
2. Hooks and pools are two separate contracts, meaning the security of Hooks does not affect the pools.
3. Governance-wise, Hooks can be developed and deployed by third-party developers permissionlessly. Hooks are not globally activated, but rather bound to different pools as needed to enable custom features.

Hooks are an elegant solution for the niche case of the scalability problem for pools, and application layer projects have been quick to apply these new technologies. However, despite Hooks being a good design for specific protocols, there’s a compelling need for a universal framework for general-purpose dApps. It needs to be a blockchain-level native extension.

The Extension Design of New Public Chains

Let’s look at what Layer 2 projects are doing to extend the Layer 1 functionality.

Arbitrum Stylus: Let application developers enshrine precompiled contracts themselves!

At the time of writing, the only way to extend (very limited) features on EVM is to use “precompiled contracts”; these contracts don’t run on EVM, but are integrated into the nodes and run further down the stack. For example, a developer could add a new, computationally intensive cryptography algorithm as a precompiled contract, but this would only operate on the node on which it is implemented. However, even with limited functionality, the permissions for adding precompiled contracts are not open to most application developers and require the Ethereum core team to enshrine them.

Arbitrum Stylus introduces the “EVM+” paradigm which keeps EVM compatibility, and allows developers to go beyond the limitations of the EVM to deploy higher-performance, precompiled contracts permissionlessly. This is accomplished by adding a Web Assembly execution environment to the execution layer itself, dynamically loading and running WASM contracts. WASM provides an order of magnitude more efficiency than the EVM and supports multiple programming languages.

With Stylus, EVM’s extension needs no longer depend on the core team to enshrine them — the core team can focus on maintaining the extended execution runtime, while the development, introduction, and governance of new features are left to the application layer for further customization. Arbitrum, emblematic of next-generation infrastructure, has unveiled a design for extensibility that addresses the current ‘enshrinement’ challenge while thoughtfully considering the long-term sustainability and growth of the ecosystem.

Native Extension: A Modular Approach of Artela!

By understanding the history success in Web2 and the needs of Web3, we can conclude that the ideal mechanism to add functionality to a system is by increasing “extensibility” — allowing developers to independently identify their needs and extend the features of that system modularly. Similar to Unix and Google Chrome, Native Extension enables developers to fulfill their custom needs from the underlying protocol without compromising its stability.

Developers are enabled to encapsulate what they need in an application without affecting the core protocol’s stability, bringing back the creative ownership to developers without needing the core team to enshrine these features on a case-by-case basis.

Artela, a new L1 public blockchain enables Native Extension.

On the Artela blockchain, we have implemented a WebAssembly (WASM) execution environment alongside the Ethereum Virtual Machine (EVM). WASM can support the operation of stateful programs, similar to precompiled contracts. Artela allows for a mechanism similar to Hooks that can be executed at various stages of block and transaction lifecycles. Altogether, Artela can go far beyond the enshrining of precompiled contracts (e.g., Arbitrum Stylus), enabling the customization of transaction and block execution flows for a much wider range of potential features and functionality.

For example, a WASM Native Extension can be bound by a dApp and triggered during the transaction verification process to utilize a new algorithm for identifying and validating relevant transactions. In Artela, these hooks are referred to as Join Points, and these Native Extensions are referred to as Aspects. Similar to the concept of Aspect-oriented programming (AoP), Aspects enable developers to incorporate new functionalities and features at various Join Points within the blockchain system.

What are the unique use cases of Aspects? One example is runtime protection. The major obstacle for large-scale asset migration to Web3 is on-chain security. Unlike the existing risk control measures that focus on the protocol source code level and take effect before runtime, runtime protection involves protocol developers writing guard rules and actions to handle unforeseen outcomes during runtime. By safeguarding the protocol in a “black-box” manner, it reinforces safety by ensuring that the final runtime results align with the protocol’s intended design, all without directly involving itself in the actual code execution.

Aspects provide developers with in-depth execution-level security extension capabilities. Developers can deploy Aspects tailored to their projects, such as enhancing runtime security to revert transactions that might potentially result in large fund theft. Aspects can also be deployed to enshrine fundamental features that are reusable across multiple projects. Aspects are modular and composable.

For Artela, our vision is to:

1. Empower application layer projects to address issues through Native Extension without waiting for the underlying blockchain team to enshrine.
2. Encourage large institutions from the Web2 world to confidently stake assets on blockchains through enhanced Web2-level runtime risk control.
3. Provide developers with an ecosystem for groundbreaking innovation, considering that the potential for EVM could soon reach its limits, while EVM+Native Extension offers more possibilities.
4. Provide a better platform for projects aiming to implement more logic and functionalities natively on-chain, including fully on-chain games and real-world assets.

Ethereum is still in the stage of figuring out the framework for enshrining features from dApps and there is no clear plan to relieve the pressure of enshrinement and return creativity to the hands of developers. For developers who are constantly exploring the boundaries of dApps, this is a pressing issue to address. That’s why we are committed to building a new Layer 1 public blockchain based on the Native Extension paradigm. This ensures that the infrastructure does not hinder innovation.

Import Web2

Although, at the code level, Web3’s decentralized stack and Web2’s stack are entirely different paradigms, this doesn’t hinder us from exploring treasures in the design philosophy and historical development of the Web. Keep building!

Artela has been building the modular future of Web3 for almost a year, and will be launching a public testnet for all builders before the end of the year! Keep up to date by following Artela on Twitter and joining our Discord.