—— 关于Vitalik Enshrinement博客的解读

作者：CP — — CTO & co-founder, Artela

Vitalik前周发布博客《Should Ethereum be okay with enshrining more things in the protocol?》，分享了对于以太坊“封装”（enshrine）上层应用所需的基础功能的思考，探讨如何建议一个框架去封装更多上层应用所需的基础功能。

这是典型的平台型系统都面临的关键问题：团队把关键上层应用功能“封装”进底层，还是由应用开发者在应用层去“扩展”（extend）这些功能。当基础设施发展到大规模扩展的前夕，“封装vs扩展”的设计十分关键，会是影响它能否大规模应用的关键设计之一。

近半年来，几大基础设施都推出了它们重要的技术更新：Uniswap推出Hook机制支持扩展自定义功能的pool；MetaMask钱包推出了Snaps支持开发者添加用户扩展；Ethereum如今也面临“封装vs扩展”的难题。

这篇文章将探讨Web3基础设施们对于“封装vs扩展”的设计取舍，以及个人对公链基础设施该问题上的一些思考。

以太坊面临什么问题？封装or扩展

在“封装vs扩展”的问题上，以太坊一直选择“扩展”。

以太坊的设计哲学源自于Unix，创建极简通用的内核，让用户需求在应用层通过开发者实现。支撑以太坊实现这一点的关键技术是：EVM。图灵完备的智能合约语言使开发者可以在应用层自定义各自应用。

这个模式看起来很合理，但它在“去中心化的Unix”上并不那么好使，重要的原因之一是：EVM所谓的图灵完备，实际使用上没那么“完备”。在gas机制和有限的opcode下，它要求程序在有限的步骤里利用有限的opcode去完成它的任务，就这点大大限制了应用难以像Web2程序在Unix的用户层中无所不能，很多高阶的dApp需要的能力EVM满足不了。无论是Rollup还是AA钱包，在不修改L1的情况下，他们虽然能跑通，但始终是MVP产物，效率和体验还是和他们的目标相距甚远。

摆在开发者面前的选择就是：EIP。把它依赖的重要功能，让以太坊核心团队把它“封装”进底层，从而提供给应用层使用。

基于EVM的“扩展”无法满足应用发展需求，现在他们需要好好考虑如何“封装”。

但去中心化的基础设施，要封装上层应用功能没那么简单，它不仅仅只是集成一段代码，背后是去中心化系统最大的难题：治理。“封装”意味着核心团队除了开发和维护外，还要承担这些功能的治理工作，同时会有削弱以太坊信任模型的风险，引入潜在影响可持续发展的问题。

所以最终的效果可以很容易看到：核心团队能“封装”的功能的数量有限，其次这个功能的重要性要得到社区大范围的共识，最后它的实现效率不会那么高，数以年计。

同时，这也意味着，如果你需要的功能不是得到广泛共识需要的基础功能，那么以太坊可能永远无法容纳你，甚至是你的尝试，可能你因此要去选择自建应用链，承受很高的开发和运营成本，失去智能合约世界可组合性的美妙。

在“封装vs扩展”的问题上，以太坊还没有明确的解决思路。如何让“封装”这件事情“有序开展”，也就是Vitalik提到的，他们还在探索一个框架，如何确定要封装的目标功能以及如何封装它们。

从Unix中还可以学到什么？Native Extension！

在“封装vs扩展”的问题上，以太坊主要是因为EVM的扩展能力不足导致需要核心团队做封装的事情来补位。我们换个角度想，如果提高应用层的可扩展性，是不是可以解决很大一部分问题了？比如：应用开发者可以按自己想法去为其应用定制所需底层功能，而无需等待底层团队封装。

我们也知道，以太坊从Unix吸取来很多设计哲学，那让我们继续Unix体系里找找思路。

基于 Unix的商用操作系统，它面向PC市场，面临更多应用层多样化的需求，甚至还有来自企业使用场景的扩展需求等。但这些商用操作系统，核心团队没有太高的“封装”负担，他们给应用提供的可扩展性足够高，使大部分的功能用户可以自己解决。

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

但Mac OS X允许应用开发者自主将程序部署进内核态，去扩展内核态的功能，而不需要Mac OS X的核心团队case by case去封装。Mac OS X提供的核心机制是“内核扩展”和“系统扩展”，这两种扩展允许开发者在一定的安全模式下开发内核扩展，使用更高权限的功能，去开发纯用户态应用完成不了的功能。

我们得到的启发是，“Kernel Extension”这种模式在“去中心化的Unix”上是否可行？它的模式如下图所示。

区块链协议上，除了支持“智能合约”外，还支持另外一种程序“Native Extension”，它

1）拥有比smart contract更多的底层协议API访问权限

2）且它的执行环境效率比EVM要有数量级别的提升

3）且它于底层协议有隔离性，不影响底层协议的稳定性

4）因此在治理方面它无需由底层团队维护，而由应用团队去维护部署

如果这个模型在技术上能满足以上四个点，似乎可以解决不少问题：应用开发者可以按自己想法去为其应用定制所需底层功能，而无需等待底层团队封装。

我们暂且把这个范式概括为“Native Extension”范式，接着看看现有Web3基础设施里面，有没有它的影子。

Hook, Hook, Hooks…

在软件世界里，伟大的轮子往往由伟大的场景造就。作为DeFi基础设施的Uniswap，处于在迈向成为“平台”的关键阶段，在“封装vs扩展”的特性上给出了令人惊艳设计：Hook。它允许开发者无需许可的利用Hook给pool添加扩展，实现功能多样化的pool体验，无需核心团队一直通过“封装”升级功能。

Hook的机制与上述Native Extension多个条件类似：

1. Hook能在pool的执行生命周期里切入，并且可以访问到运行时数据，这是更高级的访问级别
2. Hook与pool是两个独立的合约，Hook的安全性不影响pool
3. 治理方面，Hook由第三方开发者无需许可地开发部署，且不是全局激活，而是不同pool按需去绑定不同Hook以启动自定义特性。

Hook是小而美的设计，它解决pool的扩展性问题。应用层基础设施率先应用了这些概念，我们再继续再看看，复杂点的底层协议（L1/L2）的思路。

新公链项目们的扩展思路

Ethereum遇到麻烦，我们来看看致力于扩展Layer1的Layer2项目，有着什么样的想法。

Arbitrum Stylus，让应用开发者自行封装预编译合约！

大家应该都清楚，EVM可以通过“预编译合约”扩展功能，它的代码不是运行在EVM里面，而是集成在节点里，在底层运行。比如要添加新加密算法，因为它们计算太复杂太昂贵，可以实现为预编译合约，应用合约就可以调用它进而使用新加密算法。但是，预编译合约的增加权限不对应用开发者开放，也是需要通过EIP让以太坊开发团队“封装”才能加进去。

Arbitrum Stylus提出了“EVM+”范式，Layer2在追求EVM等效/兼容的同时，让开发者可以突破EVM的局限，无需许可地部署更高性能的预编译合约。它的实现原理是在执行层添加WASM执行环境，去动态加载运行WASM合约，WASM提供高于EVM一个数量级的效率，且还支持多种编程语言。

它是可以优化以太坊“封装”难题的实现之一了，EVM的扩展需求不再等待底层团队封装，底层团队专注于该执行层扩展环境的维护，而新功能的引入、开发和治理等交由应用层去发展。

不过Stylus还处于早期，这个模式更多的挑战还没暴露，且能解决的问题有限，目前只支持动态封装预编译合约，而以太坊还面临除预编译合约外的更多封装难题。但开心的是，这是我们可以看到的接近Native Extension范式实现之一了，作为新一代基础设施的代表，它引入可扩展性设计，去解决它们生态未来规模化将会遇到的“封装”难题，考虑到了长期生态发展。

Native Extension：一种“模块化封装”思路！

盘点了Web2和Web3这些基础设施项目，回过头来看“封装vs扩展”这个问题，我们可以看到一个清晰的思路就是：通过提高扩展能力，让开发者自己使用模块化的方式去封装他们要的功能。

这就是Native Extension范式在基础设施中扮演的重要角色，通过提高基础设施的扩展能力，从而把选择权交回给开发者，使得在不影响核心协议稳定性的前提下，开发者可以自由的用模块化的方式封装和拓展他们要的功能。

Ethereum在试图提升“封装”的效率，Arbitrum Stylus正在解放预编译合约，往再远的方向看，公链还可以通过Native Extension范式去彻底解放应用层的创造性，就如Uniswap V4给大家带来的感受那样。

基于Native Extension范式的新L1公链：Artela

这里切换一下视角，“我们”指我作为CTO所在的团队：Artela。我们分享下我们在这个问题上的思考和行动。

在Artela区块链上，除了EVM外，我们还安置了一个WASM执行环境。一方面它可以运行一个stateful的程序，类似有状态的预编译合约；另外在此之上，它支持一种类似Hook的机制，允许在区块和交易处理的多个生命周期节点触发运行。也就是说，它不仅仅只是和Arbitrum Stylus那样用于封装预编译合约，还可以定制交易和区块的执行流程，实现更广的功能封装。比如，在交易验证阶段里触发WASM的Native Extension，使用新的算法去识别和验证交易。这些Hook在Artela里称为Join Point，这些Native Extension不叫Smart Contract，而叫Aspect（切面），类似AoP（Aspect-oriented Programming）的概念，在运行中的区块链系统里，动态地在各个Join Point里切入新功能！

举个具体的例子，我们与投资者和Web2机构有过交流，让大规模资产导入Web3最大的阻力是什么，讨论最多的是安全问题！而Web2级别的风控技术保障了亿万资产安全，它却难以进入Web3技术堆栈。来自NASA航天领域的Carl，也发出观点相同的声音：为什么我们需要Runtime Proctection和Aspect。

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

开发者可以部署只服务于自己项目的Aspect，去定制它要的协议层功能。比如增加运行时安全，如果交易会潜在导致大额资金被盗，它会在Aspect里被拦截。

开发者也可以部署公共的Aspect，去封装多个项目可以复用的基础功能。比如某Aspect实现了特定算法和交易类型，使AA钱包更可编程可组合，其他开发者也可以启用这个Aspect，给自己项目用上这个底层特性。

对于Artela，我们一路过来想法愈发坚定：

• 让开发者在应用态可以通过Native Extension无需许可地解决问题，而非等待底层公链团队封装
• 让Web2背景的大机构大资金敢质押在区块链上（通过引入Web2级别的运行时风控增强）
• 让开发者有一个好的生态环境做破圈的事情（EVM可能很快到天花板，EVM+Native Extension可能潜力更多）
• 让全链游戏、RWA等想搬运更多业务逻辑上链的dApp，有个理想家园

我们看得到，Ethereum处于如何去“封装”应用特性的阶段，还看不到计划去解放他们的“封装”压力让创造性再一次回到开发者手上。对于勇于探索去中心化应用突破创新的这批潜在的下一代创新者而言，这局面是十分拘谨的，一方面他们需要这么一个健壮的去中心化网络，另外一方面他们施展不开手脚。这就是我们为什么致力于基于Native Extension范式构建一条新L1公链的核心原因，让基础设施不拒绝创新的脚步。

Import Web2

最后，用这两个词结束这篇文章。虽然在写代码层面，基于去中心化的Web3堆栈和Web2堆栈完全是两种思维，但不妨碍我们在设计哲学、发展历史层面去Web2这个图书馆里寻找宝藏，keep building！

关注Artela的Twitter并加入我们的Discord社区，以便及时了解Artela的最新动态。也可以在我们的网站上了解更多关于Artela的信息。