EIP-3074 对钱包与 DApp 的影响

作者：Nic @ imToken Labs

目标读者：区块链开发者

先备知识：

• 了解 EOA 与合约的不同

• 了解 EVM 与合约的执行过程

• 了解 ERC-20 的 approve 及 permit 设计

• 详情可查阅：https://support.token.im/hc/zh-tw/articles/22181703417241

EIP-3074

▶ 更好、更安全的使用体验

EIP-3074 让 EOA 能将控制权交给指定的合约，藉此获得和合约一样丰富的执行能力。

在 EIP-3074 以前，EOA 每次送出交易就只能做一个操作，例如去 approve ERC20 或是去 Uniswap 兑换；在 EIP-3074 以后，EOA 可以一次完成多个操作，或甚至出现以前无法想象的用途。

简而言之，EIP-3074 让使用体验大幅提升，目前熟悉的授权方式也将被重塑，在维持使用体验不变的前提下提升安全性。

而且透过 EIP-3074，EOA 可以不必再自己送交易上链，也就不需要烦恼要先筹出 ETH 来支付交易手续费的问题。

▶ Invoker 合约

能够获得 EOA 控制权的合约称为 Invoker 合约。当然不是任意的合约都能获得 EOA 的控制权：EOA 要用私钥签名，签名内容会明确指定是哪个 Invoker 合约，以及允许 Invoker 执行的操作。

△ EOA 签名内容会明确指定哪个 Invoker 合约（invoker address）及授权该 Invoker 合约的操作（commit）。

实际执行流程大概会长这样：

• Alice 用她的 EOA 私钥签名，然后将签名内容及签章交给 Relayer。

• Relayer 带上链到 Invoker 合约执行。

• Invoker 验证签章，验证通过后就能以 EOA 的身份去执行操作，例如去 approve USDC，然后去 Uniswap 进行资产互换，最后再使用一些 USDC 给 Relayer 作为手续费。

注 1：Relayer 为非必要，Alice 也可以自己带签名内容和签章上链。

△ Invoker 验证完签章并开始执行操作后，皆是以 Alice EOA 的身份去执行，就像是获得该 EOA （有限的）控制权。

不过要注意，执行完并不会增加该 EOA 的 nonce 值，所以同一个签名有可能可以重复使用（只要 EOA nonce 不变），因此 Invoker 需要自己实作一套 nonce 机制来避免重放。

△  如果 Invoker 合约没有防 Replay，同一笔授权就可以一直被执行。

了解更多

关于 EIP-3074 实际的运作机制介绍可以参考：https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

▶ 用途

Batchcall

让用户把原本该分为好几笔交易的执行合并为一笔，省下多次授权签名的过程以及一些 Gas 成本。

注：这会需要 DApp 也支持 Batchcall 的功能，像是目前社群正在推的 EIP-5792，否则 DApp 把使用者当普通 EOA 的话一样只会每个操作都 prompt 一次交易给用户签名。

了解 EIP-5792，请复制链接到浏览器查阅：https://eips.ethereum.org/EIPS/eip-5792

Session Key

使用者也可以让第三方在有条件限制下替他代为操作，如下图中的 delegate key 就是被授权的第三方；access policy 则是执行的限制条件，例如限制只能去操作 Uniswap、每天最多转走 1 ETH、授权有效期限等等。

这些条件都是在 Invoker 合约内设计并检查，只要检查能通过，第三方就能以使用者 EOA 身份去执行操作。

△ Telegram Bot 可以被给予特定权限，去以使用者 EOA 名义执行操作。

Native ETH Permit

只要条件满足（也就是 Permit 签章合法），就能以授权人 EOA 身份去执行 ETH 转账，达成原生 ETH Permit 的效果。

Limit Order

使用者填好限价单条件，等到条件满足就能以使用者 EOA 身份去执行，包含 approve 相关数字资产给 DEX、去 DEX 互换等等操作。和 DEX 本身提供的 Limit Order 相比，用户不需事先送交易去 approve 给 DEX。

△ Alice 成交订单时会顺便执行 Approve，不再需要事前 Approve。

把条件设计得更通用的话，就会变成像是一个 Intent 合约：只要使用者指定的条件被满足，任何人都能以他的 EOA 身份去执行完成意图。

△ 只要 Intent 条件被满足，任何人都能以使用者 EOA 名义去发起执行。

Social Recovery

让使用者遗失 EOA 私钥时，能藉由当初她（Alice）签好的 EIP-3074 授权，搭配她授权的人（Husband 及 Trust Agent）的签名来将该 EOA 的资产全部转走。实际上 Recover 的是（可转移的）资产，不是账户控制权。EOA 私钥遗失后该 EOA 就无法再使用了。

△ 当使用者遗失 EOA 私钥时，其他当初被授权的人可以签名授权转走 EOA 的资产。

EIP-3074 的影响

▶ 改善资产授权的方式，甚至取代 approve/permit？

DApp 目前都是以使用者是 EOA 的假设去设计的：使用者必须「事先 approve」且要「approve 足够大的资产数量」给 DApp 合约，如此使用者才不需要随时保持在线、等待 DApp 执行，以及不需要不断重复 approve，这对使用体验有很大的提升。

例如条件触发的应用像是限价单或是 DCA，使用者不一定会在条件符合时在在线，所以要事前先 approve 够大的资产数量让 DApp 合约去执行，而且可能是重复执行。

△ 使用者必须事前 approve DApp 足够大的资产数量，才能方便 DApp 使用他的钱去操作。

△ 但也因此必须相信 DApp 或避免 approve 给 fake DApp，以及能实时移除 approval。

或是后来出现的 permit 模式，例如，EIP-2612 或是非原生的 Permit2，都是为了改善 approve 模式的使用体验及安全性：使用者不需再 approve 很大的资产数量给各个 DApp 合约（而且每个资产都要 approve 一次），而是只需「签一个名」就可以授权 DApp 合约在「指定时间」内「提取指定数量资产」，如此不仅大大限缩了攻击面，也大大提升了使用体验。

了解更多

EIP-2612 详情，请复制下方链接到浏览器查询：https://eips.ethereum.org/EIPS/eip-2612

Permit2 详情，请复制下方链接到浏览器查询：

https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18

△ 使用者只需链下签名，并且能指定资产数量及有效期间，提供比 approve 更好的使用体验及安全性。

但事实上，不只是 approve，permit 模式被利用作为诈骗攻击手段的事件仍然层出不穷，：受害者误签了以为是要给 DApp 用的 permit 但实际上是给了攻击者。

△ 使用者在签 permit 时，只能看到要授权给谁，但不知道这会搭配什么操作一起执行。

注：另外目前的 permit 设计并不兼容重复性操作的 DApp，例如 DCA 或其他定期支付应用。这是因为 permit 有防重放机制，所以转账完一次之后就无法再用同一个 permit，等于是使用者要先为未来每一次重复性操作都预先签好 permit。

了解更多

了解 permit 模式被利用作为诈骗攻击手段的事件，请复制下方链接到到浏览器查询：

https://x.com/realScamSniffer/status/1783027808723435727

https://x.com/realScamSniffer/status/1784932506174967970

https://x.com/realScamSniffer/status/1786738218962223226

不过 EIP-3074 带来了改变的契机：当 DApp 开发者知道 EOA 可以透过 Invoker 做到各种复杂的操作之后，DApp 交互上的设计便不再需要为了提升使用体验而牺牲安全性，例如「使用者事前 approve 大笔资产数量」、「用户签个 permit 讯息授权提款」。

取而代之的是使用者将 DApp 操作与 approve 绑在一起，透过 Invoker 去进行原子化（Atomic）的执行：要不 approve 和 DApp 操作一起成功执行，要不一起失败，没有 approve 单独成功的可能，所以使用者可以很确信这一次 approve 就是给这次的操作。

而且使用者是使用链下签名的授权方式，所以使用体验和 permit 是一样的！这表示 DApp 将不再需要 permit 模式！未来钱包可以直接对 permit 签名请求进行封禁或更严格的审查，不必再担心是否会造成使用者用不了某些 DApp（但反而因此被诈骗利用）。

△ 用户不再只单纯授权某个地址，而是授权某个地址以及做哪些事，甚至可以看到模拟的执行结果。

注：这不表示可以完全阻绝诈骗！使用者一样有可能被骗进诈骗网站，诈骗网站一样可以组 approve 或转账操作让使用者签名，但此时使用者至少可以看到这次签名是要做什么操作，钱包甚至可以透过仿真显示执行结果并呈现给使用者，让使用者可以明确知道谁会少了多少钱、谁会多了多少钱。相比于没办法知道做什么操作或甚至执行结果的 permit， 用户有了更多信息去决定要不要授权。虽然不是完美的防治，但仍将是对现状大幅的改善。

▶ 钱包如何处理 EOA nonce

目前的 EIP-3074 设计会把 EOA nonce 值包含在签名内容中，所以只要 EOA 送了一笔交易上链执行，改变了 nonce 值，原本的 EIP-3074 授权就会直接全部失效。

如果使用者是去授权其他人来代为操作 EOA，例如上面提到的 Session Key 或是 Social Recovery 方式，那 EOA 的 nonce 就要避免被改变，否则就要再重新签一次所有授权并交给受托人，这对使用体验及机制的稳健程度都有不小影响。

如果使用者是由自己授权操作的话，那就不用特别避免 EOA nonce 被改变，因为 EIP-3074 签名还是和交易一样预期要在某个期限之前去执行。只是钱包要多管理该 EOA 的 EIP-3074 交易：如果有 EIP-3074 签名正在等待上链，那 EOA 自己上链的交易就要等待。

注：Invoker 合约自己会（也应该要）维护一套 nonce 机制，所以签名用过之后一样得再签一次，不管 EOA nonce 是否改变。

Session Key 和 Social Recovery 非常可能要等到 EIP-3074 修改规则把 EOA nonce 从签名内容移除，才有可能被大模规采用。因此钱包只需专注在「使用者自己授权操作」的使用情境下，并把 EIP-3074 签名也当作交易一样来处理，就不需要担心要避免 EOA 送交易、改变 EOA nonce。

不过要注意，如果是使用者自己要带自己的 EIP-3074 签名内容上链的话会有两个缺点：

1. 使用者要签两次名：一次是 EIP-3074 签名，一次是上链交易的签名。

2. 因为上链交易会在交易开始执行前就先将 EOA nonce +1，所以使用者的 EIP-3074 签名的 EOA nonce 要是预先 +1 才能对得上因为自己上链而造成的 EOA nonce +1。

△ 因为自己上链会先把 EOA nonce +1，所以开始验证 EIP-3074 签章时就会因为 EOA nonce 对不上而失败。

△ 使用者自己上链前有提先把 EIP-3074 签名里的 EOA nonce +1，就能顺利通过验证。

总结与重点

• EIP-3074 让 EOA 获得和合约一样丰富的执行能力，开启了很多新的应用场景。

• 这不仅让使用体验大幅提升，也将会改变现行的授权方式，让它在使用体验不变的前提下变得更为安全。

• 而且 EIP-3074 是单纯签名，使用者不一定要自己将签名带上链执行，也就不需要烦恼要先凑到 ETH 来支付手续费。

• EIP-3074 的用途包含 Batch Call、Session Key、Native ETH Permit、Limit Order、Social Recovery。这些许多原本都是 EOA 不可能做到的，有些像是 Limit Order 则是需要预授权等较不安全的方式才能使用。

• EIP-3074 也将改变现行的授权方式。approve 直接授权指定地址有无限期提领数字资产的权力，而且需要使用者 EOA 先送出一笔交易执行 approve，因此使用体验及安全性都不佳；permit 只需要使用者签名，且每次签名都会指定资产数量及有效期，在使用体验及安全性上都比 approve 提升不少。

• 但 permit 依然被频繁利用于诈骗，签名时使用者只能知道要授权给哪个地址、多少资产数量及有效期，但不会知道这个授权是要「用来做什么」的。「用来做什么」会是另一笔签名（或交易），正常 DApp 会让使用者签 permit 及「用来做什么」，但它们仍然会是两笔不同签名，因此被请求 permit 签名时，使用者及钱包都没办法知道这笔 permit 会被「用来做什么」。

• 有了 EIP-3074，使用者 (1) 不需要事先 approve 很大的资产数量给 DApp，而是有操作时才 approve，效果和 permit 一样；(2) 只是单纯签名且不需烦恼凑 ETH 付手续费，和 permit 一样；（3）每次 approve 都是和指定的操作所绑定、一起签名，使用者可以清楚知道这次 approve 是「用来做什么」，这会比 permit 更为安全！

• 期望 EIP-3074 能成功取代现行的 approve 及 permit 模式，提供给用户一个更安全的授权方式。