EIP-7702 协议全景解读：从标准到实践（含 Geth 代码实例分析）
EIP-7702 引入了一种新的交易类型，允许外部拥有账户（EOA）指定一个地址作为指向其实现的指针。
EIP-7702 引入了一种新的交易类型，允许外部拥有账户（EOA）指定一个地址作为指向其实现的指针。
例如，该地址可以是一个通用代理合约或最小代理合约，用于将调用消息转发到可升级的钱包实现。
为了更清晰地解释，区分「委托」代码和「委托人」账户至关重要。因此，本文有时会将已委托代码的 EOA 称为「智能 EOA」。
EIP-7702 有效地升级了 EOA，使其功能类似于智能合约（SC）钱包，为 EOA 用户解锁了可编程性和可组合性，并实现了以下功能：
社交恢复：EIP-7702 支持 EOA 用户的社交恢复功能。这对于担心丢失私钥的用户尤其有利，他们只需设置简单的社交恢复功能即可解决这一问题。[1]
交易批处理：用户可以通过摆脱 ERC-20 代币的传统两步「批准和转移」授权模型或进一步的批量发送转移来简化交易。
社交恢复：EIP-7702 支持 EOA 用户的社交恢复功能。这对于担心丢失私钥的用户尤其有利，他们只需设置简单的社交恢复功能即可解决这一问题。
任意签名密钥 WebAuthnP256BLS：钱包可以利用各种密钥类型 例如（WebAuthn、P256、BLS 等）来验证操作，[2] 在设计空间上提供更大的灵活性。
会话密钥：用户可以将具有生命周期和范围权限的会话密钥委托给密钥托管服务，从而实现订阅模式。此外，用户可以在受限制的
「沙盒」环境中与 Dapp 交互，从而阻止恶意行为者访问其完整钱包或资产，从而显著降低网络钓鱼攻击的风险和影响。
自定义 gas 代币通过多重签名方案进行权限控制等等……
EIP-7702 与 ERC-4337 的可组合性也带来了显著的优势。这种可组合性使智能 EOA 能够与现有的基于 ERC-4337 构建的 SC 钱包和基础设施生态系统无缝集成，从而简化新功能的开发和采用。一旦用户使用支持 ERC-4337 的智能合约钱包授权某个地址，该 EOA 地址就可以作为 ERC-4337 中 sender 的字段 UserOperation。
虽然智能 EOA 可以通过社交恢复等机制解决「你的私钥现在无人知晓」的问题，但它们无法解决「你的私钥现在已被他人知晓」的问题，因为私钥仍然拥有对 EOA 的完全授权。为了弥补这一缺陷，需要像 EIP-7377 这样的提案，该提案允许将 EOA 迁移到账户抽象钱包，或者未来允许用户在 EIP-7702 之后停用（并可能重新激活）私钥权限的提案。
同时，在缺乏协议级安全保障的情况下，钱包客户端可以在授权 EOA 为合约钱包后删除其本地存储的「热」私钥，并提示用户删除其私钥的任何本地或外部备份。然而，此类措施无法完全消除私钥泄露的风险，尤其是在涉及供应链攻击的场景下，例如钱包使用的库或钱包客户端本身存在后门。
那么，与 SC 钱包相比，智能 EOA 是否提供了更多有趣或便捷的功能？我最初的想法是，保留 EOA 功能有几个明显的优势：
保留现有地址：例如，这允许用户保留其灵魂绑定代币 （SBT）等物品。然而，并非所有人都愿意公开其 SBT（或链上活动），因为这可能会泄露敏感的个人信息。在隐私与透明度和可验证性需求之间取得平衡，需要其他深思熟虑的解决方案。
简化隐身地址的实现：与使用 SC 钱包相比，基于 EOA 实现隐身地址更加直接。
与现有生态系统的兼容性：用户可以从当前的技术栈中受益，例如在多条链上维护相同的地址。虽然这些功能也可以通过合约钱包实现，但 EOA 的实现方式更简单。
当然，所有这些只是初步推测，实际对用户体验的影响可能取决于不同的创意钱包应用如何利用这些功能从不同的用户群体中收集有意义的反馈和偏好。例如，以太坊的亚文化群体，例如密码朋克、Regens 和 Degens（本文对此进行了分类），可能对钱包设计有着独特的需求和视角。希望未来我们能看到更多多样化的用例和应用出现。
接下来，让我们深入研究协议本身。
01 ｜ 协议概述
EIP-7702 引入了一种新的交易类型 SET_CODE_TX_TYPE（0x04），其 TransactionPayload 定义如下：
其中 authorization_list 定义为：
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])address 中的字段代表 authorization_list 委托代码的地址，而 EOA 的地址可以从有效载荷（chain_id、address、nonce）和签名（y_parity、r、s）中恢复出来。这种 EOA 地址与 EIP-7702 交易地址的解耦，address 使得另一个 EOA 账户可以代表原始 EOA 提交授权，从而实现更灵活的委托和赞助交易。
交易收据定义为：
rlp([status,cumulative_transaction_gas_used,logs_bloom,]);在深入研究代码之前，以下部分将重点介绍一些值得注意的功能作为热身。
强制非空 authorization_list
不能 authorization_list 为空，以确保每笔 EIP-7702 交易都包含授权实现地址的明确意图。此外，该协议会验证每个 authorization_list 元组的参数，包括 chain_idnoncey_parityrs 和的 address 长度和合理范围。
通过授权 authorization_list
在 authorization_list 的每个元组中，address 字段代表授权地址，而签名者的地址则由签名和有效载荷派生而来。这种设计允许 EIP-7702 将 Gas 支付的责任委托给被授权的 EOA，从而实现广为人知的赞助交易。例如，第 2 层排序器可以直接集成 EIP-7702 钱包创建接口，或者添加 API 来收集用户授权并使用 批量提交 authorization_list。钱包服务提供商还可以协助没有余额的用户提交交易。
重要的是，即使批次中的一项授权验证失败，其他授权也不会受到影响。这种设计有助于执行（赞助的）批量授权交易。
Nonce 增量的新案例
EIP-7702 引入了一种新的机制，在每次授权成功后，都会增加 EOA 的 nonce 值。nonce 的处理流程如下：
首先，检查交易的 nonce 值，确保其与账户当前的 nonce 值匹配。然后，交易 nonce 值会递增。
检查列表中的每个授权的随机数，以确保其使用正确的值。当委托成功时，相应的授权随机数将递增。
代码路径请参考 Nonce 增量逻辑章节。
这意味着，如果交易包含授权列表，且授权签名者与交易签名者相同，则必须将 设置 tx.nonce 为 account.nonce 和 authorization.nonce 设置为 account.nonce + 1。如果交易包含由同一 EOA 签名的多个授权（实际使用中不会发生这种情况），则必须按顺序递增每个授权的 nonce。总而言之，这种机制可能会增加 SDK 初始化委托交易的复杂性，尤其是在处理所有情况时。
多路径平衡状态变化
有了 EIP-7702，从 EOA 的角度来看，ETH 余额现在不仅可以通过已签名的交易减少，还可以通过触发合约执行的交易减少。从智能合约的角度来看，EOA 可以直接发送交易来更改账户状态。这带来了以下几点考虑：
此前，EOA 只能通过已签名的交易发送 ETH，这使得交易池可以通过检查新区块中发送者的余额，来使发送者余额不足的待处理交易无效。然而，随着 EIP-7702 的推出，委托代码可以随时修改 EOA 的余额，这使得 EOA 的余额与 EIP-7702 的不变量不兼容，需要重新考虑相关的交易池逻辑。
EIP-7702 钱包实现不能依赖本地维护的不变量，并且必须查询真实账户状态，因为 EOA 可以随时发起交易来改变其余额。
协议内撤销
用户可以利用 EIP-7702 修改授权地址。如果该 address 字段设置为 0x0000000000000000000000000000000000000000，则先前的授权将被撤销。这将清除账户代码，并将账户代码哈希重置为空哈希。
重新授权
重新委托账户需要谨慎的存储管理，以避免发生冲突，否则可能导致未定义的行为。为了解决账户迁移中的难题，ERC-7201 将存储布局根植于独特的插槽中，从而避免重新委托期间发生存储位置冲突。ERC -7779（草案）还通过以下方式为 EIP-7702 钱包提供了标准化的重新委托流程：
使用 ERC-7201 防止存储位置冲突。
重新委托之前验证存储兼容性。
调用旧钱包接口清理钱包数据。
经典 EIP-1559 字段
EIP-7702 采用了 EIP-1559 定义的 Gas 费用模型，要求发送者指定 max_priority_fee_per_gas 和 max_fee_per_gas ，而不是单个字段。交易还可以包含 gas_price 和 access_list 等字段，data 使其保留其他以太坊交易的大部分功能（尽管它不能携带 blob ）。与 EIP-4844 类似，EIP-7702 强制执行了 destination to （在其他类型的交易中也称为）字段不能为空的限制，这与限制合约创建的常见做法一致。
以太坊中另一个著名的禁令是禁止与存储相关的指令（例如 EIP-7562）。EIP-7702 并未实施此类禁令，因为存储指令对于 SC 钱包来说非常重要。
下一节将会介绍更多细节。
02 ｜ 核心协议实现
在本节中，我们将深入探讨：
EIP-7702 交易旅程的实现。
与委托给代码的地址进行交互。
代码分析主要针对开源仓库 Geth ，它是客户端多样性仪表板上列出的主要以太坊客户端之一。EIP-7702 功能的完整拉取请求可在此处找到。
在执行任何操作之前，我们假设节点已激活 EIP-7702，无论是通过硬分叉（从区块高度或从时间戳）还是从创世区块。
发送 EIP-7702 交易
要发送 EIP-7702 交易，用户首先需要填写 authorization_list（此处的定义 SetCodeTx）之外的所有非签名字段。然后，用户构造 authorization_list 此处。对于每个 authorization tuple，用户首先填写非签名字段，然后使用 SignAuth 函数对其进行签名。
签名需要用户的 EOA 私钥。签名过程涉及对授权信息进行哈希处理，其中包括魔数 0x05、链 ID 、委托代码地址以及 EOA 的当前随机数。魔数在 EIP-7202 中也是一个域分隔符（另一个是 0x05SET_CODE_TX_TYPE 0x04），用于确保当不同类型的数据恰好编码为相同的字节表示时，签名生成的哈希值不会跨域冲突。更多关于当前签名域常量的讨论，请参见此处。
值得注意的是，将链 ID 设置为 ，0 允许在所有支持 EIP-7702 的 EVM 兼容链上重放授权，前提是 nonce 匹配。然而，由于 nonce 必须相同，因此在实践中跨链重用授权可能具有挑战性。例如，对于 nonce 非零的 EOA 来说。
一旦交易除签名字段以外的所有字段都准备好，用户就可以初始化交易（说明见此处）和一个「prague 签名者」（用于添加对 EIP-7702 交易哈希的支持）。然后，用户使用 SignTx 对交易进行签名，并通过 MarshalBinary 使用 RLP 编码将其序列化为字节数组。最后，将交易的 RLP 字节数组进行十六进制编码，并通过 eth_sendRawTransaction RPC 方法发送。
当节点通过 JSON-RPC 收到交易时，它会验证该交易并将其添加到交易池 [4] 中，并广播给其他节点。最终，区块提议者会尝试将其打包进区块。在打包之前，提议者会执行预检查 (preCheck)，其中包括针对 EIP-7702 交易的一些额外检查：
确保交易不是合约创建交易（详情请见此处）。
检查交易是否包含至少一个授权操作（在此处强制执行）。
在执行交易之前，节点会计算 IntrinsicGas，用于计算访问 authorization_list 的 Gas 成本（详情请见此处）。如果目标地址之前不存在，则每个授权元组都会消耗 25000 的 Gas 成本，定义为 CallNewAccountGas（在 EIP-7702 中也定义为 PER_EMPTY_ACCOUNT_COST ）。如果账户在状态中已经存在（即在本次转换之前已委托），则在申请委托时，每个授权元组的部分退款会被添加到全局退款计数器中。
最后，在状态转换期间，节点会应用 authorization_list（此处的实现）中的每个元组。该过程包括验证元组、为现有账户退还 Gas、递增 nonce 以及处理授权或撤销的代码修改。重要的是，即使 applyAuthorization 出错（例如由于 verifyAuthorization 失败），批次中的其他授权也不会受到影响。这种设计最大限度地降低了批量授权场景中的拒绝服务 (DoS) 攻击风险，这对于赞助交易尤其有用。
在授权验证过程中，节点首先验证是否 auth.ChainID 与 0 链 ID 匹配。然后，节点检查是否 auth.Nonce 不超过允许的最大值（ 2^64-1 根据 EIP-2681），并验证签名值并恢复签名者地址。之后，被访问的地址会被添加到访问列表 中，节点会确保该地址没有代码或存在委托（即，它不是合约），并且账户 nonce 与提供的 匹配 auth.Nonce。
在执行 EVM 调用之前，节点将 EIP-7702 地址标记为遵循 EIP-2929 的暖地址。
Nonce 增量逻辑
EIP-7702 引入了新的 nonce 增量路径，因为它包含了authorization_list。因此，本节将为整个 nonce 处理流程提供参考。以下是 nonce 处理的详细流程：
交易 nonce 的验证和递增此处为 验证此处为 递增：首先检查交易 nonce，确保其与账户当前状态的 nonce 一致(validation here)。验证通过后，交易 nonce 会递增（ increment here）。
授权 Nonce 验证和增量：对于 中的每个 authorization_list 中的授权元组 auth.Nonce 都会进行验证，以确保其与签名账户的当前 Nonce 匹配（此处为验证）。验证成功后，与授权关联的 Nonce 会递增（此处为增量）。
查询交易状态
用户可以使用 eth_getTransactionByHash 和 eth_getTransactionReceipt 查询交易状态。EIP-7702 交易的执行路径与其他交易相同。节点会针对交易有效负载中的 EIP-7702 字段添加特殊处理。然而，与其他交易类型相比，交易收据中没有额外的字段（ Geth 中对收据字段的总体定义已在中），因此收据无需进行特殊处理。
上述方法仅确认交易是否已包含在区块中。然而，在授权的情况下，如果授权元组未通过有效性检查，则会被跳过。在交易被包含后，维护 EOA 地址与其委托代码地址的最新映射的一种方法是：
用于 eth_getTransactionByHash 获取交易（代码）并获取授权列表。对于每个授权元组，尝试恢复权限：
如果恢复失败，则授权无效。此失败路径与交易执行期间的授权验证一致。
如果恢复成功，则使用 eth_getCode 查询恢复地址的代码（调用示例）。这将返回地址的完整代码（23 字节）（不同于 EXTCODECOPY，后者仅返回标识符的前 2 个字节，即 0xef01），然后可以使用 ParseDelegation 对其进行处理，以确定帐户是否已委托给 code（第二个返回值）以及委托给的代码地址（第一个返回值）。
指令集修改
关于指令集的变更，在具体实现中，节点会在原有指令集的基础上，添加针对 EIP-7702 的指令集修改，并初始化一个支持 EIP-7702 的新指令集。一旦检测到硬分叉，此更新的指令集就会在 EVM 解释器中启用。指令集的具体变更包括：
EXTCODECOPY 仅返回 0xef01，通过用 DelegationPrefix 0xef01000 的前两个字节标识该地址，即 xef01，将该地址标记为委托人 EOA 地址。
EXTCODESIZE 仅返回 2，即 0xef01 的字节长度。
EXTCODEHASH 仅计算的 Keccak256 哈希值 0xef01。
CALL,CALLCODE,DELEGATECALL,STATICCALL 将从委托的代码地址加载代码，并在智能 EOA 上下文中执行。这是通过在执行这些操作码期间检索代码哈希和代码来实现的。无效委托（例如，没有有效代码或预编译合约地址的委托）将被忽略，并视为没有代码。
CALL 相关操作码的 Gas 调整（CALL, CALLCODE, DELEGATECALL, STATICCALL）：这些调整是为了考虑 EOA 地址和代码地址的访问。Geth 将此逻辑封装成一个统一的函数，并根据 EIP-2929 扣除相应的 Gas 费用。EIP-7720 之前的 Gas 计算方式如下。差异来自于委托代码地址的额外访问。
与智能 EOA 交互
与智能 EOA 交互的方式与调用智能合约类似。用户只需将交易 to 字段（或 EIP -7702 交易的 destination 字段）设置为智能 EOA 地址即可。无论调用来自外部交易还是其他合约，此方法均适用。
以下是值得注意的协议实现：
在交易预检中，提议者允许智能 EOA 通过特殊处理 绕过EIP-3607，使 EOA 能够以 tx.origin 的身份发送交易。具体实现方式是，提议者读取账户代码并使用 ParseDelegation 来识别该地址是智能 EOA 还是合约。
智能 EOA 的代码格式为 0xef0100 || address（其中 | | 表示连接)，确保与现有合约代码不冲突。此编码利用了 EIP-3541，该协议拒绝以 0xef 字节 开头的合约代码。前缀0xef01 确保与 0xef00（由 EIP-3540 保留）不冲突，0x00 后续部分 0xef01 保留，以允许未来升级到 EIP-7702。委托编码和解码逻辑在此处实现。
EIP-7702 禁止递归委托（例如，创建潜在的委托链或委托环），以确保协议的简单性。节点只能检索一级委托。
03 ｜ 用例实现
在通过概念性示例了解代码之后，现在让我们通过具体示例来分析 EIP-7702 的实现和功能。
创建钱包并执行调用
我们以 Ithaca 提供的 EXP-0001 示例为例进行说明。此示例提供了创建钱包的简洁实现。具体操作如下：
生成 EOA：
该过程首先生成一个随机私钥。在实际场景中，此私钥可以用用户的钱包私钥替换。
创建密钥：
接下来，实现会提示最终用户创建一个 WebAuthn 密钥，然后使用该密钥签署 SC 钱包调用。
签署并委托钱包：
使用 EOA签署并委托合约钱包，[5]并将 WebAuthn 密钥添加为钱包的签名密钥 。
值得注意的实施细节
委托钱包并添加签名密钥，只需一笔交易：
此演示展示了如何在一笔交易中同时委托钱包和添加签名密钥。之所以能够实现这一点，是因为 EIP-7702 交易在应用委托后，仍然保留调用合约的能力。虽然合并这些操作并非绝对必要，但与发送两笔交易相比，合并交易可以减少签名交易的数量，并受益于摊销固有 Gas 成本。
第三方提交：
交易稍后可以由第三方 EOA 提交（交易发送者未设置）。在本演示中，Ithaca 的 Odyssey 提供了此处 odyssey_sendTransaction 提出的接口。其实现是一个赞助交易服务。在实际用例中，要求用户进行身份验证或通过社交验证（例如 Gitcoin Passport Scorer），并限制速率，将是抵御 Sybil 攻击和资金损失的第一道防线。
防止签名密钥被篡改：
SC 钱包确保签名密钥无法被篡改。这是通过验证「钱包签名密钥授权」的签名者与 EOA 地址匹配来实现的（SC 钱包的 Solidity 实现中 address(this) EOA 地址就是 EOA 地址）。为了构建交易，EOA 会对授权信息进行签名，并将其作为调用数据的一部分传递。
执行调用
创建钱包后，用户可以通过签名和执行调用来转账。用户使用 WebAuthn 密钥对合约调用进行签名，并根据具体的钱包实现提取签名中所需的字段。参数已准备好并用于调用合约。在此演示中，交易通过 odyssey_sendTransaction 接口发送。对于兼容 ERC-4337 的钱包，可以将其构造为 UserOperation 并发送到打包器。
值得注意的实施细节
任意密钥：已部署的合约在此代码中实现。它支持 RIP-7212，从而能够验证 P256 密钥签名。
批量调用：合约还支持 multiSend 接口 ，允许用户将多个调用聚合到单个交易中。调用必须编码到调用数据 (calldata) 中，签名后作为输入传递给合约 execute 函数。为了增强互操作性并简化 SDK 和钱包的开发，可以围绕 multiSend 该功能设计一个标准化的 ERC 代码 (ERC)。
ERC-4337 兼容性
EXP-0001 演示版开启了许多功能可能性。虽然它并非 ERC-4337 兼容，但可以通过将演示版的已部署合约替换为兼容 ERC-4337 的合约（例如 Coinbase 的智能钱包）轻松实现。这样，钱包就可以无缝继承所有 ERC-4337 功能。
私钥丢失恢复
基于上例的实现，账户恢复已经可以实现。当私钥丢失时，用户只需使用其注册的签名密钥即可从 EOA 账户中转移资产。这对于希望防止私钥丢失的现有 EOA 用户尤其有用。在实际使用中，更安全的方法是正确配置社交恢复权限。例如，与其允许常用的热签名密钥转移所有资产，不如要求多个监护人的签名来转移余额，这样更安全的设置是需要多个监护人的签名才能进行。
对于新用户来说，钱包可以帮助简化配置守护者的过程。例如，他们可以提供一个 2-of-3 方案，该方案使用：
zk-email 为用户的电子邮件地址，
存储在用户设备本地的密钥（例如密码），以及
服务提供商持有的备份密钥。
ZK 恢复
EIP-7702 允许通过零知识证明（ZKP）进行钱包恢复，只需委托给支持这些功能的合约即可。ZKP 的优势之一是能够在不损害隐私的情况下验证用户信息。例如，身份验证可以利用 Google 或 Facebook 等 OpenID 提供商发行 JSON Web Tokens (JWT) 作为 ZKP 的见证，并利用现有的身份验证基础设施。
以下是 zklogin 提供的基于 EIP-7702 的零知识恢复示例。要更改钱包的签名密钥，用户必须使用新的 WebAuthn 密钥通过 OpenID 提供商（在本例中为 Google）的登录流程获取 JWT。然后，此 JWT 将用于生成证明。最后，将证明以及 JWT 中的其他元数据和新的 WebAuthn 公钥提交给合约，以更新签名密钥。
会话密钥和订阅
如今，用户频繁与钱包提示窗口交互以授权操作，这在高频、低额支付场景中可能会导致疲劳。相比之下，在信用卡等传统系统中，「值得信赖」的订阅式支付服务可以降低授权的认知成本。
简化用户操作的一种方法是将不同用途的密钥（例如，签署低权限交易、加密和解密消息 [6]）与钱包的私钥（具有最高权限）分开。继续使用 Ithaca 的 EXP-0002 中的示例，在创建钱包期间，演示程序使用 Web Crypto API 生成签名密钥，然后将其存储在 IndexedDB 中。这允许与演示程序同源的网站通过特定接口访问签名密钥，从而使前端应用程序无需触发钱包提示即可执行签名操作。
该演示并未具体说明签名密钥的后续处理。实际上，钱包客户端可以为签名密钥分配有效期和权限，并将其委托给私钥管理服务。例如，Privy 已在此演示视频中演示了如何创建和存储「会话密钥」 。
04 ｜ 以太坊和 L2 路线图中的 EIP-7702
走向弃用 EOA
EIP-7702 可以帮助 EOA 用户体验 SC 钱包的功能，例如社交恢复、订阅等。但由于其保留了私钥的存在，因此无法完全取代 ERC-4337。对于已经应用 EIP-7702 的用户，如何才能充分获得 SC 钱包的安全保障？
作者认为可以通过兼容性补丁来实现完全迁移到 SC 钱包，例如EIP-7377中提出的迁移交易 (Migration Transactions) 的概念。稍加修改即可支持 EIP-7702 账户迁移到 SC 账户。例如，deactivated 在账户状态中添加已停用的 EOA 私钥字段。如果用户需要撤销停用状态，则需要 SC 钱包的最高权限，例如需要监护人的 M-of-N 签名。
保留「撤销停用状态」功能的目的是为了解决那些无法通过可升级合约的升级完全实现（或合约本身不可升级）的迁移场景。在这种情况下，需要重新启用私钥的权限，并发送另一笔 EIP-7702 交易，将 EOA 委托给另一个代码地址。
例如，用户可以升级其委托代码，完全迁移到 EVM 对象格式 (EOF)合约，从而利用 EOF 支持的新升级方案，并消除对旧代理合约的需求。虽然 EOF 允许现有代理合约使用旧版本到 EOF 的路径进行 EOF 升级，但移除代理合约可以通过消除通过代理转发调用的开销来降低交易成本。
走向原生 AA
此外，以太坊和 Layer-2 社区正在积极讨论原生 AA。假设以太坊生态系统将逐步走向原生 AA，那么 EIP-7702 与这些提案的兼容性如何？
在 L2 层，RIP-7560 旨在率先在 L2 上实验和实现原生 AA，同时还提出了相关提案：RIP-7711、RIP-7712 和 RIP-7696。RIP-7560 将 ERC-4337 提供的工具与 EIP-2938 中原生 AA 的设计相结合，引入了新的 AA_TX_TYPE 交易。与 ERC-4337 相比，它享有原生交易的优势，例如无需额外的 RPC 接口、使用合约地址作为 tx.origin 、更低的 Gas 成本（基本 UserOperation 的额外 Gas 成本约为 4.2 万，而基本交易约为 2.1 万），并受益于协议级的抗审查机制。
当 RIP-7560 被广泛采用时，依赖 ERC-4337 钱包或其他不兼容 RIP-7560 的钱包的用户可以使用 EIP-7702 更新其委托合约，以支持 RIP-7560 的新接口。这是必要的，因为与 ERC-4337 相比，RIP-7560 对钱包接口进行了更改，例如通过回调函数处理错误，旨在减少技术债务。使用代理合约的用户也可以升级实现地址以采用 RIP-7560 接口，从而确保平稳过渡。
在以太坊上，EIP-7701 基于 RIP-7560 的设计，提出了原生的 AA 机制。关键区别在于使用 EOF 定义入口点函数接口，解决了当前依赖 Solidity 函数选择器定义入口点所造成的技术债务（例如，特殊或恶意的钱包可能会使用不可读的函数名创建与钱包接口相同的函数哈希）。通过利用 EOF，用户可以使用 EIP-7702 升级其智能 EOA，以确保与 EIP-7701 兼容，方法是迁移到新的基于 EOF 的合约，或更新其代理合约的实现地址。
正如本篇博文所讨论的，钱包可以实现一种简单的守护者策略，例如 2-of-3 方案。这包括通过零知识证明电子邮件验证用户的电子邮件地址、存储在用户设备上的本地密钥（例如密码）以及由服务提供商持有的备份密钥 。
L2 通过 RIP-7212 和 RIP-7696 等预编译合约积极支持任意签名密钥，从而使 AA 钱包能够验证来自各种密钥类型的签名 。
解决这些隐私问题的一个潜在方法是将用户的 SBT 和链上活动分布到多个隐私钱包地址，同时保持对这些资产的全局视角。当需要验证时，可以提交零知识证明来证明所有权或参与度，而无需泄露敏感信息 。
尽管 EIP-7702 引入了 EOA nonce 可以递增的新场景，但交易池仍然可以通过监控节点上新添加的区块来处理 nonce 更新的地址。这确保了 nonce 较低的交易将被移除。然而，一旦 EOA 委托给代码，任何人都可以在交易的任何时候调用该代码，这将打破一个广泛使用的账户余额不变量，即通过迭代新区块的发送者来使余额不足的待处理交易无效：EOA 只能通过交易发送价值。这需要相应地更新交易池逻辑。更多详情请参见此处。
这里的演示使用了 viem 的 signAuthorization EIP-7702 实验功能。
这在集成了 ERC-4361：Sign-In 与以太坊的端到端加密消息或电子邮件服务中很常见，例如MetaMail。
