以太坊钱包可能很快迎来一次重大升级？了解eip-3074

以太坊钱包可能很快就会迎来重大升级。升级完成后，EOA可以发送批量事务、截止事务、无序事务等。

两位同事和我@SamWilsn和@Aditerichs正在研究如何改进以太坊的交互体验。经过多次迭代，我们提出了eip3074：操作码auth和authcall。

要使用这两个操作码，外部帐户需要对链下的消息进行签名并将消息发送给中继，然后中继将签名和调用数据发送给链上契约（称为“调用者”）。调用方契约首先使用操作码auth来验证签名，然后使用操作码authcall来中继外部帐户的调用。

authcall和普通调用只有一个区别：authcall将调用方（例如，消息的发送方）设置为使用操作码auth恢复的外部地址。这样，用户就可以与以太坊进行交互，而无需使用以太网货币。换句话说，他们的事务是由接力“赞助”的。

你可能认为这种机制很熟悉。实际上，这类似于元事务的操作。但是，需要强调的是，不能为元事务任意设置消息发送方。因此，契约必须明确支持元事务。eip3074旨在消除元事务并降低契约的复杂性。

在深入研究它的工作原理之前，让我们先谈谈我们想要构建什么。我们希望建立一种机制，允许普通用户在不使用以太网货币的情况下发送不受信任的事务。这里的关键词是“不信任”，也就是说，用户不会授予中继任何可能被利用的特权。

eip3074通过仔细选择普通帐户签名中包含的参数来创建一个无信任系统。用户签名keccak（0x03++invoker） address++commit hash）

“类字节”是EIP 2718的常量字节，值为0x03。此字节的目的是避免与其他签名机制冲突，例如eip2930的访问列表事务、eip1559的费用市场事务、eip191的0x19签名消息等。

调用方地址将用户的调用绑定到特定的约定。用户签名仅对呼叫者合约有效。因此，用户可以选择他们信任的呼叫者，就像他们选择智能合约钱包来存储资产一样。

我们期望只有少数呼叫者存在，因为如果呼叫者契约的实现出错，用户可能会遭受损失（请注意，呼叫者选择自己加入）。开发一个安全的呼叫者契约的成本很高，需要多方审计和静态证明。

但和今天的做法没什么不同。智能合约钱包也应该在大量存款前经过全面审核和认证。很多大DeFi项目也是如此。

**一个签名参数是commit Hash（或commit）。这使呼叫者和设计者能够更灵活地开发许多不同的解决方案。

此提交限制调用者仅执行特定操作并创建特定验证需求来处理调用。用户可以信任调用者遵循此过程，因为他们可以验证链上的代码。这就是区块链的优势。

让我们看一个简单的例子。用户希望通过呼叫者发送呼叫。为了避免它们的呼叫被无限中继，它们需要提供一个nonce和其他不可更改的值。用户散列这些值以获得提交，并将提交包含在签名消息中，以便可以使用auth验证契约。

调用程序使用传入的值重新生成提交哈希。这样，如果付款人更改了其中一个值，则调用者计算的提交哈希将与外部帐户签名的提交哈希完全不同，从而导致auth恢复垃圾地址，如下图所示：

我希望你现在相信，来电者就像一个智能合约钱包，可以被任何普通账户使用。现在让我们看看如何使用commit构建一个更有趣的解决方案。

通常，“一个操作对应一个签名”已成为一条经验法则。这是一个相对简单的理解。签名是基于事务的哈希值创建的。我们为什么不合并多个事务进行散列计算呢？原来，eip3074可以做到这一点。

只要一个帐号能够通过auth验证，调用者就可以根据帐号的要求进行任意次数的authcall。这是可以的，因为我们相信调用者将按原样执行代码。我们可以设计一个方案，将多个调用散列到commit中。

在上图所示的方案中，调用者将合并所有值（nonce1、nonce2等）以散列并生成提交。调用者将使用此提交和用户签名来调用auth。Auth验证用户是否实际签署了这些参数。

然后，调用者遍历每个调用并验证nonce和其他参数，然后将经过身份验证的调用数据（calldata）发送到许可地址。

在此基础上，我们可以构建更多的解决方案。例如，假设您添加了一个新参数“shelf life”。将此参数与其他参数散列以获得提交。此外，在验证过程中，调用者将验证过期时间block.number。现在，可以使用外部帐户在期限内进行交易！

eip3074将在不引入额外信任假设的情况下带来更流畅的用户体验。如果您想阅读EIP 3074的全部内容，请点击此链接：https://eips.ETHereum.org/EIPS/eip-3074

go以太坊的原实现如下：

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