本文将探讨 Web3 基础设施们对於「封装 vs 扩展」的设计取舍，以及作者对公链基础设施该议题上的一些思考，本文源自 Artela Network CTO CP 所着文章《封装还是扩展？探讨Web3基础设施的下一站》，由 BlockBeats 整理。
（前情提要：V神谈Layer2扩容全文：Rollup与Validiums（有效性验证）两者间权衡 ）
（背景补充：V神最新长文：以太坊是否应该封装更多功能？ ）
本文目录
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 提到的，他们还在探索一个框架，如何确定要封装的目标功能以及如何封装它们。
延伸阅读：V神的权衡艺术：以太坊应该封装哪些功能？
从 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」，它
- 拥有比 smart contract 更多的底层协议 API 访问许可权
- 且它的执行环境效率比 EVM 要有数量级别的提升
- 且它於底层协议有隔离性，不影响底层协议的稳定性
- 因此在治理方面它无需由底层团队维护，而由应用团队去维护部署
如果这个模型在技术上能满足以上四个点，似乎可以解决不少问题：应用开发者可以按自己想法去为其应用订制所需底层功能，而无需等待底层团队封装。
我们暂且把这个正规化概括为「Native Extension」正规化，接着看看现有 Web3 基础设施里面，有没有它的影子。
Hook, Hook, Hooks…
在软体世界里，伟大的轮子往往由伟大的场景造就。作为 DeFi 基础设施的 Uniswap，处於在迈向成为「平台」的关键阶段，在「封装 vs 扩展」的特性上给出了令人惊艳设计：Hook。它允许开发者无需许可的利用 Hook 给 pool 新增扩展，实现功能多样化的 pool 体验，无需核心团队一直通过「封装」升级功能。
Hook 的机制与上述 Native Extension 多个条件类似：
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 正规化实现之一了，作为新一代基础设施的代表，它引入可扩容性设计，去解决它们生态未来规模化将会遇到的「封装」难题，考虑到了长期生态发展。
延伸阅读：Arbitrum代币跌跌不休，团队分享了Layer2的激烈竞争心得
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，我们一路过来想法愈发坚定：
延伸阅读：RWA资料报告：推动区块链采用的真正力量
我们看得到，Ethereum 处於如何去「封装」应用特性的阶段，还看不到计划去解放他们的「封装」压力让创造性再一次回到开发者手上。对於勇於探索去中心化应用突破创新的这批潜在的下一代创新者而言，这局面是十分拘谨的，一方面他们需要这麽一个健壮的去中心化网路，另外一方面他们施展不开手脚。这就是我们为什麽致力於基於 Native Extension 正规化构建一条新 L1 公链的核心原因，让基础设施不拒绝创新的脚步。
Import Web2
最後，用这两个词结束这篇文章。虽然在写程式码层面，基於去中心化的 Web3 堆叠和 Web2 堆叠完全是两种思维，但不妨碍我们在设计哲学、发展历史层面去 Web2 这个图书馆里寻找宝藏，keep building！
📍相关报导📍
V神提出Lido「垄断」解法：将以太坊质押模型一分为二
V神开炮CBDC发展：牺牲用户隐私是错误，沦为传统银行前端
以太坊坎昆升级跳票！原定2023年底，因测试网共识问题再延2024年