編譯器漏洞無解？Runtime Protection實現DeFi鏈上風控保護_ASP:FiFaSport

重入攻擊仍然是一個挑戰，現有的防御手段主要集中在協議源代碼層面，僅在合約進入 runtime 狀態前生效

「運行時保護」是 DeFi 安全的重要補充，它以「保護執行結果」為目的，確保協議的執行與其預期設計一致

EVM 的設計不支持「運行時保護」，因為智能合約無法訪問 runtime 狀態全部上下文信息

Artela 探索一種 EVM+Extension 的執行層范式，增強執行層以消除重入攻擊

Artela 通過 Aspect Programming 實現鏈上「運行時保護」擴展

我們逐步展示了如何通過 Aspect 防范對 Curve 合約的重入攻擊

盡管重入攻擊是一個眾所周知的問題，并且出現了許多風險控制措施，但在過去的兩年中，涉及此類攻擊的安全事件仍在不斷發生：

Curve Finance 攻擊（2023 年 7 月）—6000 萬美元，Curve 因其合約編程語言 Vyper 編譯缺陷遭受重入攻擊。

Origin Protocol 攻擊（2022 年 11 月）—700 萬美元，穩定幣項目 Origin Dollar（OUSD）遭受了重入攻擊。

Siren Protocol 攻擊（2021 年 9 月）—350 萬美元，AMM 池遭受重入攻擊。

安全公司 Dedaub 發現 Solidity 編譯器存在漏洞，多數已部署合約中的死代碼極大增加 Gas 費成本:2月11日消息，安全公司 Dedaub 團隊發現以太坊編程語言 Solidity 編譯器存在漏洞，導致已部署的合約字節碼中包括死代碼（dead code），致使部署和操作智能合約時極大地增加了 Gas 費成本。Dedaub 表示，團隊在評估開源二進制分流器 Gigahorse 時發現了這個錯誤。當庫方法只被合約的構造器調用時，該漏洞就會出現。

通過 Gigahorse 分析，Dedaub 發現至少 35% 合約上存在一些死代碼，其中 33% 占據其運行的大部分字節碼。這些結果以 NFT 代理為主導，但其他代理合約也有同樣問題。對于大型合約，該問題可以被忽略，但大多數已部署的合約都是小型合約。Dedain 團隊在去年 11 月就已經發現了這個錯誤，并提醒 Solidity 團隊確認該問題。[2023/2/11 12:00:31]

Cream Finance 攻擊（2021 年 8 月）—1880 萬美元，攻擊者利用重入漏洞進行二次借貸。

目前，防范重入攻擊的重點集中在智能合約的源代碼層面，措施包括集成 OpenZeppelin 的 ReentrancyGuard，以及對合約邏輯代碼進行安全審計，以避免預定義的安全隱患。

這種方法被稱為「白盒」解決方案，旨在在源代碼層面規避漏洞，以最小化邏輯錯誤。然而，其主要挑戰在于無法防御未知隱患。

以太坊編程語言Solidity發布最新版本編譯器Solidity 0.8.18，支持巴黎硬分叉:金色財經報道，以太坊編程語言Solidity發布最新版本的Solidity編譯器Solidity0.8.18，新版本的功能包括：禁用CBOR元數據、支持巴黎硬分叉、棄用selfdestruct、從Yul生成EVM字節碼。團隊建議所有Solidity開發人員升級到版本0.8.18以利用這些改進和優化。[2023/2/2 11:43:19]

將合約從源代碼「轉化」為實際 runtime 是個具有挑戰性的過程。每一步可能為開發人員帶來無法預料的問題，而合約源代碼本身可能無法全面涵蓋所有潛在情況。在 Curve 的案例中，由于編譯器問題，即使協議源代碼是正確的，最終運行結果與協議的預期設計之間仍可能存在差異。

僅僅依靠協議在源代碼和編譯層面的安全性是不足夠的。即使源代碼看起來毫無瑕疵，由于編譯器問題，漏洞仍可能意外出現。

與現有的風險控制措施集中在協議源代碼層面并在運行之前生效不同，運行時保護涉及協議開發人員編寫運行時保護規則和操作，以處理運行時的未預料情況。 這有助于對運行時執行結果進行實時評估及應對。

smartBCH發布EVM預編譯器“Moeingaot”:金色財經消息，smartBCH發布EVM預編譯器“Moeingaot”，它基于EVM的解釋器evmone，支持將多個智能合約編譯到一個動態鏈接的庫中，并使用名為query_executor的入口來查詢與給定智能合約對應的函數。（Medium）[2022/4/16 14:28:37]

運行時保護在增強 DeFi 安全性方面至關重要，是現有安全措施的重要補充。通過以「黑盒」方式保護協議，它通過確保最終運行結果與協議預期設計相一致來增強安全性，而無需直接干涉合約代碼執行。

不幸的是，EVM 設計不支持在鏈上實現運行時保護，因為智能合約無法訪問完整的運行時上下文。

如何克服這一挑戰？我們認為以下先決條件是必要的：

一個專門的模塊，可以訪問跨智能合約的所有信息，包括整個交易上下文。

從智能合約獲得必要的授權，使模塊有權根據需要回撤 (revert) 交易。

確保模塊的功能在智能合約執行后和狀態提交之前生效。

EVM 在解決上述挑戰中目前面臨限制，難以容納更多創新。在模塊化區塊鏈的范式下，執行層需要探索 go beyond EVM 的突破。

V神提議對以太坊未來的分片和歷史訪問進行預編譯:Vitalik Buterin（V神）發文研究對未來的分片和歷史訪問進行預編譯。V神在文章中表示，當前以太坊設計中的向后兼容性挑戰之一是，歷史訪問需要在EVM中驗證Merkle證明，該證明假設區塊鏈將永遠使用相同的格式和相同的密碼。分片增加了這一點的重要性，因為用于rollups的欺詐證明和有效性證明需要指向分片數據的指針。V神提出了一種更加面向未來的方法：我們可以添加執行驗證特定類型證明的抽象任務的預編譯，而不是要求在EVM中驗證歷史和分片的證明。如果將來更改格式，預編譯邏輯將自動更改。預編譯甚至可以具有條件邏輯，用于驗證轉換前slots的一種證明和轉換后slots的另一種證明。[2021/6/13 23:33:43]

Artela 的思路是 EVM + native extension，通過構建 EVM 的 WASM 原生擴展層以實現 go beyond EVM。

我們推出了 Aspect Programming，這是支持 Artela 區塊鏈的一種編程框架，支持在區塊鏈上進行原生擴展。

Aspect 是可編程的原生擴展模塊，用于在運行時動態集成自定義功能到區塊鏈中，作為智能合約的模塊化補充，增強鏈上功能性。

聲音 | BM：帶有優化編譯器的EOSIO 2.0速度是WAVM速度的兩倍:今日，BM評論推特網友推文時稱，帶有已優化的編譯器的eosio 2.0的速度是WebAssembly（WAVM）速度的兩倍，而且WAVM還在最近一次的測試中，其速度擊敗了Lucet等其他事物。人們可以更新其基準來測試EOS虛擬eosvm三個WAVM模式Interp、JIT編譯器和compiled（編譯器）。據悉，推特網友Frank Denis發文稱，其于近期我使用libsodium最新版本運行了WebAssembly基準測試：Lucet、Wasmtime、Wasmer及其3個后端、WAVM。基準測試結論是，WAVM輕而易舉地擊敗了所有東西(包括Wasmer+LLVM)。它也是迄今為止最完整的WebAssembly實現。注：Lucet、Wasmtime、Wasmer均為計算機編譯器。[2019/10/24]

Aspect 的特性是能夠訪問區塊鏈基礎層的系統級 API，并在交易生命周期的各個切點（Join Point）添加擴展邏輯。智能合約可以綁定指定的 Aspect 以觸發擴展功能。當交易調用智能合約時，該交易也會經由與該合約關聯的 Aspect 處理。

Aspect 可以記錄每個函數調用的執行狀態，并防止在回調函數執行期間發生重入。當在回調函數執行期間發生重入調用時，Aspect 會檢測到并立即回撤該交易，防止攻擊者利用重入漏洞。通過這種方法，Aspect 有效地消除了重入攻擊，確保智能合約的安全性和穩定性。

Aspect 實現運行時保護的關鍵屬性：

可在智能合約執行后和狀態提交前觸發：Aspect 模塊可設置為在智能合約執行后但在狀態提交前激活。

完整的交易上下文訪問：Aspect 可以訪問完整的交易上下文，包括整個交易信息（方法，參數等）、調用棧（執行過程中所有內部合約調用）、狀態上下文變更以及所有交易觸發的事件。

系統調用能力：Aspect 可以進行系統調用，并在必要時發起交易回撤。

與智能合約的綁定和授權：智能合約可以綁定到 Aspect，并授予 Aspect 參與交易處理的權限。

本章我們探討如何在鏈上實現 Aspect 的運行時保護。

可以在「preContractCall」和「postContractCall」的切點（Join Point）中部署一個實際的「合約保護意圖」Aspect，以防止重入攻擊。

preContractCall: 在跨合約調用執行之前觸發

postContractCall: 在跨合約調用執行后觸發

為進行重入保護，我們的目標是在調用結束之前阻止合約重入。通過 Aspect，我們可以通過在交易生命周期的切點處添加特定邏輯來實現這一目標。

在「preContractCall」切點中，Aspect 監控合約調用堆棧。如果在調用堆棧中有任何重復調用（這意味著我們鎖定的調用中出現了意外重入），Aspect 將會回撤該調用。

我們編寫了 Curve 模擬合約并復刻重入攻擊，以更易理解的方式重現了這個過程。合約代碼如下：

可以看到，上述合約的 add_liquidity 和 remove_liquidity 都由同一個重入鎖 lock 進行了保護，這意味著如果重入保護正常工作，無法通過改鎖重入被保護函數（例如，在 remove_liquidity 中調用 add_liquidity）。

使用 vyper 編譯器 0.2.15、0.2.16 或 0.3.0（這些版本存在已知的重入保護問題）編譯上述合約。

然后，我們部署上述受害者合約，并使用以下合約對其進行攻擊：

模擬實際攻擊，此合約的 attack 方法嘗試通過其 fallback 函數從 remove_liquidity 方法重入 add_liquidity。如果實際發生了重入，可在 receipt 中觀察到在 RemoveLiquidity 事件之前記錄了一個 AddLiquidity 事件。

現在讓我們使用 Aspect 來保護受攻擊的合約。在執行以下操作之前，請先完成以下步驟：

1、部署 Aspect

2、將受害合約與 Aspect 綁定

如果對 Aspect 操作不熟悉，可以首先查看我們的開發者指南先行了解。

完成上述操作后，現在讓我們嘗試再次調用 attack 方法，以檢查操作是否會成功進行。

從動圖（文末原文鏈接可查看）中我們可以看到，重入交易已經被 revert，這意味著我們的 Aspect 正在成功保護受害合約免受重入攻擊。

最近對 Curve 的攻擊再次說明了沒有 100% 完全安全的協議。僅僅將重心放在協議的源代碼和編譯級別的安全性上是不足夠的。即使源代碼看起來毫無瑕疵，由于編譯器問題，漏洞仍然可能意外出現。

為了增強 DeFi 的安全性，運行時保護變得至關重要。通過以「黑盒」方式保護協議，確保協議的執行與其預期設計一致，可以有效地防止運行時的重入攻擊。

我們復刻了 Curve 合約并完全模擬了其近期的重入攻擊，并以更易理解的方式再現了整個過程。利用 Aspect 編程作為一種新方法，實現鏈上運行時保護，我們逐步展示了如何用 Aspect 保護受害合約。我們的目標是幫助根除 Curve 等 DeFi 協議可能遭受的重入攻擊，從而增強整個 DeFi 領域的安全性。

通過 Aspect Programming，開發人員不僅可以在安全領域實現鏈上運行時保護，還能實現諸如意圖、JIT 和鏈上自動化等前所未有的創新用例。除此之外，這個以 Cosmos SDK 為基礎的通用框架將不僅支持 Artela 區塊鏈，更能支持其他區塊鏈構建基于自己執行層的 native extension。

金色財經

企業專欄

閱讀更多

Foresight News

金色財經 Jason.

白話區塊鏈

金色早8點

LD Capital

-R3PO

MarsBit

深潮TechFlow

Tags：SPECASPSPEECTSPEC幣FiFaSportSperaxElectroneum

火必APP