「谁在抢跑 ERC4337?」一次链上猫鼠游戏的技术对决实录
🔗 原文链接:https://ethresear.ch/t/is-data-available-in-the-el-mempool/22329?u=barnabe
想象一下,发现了以太坊新交易模型中的一个细节,能让你几乎成倍地回收所支付的燃气费——而且是稳定持续的。这就是 ERC4337 抢跑的“狂野西部”。
大二那年,我在阅读 ERC-4337 规范,想更深入了解账户抽象(Account Abstraction)。ERC-4337 引入了 UserOperations(UserOps),即由智能钱包签名的特殊交易。这些交易由称为 bundlers 的角色在链上中继。因为 UserOps 是经过签名的,ERC-4337 会在执行前验证智能钱包的授权。
有趣的是,智能钱包并不直接支付链上中继的燃气费,而是由 bundlers 先垫付燃气费,智能钱包会在 UserOp 执行时偿还这些费用。
理解 UserOps
这是 UserOp 的结构(截至 0.6 版本):
struct UserOperation {
address sender;
uint256 nonce;
bytes initCode;
bytes callData;
uint256 callGasLimit;
uint256 verificationGasLimit;
uint256 preVerificationGas;
uint256 maxFeePerGas;
uint256 maxPriorityFeePerGas;
bytes paymasterAndData;
bytes signature;
}值得注意的是,UserOp 中通过 maxFeePerGas 和 maxPriorityFeePerGas 字段,包含了它愿意支付给 bundler 的中继费用。
但是,看看这个 AA 交易:bundler 支付了 0.0048 POL 燃气费,却收到了 0.0091 POL 的退款,几乎是支付金额的两倍!
AA 交易捆绑通常会多付燃气费,以避免链上拥堵时交易卡住。但它们经常大幅多付,这就给了我们机会:
我们会抓取那些以低价被中继、低于退款价值的 UserOps,提高燃气价格,然后收取退款——这个退款将高于我们为中继支付的费用。
要做到这一点,必须在原始 bundler 获得退款之前抢先执行。后执行的一方会回滚,最终亏损。
此策略需要链上有大量 4337 的交易包(bundles)发送,并且我们能观察到待处理的交易。幸运的是,Polygon 有不错的 AA 使用率,且有开放的内存池。
这和普通抢跑有什么区别?
普通抢跑通常会损害最终用户,但这里的智能钱包不会受损。它们的 UserOp 会成功执行,只是由不同的 bundler 完成(这也是 4337 规范中“另类内存池”设计的本意)。虽然原始 bundler 会亏燃气费,但理想情况下,bundler 应该以 UserOp 指定的燃气价发送 EOA 交易包,这样不会有被抢跑的漏洞,原 bundler 不会发生交易回滚,智能钱包能以所付价格获得执行速度。但原 bundler 低估燃气价时,便给了抢跑机会。无论如何,智能钱包都是在多付燃气费,只是多付给了不同的 bundler。
构建抢跑机器人
当时我没钱,也不想自己运行节点(成本太高),但想窥探 Polygon 内存池。
BlockNative 曾有个 AA 交易的“浏览器”,能显示 Polygon 待处理的 AA 交易。我在浏览器控制台发现,他们用的是自己的内存池 API(我不想付费),而且 API key 在请求里暴露了。这个浏览器后来关了,下面是个网络快照:https://web.archive.org/web/20231201172934/https://4337.blocknative.com/
我分析了网络请求,找到了一段 websocket 通讯协议,通过它我写了一个用 ethers.js 实现策略的简单脚本。
基于请求写的部分代码示例:
const blocknative_url = `wss://api.blocknative.com/v0`;
const initialPayload = {
"timeStamp":"2024-04-04T17:30:59.026Z",
"dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
"version":"4.6.7",
"appName":"unknown",
"appVersion":"unknown",
"blockchain": {
"system":"ethereum",
"network":"matic-main"
},
"categoryCode":"initialize",
"eventCode":"checkDappId",
"connectionId":"f4-2d7ff094-ed60-4851-96e8-0d52d0a26738"
};
const watchPayload = {
"timeStamp":"2024-04-04T17:30:59.026Z",
"dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
"version":"4.6.7",
"appName":"unknown",
"appVersion":"unknown",
"blockchain": {
"system":"ethereum",
"network":"matic-main"
},
"eventCode":"accountAddress",
"categoryCode":"watch",
"account": {
"address":"0x0576a174d229e3cfa37253523e645a78a0c91b57"
}
}
const watchPayload2 = {
"timeStamp":"2024-04-04T17:38:57.383Z",
"dappId":"87f7d1d2-00d5-4eea-b5a3-1c696177ab06",
"version":"4.6.7",
"appName":"unknown",
"appVersion":"unknown",
"blockchain": {
"system":"ethereum",
"network":"matic-main"
},
"eventCode":"accountAddress",
"categoryCode":"watch",
"account": {
"address":"0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789"
}
}这件事立刻引起了关注:
https://x.com/0xKofi/status/1796509704278958086
一些技巧
1. 我抢跑交易只有约 50% 机率能和目标交易在同一区块内。我想尽可能快且广泛地发送抢跑交易,保证能稳定打包在同一区块。我收集了许多公共 Polygon RPC 地址,尽可能异步发送交易。
Merkle 非常给力——他们有 Polygon 的 交易注入接口,帮我把交易迅速注入到他们节点网络的内存池,再广播给节点对等体,这曾是我的“秘密武器”。
2. 交易的 nonce 必须连续且递增。比如我先发送 nonce 3 的交易,再发送 nonce 5,节点无法打包 nonce 5 的交易,因为 nonce 4 的交易没出现。
我每 3 秒发一次交易,但发现网络有时传播不过来,导致后续交易到达时前面交易还未被全部节点看到,影响打包顺序。
1. 我准备了 8 个地址轮流发送,这样每个地址的交易间隔从约 3 秒变成 24 秒,足够网络传播。
2. 但遇到链上燃气费飙升时,地址仍会卡住。例如我发了 30 gwei 的交易,燃气费突然飙到 40 gwei,导致后续交易不被接受。对此我写了定时检查函数,看地址是否卡住,检查网络期待的下一个 nonce 是否和我的计数匹配,卡住的地址会暂时弃用,等恢复后再用。我后来还实现了用高价交易替换“解卡”(0 ETH 交易)。
延伸阅读:
https://x.com/norswap/status/1802165529567711303?s=46
有待处理的交易时,要获取下一个 nonce 其实挺难的。幸亏 ethers.js 支持 pending 参数,alloy-rs 也有类似功能。
3. 我利用 websocket 的内存池 API,所以不用自己搭节点。其实我试过用 Azure 免费额度跑 Polygon 节点(bor),但同步时间太长,效率低下。
编写 Bot 的第二版
BlockNative 停止了他们的服务。我尝试使用 Bitquery 和 Alchemy 来获取 mempool 的 websocket 流,但它们延迟非常高,而且常常无法捕捉到某些交易。等我收到数据、发送竞争性抢跑交易时,往往已经为时已晚。
无奈之下,我不得不运行自己的节点。为此,我拼凑了一些 reth(一个用 Rust 编写的高度模块化的以太坊节点)组件,添加了一个 websocket 端点,用于提供 mempool 中的新交易流。
特别感谢 Chainbound 和 Merkle —— 这两家公司都在生产环境中使用 reth,并且写了非常棒的博客来介绍如何上手。特别推荐以下两篇:
[Merkle] 修改 reth 以在 BSC 和 Polygon 上构建最快的交易网络 —— 一篇极好的教程,详细讲解了如何搭建一个只用于网络功能的节点。
链接:https://web.archive.org/web/20240705021105/https://blog.merkle.io/blog/fastest-transaction-network-eth-polygon-bsc
[Chainbound] 深入探索 Reth 的 P2P 网络栈 —— 教你如何获取 pending 交易流、节点请求和网络事件等内容。
链接:https://fiber.chainbound.io/blog/reth-p2p
但过程中也遇到了一些挑战:
1. 如果有其他节点向我们请求数据,比如请求区块头(GetBlockHeaders)或区块体(GetBlockBodies),我们必须能返回这些数据,否则会被断开连接。
解决方案:
留给读者思考:如果我们不打算运行一个完整节点,那是否还有其他办法从别处获取所需数据来构造响应?
2. Polygon 节点连接特别顽固。非常感谢 Merkle 在他们的 Discord 社区给予的支持,让我找到了正确的方向:原来 Polygon 仍然像工作量证明(PoW)那样通过网络广播新区块。而当我们把 reth 的网络栈设置为 PoS 模式时,它会将这种行为视为协议违规,进而断开连接。把网络模式重新设为 PoW 就能正常工作了。
问题解决后,一切顺利上线运行。
这个 reth 节点性能非常出色,我的抢跑成功率超过了 80%。
我将服务从 AWS 的免费套餐迁移到了 Hetzner,并对架构进行了重构,使得可以同时运行多个 reth 网络节点,并将它们的交易流转发给一个用 TypeScript 编写的统一执行引擎。
与他人交流
在 BlockNative 下架 mempool 流式 API 之后,有一些人在寻找替代方案。我联系了一些人,并为一个托管版本的替代服务 收集了兴趣反馈:https://web.archive.org/web/20241002002643/https://korky.monster/。
我注意到,许多我抢跑的交易都涉及到 Piggybox NFT 的转移。
于是我联系了 Piggybox 背后的团队 EARN’M,告诉他们他们使用的 bundler 服务在燃气费上严重溢付,我可以帮他们写一个更优的 bundler。但他们的“客服”把消息转交给团队后,就再也没回复我了。
写作 v3(未完成)🦀
我开始将我的执行引擎从 TypeScript 移植到 Rust,因为这看起来是自然的下一步(alloy-rs 非常棒!),但我发现我在原型设计/快速试验速度和系统可靠性之间做出了权衡。
Rust 本来会很不错 —— 在我的实验中,它把关键路径压缩到了小于 3 毫秒。但它对我来说更难使用,特别是在快速测试新逻辑或重构的时候。
来自 mempool 的“已知”区块交易比例
抢跑并不是没有竞争者的!在 2024 年夏天,我遇到了来自另一位搜索者的竞争,他们使用了以下地址:
"0xCd22C256E222529A29438406163Be3743d952cCD", "0xA3e411169d3e009C304820eD9ed9A2BBe47dC390", "0xbDAfc006073765c968FBEDc4F637EbE6e9df80fe", "0xe787dC2C6497A696C7B22f18b152ccB744Da5BFA", "0xbcaCb47747a7b241aE6319a2D8e10bDF20Ce6Ff8", "0x1742Bb58C2Eb72e9f0CAbd63283755c3a8fE8C66", "0x66D2445905586b6c06f86B41C0606aC850EdF324", "0xB495e75d17A55Fe05D5746ebD5Dd162fBE12E9d9", "0x239E68175459B80DbDF70E5876B83668d8A79110", "0x3d739955243086032bB532A29C4F9e7fb1a86793"这些地址也没有出现在 BundleBear 的 操作员注册表 上。
在我部署了自己的 Reth 网络节点后,他们大多数就停止了活动。
一个新的搜索者(我们称之为搜索者 B)大约在一个月前(2025 年 4 月/5 月)开始活跃。他们的执行效果非常非常好。尤其是在 Polygon 上,他们能够捕捉到所有交易,并且可以立即压过任何抢跑竞争者的出价。
例如,假设 Alchemy 提交了一个 handleOps 交易,gas price 为 30 gwei,我发一个 +1 wei 的抢跑交易,然后搜索者 B 会发一个 +2 wei 的抢跑交易。或者如果我等到搜索者 B 发出 +1 wei 的抢跑后再出一个 +2 wei 的交易,那么搜索者 B 会立刻采取以下任一行动:
如果可以通过将 gas price 提高 10%+ 来直接替换他们的交易,他们就会这么做;
如果更便宜,他们会用 0 ETH 的自转账取消原交易,并以 +3 wei 重发。
我和这位搜索者经常陷入出价战,但由于他们拥有更强的网络覆盖能力,几乎总是他们赢:
received at 2025-05-10T20:29:11.688Z
{
from: '0xF62298f2a58e07e914eCB711b0042762CA676565',
gas_limit: '1072531',
gas_price: 'null',
hash: '0x21a62de3ca45fdea7f465fcf75586b7323904c6dce04f515f5e20988389ef1cb',
input: '0x1fad948c0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000f62298f2a58e07e914ecb711b0042762ca67656500000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000b4fd6eed1f2584318719d8f38994da6150f8254b000000000000000000000000000000000000000000000000000000000000224b0000000000000000000000000000000000000000000000000000000000000160000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000b7476000000000000000000000000000000000000000000000000000000000000fd8b00000000000000000000000000000000000000000000000000000000000117480000000000000000000000000000000000000000000000000000000873a60cab0000000000000000000000000000000000000000000000000000000873a60b000000000000000000000000000000000000000000000000000000000000000de00000000000000000000000000000000000000000000000000000000000000e8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c2447e1da2a000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000001000000000000000000000000853f2c11774bb08031e7dea93803569bbe2058f800000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000ac4e9b5170f00000000000000000000000000000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c06233b2cbd9028884a62c3dc11f8724cfc088fbcf248b23f4a4d5f582ca2097c43a597b99ffaced5b3e8f6152170aaf20b360f9bb07c3eb153c3277c915a2c4500000000000000000000000000000000000000000000000000000000000003400000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001b99e2d284d5523b1608957536f9ad3c016ea462ec216e225b9266357331802f3b0be38aab54571fd69cf511276808ac46436c32b2f6bec95600fef5168e710b110000000000000000000000006cbd9b41ba653d1909eb47fca266f1c160552eac0000000000000000000000000000000000000000000000000000000000000180000000000000000000000000a34b19863e7b1b58e707c3a6bfbaa62f0fcca97f000000000000000000000000853f2c11774bb08031e7dea93803569bbe2058f80000000000000000000000000000000000000000000000000000000002faf08000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001bbf01394aedb56ece4a4e2dcf21625fc094cec98609afe7ca517c3f254de4ae0e711906bc559368cb49c063d448c27e2e3ba03d85beee7841726385b0e4a7587f00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000009636f75727479617264000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c00000000000000000000000003be9fd0ac95830558a994402d3d061dbd221575c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c99596d604be8ac20f56bff80660f72827697f600000000000000000000000031d058b5e02c8b01c749e6844d86cdd3f2962cd700000000000000000000000000000000000000000000000000000000000002000000000000000000000000006cbd9b41ba653d1909eb47fca266f1c160552eac00000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000002faf0800000000000000000000000000000000000000000000000000000000000000000e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f00000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000009636f757274796172640000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000544b02fcb9800000000000000000000000000000000000000000000000000000000000000c00000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c781c97a3374fb1ef72e23d25870880ab60a3ed62fc3b69dfa3623924d9818e35432b32360085f3499e22077d84f867bf1cd8b4b9d18590947dca89c326d581cb000000000000000000000000776023a4573bd972c4c3e2a76f611d3c2bef516e00000000000000000000000000000000000000000000000000000000000001800000000000000000000000003be9fd0ac95830558a994402d3d061dbd221575c00000000000000000000000031d058b5e02c8b01c749e6844d86cdd3f2962cd70000000000000000000000000000000000000000000000000000000002faf08000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000068210891e9a84426d16ce1663689a96b89a93558d1ba2c5a6a6f2b20d42b8d0ac666836f000000000000000000000000000000000000000000000000000000000000001c92a3863e20512e3675fb613543a5b6af64fc47d531303eb627e8bb79140f26ea509206b45ad7bc354c55de4608f354f59d24c15e5e289fe1470f59dfb16d59ce0000000000000000000000000a01dcab35dfea3ef072d154c2403d64addc3fee00000000000000000000000000000000000000000000000000000000000002c4cd39bed70000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000024000000000000000000000000000000000000000000000000000000000000001e00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000776023a4573bd972c4c3e2a76f611d3c2bef516e000000000000000000000000000000000000000000000000000000000000012000000000000000000000000000000000000000000000000000000000681fb96600000000000000000000000066dbff2ce099d19b4e8c5dc8b254ec7aeaf5e6420000000000000000000000003c499c542cef5e3811e1192ce70d8cc03d5c33590000000000000000000000000000000000000000000000000000000002faf0800000000000000000000000000a01dcab35dfea3ef072d154c2403d64addc3fee000000000000000000000000251be3a17af4892035c37ebf5890f4a4d889dcad0000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000000002466613563363530302d666130362d346263312d616430662d313838663637623765366264000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a4ce724973b58c37f3bd6ba695437b84fd98b89d10d341f8847455f4771295870000000000000000000000000000000000000000000000000000000000000041d55755cfb6256d8a7a95872afad8ae1152da94b09acde9a4d4c19c1780ba4867231537d6d751d380db93a115cd7931214205dcc5d3d53f49af04f2c8de5818ed1c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000754fd9098af9ddcb41da48a1d78f91f1398965addc0000000000000000681fb96c0000000000000000000000000000000000000000490871ee818c49fb42e45e41beab3def93dd84efe84571a23e7e32fb3df028f047035f15c351612173a48dab1dc8c59d9ab820f64eea289eec93626578da062f1b0000000000000000000000000000000000000000000000000000000000000000000000000000000000004177d45b941a0b57619771e5dbc33714e116095b845072a5bf58a4b6dac362a59871923bdfd504b07b62e2c3fdf59f237bf2e1953816680f2a022fa748e8e486d61b00000000000000000000000000000000000000000000000000000000000000',
max_fee_per_gas: '90326017109',
max_priority_fee_per_gas: '82122025008',
nonce: '80499',
to: '0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789',
type: '2',
value: '0'
}
Found competing frontrun for signature 0x77d45b941a0b57619771e5dbc33714e116095b845072a5bf58a4b6dac362a59871923bdfd504b07b62e2c3fdf59f237bf2e1953816680f2a022fa748e8e486d61b
Competitor outbid us, rebidding higher
finding wallet by address 0x8CDA72Cd622825DBAd9234186F15A3A1a4e7743C
total time 17
Bid War History for signature 0x77d45b941a0b57619771e5dbc33714e116095b845072a5bf58a4b6dac362a59871923bdfd504b07b62e2c3fdf59f237bf2e1953816680f2a022fa748e8e486d61b
Timestamp Incoming Outgoing
------------------------------------------------------------
2025-05-10T20:29:09.438Z 30000000005 0xcf1253b8bf239abff622d90f5bf552955fd0d94ba920f10afb34a6baa474751e 30000000012 0x3c26c4c3a05cdcb8af812506c061c546cda9b3e5bde4598e12caa8052b1b628f
2025-05-10T20:29:09.766Z 33003000005 0xb0cd45bb8d05a8f6cf9c4e1ae631dd343a3b915366f73c25a52dc64eca507d1f 39603600006 0x97dd62e12ed7acf3146b7b54b96e4a7617f36d5cbd73d320bfa28e4b0a19949e
2025-05-10T20:29:10.128Z 39603600011 0xbd6ca5401fcc65478eda6f888f00d7a3d4c996a314db362212f1229975f2284f 47524320013 0xc8427e501138aba66199d8e3b2924c995e3854c4b1050c658417c3069f71fb76
2025-05-10T20:29:10.541Z 47524320018 0x4652e72cda40a3336df49870aa5a8e3383cc9098230b033ce19290a6a3405c53 57029184021 0x549c563dad56f2fa09154bd5fda6d08b5c54c418e6a094ffe6d3d5cbf2943084
2025-05-10T20:29:10.921Z 57029184026 0x99afdd8f6b9b8c9345837bce28b7ef0cfd00574950973df297f9dc348ddf46b4 68435020831 0x396da589345b5b962085741cf70e3bc11af3a994b7fc4b7f25e8c7ec0a9e069d
2025-05-10T20:29:11.256Z 68435020836 0x37be6c5c8961a34330785f885c0ead2415531bcd58bc17f0768d05cd31905f36 82122025003 0x8123d8a5c3a46eb560c0ad7d36b673ccdbeebd3737d810431728051a605a100e
2025-05-10T20:29:11.706Z 82122025008 0x21a62de3ca45fdea7f465fcf75586b7323904c6dce04f515f5e20988389ef1cb 98546430009 0xfea480c7e4fca87782f6a551e52ffb16cb01842130f8f87055b9c77f05bc0962我和这个 searcher(搜寻者)有过一些来回交锋:
我好奇他们是如何识别 4337 的调用的。于是我部署了一个合约,它只会把所有调用转发到 Polygon 的 entrypoint(入口合约),然后我将交易发送到这个代理合约上。
Searcher B 起初几个小时都没有捕捉到我的交易。我在看到他们的交易后总是能稳定地出价超过他们。但大约 8 小时后,他们升级了系统,开始捕捉所有发送到代理合约的交易。
那他们是怎么知道一笔交易是通过代理转发的呢?他们是否检查了所有地址的所有交易的调用追踪(call trace)?我开始思考如果是我会用什么方法 —— 会不会他们在寻找 handleOps 的函数选择器?
果然,我构造了一个代理合约,在转发调用前添加了函数选择器,但我在发给代理合约的 calldata 中故意省略了这个函数选择器。结果,Searcher B 又没能识别出这笔交易。
不过他们几小时内也修复了这个问题。
我现在认为,他们可能已经检查所有交易的 trace,或者他们维护了一个我地址的列表,设置系统监控我部署的所有新代理合约,或者我发送的所有交易。
如果你是 Searcher B:恭喜!你赢了。 欢迎联系我,我很想和你深入聊聊。说实话,以你的能力,如果你能投入这么多时间做这个,你完全可以去做一些赚更多钱的事情。毕竟在 Polygon 上的 userOps(用户操作)数量是有上限的,这种策略的总收益也有上限。
对我而言,如果我把花在这上面的时间都用来准备一些面试,我肯定能通过那些更好交易公司的最后几轮面试,拿到更高的签约奖金 —— 远超过我这个策略赚到的钱 😄。不过,这段经历还是值得的。
这个赛道的未来发展方向
Porto by Ithica:https://github.com/ithacaxyz/porto
感谢 0xKofi!BundleBear(https://www.bundlebear.com/eip7702-overview/all)是一个很棒的资源,可以用来追踪 EIP-7702 和 4337 的采用情况。我以前每周都会查看一次,获取整体概览。他们的数据分析将持续为社区带来价值。
0xKofi 在 2024 年 9 月发布了一篇关于 4337 抢跑(frontrunning)的精彩文章:https://web.archive.org/web/20241012214743/https://www.bundlebear.com/posts/polygon-mev
我一直很想和你聊聊这个话题,我在 X(原推特)上给你留言过几次 😄
FastLane 发现了抢跑行为,并注意到它可以为验证者创造收益。他们没有试图阻止抢跑,而是构建了一套基础设施来实现抢跑民主化,让任何人都能参与抢跑。他们在 PFL 协议中增加了一个端点,为打包者(bundler)提供回滚保护,但加了一个 2 个区块的延迟机制,在这期间交易会被公开广播。这确保了所有 UserOp 都是公开的,每个 bundler 都有机会尝试抢跑,从而在防止打包失败的同时最大化验证者的收益。
FastLane 的 Thogard 还在播客中探讨了 MEV 与 4337 的交叉领域,非常值得一听:
FastLane 目前正在 Monad 上构建 AA(账户抽象)基础设施,他们推出了一个与打包者服务集成的 LST(流动性质押代币),可以在此查看:4337-bundler-paymaster-script
Pimlico 针对抢跑问题也做了几种尝试:
他们试图在 Polygon 上使用私有中继(private relays),但由于没有 proposer-builder separation(提议者-构建者分离),就无法私下向区块构建者提交交易 —— 因为根本没有构建者。他们尝试了 Merkle 和 Bloxroute,但这两个服务只是将交易广播到公共 mempool,因为没有私有中继存在。
他们也尝试使用 FastLane 的条件端点(conditional endpoint)进行实验,但发现其验证者覆盖率不足,不能满足他们的用例。
不过他们现在找到了一个不错的方案!当 UserOp 中包含 paymaster 数据时,EntryPoint 会调用 Paymaster 合约,而这个过程中会执行一个 EOA 地址检查。如果尝试抢跑,将会触发回滚(revert),从而阻止抢跑。这是一个实际示例:https://polygonscan.com/tx/0x81d7028be21f628ee0b6ea89934b1b07dc48c119a18b04845797ee9b16b1deff。
在智能钱包主导的未来世界中,UserOp 会产生比“打包者 gas 溢价”更多类型的 MEV。例如,一个 UserOp 可能会在 DEX 上进行大额交易,或在借贷协议中过度借款。打包者需要进化以捕捉这类 MEV,或者搜索者必须进化以捕捉 UserOp 内部调用所带来的回跑机会(backruns)和清算事件。这类交易流将极具价值。
随着生态演进,永远会有新的缝隙可钻、策略可打磨。对于那些愿意亲自动手的人来说,mempool 中永远有下一个机会在等着你。





