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

重入攻擊仍然是一個挑戰，現有的防御手段主要集中在協議源代碼層面，僅在合約進入 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 池遭受重入攻擊。

FuelLabs將在今年對Sway語言進行編譯器優化并支持更多后端:2月21日消息，以太坊模塊化執行層 Fuel 開發商 Fuel Labs 公布將于 2023 年實現的 Sway 語言升級內容，包括字節碼大小方面的編譯器優化、Sway 將支持更多后端（EVM 后端已經在開發中）、抽象將更加具有經濟性、更多應用程序將從 Solidity/Vyper 遷移到 Sway、改進編譯器級別的重入分析等。[2023/2/21 12:19:53]

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

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

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

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

Composable Finance創始人：NEAR將兼容Cosmos生態編譯方案:7月5日消息，波卡生態 DeFi 協議 Composable Finance 創始人在社交媒體上表示，由其發起的 NEP-364 提案已經獲得 NEAR 聯創 Illia支持，若提案被合并，NEAR 將兼容 Cosmos 生態編譯方案。[2022/7/5 1:52:35]

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

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

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

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

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

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

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

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

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

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

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

動態 | Polkadot開發公司Parity推出流式編譯器Lightbeam，優化WASM編程:跨鏈項目Polkadot開發公司Parity推出用于優化WASM的流式編譯器Lightbeam。Parity表示使用流式編譯器的主要原因是，在區塊鏈的語境中有必要嚴格限制編譯時間，因而開發Lightbeam的目標是在Wasmtime中進行初始編譯，并發揮開發框架Substrate智能合同子系統中主編譯引擎的作用[2019/6/16]

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

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

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

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

聲音 | BM：非關鍵節點可以使用WAVM編譯器:據IMEOS報道，電報群討論節點編譯合同WAVM會更快，但是如果合同變化大的話編譯時間就成問題，反之Binaryen會更穩定。BM回應稱，只有非關鍵節點才能使用WAVM編譯。[2018/7/19]

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：SPECECTSPEASPSPEC幣Deflect ProtocolMRSPEPEkaspa幣怎么挖

KuCoin