1. 项目概述用浏览器就能“听”以太坊链上正在发生什么你有没有想过不装钱包、不连节点、甚至不用写一行 Solidity只靠一个空白 HTML 文件 几行 JavaScript就能实时看到以太坊主网上刚刚被打包的交易里写了什么不是看转账金额而是真正读到那些公开的、明文的、带业务语义的消息——比如 Uniswap 的 swap 事件参数、ENS 域名注册记录、Optimism 的 L2 状态根提交、甚至某 NFT 项目刚发的铸币公告。这个项目标题说的就是这件事Read Public Messages from the Ethereum Network with Simple Web Programming。它不是教你怎么发交易而是教你如何做一个“链上广播收音机”——用最轻量的 Web 技术监听并解析以太坊网络中所有公开可读的信息流。核心关键词是Ethereum、public messages、web programming、event logs、JSON-RPC、Ethers.js。它适合三类人前端开发者想快速验证合约逻辑、产品运营需要实时抓取链上活动数据、区块链初学者想绕过复杂节点部署直接触摸真实链上世界。我第一次在本地跑通这个流程时打开控制台看到第一条来自 Mainnet 的 Transfer 事件日志被打印出来那种“原来链上信息真的像网页一样可读”的震撼感至今记得。它不依赖中心化 API比如 Alchemy 或 Infura 的付费层也不需要自己搭 Geth 节点——只要浏览器能联网就能开始“收听”。这背后的技术原理其实很朴素以太坊把所有智能合约执行产生的状态变更都以结构化日志Log的形式打包进区块。这些日志默认是公开的、不可篡改的、且完全免费可查。而 JSON-RPC 接口尤其是eth_getLogs方法就像一扇开着的窗户允许任何客户端按主题topic、区块范围、地址等条件去“翻阅”这些日志。Web 编程的“简单”就体现在我们用 Ethers.js 这样的库把底层 RPC 调用封装成几行可读代码用fetch或 WebSocket 连接公共 RPC 端点就像请求一个 JSON 接口那样自然。它解决的不是“能不能上链”的问题而是“怎么低成本、零门槛地感知链上脉搏”的问题。很多教程一上来就让你配 Hardhat、跑本地节点、写部署脚本反而把最直观、最有启发性的“读链”能力藏在了最后。而这个项目就是把那扇窗直接推开让你第一眼就看见光。2. 整体设计思路与方案选型逻辑2.1 为什么选择“读日志”而非“读交易”或“读状态”刚接触这个需求的人常会下意识想“我要读消息那是不是该解析交易的 input data”这是个典型误区。交易 input data 是调用合约方法时传入的原始字节码它经过 ABI 编码对人类完全不友好且大量交易尤其是转账根本没 input。而event logs事件日志才是以太坊为“人类可读消息”专门设计的机制。当你在 Solidity 里写emit Transfer(from, to, amount)编译器会自动生成一个Transfer事件并将from、to、amount三个参数按规则哈希后存入日志的 topics 字段同时把原始值或 indexed 参数的哈希存入 data 字段。关键在于所有 event logs 都是明文存储在区块头之外的 receipts 中且完全公开、无需权限、不消耗 gas由发交易者支付。这意味着作为观察者你只需按 topic 过滤就能精准捕获特定合约、特定事件的所有历史与实时记录。相比之下读交易 input 需要完整反向 ABI 解码且无法区分意图同一笔交易可能触发多个事件读合约状态则需知道具体 storage slot且只能查当前快照无法回溯。所以整个方案的基石就是牢牢锚定在event logs这一原生、高效、语义清晰的数据源上。2.2 为什么用 Ethers.js 而非 Web3.js 或原生 fetch选型不是比谁名气大而是看谁在“简单 Web 编程”这个约束下最稳、最省心。Web3.js 功能全面但它的事件监听contract.events.Transfer()底层仍依赖eth_subscribeWebSocket而绝大多数免费公共 RPC如 Cloudflare Ethereum Gateway、1inch RPC并不支持eth_subscribe导致本地调试时一切正常一上线就报错Method not supported。原生fetch虽然可控但你要手动拼接 JSON-RPC 请求体、处理错误重试、解析嵌套的 hex 数据比如0xabc...转数字、还要自己实现 topic 过滤逻辑——这已经超出了“simple web programming”的范畴。Ethers.js 的优势在于它内置了对eth_getLogs的完整封装自动处理 hex-to-number、topic 编码/解码、ABI 解析它提供JsonRpcProvider能无缝切换 HTTP 和 WebSocket 后端更重要的是它对fallback provider的支持让高可用性变得极其简单你可以同时配置 Cloudflare、1inch、EthGlobal 三个免费端点Ethers.js 会自动轮询健康状态失败时秒切备用用户完全无感。我实测过在连续 72 小时运行中单点 RPC 失效平均每天 2~3 次多为 Cloudflare 的 429 频率限制但 fallback 机制让日志拉取成功率保持在 99.98%。这种开箱即用的健壮性是手写 fetch 永远达不到的。2.3 为什么坚持“纯前端”而非加一层 Node.js 中间件有人会问“加个 Express 服务做代理不就能绕过浏览器 CORS 限制还能缓存日志”理论上可行但违背了本项目“simple”的初心。加中间件意味着你需要一台服务器哪怕是最便宜的 VPS、要配置 HTTPS否则现代浏览器会拦截混合内容、要处理服务宕机、要写监控告警——这已经从“一个 HTML 文件搞定”退化成“一个运维项目”。而事实上主流公共 RPC 端点Cloudflare、1inch、EthGlobal全部明确支持 CORS它们就是为浏览器直连设计的。唯一要注意的是某些小众 RPC 可能未开启 CORS这时只需换一个即可。我在全球 12 个不同地区测试过 Cloudflare 的https://cloudflare-eth.comCORS header 始终存在且稳定。所以“纯前端”不是技术妥协而是对“最小可行路径”的精准把握它让一个初中生用 VS Code 写完代码双击index.html就能在自己电脑上看到以太坊主网的实时 Transfer 事件这才是教育价值和传播力的核心。2.4 为什么聚焦“Public Messages”而非全链数据标题里的 “Public Messages” 是刻意限定不是能力不足而是价值聚焦。以太坊链上数据分三层1区块头Block Header包含哈希、时间戳、难度等元数据2交易列表Transactions包含 sender、receiver、value、input 等3收据与日志Receipts Logs包含事件、gas 使用、状态变更。其中只有第 3 层的日志才是合约开发者主动“发布”的、带业务含义的“消息”。区块头太底层交易列表太宽泛90% 是转账无业务语义而日志是经过筛选的、结构化的、有明确主题的“信号”。比如你想监控 OpenSea 的上架行为直接监听Seaport合约的OrdersMatched事件比扫全链交易快 1000 倍且结果 100% 精准。所以整个架构的设计哲学是用最窄的入口获取最有价值的信息。不追求“我能读全链”而追求“我读的每一条都是我要的”。3. 核心细节解析与实操要点3.1 理解 Event Logs 的物理结构与 topic 编码规则要真正读懂链上消息必须理解日志在区块中的存储方式。每条日志属于一个特定合约地址address包含最多 4 个topics主题和一段data数据。topics[0]固定为事件签名的 keccak256 哈希比如Transfer(address,address,uint256)的哈希是0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef。topics[1]到topics[3]存放indexed参数的哈希值如果参数声明为indexed而所有非indexed参数的原始值则拼接后存入data字段。举个实际例子ERC-20 的Transfer(address from, address to, uint256 value)通常定义为event Transfer(address indexed from, address indexed to, uint256 value)。那么当一笔转账发生时topics[0] Transfer 事件签名哈希topics[1]from地址的 keccak256 哈希注意不是地址本身topics[2]to地址的 keccak256 哈希datavalue的十六进制编码如1000000000000000000→0x0de0b6b3a7640000这个设计的精妙之处在于indexed参数被哈希后存入 topics使得按地址过滤成为 O(1) 操作RPC 节点可直接索引而非indexed参数存入 data则保证大字段如长字符串不会撑爆 topics 数组。所以当你想“只看某个地址的转入记录”就设置topics[2]为该地址的哈希想“看所有 Transfer 事件”就只设topics[0]。Ethers.js 的ethers.utils.id(Transfer(address,address,uint256))会帮你算出签名哈希ethers.utils.hexZeroPad(address, 32)则用于生成地址哈希因为地址是 20 字节需补零至 32 字节再哈希。3.2 免费公共 RPC 端点的稳定性对比与 fallback 配置不是所有免费 RPC 都生而平等。我过去一年持续监控了 7 个主流免费端点按可用性、延迟、速率限制三维度打分RPC 提供商域名平均延迟 (ms)日均中断次数速率限制CORS 支持备注Cloudflarehttps://cloudflare-eth.com1200.8100 req/min✅最稳但偶尔 4291inchhttps://rpc.1inch.io1801.250 req/min✅延迟稍高但极少挂EthGlobalhttps://ethereum-rpc.publicnode.com2100.5无显式限制✅新兴潜力大QuickNode免费层https://...quicknode.com903.510 req/min✅限制极严仅适合演示Moralis免费层https://speedy-nodes-nyc.moralis.io/...1502.1100K req/day✅需注册有配额Ankrhttps://rpc.ankr.com/eth2401.8无文档说明✅偶尔返回空响应Chainstack免费层https://api.chainstack.com/node/...1104.210 req/min✅注册繁琐不稳定结论很清晰Cloudflare 1inch 组合是黄金搭档。Cloudflare 响应快、稳定性高作为主节点1inch 作为备胎延迟虽高但几乎从不掉线。Ethers.js 的StaticJsonRpcProvider不支持 fallback但JsonRpcProvider可以。正确配置方式是const providers [ new ethers.providers.JsonRpcProvider(https://cloudflare-eth.com), new ethers.providers.JsonRpcProvider(https://rpc.1inch.io) ]; const provider new ethers.providers.FallbackProvider(providers, 1);这里1表示“只要有一个 provider 健康就认为整体健康”而不是等待所有响应。实测中当 Cloudflare 返回 429 时Ethers.js 会在 200ms 内自动切到 1inch用户完全感知不到中断。千万别用new ethers.providers.AlchemyProvider()或InfuraProvider()它们强制绑定商业服务免费 tier 有严格配额且不透明。3.3 Topic 过滤的实战技巧与常见陷阱Topic 过滤是整个方案的“瞄准镜”用不好就打偏。第一个陷阱地址哈希 vs 地址原文。很多人直接把0xAbc...当作topics[1]结果永远查不到。正确做法是先用ethers.utils.getAddress(0xAbc...)标准化地址转小写、去 0x 前缀再用ethers.utils.hexZeroPad(address, 32)补零最后ethers.utils.keccak256(paddedAddress)得到哈希。Ethers.js 提供了快捷方法ethers.utils.id(0xAbc...)但它内部就是执行上述步骤所以本质一样。第二个陷阱多 topic 组合的 AND 逻辑。如果你想查“Uniswap V2 的 Swap 事件且 from 是某个特定地址”就要设置topics: [swapTopic, fromAddressHash, null]。注意null表示该位置 topic 不限制即topics[2]可以是任意值而不是undefined或空字符串。第三个陷阱区块范围的选择。fromBlock和toBlock不能设为latest一起用否则会因区块确认延迟导致漏数据。最佳实践是fromBlock: 0x (await provider.getBlockNumber() - 100).toString(16)即从最新区块往前推 100 个约 20 分钟确保数据已最终确认toBlock: latest。这样既保证实时性又避免分叉导致的日志丢失。3.4 ABI 解析与日志解码的完整流程拿到原始日志对象后真正的“读消息”才开始。原始日志的data字段是一串 hex 字符串如0x000000000000000000000000000000000000000000000000000000003b9aca00topics是数组。解码分三步1用事件签名创建Interface对象2调用interface.parseLog(log)3从返回的Result对象中提取属性。以 ERC-20 Transfer 为例const abi [event Transfer(address indexed from, address indexed to, uint256 value)]; const iface new ethers.utils.Interface(abi); const log { // 从 eth_getLogs 返回的原始日志 address: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, topics: [0xddf252..., 0x0000...fromHash, 0x0000...toHash], data: 0x000000000000000000000000000000000000000000000000000000003b9aca00 }; const parsed iface.parseLog(log); console.log(parsed.args.from); // 0x... console.log(parsed.args.to); // 0x... console.log(parsed.args.value.toString()); // 1000000000000000000关键点在于parseLog会自动根据topics和data的结构匹配 ABI 中的indexed和非indexed参数并完成 hex-to-number、address 解析等所有转换。你不需要手动ethers.BigNumber.from(data)。如果遇到Error: cannot decode bytes32 from hex string大概率是 ABI 定义与实际日志不匹配比如事件参数类型写错了此时应去 Etherscan 查看该合约的真实 ABI。4. 实操过程与核心环节实现4.1 从零开始5 分钟搭建一个实时 Transfer 监控页我们用最简方式创建一个单文件 HTML实现“实时监听以太坊主网所有 ERC-20 Transfer 事件”。新建transfer-monitor.html内容如下!DOCTYPE html html langzh-CN head meta charsetUTF-8 titleEthereum Transfer Monitor/title script srchttps://cdn.ethers.io/lib/ethers-5.7.2.umd.min.js typeapplication/javascript/script style body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto; margin: 0; padding: 20px; background: #f8f9fa; } #logs { max-height: 60vh; overflow-y: auto; border: 1px solid #dee2e6; border-radius: 4px; padding: 10px; background: white; } .log-item { padding: 8px 12px; margin: 4px 0; border-left: 4px solid #007bff; background: #f8f9fa; font-family: monospace; } .log-header { font-weight: bold; color: #343a40; } /style /head body h1Ethereum Transfer Monitor/h1 p实时监听以太坊主网 ERC-20 Token 转账事件基于 event logs/p div idlogs/div script // 1. 初始化 provider使用 Cloudflare 主节点 1inch 备节点 const providers [ new ethers.providers.JsonRpcProvider(https://cloudflare-eth.com), new ethers.providers.JsonRpcProvider(https://rpc.1inch.io) ]; const provider new ethers.providers.FallbackProvider(providers, 1); // 2. 定义 Transfer 事件 ABI const transferAbi [event Transfer(address indexed from, address indexed to, uint256 value)]; const iface new ethers.utils.Interface(transferAbi); const transferTopic iface.getEventTopic(Transfer); // 3. 创建日志查询参数 const filter { fromBlock: 0x (await provider.getBlockNumber() - 100).toString(16), toBlock: latest, topics: [transferTopic] }; // 4. 获取初始日志并渲染 async function loadInitialLogs() { try { const logs await provider.getLogs(filter); logs.forEach(log { try { const parsed iface.parseLog(log); const item document.createElement(div); item.className log-item; item.innerHTML div classlog-header${new Date(log.blockTimestamp * 1000).toLocaleTimeString()} | Block ${log.blockNumber}/div divFrom: ${parsed.args.from}/div divTo: ${parsed.args.to}/div divValue: ${ethers.utils.formatUnits(parsed.args.value, 18)} ETH/div; document.getElementById(logs).prepend(item); } catch (e) { console.warn(Parse failed for log:, log, e); } }); } catch (e) { console.error(Failed to load initial logs:, e); } } // 5. 设置轮询每 15 秒检查新日志 async function pollNewLogs() { const latestBlock await provider.getBlockNumber(); const newFilter { ...filter, fromBlock: 0x (latestBlock - 5).toString(16), // 只查最近 5 个区块减少重复 toBlock: latest }; try { const logs await provider.getLogs(newFilter); logs.forEach(log { try { const parsed iface.parseLog(log); const item document.createElement(div); item.className log-item; item.innerHTML div classlog-headerNEW | ${new Date(log.blockTimestamp * 1000).toLocaleTimeString()}/div divFrom: ${parsed.args.from}/div divTo: ${parsed.args.to}/div divValue: ${ethers.utils.formatUnits(parsed.args.value, 18)} ETH/div; document.getElementById(logs).prepend(item); } catch (e) { console.warn(Parse failed for new log:, log, e); } }); } catch (e) { console.error(Poll failed:, e); } } // 6. 启动 loadInitialLogs(); setInterval(pollNewLogs, 15000); /script /body /html把这个文件保存用 Chrome 或 Edge 直接双击打开不要用 Firefox它对本地 file:// 协议的 fetch 有限制。几秒后你就会看到类似这样的输出NEW | 14:22:35 From: 0x742d35Cc6634C0532925a3b844Bc454e4438f44e To: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D Value: 0.1 ETH这就是真实的、刚发生的链上转账。整个过程没有安装任何依赖没有启动服务没有配置环境变量就是一个 HTML 文件。这就是“simple web programming”的力量。4.2 进阶实战监听特定合约的自定义事件以 Uniswap V3 Swap 为例现在我们把范围收窄监听 Uniswap V3 的Swap事件它比 ERC-20 Transfer 更复杂包含 7 个参数且部分为indexed。首先去 Etherscan 找到 Uniswap V3 Pool 合约例如 WETH/USDC 池0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640复制其 ABI。关键事件定义是{ anonymous: false, inputs: [ {indexed: true, internalType: address, name: sender, type: address}, {indexed: false, internalType: address, name: recipient, type: address}, {indexed: true, internalType: int256, name: amount0, type: int256}, {indexed: true, internalType: int256, name: amount1, type: int256}, {indexed: false, internalType: uint160, name: sqrtPriceX96, type: uint160}, {indexed: false, internalType: uint128, name: liquidity, type: uint128}, {indexed: false, internalType: int24, name: tick, type: int24} ], name: Swap, type: event }注意sender、amount0、amount1是indexed所以会出现在topics[1]、topics[2]、topics[3]。recipient、sqrtPriceX96等是非indexed在data里。我们想监听“所有流向我的地址的 Swap”就设置topics: [swapTopic, null, null, null]不限制 sender/amount然后在解析后过滤parsed.args.recipient myAddress。完整代码只需替换上一节的 ABI 和 filter// 替换 ABI const swapAbi [{ anonymous: false, inputs: [ {indexed: true, internalType: address, name: sender, type: address}, {indexed: false, internalType: address, name: recipient, type: address}, {indexed: true, internalType: int256, name: amount0, type: int256}, {indexed: true, internalType: int256, name: amount1, type: int256}, {indexed: false, internalType: uint160, name: sqrtPriceX96, type: uint160}, {indexed: false, internalType: uint128, name: liquidity, type: uint128}, {indexed: false, internalType: int24, name: tick, type: int24} ], name: Swap, type: event }]; const iface new ethers.utils.Interface(swapAbi); const swapTopic iface.getEventTopic(Swap); // 替换 filter指定合约地址 const myPoolAddress 0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640; const filter { address: myPoolAddress, fromBlock: 0x (await provider.getBlockNumber() - 100).toString(16), toBlock: latest, topics: [swapTopic] }; // 在 parseLog 后添加过滤 const parsed iface.parseLog(log); if (parsed.args.recipient.toLowerCase() 0xYourAddressHere.toLowerCase()) { // 渲染你的专属日志 }你会发现amount0和amount1是int256可能为负表示流出而sqrtPriceX96是一个巨大的整数需要用ethers.BigNumber.from(sqrtPriceX96).toString()获取原始值再按 Uniswap 公式换算成价格。这正是“public messages”的魅力它给你原始燃料而解读权完全在你手中。4.3 性能优化从轮询到 WebSocket 的平滑升级轮询polling简单但每 15 秒一次getLogs对 RPC 端点是种浪费且有延迟。更优方案是使用 WebSocket 实时订阅。但如前所述免费端点大多不支持eth_subscribe。好消息是Cloudflare 的wss://cloudflare-eth.com已于 2023 年底正式支持eth_subscribe。升级只需两步1将 provider 改为WebSocketProvider2用provider.on(logs, callback)替代轮询。代码改造如下// 替换 provider 初始化 const provider new ethers.providers.WebSocketProvider(wss://cloudflare-eth.com); // 替换轮询逻辑 provider.on(logs, async (log) { try { // 注意WebSocket 返回的 log 是简化版缺少 blockTimestamp // 需要额外 fetch 区块头来获取时间 const block await provider.getBlock(log.blockNumber); const parsed iface.parseLog(log); // 渲染... } catch (e) { console.warn(WS log parse failed:, e); } });实测延迟从轮询的 15 秒降至 1~2 秒且 CPU 占用更低。但要注意WebSocket 连接需要手动管理重连。Ethers.js 的WebSocketProvider内置了基础重连但建议加上心跳检测provider._websocket.onclose () { console.log(WS closed, reconnecting...); setTimeout(() { provider._websocket new WebSocket(wss://cloudflare-eth.com); }, 5000); };这样即使网络抖动断开也能在 5 秒内自动恢复。4.4 安全加固防止恶意日志注入与前端 XSS这是一个常被忽视的关键点。你从链上读到的日志数据是完全不可信的。parsed.args.from、parsed.args.to是地址看似安全但parsed.args.value如果是bytes类型比如某些合约存字符串就可能包含script标签。如果你用innerHTML直接渲染就构成 XSS 漏洞。解决方案只有两个1永远用textContent替代innerHTML渲染用户数据2对地址等关键字段做格式校验。修改渲染逻辑// 错误示范危险 item.innerHTML divFrom: ${parsed.args.from}/div; // 如果 from 是 scriptalert(1)/script就完了 // 正确示范安全 const fromEl document.createElement(div); fromEl.textContent From: ${parsed.args.from}; item.appendChild(fromEl); // 对地址增加校验 function isValidAddress(addr) { return typeof addr string addr.length 42 addr.startsWith(0x) /^[0-9a-fA-F]{40}$/.test(addr.slice(2)); } if (!isValidAddress(parsed.args.from)) { console.warn(Invalid address in log:, parsed.args.from); return; }另外ethers.utils.formatUnits返回的是字符串但如果你把它拼接到 HTML 中依然有风险。所以最保险的方式是所有链上数据先textContent渲染再用 CSS 控制样式。这看似多了一步却是生产环境的铁律。5. 常见问题与排查技巧实录5.1 问题速查表从“白屏”到“数据不更新”的全流程诊断现象可能原因排查命令/步骤解决方案页面打开后白屏控制台无报错HTML 文件未用 HTTP Server 打开直接双击 file://在终端执行npx serve或python3 -m http.server 8000用http://localhost:8000访问浏览器对 file:// 协议的 fetch 有严格限制必须走 HTTP控制台报Failed to fetch或Network ErrorRPC 端点不可达或 CORS 被拒在浏览器控制台执行fetch(https://cloudflare-eth.com, {method:POST, headers:{Content-Type:application/json}, body:{jsonrpc:2.0,method:eth_blockNumber,params:[],id:1}}).then(rr.json()).then(console.log)检查网络或换用https://rpc.1inch.io确认 URL 末尾无斜杠日志有输出但value显示为0或乱码ABI 定义与实际事件不匹配去 Etherscan 查看该合约的 Events 标签页复制官方 ABI严格对照 Etherscan 的 ABI注意indexed标记、类型大小写uint256vsuint只能查到旧日志新日志不出现fromBlock设置过大或轮询间隔太长console.log(Current block:, await provider.getBlockNumber())确认fromBlock是否小于当前块将fromBlock设为current - 5轮询间隔设为1000010秒parseLog报错cannot decode uint256 from hex stringdata字段长度不足 32 字节或 ABI 类型错误console.log(Raw data length:, log.data.length)标准uint256data 应为0x 64 字符检查 ABI 中该参数是否应为bytes32或address而非uint256页面卡死CPU 占用 100%一次性拉取过多日志如fromBlock0console.time(getLogs); await provider.getLogs(filter); console.timeEnd(getLogs)永远限制fromBlock范围生产环境不超过 1000 个区块5.2 我踩过的坑关于区块确认、时间戳与最终性最大的认知偏差是以为eth_getLogs返回的日志就是“已确认”的。实际上RPC 节点返回的是它本地视图中的日志而不同节点同步速度不同。我曾遇到一个诡异问题页面显示某笔交易在区块12345678但 2 分钟后该区块被重组reorg日志消失。解决方案是**永远等待