EIP-3074将如何改变钱包与dApp的交互方式

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）

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

1. Alice 用她的 EOA 私钥签名，然后将签名内容及签章交给 Relayer
2. Relayer 带上链到 Invoker 合约执行
3. Invoker 验证签章，验证通过后就能以 EOA 的身份去执行操作，例如去 approve USDC，然后去 Uniswap 兑换，最后再转一些 USDC 给 Relayer 作为手续费

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

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

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

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

关于 EIP-3074 实际的运作机制介绍可以参考：EIP3074 简介

用途

Batchcall

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

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

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 合约在「指定时间」内「提取指定金额」，如此不仅大大限缩了攻击面，也大大提升了使用体验。

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

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

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

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

不过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 模式，提供给使用者一个更安全的授权方式。