Shima Capital CTO：反思 Curve 事件，为何我们需要 Runtime Proctection？
如何保护我们的软件免遭失败呢？
原文作者：Carl Hua， Shima Capital 合伙人、CTO
原文来源：twitter
编译：ChainCatcher
在最近的 Curve 可重入漏洞利用之后，我回顾了我在 JPL NASA 的经历，在那里我学到了开发具备 reliable（可靠）和 resilient（弹性/韧性）软件的关键原则。对于加密行业，这些见解现在比以往任何时候都更加重要，理由如下：
归根结底，人们只真正关注两种类型的软件：可以杀死你的软件和可以让你赔钱的软件。
任何航天机器的关键软件里，大部分预算 ( 80% +) 并未分配给开发本身，而是分配给集成和测试。如果软件出现故障，飞行器就会从天而降——战斗机、无人机、航天器等。
航天软件中的大多数代码（如果被归类为关键模块）都遵守极其严格的测试/开发标准，例如 DO-178 B A 级。不仅需要测试每一行代码，而且如果有嵌套逻辑，则每个逻辑条件都是也经过专门测试。
在 JPL NASA，编写先进的航天软件的理念不是写出最漂亮、干净的代码，而是编写出容易执行单元测试的代码。为什么？很简单：当你将一艘航天器送入太空时，你只有一次机会，没有人愿意在失败的概率较大的情况下冒险。这与区块链的逻辑相同，因为不可变的代码是它们的重要特性，我们也只有一次机会在每笔交易中正确使用我们的资金，所以我们为什么不更认真地对待开发 dApp 这个过程呢？
尽管有严格的开发、测试和代码审计流程，但这些手段的显然不足以缓解所有错误和攻击，因为事实上通过测试和审计消除所有运行时错误几乎是不可能的。那么我们如何保护我们的软件免遭失败呢？
运行时保护（Runtime Protection）
运行时保护是一种安全技术，可保护软件应用程序在运行时免受恶意攻击。它的原理是在代码实际运行时进行实时检测，分析程序的实际行为以保护程序免受恶意数据和攻击的影响。
关于【Shima Capital CTO：反思 Curve 事件，为何我们需要 Runtime Proctection？】的延伸阅读
Base 链 DEX —— Aerodrome VS Curve
Velodrome是一个成功的DeFi案例，通过改进veCRV模板，实现了更优越的DEX模式。与Curve不同，Velodrome的流动性提供者不收取交易费用，而是通过VELO代币排放获得激励。通过仪表投票，veCRV/veVELO持有者决定每周发行的CRV/VELO代币分配比例。Velodrome避免了其他协议吞噬供应的可能性，并提供了类似于Convex的功能，但更简单。它正在成为超级链的基础流动性中心，可能会改变游戏规则。Velodrome已在Optimism上取得巨大成功，其产品套件包括收取和分配费用的DEX部分。
流动性提供者的博弈，Curve债务难题何解？
当场外交易的CRV变得可流动时，Curve将不得不经历另一次压力测试。
高可靠性软件的运行时保护需要花费大量的投入和设计，因为它们是确保软件不会进入未知状态或故障的最后一道防线。这不仅仅是个论点，而是几十年来经过验证的实践。
今天在 Web3 中，我认为 DeFi 应用程序需要同样的高可靠性，并且应该考虑同样的方法。然而，由于其潜在的限制，EVM 并不是为处理运行时保护等复杂任务而设计的。那么，我们如何提供运行时保护呢？
一种方式是通过 Aspect 编程，Aspects 由 Artela 区块链网络设计的，它能够在任何智能合约交易的生命周期内切换执行上下文，以对程序的实时状态进行高级检查。Artela 通过 Aspect 和兼容 EVM 的方式，提供运行时保护的独特设计，它有机会成为加密智能合约安全的未来基础。
Artela 在下面的文章中公布了 Aspects 在防止 Curve 重入攻击中的具体用法，希望一起交流！
《编译器漏洞无解？Runtime Protection 实现 DeFi 链上风控保护》
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Carl Hua，如有侵权请联系删除。转载或引用请注明文章出处！
