以太坊账户抽象失败了吗?

数据来源:大门交易所 2小时前 阅读数 1 #行情资讯

上次说了x402协议延续了闪电网络,最近和一帮程序员朋友吃饭时,又被“挑战”了一番:x402不就是之前的AA账户抽象吗?

\n

潜台词是,以太坊围绕账户抽象(Account Abstraction)搞了很多年,ERC-4337、Paymaster等投了那么多资源,包括各类Grant和钱包服务商,但事实结果大家也看到了,被很多人诟病雷声大、雨点小。

\n

尽管我不认为AA已经宣告失败,但到底症结在哪里?

\n

1、Paymaster把用户的Gas消耗转嫁到了项目方身上,听起来很美好,但项目方烧钱代付的动能很弱,ROI不明晰,无疑走入了商业模式死胡同,没有自我造血能力全靠输血怎么行?

\n

2、AA账户抽象只限于EVM生态内部,比如ERC4337、Paymaster、EntryPoint合约,全是以太坊专属的,若想实现包含Solana、BTC等跨EVM生态使用,就得继续叠加中间层服务来实现功能,但问题是,中间层服务又多了一道手续费瓜分,对商业模式ROI的挑战就更大了!

\n

还有很多复杂技术问题,我就不展开了,但说点大家能听懂的,AA本质上是为“技术而技术”的产物,是过去以太坊纯研究趋向下的作品。

\n

相较之下,x402协议玩的是什么?有什么不同?有人诟病说怎么把HTTP 402状态码这种30年前就有的远古物种搬出来了,又搞黄金上雕花的游戏。

\n

但别忘了,HTTP 402状态码——这是互联网底层协议,是Web2和Web3的公共语言。

\n

AA需要智能合约、需要链上状态、需要EVM虚拟机执行,x402只需要一个HTTP请求头,任何支持HTTP的系统都能用——Web2的API、Web3的RPC、甚至传统支付网关,全部兼容。

\n

这不是技术堆叠的优化方案,而是协议层化繁从简的一次“降维打击”,与其在应用层折腾各种兼容适配和信任方式,不如先统一最上游协议层的标准。

\n

关键是,x402天然就是一个很好的跨链互操作标准,只要Agent能发HTTP请求、能处理402响应、能完成EIP-3009授权(或其他链的等效标准),管你是Base、Monad、Solana、Avalanche还是BSC,协议层面跨链无感知,只体现在结算支付的单点问题上,相较之下跨链成本要低多了。

\n

Facilitator可以同时服务多条链,用户的支付历史数据可以统一索引,开发者接入一次就能“打通”全生态。

\n

我整体感觉,AA是研究员思维下的精致工程,而x402协议则是市场需求倒逼出来的实用主义。

\n

问题来了,ERC-8004 会走AA的老路吗?

\n

仅从理论层面看,ERC-8004像极了AA 2.0,仍是EVM专属,需要部署三层注册表(Identity/Reputation/Validation),早期激励也比较依赖外部补贴或质押,这些都是AA曾经踩过的坑,其他链要兼容的话,还是得额外增加一层信任成本。

\n

但区别在于,在x402框架下,ERC-8004只是一个工具,而不是一个统领标准。其他链要兼容的是x402协议,并非ERC8004。

\n

这个定位差异很重要,AA当年的问题是什么?它想成为“以太坊支付体验的唯一标准”,要求整个生态围着它转:钱包要适配、应用要集成、用户要改变习惯。这种“自上而下”的强推,在没有杀手级应用和明确ROI的情况下,自然推不动。

\n

而ERC-8004不一样。它不需要成为主角,因为x402已经解决了最核心的问题:支付。 ERC-8004只是在这个已经跑通的支付网络上,提供一个“可选的”信任层。

\n

况且,ERC-8004搭的是x402的顺风车,不需要自己从零建生态。 x402已经有了清晰的商业闭环(Provider引流、Facilitator收费)、完整的技术栈(HTTP协议+EIP-3009)、活跃的项目生态,ERC-8004只需要“即插即用”就行了。

\n

Note:我一向对曾经扑在一线的Devs和长期主义付出表示尊敬,但当某个方向若迟迟得不到Mass Adoption时,不妨换个路径重新开发,x402就是全新的开始!

\n

声明:

    \n
  1. 本文转载自 [tmel0211],著作权归属原作者 [tmel0211],如对转载有异议,请联系 Gate Learn 团队,团队会根据相关流程尽速处理。
  2. 免责声明:本文所表达的观点和意见仅代表作者个人观点,不构成任何投资建议。
  3. 文章其他语言版本 由 Gate Learn 团队翻译, 在未提及 Gate 的情况下不得复制、传播或抄袭经翻译文章。
\n