Partnered With:

Interpretation of Vitalik's blog: Is the next step for Web3 infrastructure encapsulation or expansion?

Read this article in 14 Minutes

This article will explore the design trade-offs of "encapsulation vs. extension" in Web3 infrastructure, as well as some personal thoughts on this issue regarding public chain infrastructure.

Original Title: Encapsulation or Extension? Exploring the Next Stop of Web3 Infrastructure - Interpretation of Vitalik Enshrinement's Blog

Original Author: CP, CTO & co-founder, Artela

Vitalik published a blog post two weeks ago titled "Should Ethereum be okay with enshrining more things in the protocol?" In the post, he shared his thoughts on the basic functionalities required for Ethereum to "enshrine" upper-layer applications and discussed how to propose a framework to encapsulate more basic functionalities required for upper-layer applications.

This is a key issue that typical platform systems face: whether the team "encapsulates" the critical upper-layer application functions into the underlying layer, or whether the application developers "extend" these functions at the application layer. When the infrastructure is on the eve of large-scale expansion, the design of "encapsulation vs. extension" is crucial and will be one of the key designs that affect its ability to be widely applied.

In the past six months, several major infrastructure have launched their important technical updates: Uniswap has introduced the Hook mechanism to support the extension of custom functions in the pool; MetaMask wallet has launched Snaps to support developers in adding user extensions; Ethereum is now facing the dilemma of "encapsulation vs. extension".

This article will explore the design choices of "encapsulation vs. extension" in Web3 infrastructure, as well as some personal thoughts on this issue in public chain infrastructure.

Ethereum faces what problems? Encapsulation or expansion

Regarding the issue of "encapsulation vs. extension", Ethereum has always chosen "extension".

The design philosophy of Ethereum is derived from Unix, creating a minimal and universal kernel, allowing user needs to be implemented through developers at the application layer. The key technology that supports Ethereum in achieving this is the EVM. The Turing-complete smart contract language allows developers to customize their own applications at the application layer.

This pattern looks reasonable, but it doesn't work as well on "decentralized Unix" for one important reason: EVM's so-called Turing completeness is not as "complete" in practice. Under the gas mechanism and limited opcode, it requires programs to use limited opcode to complete their tasks in a limited number of steps, which greatly limits the ability of applications to do everything like Web2 programs in the user layer of Unix. Many advanced dApps require capabilities that EVM cannot meet. Whether it's Rollup or AA Wallet, they can run, but they are still MVP products, and their efficiency and experience are far from their goals without modifying L1.

The choice facing developers is: EIP. Its important functions are "packaged" into the underlying layer by the Ethereum core team, providing them for use at the application layer.

Based on the EVM, the "expansion" cannot meet the development needs of applications. Now they need to consider how to "encapsulate" properly.

However, it is not so simple to encapsulate upper-layer application functions in decentralized infrastructure. It is not just about integrating a piece of code, but rather the biggest challenge of decentralized systems: governance. "Encapsulation" means that the core team not only develops and maintains, but also takes on the governance work of these functions, while there is a risk of weakening the trust model of Ethereum and introducing potential issues that could affect its sustainable development.

So the final result can be easily seen: the number of functions that the core team can "encapsulate" is limited, and secondly, the importance of this function needs to be widely recognized by the community. Finally, its implementation efficiency will not be so high, taking years to achieve.

At the same time, this also means that if the functionality you need is not a basic function that requires widespread consensus, then Ethereum may never be able to accommodate you, and even your attempts may require you to choose to build your own application chain, bearing high development and operation costs, and losing the wonderful composability of the smart contract world.

On the issue of "encapsulation vs. extension", Ethereum does not yet have a clear solution. How to make "encapsulation" happen in an orderly manner, as Vitalik mentioned, they are still exploring a framework for determining the target functions to be encapsulated and how to encapsulate them.

What else can we learn from Unix? Native Extension!

On the issue of "encapsulation vs. extension", Ethereum mainly needs the core team to do encapsulation to make up for the insufficient extension capability of EVM. If we think from a different perspective, if we improve the scalability of the application layer, can't we solve a large part of the problem? For example, application developers can customize the required underlying functions for their applications according to their own ideas, without waiting for the underlying team to encapsulate them.

We also know that Ethereum draws a lot of design philosophy from Unix, so let's continue to look for ideas in the Unix system.

Based on Unix, this commercial operating system is aimed at the PC market and faces a diverse range of application layer needs, as well as expansion requirements from enterprise usage scenarios. However, the core team of these commercial operating systems does not have a high "encapsulation" burden, and they provide sufficient scalability for applications, allowing most users to solve their own functionality needs.

Using Mac OS X as an example, the general operating system distinguishes between kernel mode and user mode. User applications generally run in user mode and use the functionality provided by kernel mode programs. A simple (but not complete) comparison is that smart contracts on top of EVM are equivalent to user-mode applications, while the Ethereum protocol layer is equivalent to kernel mode.

However, Mac OS X allows application developers to independently deploy programs into kernel mode to extend kernel functionality, without requiring the Mac OS X core team to encapsulate on a case-by-case basis. The core mechanisms provided by Mac OS X are "kernel extensions" and "system extensions", which allow developers to develop kernel extensions in a certain security mode, using higher-level permissions to develop functionality that cannot be completed by pure user-mode applications.

Our inspiration is whether the "Kernel Extension" model is feasible in "decentralized Unix"? Its model is shown in the following figure.

On the blockchain protocol, in addition to supporting "smart contracts", there is also support for another type of program called "Native Extension".

1) Have more access to underlying protocol APIs than smart contracts.

2) And its execution environment efficiency is orders of magnitude higher than EVM.

3) And it has isolation from the underlying protocol, without affecting the stability of the underlying protocol.

4) Therefore, in terms of governance, it does not need to be maintained by the underlying team, but by the application team for maintenance and deployment.

If this model can meet the above four points technically, it seems to solve many problems: application developers can customize the required underlying functions for their applications according to their own ideas without waiting for the underlying team to encapsulate them.

We will temporarily summarize this paradigm as the "Native Extension" paradigm. Next, let's take a look at whether there is any trace of it in the existing Web3 infrastructure.

Hook, Hook, Hooks…

In the software world, great wheels are often created by great scenarios. Uniswap, as the DeFi infrastructure, is at a critical stage of becoming a "platform", and it has given an amazing design in the "encapsulation vs. extension" feature: Hook. It allows developers to use Hook to add extensions to the pool without permission, achieving a diversified pool experience without the core team constantly upgrading the function through "encapsulation".

Developers can deploy Aspects that serve only their own projects to customize the protocol layer functionality they need. For example, adding runtime security to intercept transactions that may potentially lead to large amounts of funds being stolen within the Aspect.

Developers can also deploy public Aspects to encapsulate basic functions that can be reused across multiple projects. For example, if a certain Aspect implements a specific algorithm and transaction type, making the AA wallet more programmable and composable, other developers can also enable this Aspect and use this underlying feature in their own projects.

· Allow developers to solve problems through Native Extension without permission in the application state, rather than waiting for the underlying public chain team to package it.

· Let developers have a good ecological environment to break through (EVM may soon reach its ceiling, EVM+Native Extension may have more potential)

· Let dApps such as full-chain games and RWA that want to move more business logic onto the chain have an ideal home.

Import Web2

Finally, end this article with these two words. Although at the code level, the decentralized Web3 stack and the Web2 stack are completely different ways of thinking, it does not prevent us from searching for treasures in the Web2 library in terms of design philosophy and historical development. Keep building!