走进bittree币趣

以太坊钱包可能很快进行一次重大升级。部署了提案的变更后，外部账户(EOA)将马上可以发送批量交易、逾期交易、无序交易等。我的同事@_SamWilsn_和@adietrichs和我一直致力于改善与以太坊交互的用户体验。经过了多次迭代，我们提出了"EIP-3074:AUTHandAUTHCALLopcodes"。这些操作码是这样使用的：外部账户对一条链下信息签名，给一个中继器提供消息，这个中继器把签名和调用数据传给一个链上合约(被称为invoker，调用器)，合约用操作码AUTH验证签名，随后用操作码AUTHCALL发送外部账户的调用。操作码AUTHCALL的功能基本与CALL相同，除了它把CALLER(即msg.sender信息发送者)设为外部账户的地址，需要通过AUTH来恢复。这使得用户可以无须ETH也能与以太坊交互。也就是说，他们的交易可以由一个中继器来“资助”。这个方案听上去可能很熟悉。实际上，它与meta-txs(元交易)的工作机制几乎相同。一个重要区别是meta-txs无法随意设置msg.sender。因此，合约必须明确支持meta-txs。EIP-3074旨在去除meta-txs，减少合约复杂性。为了更深入它的工作机制，一起来了解我们正在构建什么吧。我们想要一个机制允许没有ETH的外部账户可以无须信任地发送交易。“无须信任”是关键。用户不应该给中继器任何可以被利用的特权。EIP-3074允许通过谨慎选择加入到外部账户签名的参数来构建去信任系统。用户需要对keccak(0x03invoker_addresscommit_hash)哈希函数签名。

“typebyte(类型字节)"是EIP-2718里值为0x03的恒定字节。这是用来防止与其他签名规则冲突的，比如EIP-2930的访问列表交易、EIP-1559的费用市场交易、EIP-191的0x19签名消息等。调用器地址把用户的调用与一个特定合约进行捆绑。签名只对该合约有效，即调用者。这使得用户可以选择一个他们信任的调用器——就像选择一个智能合约钱包托管资产一样。我们预想调用器的数量不会多，因为如果他们实现出错的话(注意调用器的使用是选择性的)，用户的利益会受损。开发一个安全的调用器花费会很高。它需要接受多方的审计，并在静态证明上是可靠的。这与现状其实没有太大区别。智能合约钱包在被用来托管大额资产前应该通过了全面的审计与证明。很多大型DeFi项目也是这样做的。要签名的最后一个参数是commit_hash（委托哈希）。这就是给调用器设计师很大灵活性，以及允许非常多不同签名规则得以开发的地方。委托参数限定调用者只能执行某些操作，并为处理一次调用建立了一定的有效性要求。用户可以信任调用器会遵循这个程序，因为代码可以在链上得到验证。这是区块链很好的一个特性。现在来看一个简单的案例。假设一个用户想通过调用器发送一个调用。为了避免调用被传送，他们提供一个随机数。他们还提供其他不可篡改的数值。用户对这些数值进行哈希以获得委托，并在用于AUTH的签名信息里使用该委托。

调用器会用收到的值重新生成委托哈希值。这样，如果资助方修改了一个值，调用器会计算出一个不同于外部账户签名的委托哈希值，导致AUTH恢复一个垃圾地址。会出现下图的情况：
希望现在你相信调用器能像一个智能合约钱包那样运作，任何外部账户都可以使用。现在看一下如何用委托哈希构建更多有趣的方案。总的来说，最重要的是”一个操作一个签名“。这是看待事情的一个简单方法。一个签名由一笔交易的哈希创造，为什么不对多笔交易进行哈希呢？其实EIP-3074是可以实现的。当一个账户已经用AUTH验证了，调用器就可以进行该账户想要的、尽可能多次的AUTHCALL。因为我们信任该调用器会没有偏差地执行它的代码，这很好。我们还可以设计出委托哈希是多个调用的哈希值的方案。
在上文的方案里，调用者会用到全部的数值(随机数1、随机数2等)，并把它们合起来进行哈希，生成一个委托哈希值。它用委托哈希值和用户签名来调用AUTH。AUTH会验证用户是否都对那些参数签名了。然后，调用器会对所有调用逐个验证其随机数和其他参数，然后把鉴别过的调用数据发送到鉴别过的地址。在这个基础上可以构建更多的方案。假如你添加了一个新参数”expiration（逾期）"。这个参数会被哈希成委托哈希值，且在验证过程中，调用者会验证是否expiration