我们来看一个简单的案例。用户想要通过调用者发送一个调用。为了避免他们的调用被无限次中继，他们需要提供一个 nonce，另外还有其它不可更改的值。用户对这些值进行哈希计算得到 commit，并将该 commit 包含在签名消息内，以便合约使用操作码 AUTH 进行验证。

　　调用者会使用传入的值来重新生成 commit 哈希。这样一来，如果代付者（sponsor）改变了其中一个值，调用者计算得到的 commit 哈希会与外部账户签署的完全不同，导致 AUTH 恢复出一个垃圾地址，如下图所示：

　　希望你现在已经相信，调用者就像任何普通账户都可以使用的智能合约钱包。现在我们来看看如何使用 commit 来构建更有趣的方案。

　　通常情况下，“一个操作对应一个签名” 已经成了经验法则。这是一种比较简单的理解。签名是基于一个事务的哈希值创建的，为什么我们不将多个事务合并进行哈希计算呢？事实证明，EIP 3074 可以做到这点。

　　只要某个账户可以通过 AUTH 的验证，调用者就可以按该账户的要求做任意多次 AUTHCALL。这样做是没问题的，因为我们相信调用者会如实执行代码。我们可以设计将多个调用合并哈希成 commit 的方案。

　　在上图所示的方案中，调用者会将所有值（nonce1、nonce2 等）合并进行哈希，生成 commit。调用者将使用这个 commit 和用户签名来调用 AUTH。AUTH 会验证用户是否真的签署了这些参数。

　　然后，调用者会遍历每个调用并验证 nonce 和其它参数，然后将经过认证的调用数据（calldata）发送至被许可的地址。

　　在此基础上，我们还可以构建更多方案。例如，假设你增加一个新的参数 “保质期”。该参数会与其它参数一起经过哈希得到 commit。另外，在验证过程中，调用者会验证expiration < block.number。现在，外部账户已经可以使用限期交易了！

　　EIP 3074 将带来更多流畅的用户体验，同时不会引入额外的信任假设。如果你想要阅读 EIP 3074 的完整内容，请点击这个链接：https://eips.ethereum.org/EIPS/eip-3074

　　go-ethereum 的原型实现在此处维护：

　　https://github.com/quilt/go-ethereum/tree/eip-3074

　　我们正在与一些对该机制有兴趣的团队合作。如果你觉得这个机制有用的话，请告诉我们，让我们一起努力！欢迎大家提供对该提案的反馈，非常感谢！点击该链接，留下你的反馈：https://ethereum-magicians.org/t/eip-3074-auth-and-authcall-opcodes/4880/49。

　　最后，如果你对我们的工作感兴趣，我们的团队正在火热招聘中。我们致力于对以太坊核心协议进行中长期改进。如需了解更多信息，请直接私信我 @lightclients。

　　（完）

　　 (责任编辑：admin)