AUTHCALL 将得到一个新的参数 index，该参数指向最后一个 AUTH 创建的列表中的地址。

　　用户地址的 nonce 将随 AUTHCALL 递增。nonce 并非由调用者存储，而是实际的账户 nonce。

　　利：

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

• 　　安全性由协议保障。

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

　　弊：

• 　　nonce 实现，不支持并行。

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

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

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

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

　　利：

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

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

　　弊：

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

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