以太坊基金會今日發文披露了一個2019年首次發現的安全漏洞，在上個月的柏林升級之前，該漏洞的嚴重程度為發生攻擊時可能使主網癱瘓。該漏洞的本質是觸發隨機Trie查詢，以太坊開發人員曾試圖用EIP-1884、EIP-2583、EIP-2929、以及快照功能來抵禦該漏洞，最終在柏林升級之後該漏洞危險性降低。
通過此博客文章，目的是正式披露以太坊平台所面臨的一個嚴重威脅。在以太坊柏林硬分叉之前，這個威脅是切實存在的。
狀態（State）
讓我們從以太坊和狀態的背景知識開始。
以太坊狀態由一種patricia-merkle trie（一種前綴樹）組成。這篇文章將不做過多的詳細介紹，隨着狀態的增長，這個樹上的樹枝變得越來越密。添加的每個帳戶都是一片葉子。在樹的根和葉本身之間，有許多“中間”節點。
為了在這棵巨大的樹中查找給定的帳戶或“葉子”，需要從根到中間節點來解析大約6-9個哈希的某個位置，以最終解析最後一個哈希hash，該哈希會指向我們正在尋找的數據。
簡而言之：每執行一次Trie查找來查找帳戶，就會執行8-9個解析操作。每個解析操作都是一次數據庫查找，並且每詞數據庫查找可以是任意數量的真實磁盤操作。磁盤操作的次數很難估計，但是由於trie密鑰是加密哈希（抗衝突），因此密鑰是“隨機的”，這對任何數據庫來說都是最糟糕的情況。
隨着以太坊的增長，有必要提高訪問trie的操作的gas價格。這是在2016年10月區塊高度2,463,000的Tangerine Whistle中執行的，其中包括EIP150。EIP150在所謂的“上海攻擊”之後大幅提高了某些操作的gas成本，並進行了一系列更改以防止DoS攻擊。
另一項gas提升同樣在伊斯坦布爾升級中被執行，即2019年12月區塊高度9,069,000。在這次升級中，EIP 1884被激活。
- EIP 1884引入了以下操作成本更改：
- SLOAD從200提升到800gas，
- BALANCE從400提升到700gas（SELFBALANCE有所降低），
- EXTCODEHASH從400提升到700gas。
問題
2019年3月，Martin Swende對EVM操作碼性能進行了一些測量。 這次調查之後促成創建了EIP-1884。 在EIP-1884上線之前的幾個月，《Broken Meter》論文正式發表（2019年9月）。
兩位以太坊安全研究人員（Hubert Ritzdorf和Matthias Egli ）與該論文的一位作者Daniel Perez合作“武器化”了一個漏洞，他們將漏洞提交給了以太坊賞金計劃。這是在2019年10月4日。
我們建議您完整閱讀那次提交的內容，這是一份精心撰寫的報告。
在專門用於討論跨客戶端安全性的頻道上，當天，來自Geth，Parity和Aleth的開發人員被告知了有關提交的信息。
該漏洞的本質是觸發隨機trie查詢。 一個非常簡單的變體是：
在他們的報告中，研究人員通過eth_call對同步到主網的節點執行了此有效負載，這些是在使用10M gas時執行的數量：
使用EXTCODEHASH （400 gas）發動10M gas攻擊
- Parity: ~90s
- Geth: ~70s
使用EXTCODESIZE （700gas）發動10M gas攻擊
- Parity : ~50s
- Geth : ~38s
顯而易見，EIP 1884引入的更改確實在降低攻擊方面產生了影響，但遠遠不夠。
在大阪Devcon大會之前確實如此。在Devcon期間，主網客戶端開發人員之間共享了該問題的知識。我們還與Hubert和Mathias以及Greg Markou（來自Chainsafe的ETC工作人員）進行了會面。 ETC開發人員也收到了這份報告。
隨着2019年臨近尾聲，我們知道我們遇到的問題比我們之前預期的要大，惡意交易可能導致區塊時間間隔增加到分鐘級。更糟的是，開發人員已經對EIP-1884感到不滿意，因為EIP-1884中斷了某些合約程序，而用戶和礦工們都為提高gas限制而着急。
此外，僅兩個月後的2019年12月，Parity Ethereum宣布退出以太坊工作，而OpenEthereum接管了代碼庫的維護工作。
之後一個新的客戶端協調頻道被創建，在該頻道中，Geth，Nethermind，OpenEthereum和Besu開發人員繼續進行協調。
解決方案
我們意識到，我們必須採取兩種方法來解決這些問題。 一種方法是使用以太坊協議，並以某種方式在協議層解決該問題。 最好不要違反合約，最好不要懲罰“良好”行為，但仍要設法防止攻擊。
第二種方法是通過軟件工程，通過更改客戶端中的數據模型和結構。
協議層工作
如何處理這些類型的攻擊的第一個迭代升級可以在這裡查看。 2020年2月，該解決方案以EIP 2583的形式正式發布。其背後的想法是，每當一次Trie查找導致遺漏（miss）時，簡單地增加一個罰款。
但是，Peter為這個想法找到了一種解決方法——“屏蔽中繼”攻擊——將這種懲罰的有效範圍設定一個上限（約800gas）。
對於miss所導致的罰款的問題在於，首先需要進行查找，以確定必須施加罰款。 但是，如果剩餘的gas不足以進行罰款，則表明已執行了未付費用。 即使確實導致拋出異常，也可以將這些狀態讀取包裝到嵌套調用中。 允許外部調用者繼續重複攻擊而無需支付（全部）罰款。
因此，這個EIP被棄置，而我們正在尋找更好的替代方案。
- 阿列克謝·阿克胡諾夫（Alexey Akhunov）探索了Oil的概念，它是“gas”的第二種來源，但與gas本質上不同，因為執行層看不到它，並可能導致交易全局還原。
- Martin在2020年5月提出了一個類似提案，關於Karma的。
在迭代這些計劃時，Vitalik Buterin建議僅增加gas成本，並維持訪問名單。 2020年8月，Martin和Vitalik開始迭代，也就是後來的EIP-2929及EIP-2930。
EIP-2929有效地解決了許多以前的問題。
- 與EIP-1884（無條件增加成本）相反，它僅針對尚未訪問的內容增加成本。這導致凈成本僅增加了不足百分之一。
- 此外，它與EIP-2930一樣，不會破壞任何合約流
- 而且，可以通過提高gas成本（不中斷操作）來進一步調整它。
2021年4月15日，它們都隨着柏林升級而上線。
開發工作
2019年10月，Peter嘗試解決此問題的方法是進行動態狀態快照。
快照是一種二級數據結構，用於以平面格式存儲以太坊狀態，在Geth節點的實時運行期間，可以完全在線構建。
照的好處在於，它充當狀態訪問的一種加速結構：
- 快照無需提供O（log N）磁盤讀取（x LevelDB開銷）來訪問帳戶/存儲插槽，而是可以提供直接的O（1）訪問時間（x LevelDB開銷）。
- 快照支持每項條目O（1）複雜度的帳戶和存儲迭代，這使遠程節點可以比以前便宜得多地檢索順序狀態數據。
- 快照的存在還實現了更多奇特的用例，例如離線修剪狀態Trie或遷移到其他數據格式。
快照的缺點是原始帳戶和存儲數據實際上是重複的。對於主網，這意味着要使用額外的25GB SSD空間。
動態快照的想法已經在2019年中期開始，主要目的是成為snap 同步的推動者。當時，Geth團隊正在開展許多“大項目”。
- 離線狀態修剪
- 動態快照+snap同步
- 通過分片狀態進行的LES狀態分佈
但是，最後決定完全優先考慮快照，暫時將其他項目推遲。 這些奠定了後來成為snap / 1同步算法的基礎。 於2020年3月合併到主網。
隨着“動態快照”功能的發布，我們有了一些喘息的空間。 如果以太坊網絡受到攻擊，那將是痛苦的，是的，但是至少有可能通知用戶有關啟用快照的信息。 整個快照生成將花費大量時間，並且尚無法同步快照，但是網絡至少可以繼續運行。
在2021年3月至4月，snap / 1協議在geth中推出，從而可以使用基於快照的新算法進行同步。 儘管仍然不是默認的同步模式，但這是使快照不僅可用作攻擊防護，而且對於用戶來說是一項重大改進。
在協議方面，柏林升級在2021年4月正式執行。
以下是在我們的AWS監控環境中制定的一些基準測試：
- 柏林升級前，無快照，25M gas：14.3s
- 柏林升級前，有快照，25M gas：1.5s
- 柏林升級后，無快照，25M gas：~3.1s
- 柏林升級后，有快照，25M gas：~0.3s
（粗略的）數字錶示，柏林升級將攻擊的效率降低了5倍，快照將攻擊的效率降低了10倍，總共將攻擊影響降低了50倍。
我們估計，目前在主網（15M gas）上，在沒有快照的情況下，創建區塊可能需要2.5-3s在一個 geth節點上執行。 隨着狀態的增長，該數字將繼續惡化（對於非快照節點）。
如果使用refund來增加一個區塊內的有效gas使用量，則可以進一步提高（max）2x倍。 使用EIP 1559，區塊gas限制將具有更高的彈性，並允許在臨時爆發中再增加2倍（ELASTICITY_MULTIPLIER）。
至於實施這種攻擊的可行性； 攻擊者購買一個完整的區塊所需的成本約為幾個ETH（以100Gwei的價格購買15Mgas為1.5ETH）。
為什麼現在披露這個威脅？
長期以來，這種威脅一直是“公開秘密”，實際上至少有一次被無意間地公開披露，並且在ACD電話會議中多次被提及，但沒有明確的細節。
由於柏林升級現在已經過去，並且默認情況下，geth節點正在使用快照，因此我們估計這個威脅的危險程度非常低，可以公開了，現在該對此前的開發者幕後工作進行全面披露。
至關重要的是，社區必須有機會了解對用戶體驗產生負面影響的變更背後的原因，例如增加gas成本和限制refund。
這篇文章是由馬丁·霍爾斯特·斯文德（Martin Holst Swende）和彼得·西拉吉（Peter Szilagyi）2021-04-23撰寫的。 在2021-04-26與其他基於以太坊的項目共享，並在2021-05-18公開披露。
本文鏈接：https://www.8btc.com/article/6636733
轉載請註明文章出處