以太坊Pectra升级:EIP-7702深度解析及最佳实践

前言

以太坊即将迎来Pectra升级,这是一次意义重大的更新,多项重要的以太坊改进提案将被引入。其中,EIP-7702对以太坊外部账户(EOA)进行了变革性改造。该提案模糊了EOA与合约账户CA之间的界限,是继EIP-4337之后,朝着原生账户抽象迈进的关键一步,为以太坊生态系统带来了全新的交互模式。

Pectra已在测试网络完成部署,预计不久后将上线主网。本文将深入分析EIP-7702的实现机制,探讨其可能带来的机遇与挑战,并为不同参与者提供实用的操作指南。

协议分析

概述

EIP-7702引入了一种新的交易类型,允许EOA指定一个智能合约地址,为其设置代码。这使EOA能够像智能合约一样执行代码,同时保留发起交易的能力。这一特性为EOA赋予了可编程性与可组合性,用户可以在EOA中实现社交恢复、权限控制、多签管理、zk验证、订阅式支付、交易赞助以及交易批处理等功能。值得注意的是,EIP-7702能与EIP-4337实现的智能合约钱包完美兼容,二者的无缝集成大大简化了新功能的开发与应用过程。

EIP-7702引入了交易类型为SET_CODE_TX_TYPE (0x04)的交易,其数据结构定义如下:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

其中authorization_list字段定义为:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

在新的交易结构中,除authorization_list字段外,其余遵循与EIP-4844相同的语义。该字段是列表类型,可包含多个授权条目,每个授权条目中:

• chain_id表示此授权委托所生效的链
• address表示委托的目标地址
• nonce需与当前授权账户的nonce匹配
• y_parity, r, s是授权账户签署授权的签名数据

一笔交易内的authorization_list字段可包含多个不同授权账户(EOA)签署的授权条目,即交易发起者可与授权者不同,以实现对授权者的授权操作进行gas代付。

实现

授权者签署授权数据时,需先将chain_id, address, nonce进行RLP编码。然后将编码后的数据与MAGIC数一起进行keccak256哈希运算,得到待签名的数据。最后,使用授权者的私钥对哈希后的数据签名,获得y_parity, r, s数据。MAGIC (0x05)作为域分隔符使用,目的是确保不同类型签名的结果不会冲突。

当授权者授权的chain_id为0时,表示授权者允许在所有支持EIP-7702的EVM兼容链上重放授权(前提是nonce也刚好匹配)。

授权者签署完授权数据后,交易发起者会将其汇聚在authorization_list字段中进行签名并通过RPC广播交易。在交易被包含在区块中执行前,Proposer会先对交易进行预检查,其中对to地址进行强制检查以确保此交易不是合约创建交易,即发送EIP-7702类型的交易时,交易的to地址不能为空。

同时,此类交易要求authorization_list字段必须至少包含一项授权条目,如有多个授权条目都由同一个授权者签署,最终只有最后一个授权条目起效。

交易执行过程中,节点会先增加交易发起者的nonce数值,再对authorization_list中的每个授权条目进行applyAuthorization操作。在applyAuthorization操作中,节点会先检查授权者的nonce,然后再增加授权者的nonce。这意味着如果交易发起者与授权者为同一用户(EOA)时,在签署授权交易时nonce的数值应该再加1。

节点应用某个授权条目时,如遇任何错误,该条授权条目将被跳过,交易不会失败,其他授权条目会继续应用,以此确保在批量授权场景中不会出现DoS风险。

授权应用完成后,授权者地址的code字段将被设置为0xef0100 || address,其中0xef0100是固定标识,address是委托的目标地址。由于EIP-3541的限制,用户无法通过常规方式部署0xef字节开头的合约代码,这保证了此类标识只能由SET_CODE_TX_TYPE (0x04)类型的交易才能部署。

授权完成后,授权者若要移除授权,只需将委托的目标地址设置为0地址即可。

通过EIP-7702引入的新交易类型,使授权者(EOA)既可像智能合约一样执行代码,也同时保留了发起交易的能力。相较于EIP-4337,这为用户带来了更接近原生账户抽象(Native AA)的体验,极大降低了用户的使用门槛。

最佳实践

尽管EIP-7702为以太坊生态注入了新活力,但新的应用场景也会带来新的风险。以下是生态参与者在实践过程中需要警惕的方面:

私钥存储

即便EOA在委托后可借助智能合约内置的社交恢复等手段解决因私钥丢失导致的资金损失问题,但它仍无法避免EOA私钥被泄露的风险。需要明确的是,执行委托后,EOA私钥依旧对账户拥有最高控制权,持有私钥便能随意处置账户中的资产。用户或钱包服务商在为EOA完成委托后,即便完全删除存储在本地的私钥,也不能完全杜绝私钥泄露风险,尤其是处于存在供应链攻击风险的场景中。

对于用户来说,在使用委托后的账户时,仍应将私钥保护放在首位,时刻注意:Not your keys, not your coins。

多链重放

用户在签署委托授权时,能通过chainId选择委托可以生效的链,当然用户也可以选择使用chainId为0进行委托,这使得委托可以在多链上重放生效,以方便用户一次签名即可在多链上进行委托。但需注意的是,在多链上委托的同一合约地址中,也可能存在不同的实现代码。

对于钱包服务商来说,在用户进行委托时,应检查委托生效链与当前连接的网络是否相符,并提醒用户签署chainId为0的委托可能带来的风险。

用户也应注意,在不同链上的相同合约地址,其合约代码并不总是相同,应先了解清楚委托的目标。

无法初始化

当前主流的智能合约钱包大多采用代理模型,钱包代理在部署时,会通过DELEGATECALL调用实现合约的初始化函数,以此达成钱包初始化与代理钱包部署的原子化操作,避免被抢先初始化的问题。但用户在使用EIP-7702进行委托时,仅会更新其地址的code字段,无法通过调用委托地址进行初始化。这就使得EIP-7702无法像常见的ERC-1967代理合约一样能在合约部署的交易中调用初始化函数进行钱包初始化。

对于开发者来说,在将EIP-7702与现有的EIP-4337钱包进行组合适配时,应注意在钱包的初始化操作中进行权限检查(例如通过ecrecover恢复签名地址进行权限检查),以避免钱包初始化操作被抢跑的风险。

存储管理

用户在使用EIP-7702委托功能时,可能会因功能需求变更、钱包升级等原因,需要重新委托到不同的合约地址。但不同合约的存储结构可能存在差异(比如不同合约的slot0插槽可能代表不同类型的数据),在重新委托的情况下,有可能导致新合约意外复用旧合约的数据,进而引发账户锁定、资金损失等不良后果。

对于用户来说,应谨慎处理重新委托的状况。

对于开发者来说,在开发过程中应遵循ERC-7201提出的Namespace Formula,将变量分配到指定的独立存储位置,以缓解存储冲突的风险。此外ERC-7779 (draft)还专为EIP-7702提供了重新委托的标准流程:包括使用ERC-7201防止存储冲突,并在重新委托之前验证存储兼容性,以及调用旧委托的接口清理存储的旧数据。

假充值

用户进行委托后,EOA也将可以作为智能合约使用,因此中心化交易所(CEX)可能会面临智能合约充值普遍化的情况。

CEX应通过trace检查每笔充值交易的状态,防范智能合约假充值风险。

账户转换

实施EIP-7702委托后,用户的账户类型可以在EOA与SC之间自由转换,这使得账户既可以发起交易,也可以被调用。意味着当账户调用本身并进行外部调用时,其msg.sender也将是tx.origin,这会打破一些仅限EOA参与项目的安全假设。

对于合约开发者来说,假设tx.origin始终是EOA将不再可行。同样地,通过msg.sender == tx.origin检查来防御重入攻击也将失效。

开发者在开发过程中理应假设未来的参与者可能都为智能合约。

合约兼容性

现有的ERC-721,ERC-777代币在对合约进行转账时都具有Hook功能,这意味着接收者必须实现相应的回调函数以成功接收代币。

对于开发者来说,用户委托的目标合约理应实现相应的回调函数,以确保能够和主流代币兼容。

钓鱼检查

实施EIP-7702委托后,用户账户中的资产可能都将由智能合约控制,一旦用户将账户委托到了恶意的合约,攻击者窃取资金将变得轻而易举。

对于钱包服务商来说,尽快支持EIP-7702类型的交易尤为重要,并且在用户进行委托签名时,应向用户着重展示委托的目标合约,以缓解用户可能遭受钓鱼攻击的风险。

此外,对账户委托的目标合约进行更深入的自动分析(开源检查,权限检查等)可以更好地帮助用户避免此类风险。

总结

本文围绕以太坊即将到来的Pectra升级中的EIP-7702提案展开探讨。EIP-7702通过引入新的交易类型,使EOA具备可编程性与可组合性,模糊了EOA与合约账户的界限。由于目前还没有一个经过实战考验的兼容EIP-7702类型的智能合约标准,因而在实际应用中,不同的生态参与者,如用户、钱包服务商、开发者、CEX等,都面临着诸多挑战与机遇。本文所阐述的最佳实践内容无法涵盖所有的潜在风险,但仍值得各方在实际操作中借鉴应用。