本文將探討 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 的執行生命週期裡切入，並且可以訪問到執行時資料，這是更高階的訪問級別
- 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 正規化實現之一了，作為新一代基礎設施的代表，它引入可擴容性設計，去解決它們生態未來規模化將會遇到的「封裝」難題，考慮到了長期生態發展。
延伸閱讀：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，我們一路過來想法愈發堅定：
- 讓開發者在應用態可以通過 Native Extension 無需許可地解決問題，而非等待底層公鏈團隊封裝
- 讓 Web2 背景的大機構大資金敢質押在區塊鏈上（通過引入 Web2 級別的執行時風控增強）
- 讓開發者有一個好的生態環境做破圈的事情（EVM 可能很快到天花板，EVM+Native Extension 可能潛力更多）
- 讓全鏈遊戲、RWA 等想搬運更多業務邏輯上鏈的 dApp，有個理想家園
延伸閱讀：RWA資料報告：推動區塊鏈採用的真正力量
我們看得到，Ethereum 處於如何去「封裝」應用特性的階段，還看不到計劃去解放他們的「封裝」壓力讓創造性再一次回到開發者手上。對於勇於探索去中心化應用突破創新的這批潛在的下一代創新者而言，這局面是十分拘謹的，一方面他們需要這麼一個健壯的去中心化網路，另外一方面他們施展不開手腳。這就是我們為什麼致力於基於 Native Extension 正規化構建一條新 L1 公鏈的核心原因，讓基礎設施不拒絕創新的腳步。
Import Web2
最後，用這兩個詞結束這篇文章。雖然在寫程式碼層面，基於去中心化的 Web3 堆疊和 Web2 堆疊完全是兩種思維，但不妨礙我們在設計哲學、發展歷史層面去 Web2 這個圖書館裡尋找寶藏，keep building！
