利：

• 用户可以清楚地了解情况。

• 安全性由协议保障。

• 依然支持批处理和账户抽象。

弊：

• nonce 实现，不支持并行。

• 复杂调用者程序的事务处理起来很繁琐，因为用户必须查看并接受整个调用列表。

不同的实现可能支持不同的 nonce 方案。但是，无论我们使用什么机制，该机制必须由协议而非调用者执行。

无论如何都应该避免让复杂调用者执行大量用户调用。复杂操作应该作为普通的智能合约实现，而非尝试实现使用多个外部账户调用的算法。

替代方案：完全避免硬分叉

还有一个选择是完全避免 AUTH 机制，并通过 vbuterin 建议的另一种交易池来解决账户抽象和批量处理问题。

利：

• 无需硬分叉，可由智能合约和可以感知这些智能合约的节点支持。

• 可用于一切支持 EIP 3074 的实现，而不会引入额外的风险。

弊：

• 不向后兼容已有的外部账户。用户需要部署一个合约钱包并将资产转移到该钱包内。

除非要求在不迁移的情况下支持已有的外部账户，否则这个选择看起来更安全。