首頁

Partnered With:

Vitalik部落格解讀：Web3基礎架構的下一站是封裝還是擴充？

閱讀本文需 21 分鐘

本文將探討 Web3 基礎設施們對於「封裝 vs 擴充」的設計取捨，以及個人對公鏈基礎設施該議題上的一些思考

原文標題：封裝還是擴充？探討Web3 基礎設施的下一站－關於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 市場，面臨更多應用層多樣化的需求，甚至還有來自企業使用場景的擴展需求等。但這些商用作業系統，核心團隊沒有太高的「封裝」負擔，他們給應用程式提供的可擴展性足夠高，使大部分的功能使用者可以自己解決。

以MacMac OS X 舉例，一般作業系統區分核心態作業系統和用戶態，用戶應用程式一般運行在用戶態，使用由內核態程式提供的功能。一個簡單（但不完全）的對比是，EVM 之上的智能合約都相當於用戶態的應用，以太坊協定層相當於內核態。

但Mac OS X 允許應用開發者自主將程式部署進核心態，去擴充核心態的功能，而不需要Mac OS X 的核心團隊case by case 去封裝。 Mac OS X 提供的核心機制是「核心擴展」和「系統擴展」，這兩種擴展允許開發者在一定的安全模式下開發核心擴展，使用更高權限的功能，去開發純用戶態應用完成不了的功能。

我們得到的啟發是，「Kernel Extension」這種模式在「去中心化的 Unix」上是否可行？它的模式如下圖所示。

區塊鏈協議上，除了支援「智能約」外，還支援另外一種程式「Native Extension」，它

1）擁有比smart contract 更多的底層協定API 存取權

< p>

2）且它的執行環境效率比EVM 要有數量等級的提升

3）且它於底層協定有隔離性，不影響底層協定的穩定性

4）因此在治理方面它不需要由底層團隊維護，而由應用團隊去維護部署

如果這個模型在技術上能滿足以上四個點，似乎可以解決不少問題：應用開發者可以按自己想法去為其應用定制所需底層功能，而無需等待底層團隊封裝。

我們暫且把這個範式概括為「Native Extension」範式，接著看看現有 Web3 基礎設施裡面，有沒有它的影子。

Hook, Hook, Hooks…

在軟體世界裡，偉大的輪子往往由偉大的場景造就。作為 DeFi 基礎設施的 Uniswap，處於在邁向成為「平台」的關鍵階段，在「封裝 vs 擴展」的特性上給出了令人驚艷設計：Hook。它允許開發者無需許可的利用 Hook 為 pool 添加擴展，實現功能多樣化的 pool 體驗，無需核心團隊一直透過「封裝」升級功能。

Hook 的機轉與上述Native Extension 多個條件類似：

· Hook 能在pool 的執行生命週期裡切入，並且可以存取到運行時數據，這是更高級的存取等級

· Hook 與pool 是兩個獨立的合約，Hook 的安全性不影響pool

· 治理方面，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">

在Artela 區塊鏈外，我們除了EVM">

在Artela 區塊鏈外，我們也安置了一個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 公鏈的核心原因，讓基礎設施不拒絕創新的腳步。