tech

构建ETH-BSC桥实时监控器

Binance Bridge与Multichain或cBridge相比需要多长时间？既然我已经有了运行的基础设施，我决定：为什么不建立一个桥接监控器呢？

构建ETH-BSC桥实时监控器
一键发币： Aptos | X Layer | SUI | SOL | BNB | ETH | BASE | ARB | OP | Polygon | Avalanche | 用AI学区块链开发

这是我在之前写的一篇文章的延续，详细介绍了我使用AWS Node Runner Project部署独立区块链节点的经历。

在设置好我的以太坊和币安智能链（BSC）节点后，我想实际利用它们。不仅仅是让它们在那里同步区块。我坦白承认，Claude给了我一个简单的想法，即桥接监控器，这来自于一个问题：在以太坊和BSC之间桥接资产实际上需要多长时间？

没有人有“桥接拥堵”和“延迟交易”的真实数据。DefiLlama显示桥接交易量，各个桥接网站显示“运营状态”，但没有交易级别的数据。Binance Bridge与Multichain或cBridge相比需要多长时间？既然我已经有了运行的基础设施，我决定：为什么不建立一个桥接监控器呢？

代码 免责声明 —— 我是一个加密货币新手，这个个人项目是为了学习和好奇心的目的而进行的。如果提到错误的概念、方法或陈述，请原谅我。

1、想法

桥接交易是通过调用特定的智能合约进行的。当有人从以太坊桥接USDT到BSC时，他们的交易会发送到以太坊上的桥接合约地址。然后桥接会在BSC上释放资金。

因此，为了监控桥接：

  1. 监视发送到已知桥接合约地址的交易
  2. 跟踪它们完成的时间
  3. 计算性能指标

2、检测桥接交易

我首先从最流行的ETH-BSC桥接开始：

bridges = {  
    'eth': {  
        '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',  
        '0x3ee18B2214AFF97000D974cf647E7C347E8fa585': 'Binance Bridge',  
        '0x5427FEFA711Eff984124bFBB1AB6fbf5E3DA1820': 'cBridge',  
    },  
    'bsc': {  
        '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',  
        '0x841ce48F9446C8E281D3F1444cB859b4A6D0738C': 'cBridge BSC',  
    }  
}

监控逻辑是扫描最近的区块，检查是否有任何交易发送到这些地址，并将它们保存到数据库中。

3、问题 —— BSC PoA错误

第一个主要障碍很快就出现了：

⚠️ 扫描bsc的block 56150636时出错：extraData字段是280字节，但应该为32字节。很可能你连接的是POA链。

原来BSC使用的是权威证明共识，而不是像以太坊那样的工作量证明。这打破了Web3.py对区块结构的默认假设。

解决方法： 一行中间件代码，之后BSC扫描就正常了。

from web3.middleware import geth_poa_middleware

4、问题 —— 所有交易都处于挂起状态

我很快用FastAPI创建了一个基本的终端风格仪表板：

它显示了检测到的交易！15个挂起，1个完成。感觉很好。沉浸在仪表板更新中，我后来才发现数字迅速增加（很快达到了1,497个交易被检测到），但**零个完成。**平均时间0.0m，成功率0%。

问题是状态更新逻辑不正确。 它一次检查10个交易，每30秒运行一次，同时使用基于时间的逻辑而不是实际的区块链验证。

修复方法：

# 检查所有挂起的交易（移除了LIMIT）  
cursor.execute('''  
    SELECT tx_hash, created_at, direction, block_number  
    FROM transactions   
    WHERE status = 'pending'  
''')  

# 更频繁地更新  
if cycle % 3 == 0:  # 每15秒而不是30秒  
    self.show_comprehensive_stats()

# 实际上在链上验证交易  
receipt = w3.eth.get_transaction_receipt(tx_hash)  

if receipt and receipt['status'] == 1:  
    cursor.execute('''  
        UPDATE transactions  
        SET status = 'completed',  
            completed_at = datetime('now'),  
            completion_time = ?,  
            gas_used = ?  
        WHERE tx_hash = ?  
    ''', (elapsed, receipt['gasUsed'], tx_hash))

修复后，情况开始变得真实：

  • 追踪了7,956笔交易
  • 完成了7,101笔
  • 平均完成时间为4.1m
  • 各桥的成功率：Wormhole Token为92%，cBridge为76%等。

5、从5个桥扩展到20+

初始版本只监控5个桥接合约。但实际上，有几十个桥接在ETH和BSC之间运行。我将合约列表扩展，包括：

        self.bridges = {  
            'eth': {  
                # Multichain (AnySwap) - 多个合约  
                '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',  
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'Multichain USDT',  
                '0x765277EebeCA2e31912C9946eAe1021199B39C61': 'Multichain ETH',  
                '0xC564EE9f21Ed8A2d8E7e76c085740d5e4c5FaFbE': 'Multichain USDC',  
                # Binance Bridge  
                '0x3ee18B2214AFF97000D974cf647E7C347E8fa585': 'Binance Bridge',  
                '0xfA0F307783AC21C39E939ACFF795e27b650F6e68': 'Binance Token Hub',  
                # cBridge (Celer)   
                # ... +15 more from Wormhole Portal Bridge, Stargate (LayerZero), Synapse Bridge, Hop Protocol, Across Protocol, deBridge, Connext  
            },  

            'bsc': {  
                # BSC上的Multichain  
                '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',  
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'Multichain USDT',  
                '0xC564EE9f21Ed8A2d8E7e76c085740d5e4c5FaFbE': 'Multichain USDC',  
                # Binance Bridge BSC侧  
                '0x0000000000000000000000000000000000001004': 'BSC Token Hub',  
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'BSC Bridge',  
                # cBridge BSC + many more from Wormhole BSCStargate BSC, Synapse BSC, deBridge BSC, Orbit Bridge  
            }  
        }

这立即提高了检测和捕获交易的数量。

6、添加一些性能分析

有了真实的数据流，我可以开始得到哪个桥最快的问题的答案！

查看仪表板：

  • Synapse Bridge: 平均3.4m，100%成功
  • Stargate: 平均3.7m，13%成功
  • cBridge Main: 平均3.3m，74%成功
  • 潜在ETH Bridge: 平均4.1m，90%成功

7、清理数据库

随着功能的添加，需要新的数据库列，这会导致旧代码尝试保存没有新字段的事务时出错：

❌ 保存错误：表transactions没有名为token_symbol的列

我添加了一个clean_db_setup.py，清除数据库并用全面的模式重新开始。

8、添加卡住的交易警报

检测可能卡住的交易似乎很有用：

顶部的红色警报框显示挂起超过30分钟的交易。在实际使用中，当您的特定交易卡住时，您会想要通知。

9、关于桥接性能的发现

根据我只有几个小时的实验，这些是结论：

  • 最快: cBridge约3.3分钟
  • 最可靠: Synapse 100%成功率
  • 最慢: 一些“潜在”桥接约30分钟以上

查看方向分析：

  • ETH → BSC: 465笔交易
  • BSC → ETH: 1,819笔交易
  • 总体成功率: 97%

令人惊讶的是，几乎4倍的人从BSC桥接到以太坊，而不是相反方向。我原本以为相反——人们逃离昂贵的以太坊Gas费去便宜的BSC。

但我的实验显示相反。这可能是因为信任因素——尽管成本较高，以太坊被视为长期持有的更安全选择。因此，人们可能在BSC上进行收益耕种或交易，然后桥接利润回到“更安全”的以太坊。这也可能是因为以太坊仍然拥有最成熟的生态系统——主要的DeFi协议、NFT市场和机构基础设施都在主网上，所以人们桥接回来以访问它们。

10、我的设置总结

你可以在这里找到个人项目代码，readme中有更多信息。简单设置如下：

监控过程：

  • 每5秒扫描以太坊和BSC链
  • 监控20多个桥接合约
  • 检查最后10个区块的新交易
  • 每15秒更新交易状态
  • 将所有内容保存到SQLite

仪表板：

  • FastAPI在端口8000上提供服务
  • 每30秒自动刷新
  • 显示不同桥接的性能比较
  • 分页查看所有交易
  • 按桥接、状态、方向筛选

服务器资源： 在与以太坊AWS Node Runner节点相同的EC2实例上舒适运行。

11、结束语

使用我自己的节点提供了调整区块链扫描频率的灵活性，无论我感觉如何，而且完全没有API延迟。使用管理提供商会有基于API调用/信用的定价模型，可能会有速率限制或API配额。（虽然管理自己的节点在生产中可能仍然更贵；我们应当进行自己的成本分析）。

交易量。实际上在短时间内看到监控桥接上的1,000多笔交易非常令人惊讶。ETH-BSC走廊比我想的活跃得多（尽管我没有多少参考框架）。

成功率差异很大。有些桥接显示100%的成功率，其他则为70-80%。不确定这是真实的还是我的完成检测逻辑的问题；但我不会进一步调查：P。

“潜在”桥接。我检测到的大量交易是发送到DEX路由器（“Potential”桥接），而不是直接的桥接合约。这些可能是桥接相关的（一些桥接通过DEX路由），或者可能是噪音。需要更好的过滤。

原文链接：Vibe Coding a Real-Time ETH-BSC Bridge Monitor utilizing My Own AWS NodeRunner Nodes

DefiPlot翻译整理，转载请标明出处

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。

Read next