作者：Vitalik Buterin 編譯：Odaily星球日報 念銀思唐
特別感謝 Justin Drake, Tina Zhen 和 Yoav Weiss 的反饋和審查。
從以太坊項目开始，就有一個強烈的理念，即試圖使核心以太坊盡可能簡單，並通過在其上構建協議來盡可能實現這一點。在區塊鏈領域，“在L1上構建”與“專注於L2”的爭論通常被認爲主要是關於擴展的，但實際上，在滿足多種以太坊用戶的需求方面存在類似的問題：數字資產交換、隱私、用戶名、高級加密、账戶安全、抗審查、搶先交易保護，等等。然而，最近有一些謹慎的想法愿意將更多這些功能封裝（enshrine）進核心以太坊協議中。
這篇文章將深入探討最初的最小封裝哲學背後的一些哲學推理，以及一些最近思考這些想法的方法。目標將是开始建立一個框架，以便更好地確定可能的目標，在這些目標中，封裝某些功能可能值得考慮。
關於協議極簡主義的早期哲學
在當時被稱爲“以太坊 2.0 ”的早期歷史中，人們強烈希望創建一個幹淨，簡單和美觀的協議，該協議盡可能少地嘗試通過自身來構建，並將幾乎所有這類工作都留給用戶。理想情況下，協議只是一個虛擬機，而驗證一個區塊只是一個虛擬機調用。
這是我和 Gavin Wood 在 2015 年初繪制白板圖的近似重建，當時我在談論以太坊 2.0 的樣子。
“狀態轉換函數”（處理區塊的函數）將只是單個 VM 調用，所有其他邏輯將通過合約發生：一些系統級合約，但主要是由用戶提供的合約。這個模型的一個非常好的功能是，即使是整個硬分叉也可以被描述爲對於區塊處理器合約而言的單筆交易，該交易將通過鏈下或鏈上治理進行批准，然後以升級的權限運行。
2015 年的這些討論特別適用於我們考慮的兩個領域：账戶抽象和擴容。在擴容的情況下，我們的想法是嘗試創建一個最大程度的抽象形式的擴容，感覺就像上面圖表的自然擴展。合約可以調用大多數以太坊節點未存儲的數據，協議將檢測到這一點，並通過某種非常通用的擴展計算功能來解決調用。從虛擬機的角度來看，該調用將進入某個單獨的子系統，然後一段時間後神奇地返回正確的答案。
我們對這種思路進行了簡短的探索，但很快就放棄了，因爲我們太專注於驗證任何類型的區塊鏈擴容都是可能的。盡管我們稍後會看到，數據可用性採樣和 ZK-EVM 的結合意味着以太坊擴容的一個可能的未來實際上看起來非常接近這個愿景！另一方面，對於帳戶抽象，我們從一开始就知道某種實現是可能的，因此研究立即开始嘗試使一些盡可能接近“交易只是一個調用”的純粹出發點的東西變爲現實。
在處理交易和從發送方地址發出實際的底層 EVM 調用之間，會出現大量的樣板代碼，之後還會出現更多的樣板代碼。我們如何將這些代碼盡可能減少到接近於零？
這裏的主要代碼之一是 validate_transaction(state, tx)，它負責檢查交易的 nonce 和籤名是否正確。從一开始，帳戶抽象的實際目標就是允許用戶用自己的驗證邏輯替換基本的非增量驗證和 ECDSA 驗證，這樣用戶就可以更輕松地使用社交恢復和多籤名錢包等功能。因此，找到一種方法將 apply_transaction 重新架構爲一個簡單的 EVM 調用，這不僅僅是一個“爲了使代碼幹淨而使代碼幹淨”的任務；相反，它是關於將邏輯移動到用戶的帳戶代碼中，爲用戶提供所需的靈活性。
然而，堅持讓 apply_transaction 包含盡可能少的固定邏輯的做法最終帶來了很多挑战。我們可以看下最早的帳戶抽象提案之一 EIP-86 。
如果按原樣包含 EIP-86 ，它將降低 EVM 的復雜性，代價是大量增加以太坊堆棧其他部分的復雜性，需要在其他地方編寫本質上完全相同的代碼，除了引入全新的怪異類別之外，例如具有相同哈希值的同一交易可能會在鏈中多次出現，更不用說多重失效問題了。
账戶抽象中的多重失效問題。在鏈上包含的一筆交易可能會使內存池中的數千筆其他交易無效，從而使內存池很容易被廉價地充斥。
從那時起，帳戶抽象分階段發展。EIP-86 後來變成了 EIP-208 ，最終出現了實際可行的 EIP-2938 。
然而，EIP-2938 一點也不簡約。其內容包括：
新的交易類型
三個新交易範圍的全局變量
兩個新的操作碼，包括非常笨拙的 PAYgas 操作碼，用於處理 gas 價格和 gas 限制檢查，作爲 EVM 執行斷點，以及臨時存儲 ETH 以一次性支付費用
一組復雜的挖礦和轉播策略，包括交易驗證階段禁止的操作碼列表
爲了在不涉及以太坊核心开發人員（專注於優化以太坊客戶端和實現合並）的情況下實現账戶抽象，EIP-2938 最終被重新架構爲完全是協議外的 ERC-4337 。
ERC-4337 。它確實完全依賴於 EVM 調用！
因爲這是一個 ERC，它不需要硬分叉，並且在技術上存在於“以太坊協議之外”。所以……問題解決了嗎？事實證明並非如此。ERC-4337 當前的中期路线圖實際上涉及最終將 ERC-4337 的大部分轉變爲一系列協議功能，這是一個有用的指導示例，可以了解爲什么要考慮這條路徑。
封裝 ERC-4337
有幾個關鍵原因討論了最終將 ERC-4337 重新納入協議：
gas 效率：在 EVM 內部進行的任何操作都會導致一定程度的虛擬機开銷，包括在使用諸如存儲槽之類 gas 費昂貴的功能時效率低下。目前，這些額外的低效率加起來至少要消耗 2 萬 gas，甚至更多。將這些組件放入協議中是消除這些問題的最簡單方法。
代碼 bug 風險：如果 ERC-4337 “入口點合約”有一個足夠可怕的 bug，所有與 ERC-4337 兼容的錢包都可能看到他們所有的資金枯竭。用協議內功能取代合約會產生一種隱含的責任，即通過硬分叉修復代碼錯誤，從而消除用戶的資金枯竭風險。
支持 EVM 操作碼，如 txt.origin。ERC-4337 本身使 txt.origin 返回將一組用戶操作打包到交易中的“捆綁器（bundler）”的地址。原生帳戶抽象可以解決這個問題，方法是使 txt.origin 指向發送交易的實際帳戶，使其運作方式與 EOA 相同。
抗審查：提議者/構建者分離的挑战之一是審查單筆交易變得更容易。在以太坊協議可以識別單筆交易的世界中，包含列表可以極大地緩解這個問題，該列表允許提議者指定在幾乎所有情況下必須包含在接下來兩個插槽中的交易列表。但是協議外的 ERC-4337 將“用戶操作”封裝在單筆交易中，使得用戶操作對以太坊協議不透明；因此，以太坊協議提供的包含列表將無法對 ERC-4337 用戶操作提供審查阻力。封裝 ERC-4337 ，並使用戶操作成爲一種“適當的”交易類型，將解決這個問題。
值得一提的是，在目前的形式下，ERC-4337 比“基本”以太坊交易要貴得多：交易成本爲 21, 000 gas，而 ERC-4337 的成本約爲 42, 000 gas。
理論上，應該有可能對 EVM gas 成本系統進行調整，直到協議內成本和協議外訪問存儲的成本相匹配；當其他類型的存儲編輯操作更便宜時，轉移 ETH 沒有理由需要花費 9000 gas。事實上，與即將到來的 Verkle 樹轉換相關的兩個 EIP 實際上試圖做到這一點。但是，即使我們這樣做了，有一個顯而易見的原因可以解釋爲什么無論 EVM 變得多么高效，封裝的協議功能都將不可避免地比 EVM 代碼便宜得多：封裝代碼不需要爲預加載支付 gas。
功能齊全的 ERC-4337 錢包很大，編譯並放到鏈上的這個實現佔用了約 12, 800 字節。當然，你可以一次部署這段代碼，並使用 DELEGATECALL 來允許每個單獨的錢包調用它，但是仍然需要在使用它的每個區塊中訪問該代碼。在 Verkle 樹 gas 成本 EIP 下， 12, 800 字節將組成 413 個 chunk，訪問這些 chunk 將需要支付 2 倍的 witness branch_cost（總共 3, 800 gas）和 413 倍的 witness chunk_cost（總共 82, 600 gas）。這甚至還沒有开始提到 ERC-4337 入口點本身，在 0.6.0 版本中，鏈上有 23, 689 字節（根據 Verkle 樹 EIP 規則，約有 158, 700 個 gas 要加載）。
這就導致了一個問題：實際訪問這些代碼的 gas 成本必須以某種方式在交易中分攤。ERC-4337 使用的當前方法不是很好：bundle 中的第一筆交易消耗了一次性存儲/代碼讀取成本，使其比其他交易昂貴得多。協議內封裝將允許這些公共共享庫成爲協議的一部分，所有人都可以免費訪問。
我們能從這個例子中學到什么，什么時候更普遍地進行封裝？
在這個例子中，我們看到了在協議中封裝账戶抽象方面的一些不同的基本原理。
當固定成本較高時，“將復雜性推向邊緣”的基於市場的方法最容易失敗。事實上，長期的账戶抽象路线圖看起來每個區塊都有很多固定的成本。244, 100 gas 用於加載標准化錢包代碼是一回事；但是聚合可能會爲 ZK-SNARK 驗證增加數十萬的 gas，以及證明驗證的鏈上成本。沒有一種方法可以在不引入大量市場低效率的情況下向用戶收取這些成本，而將其中一些功能轉化爲所有人都可以免費訪問的協議功能則可以很好地解決這個問題。
社區範圍內對代碼 bug 的響應。如果一些代碼片段被所有用戶或非常廣泛的用戶使用，那么區塊鏈社區承擔硬分叉的責任來修復出現的任何錯誤通常更有意義。ERC-4337 引入了大量的全局共享代碼，從長遠來看，通過硬分叉修復代碼中的錯誤無疑比導致用戶損失大量 ETH 更合理。
有時，可以通過直接利用協議的功能來實現其更強形式。這裏的關鍵例子是協議內的抗審查功能，如包含列表：協議內的包含列表可以比協議外的方法更好地保證審查阻力，爲了使用戶級操作真正受益於協議內的包含列表，單個用戶級操作需要對協議“易讀”。另一個鮮爲人知的例子是， 2017 年時代的以太坊權益證明設計對權益密鑰進行了账戶抽象，這被放棄了並轉而支持封裝 BLS，因爲 BLS 支持一種“聚合”機制，必須在協議和網絡層面實現，這可以使處理大量籤名的效率更高。
但重要的是要記住，與現狀相比，即使是封裝協議內账戶抽象，仍然是一種巨大的“去封裝化”。如今，頂級以太坊交易只能從外部擁有的账戶（EOA）發起，這些账戶使用單個 secp 256 k 1 橢圓曲线籤名進行驗證。帳戶抽象消除了這一點，並將驗證條件留給用戶自行定義。因此，在這個關於账戶抽象的故事中，我們也看到了反對封裝的最大理由：靈活地滿足不同用戶的需求。
讓我們通過查看最近被考慮封裝的其他幾個特徵示例來進一步充實這個故事。我們將特別關注：ZK-EVM，提議者-構建者分離，私有內存池，流動性質押和新的預編譯。
封裝 ZK-EVM
讓我們把注意力轉移到以太坊協議的另一個潛在封裝目標：ZK-EVM。目前，我們有大量的 ZK-rollup，它們都必須編寫相當相似的代碼來驗證 ZK-SNARK 中類似以太坊區塊的執行。有一個相當多樣化的獨立實現生態系統：PSE ZK-EVM、Kakarot、Polygon ZK-EVM、Linea、Zeth 等等。
EVM ZK-rollup 領域最近的一個爭議與如何處理 ZK 代碼中可能出現的 bug 有關。目前，所有這些正在運行的系統都有某種形式的“安全理事會”機制，可以在出現 bug 的情況下控制證明系統。去年，我試圖創建一個標准化的框架，以鼓勵項目明確他們對證明系統的信任程度，以及對安全理事會的信任程度，並隨着時間的推移，逐漸減少對該組織的權力。
從中期來看，rollup 可能依賴於多個證明系統，而安全理事會只有在兩個不同的證明系統產生分歧的極端情況下才有權力。
然而，有一種感覺是，其中一些工作感覺是多余的。我們已經有了以太坊基礎層，它有一個 EVM，我們已經有了一個處理實現中 bug 的工作機制：如果有 bug，客戶端將進行更新來修復，然後鏈繼續運作。從有 bug 的客戶端角度來看，似乎已經最終確認的區塊將不再確認，但至少我們不會看到用戶損失資金。同樣，如果 rollup 只是想保持與 EVM 等同的作用，那么它們需要實施自己的治理來不斷更改其內部 ZK-EVM 規則以匹配對以太坊基礎層的升級，這感覺是錯誤的，因爲最終它們是在以太坊基礎層本身之上構建的，它知道何時升級以及根據什么新規則。
由於這些L2 ZK-EVM 基本上使用與以太坊完全相同的 EVM，我們能否以某種方式將“驗證 EVM 在 ZK 中的執行”納入協議功能，並通過應用以太坊的社會共識來處理異常情況，如 bug 和升級，就像我們已經爲基礎層 EVM 執行本身所做的那樣？
這是一個重要而富有挑战性的話題。
關於原生 ZK-EVM 中數據可用性的一個可能的爭論主題是有狀態性（statefulness）。如果 ZK-EVM 不需要攜帶“見證（witness）”數據，它們的數據效率就會高得多。也就是說，如果某個特定的數據已經在之前的某個區塊中被讀取或寫入，我們可以簡單地假設證明者可以訪問它，並且不必再次使它可用。這不僅僅是不重新加載存儲和代碼；事實證明，如果一個 rollup 正確地壓縮了數據，那么與無狀態壓縮相比，有狀態壓縮最多可以節省 3 倍的數據。
這意味着對於 ZK-EVM 預編譯，我們有兩個選項：
1.預編譯要求所有數據在同一區塊中可用。這意味着 prover 可以是無狀態的，但也意味着使用這種預編譯的 ZK-rollup 比使用自定義代碼的 rollup 要昂貴得多。
2.預編譯允許 pointer 指向先前執行使用或生成的數據。這使得 ZK-rollup 接近最優，但它更復雜，並引入了一種必須由 prover 存儲的新狀態。
我們能從中學到什么？以某種方式將 ZK-EVM 驗證封裝有一個很好的理由：rollup 已經在構建自己的自定義版本，並且以太坊愿意將其多個實現和鏈下社會共識的權重置於L1上執行 EVM，這感覺是錯誤的，但是做完全相同工作的L2必須實現涉及安全理事會的復雜小工具。但另一方面，細節中有一個大問題：有不同版本的 ZK-EVM，它們的成本和收益不同。有狀態和無狀態的區分只是觸及了表面；嘗試支持“近 EVM（almost-EVM）”，這些定制代碼已經被其他系統證明，這可能會暴露出更大的設計空間。因此，封裝 ZK-EVM 既帶來了希望，也帶來了挑战。
封裝提議者與構建者分離（ePBS）
MEV 的興起使區塊生產成爲一種大規模經濟活動，復雜的參與者能夠生產出比默認算法產生更多收入的區塊，而默認算法只是觀察交易的內存池並包含它們。到目前爲止，以太坊社區試圖通過使用 MEV-Boost 等協議外的提議者-構建者分離（proposer-builder separation）方案來解決這個問題，該方案允許常規驗證者（“提議者”）將區塊構建外包給專門的參與者（“構建者”）。
然而，MEV-Boost 在一個新的參與者類別中進行了信任假設，稱爲中繼（relay）。在過去的兩年裏，有很多人提議創建“封裝 PBS”。這樣做的好處是什么？在這種情況下，答案非常簡單：通過直接使用協議功能構建的 PBS 比不使用它們構建的 PBS 更強大（在具有更弱的信任假設的意義上）。這與封裝協議內價格預言機的情況類似——盡管在這種情況下，也存在強烈的反對意見。
封裝私有內存池
當用戶發送交易時，該交易立即公开並對所有人可見，甚至在它被包含在鏈上之前。這使得許多應用程序的用戶容易受到經濟攻擊，例如搶先交易。
最近，有許多項目專門致力於創建“私有內存池”（或“加密內存池”），它將用戶的交易加密，直到它們被不可逆轉地被接受到一個區塊中。
然而，問題是，這樣的方案需要一種特殊的加密：爲了防止用戶湧入系統並率先進行解密，加密必須在交易確實被不可逆轉地被接受後自動解密。
爲了實現這種形式的加密，有各種不同權衡的技術。Jon Charbonneau 曾做過很好的描述：
對中心化運營商進行加密，例如 Flashbots Protect。
時間鎖加密，該加密形式經過一定的順序計算步驟後，任何人都可以解密，並且不能並行化；
閾值加密，信任一個誠實的多數委員會來解密數據。具體建議請參見封閉信標鏈概念。
可信硬件，如 SGX。
不幸的是，每一種加密方式都有不同的弱點。雖然對於每個解決方案，都有一部分用戶愿意信任它，但沒有一個解決方案的信任程度足以讓它實際上被 Layer 1 接受。因此，至少在延遲加密得到完善或其他一些技術突破之前，在 Layer 1 封裝反提前交易功能似乎是一個困難的命題，即使它是一個足夠有價值的功能，許多應用程序解決方案已經出現。
封裝流動性質押
以太坊 DeFi 用戶的一個共同需求是能夠同時使用他們的 ETH 進行質押和作爲其他應用程序中的抵押品。另一個常見的需求僅僅是爲了方便：用戶希望能夠在沒有運行節點並保持其始終在线的復雜性的情況下進行質押（並保護线上質押密鑰）。
到目前爲止，滿足這兩種需求的最簡單質押“接口”只是一種 ERC 20 代幣：將你的 ETH 轉換爲“質押 ETH”，持有它，然後再轉換回來。事實上，Lido 和 Rocket Pool 等流動性質押提供商已經开始這樣做了。然而，流動性質押有一些自然的中心化機制在起作用：人們自然會進入最大版本的質押 ETH，因爲它是最熟悉和最具流動性的。
每個版本的質押 ETH 都需要有一些機制來確定誰可以成爲底層節點運營商。它不能是無限制的，因爲這樣攻擊者就會加入並利用用戶的資金擴大攻擊。目前，排名前兩位的是 Lido 和 Rocket Pool，前者擁有 DAO 白名單節點運營商，後者允許任何人在存入 8 枚 ETH 的情況下運行一個節點。這兩種方法有不同的風險：Rocket Pool 方法允許攻擊者對網絡進行 51% 的攻擊，並迫使用戶支付大部分成本；至於 DAO 方法，如果某質押代幣佔主導地位，就會導致一個單一的、可能受到攻擊的治理小工具控制所有以太坊驗證者的很大一部分。值得肯定的是，像 Lido 這樣的協議已經實施了防範措施，但一層防御可能還不夠。
在短期內，一種選擇是鼓勵生態系統參與者使用多樣化的流動性質押提供商，以減少一家獨大帶來系統性風險的可能性。然而，從長期來看，這是一種不穩定的平衡，過度依賴道德壓力來解決問題是危險的。一個自然的問題出現了：在協議中封裝某種功能以使流動性質押不那么中心化是否有意義？
這裏的關鍵問題是：什么樣的協議內功能？簡單地創建一個協議內可替代的“質押 ETH”代幣存在一個問題，即它要么必須有一個封裝以太坊範圍內治理來選擇誰來運行節點，要么是开放的，但這會把它變成攻擊者的工具。
一個有趣的想法是 Dankrad Feist 關於流動性質押最大化的文章。首先，我們咬緊牙關，如果以太坊受到 51% 攻擊，可能只有 5% 的攻擊 ETH 被罰沒。這是一個合理的權衡；目前有超過 2600 萬枚 ETH 被質押，其中三分之一（約 800 萬枚 ETH）的攻擊成本是過度的，特別是考慮到有多少種“模型外”攻擊可以以更低的成本完成。事實上，類似的權衡已經在“超級委員會”關於實施 single-slot finality 的提案中進行了探討。
如果我們接受只有 5% 的攻擊 ETH 被罰沒，那么超過 90% 的質押 ETH 將不會受到罰沒的影響，因此它們可以作爲協議內可替代流動性質押代幣，然後被其他應用程序使用。
這條路徑很有趣。但它仍然留下了一個問題：具體封裝什么？Rocket Pool 的運作方式與此非常相似：每個節點運營商提供一些資金，流動性質押者提供其余的資金。我們可以簡單地調整一些常量，將最大罰沒懲罰限制爲 2 枚 ETH，Rocket Pool 現有的 rETH 將變得無風險。
通過簡單的協議調整，我們還可以做其他聰明的事情。例如，假設我們想要一個系統，有兩種“層”的質押：節點運營商（高抵押品要求）和儲戶（沒有最低抵押品要求，可以隨時加入和離开），但我們仍然希望通過賦予一個隨機抽樣的儲戶委員會權力來防止節點運營商的中心化，比如建議必須包括的交易列表（出於抗審查的原因），在不活動泄漏期間控制分叉選擇，或者需要在區塊上籤名。這可以通過一種基本上脫離協議的方式來實現，方法是調整協議，要求每個驗證器提供（i）一個常規的質押密鑰，以及（ii）一個 ETH 地址，該地址可以在每個槽間被調用以輸出二級質押密鑰。該協議將賦予這兩項密鑰權力，但在每個槽中選擇第二個密鑰的機制可以留給質押池協議。直接封裝一些功能可能仍然更好，但值得注意的是，這種“包含一些東西，把其他東西留給用戶”的設計空間是存在的。
封裝更多預編譯
預編譯（或“預編譯合約”）是實現復雜加密操作的以太坊合約，其邏輯在客戶端代碼中原生實現，而不是 EVM 智能合約代碼。預編碼是以太坊开發之初採用的一種折衷方案：由於虛擬機的开銷對於某些非常復雜和高度專業化的代碼來說太大了，我們可以在本地代碼中實現一些對重要應用程序有價值的關鍵操作，以使其更快。如今，這基本上包括一些特定的散列函數和橢圓曲线運算。
目前有人在推動爲 secp 256 r 1 添加預編譯，這是一種與用於基本以太坊账戶的 secp 256 k 1 略有不同的橢圓曲线，因爲它得到了可信硬件模塊的良好支持，因此廣泛使用它可以提高錢包安全性。近年來，社區還推動爲 BLS-12-377、BW 6-761、廣義配對和其他功能添加預編譯。
對這些要求更多預編譯文件的反駁是，之前添加的許多預編譯（例如 RIPEMD 和 BLAKE）最終的使用量遠低於預期，我們應該從中吸取教訓。與其爲特定操作添加更多的預編譯，我們也許應該專注於一種更溫和的方法，該方法基於 EVM-MAX 和休眠但始終可恢復的 SIMD 提案等思想，這將使 EVM 實現能夠以更低的成本執行廣泛的代碼類。也許即使是現有的很少使用的預編譯也可以被刪除，並用相同函數的 EVM 代碼實現（不可避免地效率較低）代替。也就是說，仍然有可能存在特定的加密操作，這些操作的價值足以加速，因此將它們作爲預編譯添加是有意義的。
我們從這一切中學到了什么？
盡可能少封裝的愿望是可以理解的，也是好的；它源自 Unix 哲學傳統，即創建極簡的軟件，可以很容易地適應用戶的不同需求，避免軟件膨脹的詛咒。然而，區塊鏈不是個人計算操作系統，而是社會系統。這意味着在協議中封裝某些功能是有意義的。
在許多情況下，這些其他的例子與我們在帳戶抽象中看到的類似。但我們也學到了一些新的教訓：
封裝功能可以幫助避免堆棧中其他區域的中心化風險：
通常，保持基本協議的最小化和簡單性會將復雜性推到一些協議之外的生態系統。從 Unix 哲學的角度來看，這很好。然而，有時存在協議外生態系統將中心化的風險，通常（但不僅僅是）因爲高固定成本。封裝有時可以減少事實上的中心化。
封裝太多內容，可能會過度擴大協議的信任和治理負擔：
這是前一篇關於“不要讓以太坊共識過載”文章的主題：如果封裝一個特定的功能削弱了信任模型，並使以太坊作爲一個整體變得更加“主觀”，這就削弱了以太坊的可信中立性。在這些情況下，最好將特定功能作爲以太坊之上的機制，而不是試圖將其引入以太坊本身。在這裏，加密內存池是最好的例子，它可能有點難以封裝，至少在延遲加密技術改進之前是這樣。
封裝太多內容可能會使協議過於復雜：
協議復雜性是一種系統性風險，在協議中添加太多功能會增加這種風險。預編譯就是最好的例子。
長期來看，封裝功能可能會適得其反，因爲用戶的需求是不可預測的：
一個很多人認爲很重要並且會被很多用戶使用的功能，很可能在實踐中並沒有被經常使用。
此外，流動性質押、ZK-EVM 和預編譯案例顯示了一條中間道路的可能性：最小可行封裝（minimal viable enshrinement）。協議不需要封裝整個功能，而可以包含解決關鍵挑战的特定部分，使該功能易於實現，而不會過於偏執或過於狹隘。這樣的例子包括：
與其封裝一個完整的流動性質押系統，不如改變質押懲罰規則，讓去信任流動性質押更可行；
與其封裝更多的預編譯器，不如封裝 EVM-MAX 和/或 SIMD，以使更廣泛的操作類別更容易有效地實現；
可以簡單地封裝 EVM 驗證，而不是封裝 rollup 的整個概念。
我們可以將前面的圖表擴展如下：
有時候，去封裝一些東西是有意義的，去除很少使用的預編譯就是一個例子。帳戶抽象作爲一個整體，正如前面提到的，也是一種重要的去封裝形式。如果我們想支持現有用戶的向後兼容性，那么該機制實際上可能與去封裝預編譯的機制驚人地相似：其中一個提案是 EIP-5003 ，它將允許 EOA 將其帳戶轉換爲具有相同（或更好）功能的合約。
哪些功能應該被引入協議，哪些功能應該留給生態系統的其他層，這是一個復雜的權衡。隨着我們對用戶需求的理解以及可用想法和技術套件的不斷改進，這種權衡有望隨着時間的推移而繼續改進。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。