2

走进 EIP-3074

 3 years ago
source link: https://news.ethereum.cn/Technology/eip-3074
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
ETH   $ 2100.03   5.22%      Gas:  123 Gwei          Epoch / Slot :
Loading...
       活跃验证者 :
Loading...

走进 EIP-3074

EIP-3074解决如何在去信任的前提下提供更顺滑的用户体验


lightclient       2021-04-02

来源 | @lightclients

以太坊钱包可能很快进行一次重大升级。部署了提案的变更后,外部账户 (EOA) 将马上可以发送批量交易、逾期交易、无序交易等。

我的同事 @SamWilsn @adietrichs 和我一直致力于改善与以太坊交互的用户体验。经过了多次迭代,我们提出了 "EIP-3074: AUTH and AUTHCALL opcodes"。

这些操作码是这样使用的:外部账户对一条链下信息签名,给一个中继器提供消息,这个中继器把签名和调用数据传给一个链上合约 (被称为 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 (0x03 ++ invoker_address ++ commit_hash) 哈希函数签名。

msg

“type byte (类型字节)" 是 EIP-2718 里值为 0x03 的恒定字节。这是用来防止与其他签名规则冲突的,比如 EIP-2930 的访问列表交易、EIP-1559 的费用市场交易、EIP-191的 0x19 签名消息等。

调用器地址把用户的调用与一个特定合约进行捆绑。签名只对该合约有效,即调用者。这使得用户可以选择一个他们信任的调用器——就像选择一个智能合约钱包托管资产一样。

我们预想调用器的数量不会多,因为如果他们实现出错的话 (注意调用器的使用是选择性的),用户的利益会受损。开发一个安全的调用器花费会很高。它需要接受多方的审计,并在静态证明上是可靠的。

这与现状其实没有太大区别。智能合约钱包在被用来托管大额资产前应该通过了全面的审计与证明。很多大型 DeFi 项目也是这样做的。

要签名的最后一个参数是 commit_hash (委托哈希)。这就是给调用器设计师很大灵活性,以及允许非常多不同签名规则得以开发的地方。

委托参数限定调用者只能执行某些操作,并为处理一次调用建立了一定的有效性要求。用户可以信任调用器会遵循这个程序,因为代码可以在链上得到验证。这是区块链很好的一个特性。

现在来看一个简单的案例。假设一个用户想通过调用器发送一个调用。为了避免调用被传送,他们提供一个随机数。他们还提供其他不可篡改的数值。用户对这些数值进行哈希以获得委托,并在用于AUTH的签名信息里使用该委托。

commit

调用器会用收到的值重新生成委托哈希值。这样,如果资助方修改了一个值,调用器会计算出一个不同于外部账户签名的委托哈希值,导致 AUTH 恢复一个垃圾地址。会出现下图的情况:

error

希望现在你相信调用器能像一个智能合约钱包那样运作,任何外部账户都可以使用。现在看一下如何用委托哈希构建更多有趣的方案。

总的来说,最重要的是”一个操作一个签名“。这是看待事情的一个简单方法。一个签名由一笔交易的哈希创造,为什么不对多笔交易进行哈希呢?其实 EIP-3074 是可以实现的。

当一个账户已经用 AUTH 验证了,调用器就可以进行该账户想要的、尽可能多次的 AUTHCALL。因为我们信任该调用器会没有偏差地执行它的代码,这很好。我们还可以设计出委托哈希是多个调用的哈希值的方案。

nonce

在上文的方案里,调用者会用到全部的数值 (随机数1、随机数2等),并把它们合起来进行哈希,生成一个委托哈希值。它用委托哈希值和用户签名来调用AUTHAUTH 会验证用户是否都对那些参数签名了。

然后,调用器会对所有调用逐个验证其随机数和其他参数,然后把鉴别过的调用数据发送到鉴别过的地址。

在这个基础上可以构建更多的方案。假如你添加了一个新参数”expiration (逾期)"。这个参数会被哈希成委托哈希值,且在验证过程中,调用者会验证是否 expiration < block.number。这样外部账户就可以有逾期交易了!

EIP-3074 提供的是功能强大的基元,能为更多顺滑用户体验打开可能性而无须引入额外的信任假设。如果你想阅读这份 EIP 的完整版,你可以点击这里:

https://eips.ethereum.org/EIPS/eip-3074

用 go-ethereum 编写的原型实现可以在这里看到:https://t.co/XWhlX9C4Y5?amp=1

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源,文章版权归原作者所有,转载须注明原文出处以及ethereum.cn,若需长期转载,请联系[email protected]进行授权。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK