Decoupling Reentrancy Protection from Smart Contract Implementation Logic
本文介绍了 Sentinel，这是一种基于代理的新型框架，通过在代理层拦截调用并利用双模式安全系统，将重入保护与智能合约逻辑解耦，从而实现对包括只读变体在内的主要重入攻击的 100% 覆盖。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，区块链世界就像一家繁忙且高风险的银行，任何人都可以自行制定资金流动的规则。这些规则被称为智能合约。尽管它们功能强大，但存在一个著名的弱点，称为重入漏洞。
问题所在：“双重记账”劫案
要理解这个问题，请想象一位银行柜员（即智能合约），其职责是：
- 检查你的余额。
- 向你支付款项。
- 然后更新账本，显示你的余额已为零。
在正常世界中，这是安全的。但在区块链世界中，这位“柜员”是一个可能被中断的机器人。一个精明的窃贼（攻击者）可以呼叫柜员取款。在柜员完成第 3 步（更新账本）之前，窃贼的机器人合约会再次呼叫柜员以提取更多资金。
由于账本尚未更新，柜员仍认为窃贼拥有全额资金。窃贼可以在一秒钟内重复此循环数十次，在柜员意识到出错之前掏空银行金库。这就是重入攻击。
旧方案：“请勿打扰”标志
此前，开发人员试图通过在柜员桌上放置“请勿打扰”标志（即锁）来解决此问题。
- 缺陷：这些标志通常只贴在特定的桌子上（即特定函数）。如果窃贼发现了一扇没有标志的后门（不同的函数），他们仍然可以进入。
- 局限性：如果银行有多个分行（多个合约）相互通信，一个分行的标志无法阻止窃贼在分行之间穿梭以混淆系统。
- 盲点：这些标志还会阻挡合法的“仅查看”请求（例如在不消费的情况下查询余额），导致银行运行缓慢且笨拙。
新方案：Sentinel（智能门房）
本文作者 Shashank Joshi 和 Wojciech Golab 提出了一种名为Sentinel的新系统。他们不是试图修补柜员的桌子，而是建立了一位站在银行入口处的智能门房（即代理）。
以下是 Sentinel 的工作原理，使用简单的类比说明：
1. 门房拦截所有人
无论谁试图进入银行或想做什么，都必须先经过 Sentinel 门房。门房不关心银行内部的复杂规则；他只专注于安全。这意味着银行内部规则（业务逻辑）无需重写即可确保安全。
2. 两种运行模式
门房根据风险程度穿着不同的制服，即处于不同的“模式”：
优化模式（单桌守卫）：
如果银行规模较小且只有一个分行，门房会在门上使用简单快速的锁。这种方式成本低且速度快。如果有人试图在门锁闭时偷偷返回，他们会立即被拒之门外。这非常适合简单、单一合约的场景。高安全模式（全球安全网络）：
如果银行是庞大分行网络的一部分，门房会连接到一个中央安全枢纽（称为 LockRegistry）。- 想象门房呼叫中央枢纽：“A 分行目前是否忙碌？”
- 如果枢纽回答“是”，门房将阻止进入。
- 这防止了窃贼在不同分行之间穿梭以欺骗系统。它在整个网络范围内协调安全，而不仅仅局限于一个房间。
3. “仅查看”例外
区块链的一个棘手之处在于，有时人们只想查看余额而不进行消费（称为 staticcall）。
- 旧式锁会阻挡这些“查看者”，导致延迟。
- Sentinel 足够智能，能够检测某人是否仅处于“查看”状态。如果是，门房会让他们透过窗户窥视而无需锁门，但他仍会密切监视，确保他们不会在查看时试图从后门潜入。
为何这很重要
作者针对70 个已知易受此类攻击的智能合约对 Sentinel 进行了测试。
- 结果：Sentinel 阻止了**100%**的攻击，包括那些发生在不同合约之间或涉及“仅查看”技巧的棘手攻击。
- 对比：旧的标准工具（如 OpenZeppelin 的防护机制）仅阻止了约 73% 的攻击。它们在复杂的跨合约劫案中失败了。
- 成本：运行这位“门房”需要消耗少量额外的能量（Gas），但作者表示，为了阻止数百万美元的盗窃，这是一个微不足道的代价。
结论
本文提出了一种将智能合约的安全性与其业务逻辑分离的方法。通过在合约前部署一位智能且适应性强的“门房”，他们可以阻止窃贼利用系统中的时间差进行攻击，无论合约内部规则多么复杂。这是一种从试图修补墙上每一个可能的漏洞，转向建造一道坚不可摧的大门的理念转变。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。