关于开发者来说，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 终究列出的调用者应该警觉的检查/缝隙/状况非详尽清单中可见一斑。这份清单势必会变得越来越长，很可能伴随着苦楚的发现进程。
此外，歹意参与者能够编写一个看似无害的调用者程序，可是故意留下一个纤细的缝隙，等到很多外部账户授权该调用者之后才会被攻击者利用。
假如攻击者没有直接或当即利用这个缝隙从用户那里盗取资金，这个缝隙可能很长时刻都不会被发现。
管理劫持示例
-
歹意去中心化买卖所 EveSwap 为其用户编写了一个调用者程序。这个调用者程序经过空投 EVE 代币来为用户提供 gas 资助，并批量处理用户的同意和转账业务。
-
EveSwap 的调用者程序看似无害，并且永久不会盗取用户的代币，由于这样立刻就会泄露。
-
用户很开心。买卖都成功了，买卖费也很廉价。几个月来平安无事。
-
可是，每当有人运用 EveSwap 买卖 AliceSwap 的管理代币 ALI 时，会主动将用户的 AliceSwap 投票权托付给 EveSwap。
-
一旦授权人数到达某个阈值，EveSwap 就会经过管理提案劫持 AliceSwap。
EveSwap 用户不太可能注意到这个进程，由于买卖总是成功的，可是终究会给 AliceSwap 带来毁灭性的冲击。
跨链重放示例
EIP 3074 合理地主张 commit 应该包括 chainid。可是，这是由调用者，而非协议履行的。在另一条链上有着相同地址的调用者可能会跳过该检查（或与此相关的检查）。
-
EveSwap 在兼容 EVM 的 BobSpongeChain 上运转，后者支撑 EIP 3074。EveSwap 在 BobSpongeChain 上部署了一个诚笃的调用者。
-
用户运用该调用者在 BobSpongeChain 上买卖，然后运用桥将财物转移到以太坊上。
-
EveSwap 运用同一个部署密钥在以太坊上部署了另一个地址相同的调用者。这个在以太坊上的调用者不会检查
commit，只会检查ownerOnly，并充任其全部者的通用 AUTH/AUTHCALL 署理。 -
这样一来，EveSwap 就能够劫持用户在以太坊上的外部账户并卷走他们的财物了。
用户从未在以太坊上买卖过，运转在 BobSpongeChain 上的调用者程序又经过了严格的安全检查。尽管如此，用户仍是丢失了全部财物。
以太坊经过 EIP 155 的重放维护来防备这种状况。AUTHCALL 没有重放维护。由于全部 commit 检查都交给调用者完成，咱们失去了以太坊提供的全部买卖维护。攻击是在所难免的，由于维护措施很随意。假如要接受EIP 3074，AUTH 音讯有必要清晰包括 chainid，而非将其作为 commit 的一部分。
咱们还能采纳什么别的手段？
我的提议是完成一个更清晰的机制，在协议层面强制规定 commit 的含义。commit 结构将是类型化的（如 EIP 712 所述），钱包会以用户可读的形式将 commit 呈现出来。用户能够确切地知道业务是什么姿态的，并坚信这个业务不会在任何链上重放，无需依赖于调用者程序开发者的品行和能力。
一个可能的完成：
AUTH 将运用包括授权调用列表的类型化结构替代 commit 哈希值。每个调用都将指定 https://bicoin8.com/wp-content/uploads/2023/04/202304211cHpE0.jpgnonce,to,gas,calldata,value,chainid}。签名将被验证，整个授权调用列表将保存为 authorized_transactions 而非 authorized 地址变量。
AUTHCALL 将得到一个新的参数 index，该参数指向终究一个 AUTH 创立的列表中的地址。
用户地址的 nonce 将随 AUTHCALL 递加。nonce 并非由调用者存储，而是实践的账户 nonce。
利：
-
用户能够清楚地了解状况。
-
安全性由协议保证。
-
仍然支撑批处理和账户笼统。
弊：
-
nonce 完成，不支撑并行。
-
杂乱调用者程序的业务处理起来很繁琐，由于用户有必要检查并接受整个调用列表。
不同的完成可能支撑不同的 nonce 计划。可是，不管咱们运用什么机制，该机制有必要由协议而非调用者履行。
不管如何都应该避免让杂乱调用者履行很多用户调用。杂乱操作应该作为一般的智能合约完成，而非尝试完成运用多个外部账户调用的算法。
替代计划：完全避免硬分叉
还有一个选择是完全避免 AUTH 机制，并经过 vbuterin 主张的另一种买卖池来解决账户笼统和批量处理问题。
利：
-
无需硬分叉，可由智能合约和能够感知这些智能合约的节点支撑。
-
可用于全部支撑 EIP 3074 的完成，而不会引入额外的危险。
弊：
-
不向后兼容已有的外部账户。用户需求部署一个合约钱包并将财物转移到该钱包内。
除非要求在不迁移的状况下支撑已有的外部账户，不然这个选择看起来更安全。
视野开拓
与许多经济学家的信念相反，灯塔服务可以由私人提供……尽管文献中有大量有关灯塔的论述。就我所知没有一个经济学家对灯塔的财政和管理作为广泛深入的研究。灯塔是凭空拿来的一个例子，其目的是提供'确定的细节，以具有艺术意味的逼真的事物来代替空洞和虚幻的叙述”-《经济学的著名寓言》
