重入攻击仍然是一个挑战，现有的防御手段主要集中在协议源代码层面，仅在合约进入 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 池遭受重入攻击。
Nethermind：Warp 已转译和编译 Uniswap V3:10月9日消息，以太坊客户端 Nethermind 表示， Warp 项目的下一个重要里程碑已经实现，已成功转译和编译 Uniswap V3 为 Uniswap V3 Warped（UniStark），目前正在完成一个 hardhat 插件，允许在转译的 Cairo 上运行所有 Solidity hardhat 测试。也就是说，Warp 已经转换和部署了 Uniswap V3 存储库中的每个 Solidity 文件，只需对源代码进行少量更改。
注，Warp 旨在将任意 Solidity 合约转换到 Cairo，并将它们部署到 StarkNet 上。6 月份，Nethermind 上线 Warp 2.0，支持将 Solidity 合约转换为 Cairo 合约，以部署到 StarkNet 上。[2022/10/9 12:50:09]
Cream Finance 攻击（2021 年 8 月）—1880 万美元，攻击者利用重入漏洞进行二次借贷。
目前，防范重入攻击的重点集中在智能合约的源代码层面，措施包括集成 OpenZeppelin 的 ReentrancyGuard，以及对合约逻辑代码进行安全审计，以避免预定义的安全隐患。
这种方法被称为「白盒」解决方案，旨在在源代码层面规避漏洞，以最小化逻辑错误。然而，其主要挑战在于无法防御未知隐患。
以太坊Solidity推出Solidity论坛 供开发人员讨论语言设计和编译器等问题:以太坊Solidity基于开源讨论平台Discourse推出Solidity论坛，供开发人员讨论Solidity编程语言的设计、Solidity编译器、Solidity文档以及Solidity版本等问题。不过，紧急的Solidity支持问题、错误或漏洞报告、以太坊研究的具体讨论以及提案EIP等不在该论坛讨论范围之内。[2021/2/2 18:41:24]
将合约从源代码「转化」为实际 runtime 是个具有挑战性的过程。每一步可能为开发人员带来无法预料的问题，而合约源代码本身可能无法全面涵盖所有潜在情况。在 Curve 的案例中，由于编译器问题，即使协议源代码是正确的，最终运行结果与协议的预期设计之间仍可能存在差异。
仅仅依靠协议在源代码和编译层面的安全性是不足够的。即使源代码看起来毫无瑕疵，由于编译器问题，漏洞仍可能意外出现。
与现有的风险控制措施集中在协议源代码层面并在运行之前生效不同，运行时保护涉及协议开发人员编写运行时保护规则和操作，以处理运行时的未预料情况。 这有助于对运行时执行结果进行实时评估及应对。
动态 | 波场TRON发布了最新版v0.5.9编译器:随着Odyssey-3.6.6完成升级和第29号投票请求（第32号提案）的通过，TVM（波场虚拟机）中开启了多个新特性，为了配合新特性，波场TRON发布了最新版v0.5.9编译器，Solidity编译器v0.5.9新增了如下3个新特性：
1. 新增 address.isContract，用于判断一个地址是否为合约地址；
2. 新增预编译合约batchvalidatesign，用于进行批量签名验证，支持在合约中对一个消息的多个签名进行批量验证，加快了多个签名的总验签速度；
3. 新增预编译合约validatemultisign，用于支持多重签名的验证。开发者如果在应用开发过程中使用以上特性，请使用最新版v0.5.9编译器对Solidity合约代码进行编译 。[2020/2/26]
运行时保护在增强 DeFi 安全性方面至关重要，是现有安全措施的重要补充。通过以「黑盒」方式保护协议，它通过确保最终运行结果与协议预期设计相一致来增强安全性，而无需直接干涉合约代码执行。
不幸的是，EVM 设计不支持在链上实现运行时保护，因为智能合约无法访问完整的运行时上下文。
如何克服这一挑战？我们认为以下先决条件是必要的：
动态 | Polkadot开发公司Parity推出流式编译器Lightbeam，优化WASM编程:跨链项目Polkadot开发公司Parity推出用于优化WASM的流式编译器Lightbeam。Parity表示使用流式编译器的主要原因是，在区块链的语境中有必要严格限制编译时间，因而开发Lightbeam的目标是在Wasmtime中进行初始编译，并发挥开发框架Substrate智能合同子系统中主编译引擎的作用[2019/6/16]
一个专门的模块，可以访问跨智能合约的所有信息，包括整个交易上下文。
从智能合约获得必要的授权，使模块有权根据需要回撤 (revert) 交易。
确保模块的功能在智能合约执行后和状态提交之前生效。
EVM 在解决上述挑战中目前面临限制，难以容纳更多创新。在模块化区块链的范式下，执行层需要探索 go beyond EVM 的突破。
Artela 的思路是 EVM + native extension，通过构建 EVM 的 WASM 原生扩展层以实现 go beyond EVM。
我们推出了 Aspect Programming，这是支持 Artela 区块链的一种编程框架，支持在区块链上进行原生扩展。
Aspect 是可编程的原生扩展模块，用于在运行时动态集成自定义功能到区块链中，作为智能合约的模块化补充，增强链上功能性。
声音 | BM：非关键节点可以使用WAVM编译器:据IMEOS报道，电报群讨论节点编译合同WAVM会更快，但是如果合同变化大的话编译时间就成问题，反之Binaryen会更稳定。BM回应称，只有非关键节点才能使用WAVM编译。[2018/7/19]
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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。