Author: CP, CTO & co-founder of Artela

Vitalik published a blog post last week titled "Should Ethereum be okay with enshrining more things in the protocol?", in which he shared his thoughts on the basic functions required for Ethereum's "enshrine" upper-layer applications, and discussed how to propose a framework to encapsulate more basic functions required for upper-layer applications.

This is a key issue that typical platform systems face: should the team "encapsulate" key upper-layer application functions into the bottom layer, or should application developers "extend" these functions at the application layer? When the infrastructure is about to be expanded on a large scale, the design of "encapsulation vs. extension" is very critical and will be one of the key designs that affect whether it can be applied on a large scale.

In the past six months, several major infrastructures have launched their important technical updates: Uniswap launched the Hook mechanism to support the expansion of custom functions pool；MetaMaskwalletSnaps were launched to support developers in adding user extensions; Ethereum is now also facing the problem of “encapsulation vs extension”.

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

What problems does Ethereum face? Encapsulation or expansion

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

Ethereum's design philosophy is derived from Unix, creating a minimalist and universal kernel, allowing users to realize their needs through developers at the application layer. The key technology that supports Ethereum to achieve this is: EVM. Turing-complete intelligencecontractThe language enables developers to customize their applications at the application layer.

This model seems reasonable, but it doesn't work so well on "decentralized Unix". One of the important reasons is that the so-called Turing completeness of EVM is not so "complete" in actual use. Under the gas mechanism and limited opcodes, it requires the program to use limited opcodes in limited steps to complete its tasks. This greatly limits the application from being omnipotent like Web2 programs in the user layer of Unix. Many high-level dApps require capabilities that EVM cannot meet. Whether it is Rollup or AA walletWithout modifying L1, they can run it, but it is still an MVP product, and the efficiency and experience are still far from their goals.

The choice before developers is: EIP. Let the Ethereum core team "encapsulate" the important functions it relies on into the bottom layer, so that it can be used by the application layer.

The "extension" based on EVM cannot meet the needs of application development, and now they need to consider how to "encapsulate".

However, it is not that simple to encapsulate upper-layer application functions for decentralized infrastructure. It is not just about integrating a piece of code. Behind it lies the biggest problem of decentralized systems: governance. "Encapsulation" means that in addition to development and maintenance, the core team must also undertake the governance of these functions. At the same time, there is a risk of weakening the Ethereum trust model and introducing potential problems that affect sustainable development.

So the finalXiaobai NavigationThe effect is easy to see: the number of functions that the core team can "encapsulate" is limited, and the importance of this function must be obtained.CommunityThe efficiency of achieving a large-scale consensus will not be that high in the end, and it will take years.

At the same time, this also means that if the functions you need are not basic functions required for broad consensus, then Ethereum may never be able to accommodate you, or even your attempts. You may therefore have to choose to build your own application chain, bear high development and operation costs, and lose intelligence.contractThe beauty of the composability of the world.

Ethereum has not yet come up with a clear solution to the problem of “encapsulation vs. extension.” As Vitalik mentioned, they are still exploring a framework to determine the target functions to be encapsulated and how to encapsulate them.

What else can we learn from Unix? NativeExtension!

On the issue of "encapsulation vs. extension", Ethereum's core team needs to do encapsulation to fill the gap mainly because of the insufficient expansion capability of EVM. If we think about it from another perspective, if we improve the scalability of the application layer, can 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.

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

Commercial operating systems based on Unix are oriented to the PC market and face more diversified demands at the application layer, and even expansion demands from enterprise usage scenarios, etc. However, the core teams of these commercial operating systems do not have too high a "packaging" burden, and the scalability they provide to applications is high enough so that users can solve most functions by themselves.

以 Mac OS X 举例，一般操作系统区分内核态和用户态，用户应用程序一般运行在用户态，使用由内核态程序提供的功能。一个简单（但不完全）的对比是，EVM 之上的智能contract都相当于用户态的应用，以太坊协议层相当于内核态。

However, Mac OS X allows application developers to deploy programs into kernel state to expand the functions of kernel state without the need for the core team of Mac OS X to encapsulate them case by case. The core mechanisms provided by Mac OS X are "kernel extension" and "system extension". These two extensions allow developers to expand the functions of kernel state in a certain way.SafetyDevelop kernel extensions in this mode and use functions with higher permissions to develop functions that pure user-mode applications cannot complete.

The inspiration we got is, is the "Kernel Extension" model feasible on "decentralized Unix"? Its model is shown in the figure below.

BlockchainIn terms of protocol, in addition to supporting “smart contracts”, it also supports another program “Native Extension”, which

1) Has more access to underlying protocol APIs than smart contracts

2) Its execution environment efficiency is orders of magnitude higher than that of EVM

3) It is isolated from the underlying protocol and does not affect the stability of the underlying protocol

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

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

Let’s summarize this paradigm as the “Native Extension” paradigm for now, and then see if 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. As a DeFi infrastructure, Uniswap is at a critical stage of becoming a "platform" and has given a stunning design in the "encapsulation vs. extension" feature: Hook. It allows developers to use Hook to add extensions to the pool without permission, achieving a functionally diverse pool experience without the core team having to constantly upgrade functions through "encapsulation".

The mechanism of Hook is similar to the above Native Extension multiple conditions:

Hook can be inserted into the execution life cycle of the pool and can access runtime data, which is a higher level of access

Hook and pool are two independent contracts.SafetySex does not affect the pool

In terms of governance, Hooks are developed and deployed by third-party developers without permission, and are not globally activated. Instead, different pools bind different Hooks on demand to enable custom features.

Hook is a small and beautiful design that solves the scalability problem of pool. The application layer infrastructure first applied these concepts. Let's continue to look at the more complex underlying protocols (L1/L2)’s idea.

Expansion ideas of new public chain projects

Ethereum is in trouble, let’s take a look at the ideas of Layer2 projects dedicated to expanding Layer1.

ArbitrumStylus allows application developers to package precompiled contracts themselves!

Everyone should know that EVM can extend its functions through "precompiled contracts". Its code does not run in EVM, but is integrated in the node and runs at the bottom. For example, if you want to add new encryption algorithms, because their calculations are too complex and expensive, you can implement them as precompiled contracts, and the application contract can call it to use the new encryption algorithm. However, the permission to add precompiled contracts is not open to application developers, and it also needs to be "encapsulated" by the Ethereum development team through EIP before it can be added.

Arbitrum Stylus proposed the "EVM+" paradigm. While pursuing EVM equivalence/compatibility, Layer2 allows developers to break through the limitations of EVM and deploy higher-performance precompiled contracts without permission. Its implementation principle is to add a WASM execution environment to the execution layer to dynamically load and run WASM contracts. WASM provides an order of magnitude higher efficiency than EVM and also supports multiple programming languages.

It is one of the implementations that can optimize Ethereum's "packaging" problem. The expansion requirements of EVM no longer wait for the underlying team to encapsulate. The underlying team focuses on maintaining the execution layer expansion environment, while the introduction, development and governance of new functions are left to the application layer to develop.

However, Stylus is still in its early stages, and more challenges of this model have not yet been exposed. It can only solve limited problems. Currently, it only supports dynamic encapsulation of precompiled contracts, and Ethereum faces more encapsulation problems besides precompiled contracts. But the good news is that this is one of the implementations close to the Native Extension paradigm that we can see. As a representative of the new generation of infrastructure, it introduces scalability design to solve the "encapsulation" problem that their ecosystem will encounter in the future, taking into account long-term ecological development.

Native Extension: A "modular packaging" idea!

After reviewing the infrastructure projects such as Web2 and Web3, and looking back at the issue of "encapsulation vs. extension", we can see a clear idea: by improving the extensibility, developers can use a modular approach to encapsulate the functions they want.

This is the important role that the Native Extension paradigm plays in infrastructure. By improving the scalability of infrastructure, the choice is returned to developers, allowing developers to freely encapsulate and expand the functions they want in a modular way without affecting the stability of the core protocol.

Ethereum is trying to improve the efficiency of "packaging", Arbitrum Stylus is liberating precompiled contracts, and looking further ahead, the public chain can also completely liberate the creativity of the application layer through the Native Extension paradigm, just like what Uniswap V4 brings to everyone.

New L1 public chain based on Native Extension paradigm: Artela

Let's switch perspectives here. "We" refers to the team I work for as CTO: Artela. Let's share our thoughts and actions on this issue.

In Artela BlockchainIn addition to EVM, we have also installed a WASM execution environment. On the one hand, it can run a stateful program, similar to a stateful precompiled contract; on top of this, it supports a Hook-like mechanism that allows triggering execution at multiple lifecycle nodes in block and transaction processing. In other words, it is not just used to encapsulate precompiled contracts like Arbitrum Stylus, but can also customize the execution process of transactions and blocks to achieve a wider range of functional encapsulation. For example, in the transaction verification phase, the WASM Native Extension is triggered to use a new algorithm to identify and verify transactions. These Hooks are called Join Points in Artela, and these Native Extensions are not called SmartContracts, but Aspects, which are similar to the concept of AoP (Aspect-oriented Programming). In operationBlockchainIn the system, new functions are dynamically introduced into each Join Point!

For example, we have discussed with investors and Web2 institutions what is the biggest obstacle to large-scale asset import into Web3.SafetyProblem! Web2-level risk control technology protects billions of assetsSafety, but it is difficult to enter the Web3 technology stack. Carl, who comes from NASA's aerospace field, also expressed the same view: why do we need Runtime Procedure and Aspect.

Runtime Protection 是Safety风控的核心手段，现在的 Web3 里我们可以看到，一批很强的安全公司，既有静态审计又有形式化验证，有实时监控还可抢跑交易，这似乎是所有方法了，但距离 Web2 级别的实时风控还差远着，核心的根源问题是，围绕 mempool 的安全手段只有这么多了，因为交易一旦越过过了 Mempool 就无能为力了。在 Mempool 后的交易执行阶段，如果有扩展能力，让安全专家部署 runtime 级的安全策略，安全级别将会再上一个水平。而 Aspect，提供给开发者深入到执行层的安全扩展能力！

Developers can deploy Aspects that only serve their own projects to customize the protocol layer functions they need. For example, to increase runtime security, if a transaction could potentially result in a large amount of funds being stolen.steal, it will be intercepted in Aspect.

Developers can also deploy public aspects to encapsulate basic functions that can be reused by multiple projects. For example, an aspect implements a specific algorithm and transaction type, making the AA walletMore programmable and composable, other developers can also enable this Aspect and use this underlying feature for their own projects.

As for Artela, we have become more and more determined along the way:

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

Let big institutions and big funds with Web2 background dare to pledgeBlockchain(By introducing Web2-level runtime risk control enhancements)

Provide developers with a good ecological environment to do things that break the circle (EVM may soon reach its ceiling, and EVM+Native Extension may have more potential)

Provide an ideal home for full-chain games, RWA, and other dApps that want to move more business logic to the chain

We can see that Ethereum is at the stage of how to "encapsulate" application features, and there is no plan to relieve their "encapsulation" pressure and return creativity to developers. For this group of potential next-generation innovators who are brave enough to explore breakthrough innovations in decentralized applications, this situation is very constrained. On the one hand, they need such a robust decentralized network, and on the other hand, they are unable to do anything. This is the core reason why we are committed to building a new L1 public chain based on the Native Extension paradigm, so that the infrastructure does not reject the pace of innovation.

Import Web2

Finally, let me end this article with these two words. Although the decentralized Web3 stack and Web2 stack are completely different in terms of code writing, it does not prevent us from looking for treasures in the Web2 library in terms of design philosophy and development history. Keep building!

The article comes from the Internet:Interpretation of Vitalik’s blog post: Is the next stop for Web3 infrastructure encapsulation or expansion?

Related recommendations: MakerDAO Analysis: DAI Growth drivers and future challenges

MakerDAO increases its exposure to real world assets (RWAs). Written by: Kunal Compiled by: Xiaobai Navigation Coderworld In this article, I will examine Maker DAO and its stablecoin DAI. Since July 2023, MKR TokenIt has soared to nearly 90%. The reasons are as follows: Maker…