TokenPocket钱包安卓版官网|解读V神「封装or扩展」：Web3基础设施下步该左转右转？ | 动区动趋-最具影响力的区块链新闻媒体

本文将探讨 Web3 基础设施们对于「封装 vs 扩展」的设计取捨，以及作者对公链基础设施该议题上的一些思考，本文源自 Artela Network CTO CP 所着文章《封装还是扩展？探讨Web3基础设施的下一站》，由 BlockBeats 整理。 （前情提要：V神谈Layer2扩容全文：Rollup与Validiums（有效性验证）两者间权衡 ） （背景补充：V神最新长文：以太坊是否应该封装更多功能？ ）

本文目录

• 以太坊面临什么问题？封装 or 扩展
• 从 Unix 中还可以学到什么？Native Extension！
• Hook, Hook, Hooks…
• 新公链专案们的扩容思路
  • Arbitrum Stylus，让应用开发者自行封装预编译合约！
• Native Extension：一种「模组化封装」思路！
• 基于 Native Extension 正规化的新 L1 公链：Artela
• Import Web2

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 提到的，他们还在探索一个框架，如何确定要封装的目标功能以及如何封装它们。

Tags： 以太坊  Vitalik Bute  扩展  封装 

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处“来源演示站”。