
在 2026 年 10 月 3 日進行的 Benchmark 中,BlockRazor 與 Eira Nodes 共匹配 1,129 個 Robinhood Chain Feed 事件。BlockRazor 有 61.12% 率先到達,Eira Nodes 為 38.88%;從 P50 到 P99,BlockRazor 的相對延遲均更低。在大數據包樣本中,BlockRazor 在 80 個超過 50 KB 的區塊中有 77 個領先 Eira,正面勝率為 96.25%。
核心結果
- 整體樣本:1,129 個匹配事件
- 首達率:BlockRazor 61.12%,Eira Nodes 38.88%
- P95:0.312 ms 對 0.956 ms
- P99:0.568 ms 對 1.492 ms
- 超過 50 KB 的數據包:BlockRazor 77/80(96.25%),Eira Nodes 3/80(3.75%)
Benchmark 測試方法
Benchmark 客戶端部署在 AWS 美國東部(俄亥俄)區域的可用區 use2-az2。同一個客戶端同時連接 BlockRazor Direct Sequencer Feed Ultra 的 WebSocket JSON 接口,以及 Commitment Level 為 RECEIVED 的 Eira Pulse gRPC 接口。Eira 的 gRPC 運行時直接生成結構化 Update;BlockRazor 的原生兼容 WebSocket JSON 使用 ByteDance Sonic 解析。兩側均在事件可以被客戶端使用時記錄時間戳,再按區塊高度完成匹配。
高性能 JSON 解析
連接 Robinhood Chain Direct Sequencer Feed 的 Go 客戶端可以使用 ByteDance Sonic 解析通過 WebSocket 接收的 JSON 消息。Sonic 使用 JIT 編譯和 SIMD 加速,降低延遲敏感型交易系統的解析延遲與 CPU 開銷。
在我們的 Benchmark 中,Sonic 的 P50 JSON 解析延遲約為 2–3 微秒。實際性能可能受到消息大小、數據結構、CPU 架構和運行環境影響。建議使用真實 Feed 數據進行測試,並在處理延遲敏感流量前預熱常用 Go 類型。
目前的參考實現使用 Go。對於使用 Rust、C++ 或其他語言的交易策略,開發者可以將上述延遲作為參考,選擇並測試相應的高性能 JSON 解析庫。
每個匹配事件中,率先成為客戶端可用事件的來源記為 0.000 ms,另一個來源記錄兩個時間戳之差。因此,結果包含兩個產品各自必需的客戶端接入流程,而不是只衡量原始網絡傳輸或 Sequencer 到客戶端的絕對延遲。
整體延遲結果
| 來源 | 樣本數 | 首達率 | P50 | P70 | P80 | P90 | P95 | P99 |
|---|---|---|---|---|---|---|---|---|
| BlockRazor | 1,129 | 61.12% | 0.000 ms | 0.050 ms | 0.134 ms | 0.236 ms | 0.312 ms | 0.568 ms |
| Eira Nodes | 1,129 | 38.88% | 0.064 ms | 0.212 ms | 0.302 ms | 0.541 ms | 0.956 ms | 1.492 ms |
在 1,129 個匹配事件中,BlockRazor 的首達率為 61.12%,比 Eira Nodes 的 38.88% 高 22.24 個百分點。P95 方面,BlockRazor 為 0.312 ms,Eira 為 0.956 ms,降低 0.644 ms(67.36%);P99 方面,BlockRazor 為 0.568 ms,Eira 為 1.492 ms,降低 0.924 ms(61.93%)。
大數據包結果:BlockRazor 在 96.25% 的樣本中領先
鏈上行情活躍時,大數據包通常會連續出現,因此連續大包期間的首達性能更能反映行情高峰期的接入穩定性。本次大數據包樣本包含從區塊 79165757 到 79165836 的 80 個連續匹配區塊,大小介於 65.16 KB 至 124.54 KB。
| 數據包範圍 | 匹配區塊 | BlockRazor 首達 | Eira Nodes 首達 | BlockRazor 勝率 |
|---|---|---|---|---|
| 超過 50 KB | 80 | 77 | 3 | 96.25% |
對於 BlockRazor 勝出的 77 個區塊,領先幅度按 Eira 相對延遲減去 BlockRazor 相對延遲計算。分位數採用最近秩法:先將 77 個領先幅度由小到大排序,再按百分位比例 p 取第 ⌈p × 77⌉ 個樣本;例如 P95 取第 74 個樣本。
| 勝出樣本 | 平均領先 | P50 | P70 | P80 | P90 | P95 | P99 |
|---|---|---|---|---|---|---|---|
| 77 | 0.618 ms | 0.495 ms | 0.804 ms | 0.977 ms | 1.152 ms | 1.510 ms | 2.113 ms |
其中,BlockRazor 在 38 個勝出區塊中的領先幅度不低於 0.5 ms,佔 49.35%;在 13 個區塊中的領先幅度不低於 1 ms,佔 16.88%。這組分布表明,在本次大數據包樣本中,WebSocket JSON 路徑保持了穩定的客戶端可用時間優勢。
這對交易系統意味着什麼?
更低的 Feed 延遲可以為後續交易流程保留更多反應時間:
更早接收 → 更早解析和過濾 → 更早評估 → 更早構建與模擬 → 更早提交
這一優勢更適用於 Sniping、Copy Trading、地址監控和實時信號系統。選擇 Feed 時,還應綜合考慮事件覆蓋率、重連行為、消息完整性、跨區域一致性、協議兼容性和運營支持。
常見問題
為什麼 BlockRazor 的 P50 是 0.000 ms?
每個匹配事件中,率先成為客戶端可用事件的來源相對延遲被記為零。這不代表從 Sequencer 到客戶端的完整路徑耗時為零。
gRPC 與 WebSocket JSON 可以直接對比嗎?
兩種協議不同,因此這不是協議無關的原始字節測試。Benchmark 對比的是策略代碼真正關心的時間點:結構化事件何時可以使用。Eira 包含 gRPC/Protobuf 解碼,BlockRazor 包含 Sonic JSON 解析。
為什麼使用 Sonic?
BlockRazor 保持對原生 WebSocket JSON 訂閱格式的兼容。Sonic 可以在保留這一兼容性的同時降低 JSON 解析開銷,其解析耗時已包含在 BlockRazor 的結果中。
在你的環境中測試 BlockRazor
你可以查看 BlockRazor Robinhood Chain 產品方案,閱讀 Direct Sequencer Feed Ultra 接入指南,並從策略實際運行區域對比不同 Feed。如需查看 BlockRazor 與 Robinhood Chain 官方 Feed 的另一組對比,請參考 BlockRazor Sequencer Feed Benchmark。如需開通或接入支持,請聯繫 BlockRazor。