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

作者：CP，Artela CTO & co-founder

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 多個條件類似：

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

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

· 治理方面，Hook 由第三方開發者無需許可地開發部署，且不是全局激活，而是不同 pool 按需去綁定不同 Hook 以啟動自定義特性。

Hook 是小而美的設計，它解決 pool 的擴展性問題。應用層基礎設施率先應用了這些概念，我們再繼續再看看，複雜點的底層協定（L1/L2）的思路。

新公鏈專案們的擴展思路

Ethereum 遇到麻煩，我們來看看致力於擴展 Layer 1 的 Layer 2 專案，有著什麼樣的想法。

Arbitrum Stylus，讓應用開發者自行封裝預編譯合約！

大家應該都清楚，EVM 可以通過「預編譯合約」擴展功能，它的代碼不是運行在 EVM 裡面，而是集成在節點裡，在底層運行。比如要添加新加密算法，因為它們計算太複雜太昂貴，可以實現為預編譯合約，應用合約就可以調用它進而使用新加密算法。但是，預編譯合約的增加許可權不對應用開發者開放，也是需要通過 EIP 讓以太坊開發團隊「封裝」才能加進去。

Arbitrum Stylus 提出了「EVM+」範式，Layer 2 在追求 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！