|
原文标题：《引介 | 对 EIP-3074 的批评以及一种简单的替代》 对于开发者来说，AUTH/AUTHCALL 机制非常具有吸引力。它可以让人们创建调用者来实现不同的批量处理策略（例如，支持多个 nonce 来实现更好的并行性）、gas 抽象模型和复杂的账户抽象方法等。 这种灵活性源于这一机制赋予了开发者极大的自由。AUTH/AUTHCALL 机制不要求开发者遵循特定的模式，而是要求用户签署一个 commit 哈希值（commit 内容将由调用者来解析），让开发者基于 commit 自行设置限制。 然而，这种灵活性是以牺牲安全性为代价的。在本文中，我想要介绍一种更简单的替代方案。这个方案具备 AUTH/AUTHCALL 机制的绝大多数优点，但是风险远低于后者。 为什么签署一个 AUTH commit 所带来的风险高于签署一个与存在漏洞 / 恶意合约相关的事务？ 用户在签署与合约相关的事务时，所承担的风险是已知的，即，可能会损失在该合约控制范围内的资产。比方说，用户给一个 ERC 20 合约签署了批准事务，授权恶意的 DEX 合约。这个恶意 DEX 合约就可以提走用户在 ERC 20 合约中的全部余额。但是，它无法从该用户的其它 ERC 20 合约中提走代币，除非得到该用户的批准。它也不能代表用户进行其它操作，因为这也需要专门获得用户的批准。 相较之下，EIP-3074 不仅要求用户签署 「空白支票」，而且假设调用者是诚实且没有漏洞的。一个恶意 / 存在漏洞的调用者可以代表用户执行任何操作 —— 访问用户持有的资产，代表用户进行投票，控制用户所有的合约等。 更糟糕的是，调用者随时都可以作恶，因为 nonce 实现是由调用者控制的。存在漏洞 / 恶意的 nonce 逻辑实现可以重放用户过去的事务。如果 commit 验证的其它部分的逻辑也存在漏洞，调用者就可以利用这个 nonce 逻辑实现来代表用户执行任何操作。即使漏洞被发现，用户也无法撤回空白支票。这个外部账户（EOA）已经被永久入侵了。 编写一个正确的调用者程序很难，而且我们几乎可以肯定，调用者会不定期出现错误，从 EIP-3074 最后列出的调用者应该警惕的检查 / 漏洞 / 情况非详尽清单中可见一斑。这份清单势必会变得越来越长，很可能伴随着痛苦的发现过程。 此外，恶意参与者可以编写一个看似无害的调用者程序，但是故意留下一个细微的漏洞，等到大量外部账户授权该调用者之后才会被攻击者利用。 如果攻击者没有直接或立即利用这个漏洞从用户那里窃取资金，这个漏洞可能很长时间都不会被发现。 治理劫持示例
|