Interpretation of Vitaliks blog post: Is the next stop for Web3 infrastructure encapsulation or extension?
Original title: Encapsulation or Extension? The next stop to discuss Web3 infrastructure - interpretation of Vitalik Enshrinement blog
Original author: CP, Artela CTO co-founder
Vitalik published a blog Should Ethereum be okay with enshrining more things in the protocol? last week, sharing his thoughts on the basic functions required for Ethereums enshrine upper-layer applications, and discussing how to recommend a framework to encapsulate more Basic functions required by upper-layer applications.
This is a key issue faced by typical platform systems: 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 develops to large-scale expansion, the design of encapsulation vs. extension is very critical and will be one of the key designs that affects whether it can be applied on a large scale.
In the past six months, several major infrastructures have launched important technical updates: Uniswap launched a Hook mechanism to support pools that extend custom functions; MetaMask wallet launched Snaps to support developers to add user extensions; Ethereum is now also facing encapsulation vs. extension difficult problem.
This article will discuss the design choices of encapsulation vs. extension of Web3 infrastructure, as well as some personal thoughts on this issue of public chain infrastructure.
What problems does Ethereum face? Encapsulate or extend
On the issue of encapsulation vs extension, Ethereum has always chosen extension.
The design philosophy of Ethereum originates from Unix, creating a minimalist and universal kernel to allow user needs to be realized by developers at the application layer. The key technology that supports Ethereum to achieve this is: EVM. Turing-complete smart contract language allows developers to customize their applications at the application layer.
This model seems reasonable, but it does not 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 opcode, it requires the program to use limited opcode in limited steps to complete its tasks. This greatly limits the application and makes it difficult to be omnipotent like Web2 programs in the user layer of Unix. Many high-level applications The capabilities required by high-level dApps cannot be met by EVM. Whether it is Rollup or AA wallet, although they can run smoothly without modifying L1, they are still MVP products, 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 depends on into the bottom layer, thereby providing them for use by the application layer.
EVM-based extensions cannot meet application development needs, and now they need to carefully consider how to encapsulate them.
However, it is not that simple for decentralized infrastructure to encapsulate upper-layer application functions. It is not just about integrating a piece of code. Behind it is the biggest problem of decentralized systems: governance. Encapsulation means that in addition to development and maintenance, the core team must also be responsible for the governance of these functions. At the same time, there is a risk of weakening the trust model of Ethereum and introducing problems that may potentially affect sustainable development.
So the final effect can be easily seen: there is a limited number of functions that the core team can encapsulate. Secondly, the importance of this function needs to be widely recognized by the community. Finally, its implementation efficiency will not be so high, and it will take several years. .
At the same time, this also means that if the functions you need are not basic functions that are widely recognized, then Ethereum may never be able to accommodate you, even if you try, you may have to choose to build your own application chain and bear a high cost. development and operation costs, and lose the beauty of composability in the smart contract world.
On the issue of encapsulation vs extension, Ethereum has not yet had a clear solution. How to make encapsulation happen in an orderly manner is what Vitalik mentioned. They are still exploring a framework, how to determine the target functions to be encapsulated and how to encapsulate them.
What else can you 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 lack of expansion capabilities of the EVM. Let’s 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 underlying functions required for their applications according to their own ideas without waiting for the underlying team to encapsulate them.
We also know that Ethereum has absorbed many design philosophies from Unix, so let us continue to look for ideas in the Unix system.
A commercial operating system based on Unix, it is oriented to the PC market and faces more diversified demands on the application layer, and even expansion demands from enterprise usage scenarios. But for these commercial operating systems, the core team does not have a high encapsulation burden. The scalability they provide for applications is high enough so that users can solve most functions by themselves.
Taking Mac OS X as an example, general operating systems distinguish between kernel mode and user mode. User applications generally run in user mode and use functions provided by kernel mode programs. A simple (but incomplete) comparison is that smart contracts on EVM are equivalent to user-mode applications, and the Ethereum protocol layer is equivalent to kernel-mode.
However, Mac OS X allows application developers to independently deploy programs into the kernel state to expand the functions of the kernel state without requiring the Mac OS The core mechanisms provided by Mac OS function.
The inspiration we got is, is the Kernel Extension model feasible on decentralized Unix? Its pattern is shown in the figure below.
In addition to supporting smart contracts, the blockchain protocol also supports another program Native Extension, which
1) Has more underlying protocol API access rights than smart contracts
2) And its execution environment efficiency is orders of magnitude higher than that of EVM.
3) And 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 is maintained and deployed by the application team.
If this model can technically meet the above four points, it seems that it can 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 it.
Lets summarize this paradigm as the Native Extension paradigm for the time being, and then look at whether there is any shadow of it in the existing Web3 infrastructure.
Hook, Hook, Hooks…
In the software world, great wheels are often created by great scenarios. As DeFi infrastructure, Uniswap is in the critical stage of becoming a platform and has an amazing design on the characteristics of encapsulation vs expansion: Hook. It allows developers to use Hooks to add extensions to the pool without permission to achieve a functionally diverse pool experience, without the need for the core team to constantly upgrade functions through encapsulation.
The mechanism of Hook is similar to the above-mentioned Native Extension multiple conditions:
· Hook can cut into the execution life cycle of the pool and can access runtime data. This is a more advanced access level.
· Hook and pool are two independent contracts, and the security of Hook 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 as needed to activate custom features.
Hook is a small but beautiful design that solves the scalability problem of the pool. The application layer infrastructure took the lead in applying these concepts. Lets continue and look at the ideas of the more complicated underlying protocols (L1/L2).
Expansion ideas of new public chain projects
Ethereum is in trouble, lets take a look at the ideas of Layer 2 projects dedicated to extending Layer 1.
Arbitrum Stylus allows application developers to package precompiled contracts by themselves!
Everyone should know that EVM can expand 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 they are too complex and expensive to calculate, you can implement it as a precompiled contract, and the application contract can call it and use the new encryption algorithm. However, the added permissions of the precompiled contract are not open to application developers, and they need to be encapsulated by the Ethereum development team through EIP before they can be added.
Arbitrum Stylus proposed the EVM+ paradigm. Layer 2, while pursuing EVM equivalence/compatibility, allows developers to break through the limitations of EVM and deploy higher-performance precompiled contracts without permission. Its implementation principle is to add the 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 the encapsulation problem of Ethereum. The expansion requirements of EVM no longer wait for the bottom team to encapsulate. The bottom team focuses on the maintenance of the execution layer extension environment, while the introduction, development and governance of new functions are exchanged. It is developed by the application layer.
However, Stylus is still in its early stages. More challenges of this model have not yet been exposed, and the problems it can solve are limited. Currently, it only supports dynamic packaging of precompiled contracts, and Ethereum also faces more packaging problems besides precompiled contracts. But happily, this is one of the implementations we can see that is close to the Native Extension paradigm. As a representative of the new generation of infrastructure, it introduces scalability design to solve the encapsulation problems that their ecosystem will encounter in the future scale. ” problem, taking into account long-term ecological development.
Native Extension: A modular encapsulation idea!
After taking stock of infrastructure projects such as Web2 and Web3, looking back at the question of encapsulation vs. extension, we can see a clear idea: by improving expansion capabilities, developers can use modular methods to encapsulate what they want. function.
This is the important role that the Native Extension paradigm plays in infrastructure. By improving the scalability of the infrastructure, the choice is returned to developers, so that developers can freely use it without affecting the stability of the core protocol. Modular approach to encapsulate and expand their desired functions.
Ethereum is trying to improve the efficiency of encapsulation, and Arbitrum Stylus is liberating pre-compiled contracts. Looking further ahead, public chains can also completely liberate the creativity of the application layer through the Native Extension paradigm, just like what Uniswap V4 brings to everyone. Feel that way.
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 us share our thoughts and actions on this issue.
On the Artela blockchain, in addition to the EVM, we also installed a WASM execution environment. On the one hand, it can run a stateful program, similar to a stateful precompiled contract; on the other hand, it supports a Hook-like mechanism, allowing it to be triggered at multiple life cycle nodes of block and transaction processing. In other words, it is not only used to encapsulate precompiled contracts like Arbitrum Stylus, but can also customize the execution process of transactions and blocks to achieve wider functional encapsulation. For example, WASMs Native Extension is triggered during the transaction verification phase and new algorithms are used to identify and verify transactions. These Hooks are called Join Points in Artela, and these Native Extensions are not called Smart Contracts, but Aspects. They are similar to the concept of AoP (Aspect-oriented Programming). In the running blockchain system, they are dynamically New features are added to Join Point!
To give a specific example, we have communicated with investors and Web2 institutions to find out what is the biggest obstacle to importing large-scale assets into Web3. The most discussed issue is security! While Web2-level risk control technology ensures the security of billions of assets, it is difficult to enter the Web3 technology stack. Carl, who comes from NASAs aerospace field, also expressed the same view: why we need Runtime Proctection and Aspect.
Runtime Protection is the core method of security risk control. In todays Web3, we can see that a group of very strong security companies have both static auditing and formal verification, real-time monitoring and front-running transactions. This seems to be all method, but it is still far from Web2-level real-time risk control. The core root problem is that there are only so many security methods around mempool, because once a transaction crosses Mempool, there is nothing it can do. In the transaction execution phase after Mempool, if there is expansion capability and security experts can deploy runtime-level security policies, the security level will be raised to a higher level. Aspect provides developers with security extension capabilities that go deep into the execution layer!
Developers can deploy aspects that only serve their own projects to customize the protocol layer functions they want. For example, to increase runtime security, if a transaction potentially leads to the theft of large amounts of funds, it will be blocked in Aspect.
Developers can also deploy public aspects to encapsulate basic functions that can be reused by multiple projects. For example, an Aspect implements specific algorithms and transaction types, making the AA wallet more programmable and combinable. Other developers can also enable this Aspect and use this underlying feature for their own projects.
As for Artela, our thoughts have become more and more determined along the way:
· Allow developers to solve problems without permission through Native Extension in the application state, instead of waiting for the underlying public chain team to encapsulate it
· Let large institutions with Web2 background dare to pledge large amounts of money on the blockchain (enhanced by introducing Web2-level runtime risk control)
· Allow developers to have a good ecological environment to do things that break the circle (EVM may reach the ceiling soon, and EVM+Native Extension may have more potential)
· Let full-chain games, RWA and other dApps that want to move more business logic onto the chain have an ideal home
We can see that Ethereum is at the stage of how to encapsulate application features, and there is no plan to release their encapsulation pressure and let creativity return to the hands of developers again. For this group of potential next-generation innovators who are brave enough to explore breakthrough innovations in decentralized applications, this situation is very restrictive. On the one hand, they need such a robust decentralized network, but on the other hand, they cannot use their hands and feet. 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 resist the pace of innovation.
Import Web2
Finally, end this article with these two words. Although at the level of writing code, the decentralized Web3 stack and the Web2 stack are completely two different ideas, it does not prevent us from looking for treasures in the Web2 library in terms of design philosophy and development history. Keep building!
