以太坊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等,都面临着诸多挑战与机遇。本文所阐述的最佳实践内容无法涵盖所有的潜在风险,但仍值得各方在实际操作中借鉴应用。