链上账户长期只有两种：私钥直管的普通账户，和链上有自己代码的合约账户。EIP-7702 在两者之间焊了一条缝：普通账户的持有人签一份委托，账户在链上就挂上指定合约的代码，此后别人看你的地址，看到的是那段代码定义的行为；而掌握发起权的，仍然是原来那把私钥。这个状态可以撤销、可以换目标，但在此之前它一直生效。
对协议来说，这改变了识别逻辑。很多合约历史上用简单的地址探测区分用户类型，委托生效后这类探测会把你的账户判成合约地址，于是协议流程里那些只为纯外部账户准备的分支开始绕路：有的功能反而可用了，有的校验反而报错——挂代码不等于该合约实现协议期望的全部接口，身份变了、能力未必配套。钱包与协议两侧都在为此修补，兼容矩阵按版本各自推进，任何一笔具体委托前先看钱包与协议文档当前的支持说明，比套经验更可靠。
委托真正吸引人的地方是它给批量能力开了门：一次授权下，多笔操作可以被编排成一个序列执行——先领手续费、再调整抵押、再提交还款这类组合，过去要靠第三方合约搬资金才能实现，现在有机会在同一账户内完成。要分清两层来源：发起批处理的规则来自你委托的那个合约的实现，能不能顺利执行还取决于每个被调用协议对账户形态的容忍度。两层的任何一边没准备好，组合就会在某一步 整笔回退。
安全面要按新边界重算。委托状态挂在账户上，不会因为你换了一台设备或清了一次应用而消失；它被新委托替换或被清空之前一直有效，这意味着签错一次委托，暴露期是开放的而不是单次的。委托目标合约拿到的是按它自身逻辑运转的行动框架，其代码是否经过审计、谁有权改它的行为、要不要预存资金，决定风险等级。把陌生活动页诱导你签的那份委托和当年的无限授权放在同一类里对待：那都是把一段未来的行动空间交出去。
已有 DeFi 仓位的持有人，动委托之前重验三件事。第一，仓位协议是否支持委托账户发起的操作与签名验证路径，历史上只对纯私钥签名做兼容的协议不在少数。第二，此前签给各合约的授权按地址记账，委托改变了地址的行为但不改变授权本身，别误以为换委托顺带重置了权限。第三，若你同时在用智能账户钱包与委托功能，两者的资产清单、授权清单和恢复方式要分开记录，出问题时的排查路径完全不同。
这项机制随以太坊的 Pectra 升级进入主网，生态适配仍在滚动推进，本文描述的是机制骨架而非某天的功能清单。判断自己是否该用、何时用，标准其实古老：只有当你能完整说出委托目标的代码替你做什么、做错时你怎么撤销、撤销前最坏会发生什么，三个问题都答得出，签名才按下去。
最后补一个容易想反的点：委托不是给账户换主人，私钥仍是发起权之源，委托合约只是被借来的一段行为逻辑。这带来一个特殊的责任结构——密钥泄露时攻击者连委托状态一起继承，可以先替换委托再执行资金动作，恢复流程里必须把检查委托目标列为固定一步，和撤授权、换密码并列。老派账户的应急清单从此多了一行，写它只要十秒，漏掉它的代价可能是整仓。
还有一个实操细节：委托状态下发起的交易， gas 账单与撤单方式和纯账户没有本质区别，但排查路径多了一层——如果一笔操作的表现和文档预期不符，先确认当前生效的委托目标是不是你以为的那一个，再怀疑协议侧。委托目标地址可以在链上直接读出，这一行核查在排障清单里应该排在最前，因为它的成本最低、命中率的却不低。
风险提示
EIP-7702 相关钱包与协议的兼容性随版本演进，以双方官方文档当前说明为准；委托目标合约的质量决定实际风险面。本文只做机制说明与安全边界提示，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。