引言
截止到發稿日當天(2025/8/26)，Solana鏈上的真實TPS依舊保持1000以上，鏈上的各類Bot程序在DeFi、NFT和自動化交易中的應用日益廣泛，但大量的開發者仍舊困擾於交易延遲對Bot效率和競爭力的負面影響。
本篇文章中，我們將基於對Solana Infra的理解，構建一個最小規模的Bot程序，並在自動化交易和Trading Bot等常見應用場景下，分別開展Server E2E 和 Client E2E 模式下的延遲基準測試。
我們將在文章中分享對高性能低延遲程序的架構設計、設計經驗和測試方法，提供高性能Bot的基礎模板以及基準性能測試作為參考。我們的目的是通過本篇文章為對延遲有極致追求的開發者提供基礎設計思路和性能基準（開發者可以自主對比我們的測試結果來壓縮現有系統的延遲空間，更輕鬆地推進到優化的極限），在提升Bot性能表現的同時鼓勵更多的功能性差異化競爭。
E2E 測試的必要性和意義
在本文範圍中，E2E（end to end）是指收到交易信號或用戶意圖—>構建交易—>發送交易—>收到shred—>確認交易結果的全過程。參考實際的應用場景，我們將E2E 測試分為Server E2E 和 Client E2E兩種模式，Server E2E 模式適用於自動化交易程序以及計劃優化內部系統延遲的Web Trading Bot，而Client E2E模式適用於需要從瀏覽器或手機App等交互媒介收集用戶交易意圖的各類在線交易系統。
在競爭日益激烈的Solana生態中，同一個交易信號存在多個競爭對手，在毫秒級進行優化並降低延遲能夠顯著提升競爭效果，同時減少滑點損失、降低交易失敗率。
因此，低延遲對於Solana Bot是競爭勝負的關鍵。由於可供參考的高性能分佈式系統資料較少，若開發者採取傳統的設計模式與性能測試方式會容易忽略網絡延遲、地理因素和外部依賴，導致存在潛在的架構設計問題。相比之下，E2E測試可以
- 識別交易全鏈路瓶頸：包括RPC調用、簽名、廣播和確認
- 優化架構設計：幫助開發者基於實際測試數據思考架構設計的Tradeoff
- 提供技術決策依據：通過對比原生Shred解析和Yellowstone(Geyser) gRPC訂閱的延遲差異，提供確認交易的技術決策依據
Server E2E vs Client E2E: 測試類型介紹及其差異性分析
Server E2E測試
Server E2E是指在服務器端通過自動化程序直接與Solana RPC交互的延遲測試方式。Server E2E模擬的是自動化交易Bot從構建交易到確認交易上鏈的全鏈路場景，不涉及用戶在界面側的操作，適合在服務端批量操作的高頻交易Bot。Server E2E的測試鏈路如下圖：
我們使用Rust構建Bot程序並部署於Bot Server，Bot程序在交易發送端集成BlockRazor的Solana交易發送服務。當Bot程序發出交易並被納入區塊後，區塊會以shred的形式在Solana網絡中廣播，我們採用原生Shred解析（集成BlockRazor的Shred Stream）和Yellowstone gRPC訂閱的方式來確認交易是否已被納入區塊。
Client E2E測試
Client E2E測試是指模擬用戶手動在客戶端（Web應用、手機App等）操作與服務端交互的交易延遲測試方式，適用於擁有終端用戶的Trading Bot，其測試交易鏈路如下圖：
和Server E2E測試不同，Client E2E測試中的Bot程序需要面向終端用戶提供交易服務，因此在Server E2E測試的基礎上，我們在交易發送端引入Bot Client並通過HTTP請求向Bot Server發送交易。
由於存在Bot Client和Bot Server間的HTTP請求交互，在延遲上Client E2E相比Server E2E會額外引入瀏覽器渲染、網絡代理、DNS域名解析、跨地區網絡傳輸等導致的延遲。
小結
Server E2E和Client E2E的差異如下
測試案例：實際業務場景與必要性
測試方法
- 在不同的測試用例中構建、簽名並發出一組交易，記錄每筆交易的簽名時間
- ☞ 解析原生Shred，監聽測試交易，如測試交易的簽名命中則記錄時間戳，視為交易確認時間。該方法不代表交易的最終確認結果，但可以以更低延遲高概率命中
- 訂閱Yellowstone推出的gRPC流，監聽測試交易，如測試交易的簽名命中則記錄時間戳，視為交易確認時間，該方法監聽命中的交易為Processed級別
- 為每筆測試交易設置高優先費(Priority Fee)和Tip
- Priority Fee: 0.005 SOL
- Tip: 0.003 SOL
- 每組100筆交易，每隔5s發送一筆交易
測試指標
- 交易延遲：交易簽名和交易確認的時間戳差值
測試用例
Server E2E 多地區
Server E2E 多地區是指在法蘭克福、阿姆斯特丹、紐約和東京部署獨立的Bot Server並對接同地區的BlockRazor Solana交易發送Relay，如下圖：
按照前述測試方法通過每台Bot Server發送一組模擬交易，記錄交易延遲，測試結果如下：
從地區維度看，法蘭克福的交易延遲最低，阿姆斯特丹次之，紐約的交易延遲較高，東京地區的交易延遲最高，E2E延遲和地區的Validator聚集程度呈負相關。
以上現象主要是由當前Solana質押的☞ 地理分佈狀態 導致。假設將Bot Server部署在東京，而Leader節點高頻率在Validator最為密集的法蘭克福出現，那麼從交易發出到被Leader節點接收需要從日本跨越到德國，同樣地，Leader節點產生區塊到其shred被Bot Server接收需要從德國跨越回日本。
從監聽交易的方式來看，在本地解析shred的方式擁有更低的延遲，但無法獲得交易實際執行結果，相對來說Yellowstone訂閱的方式能夠獲得交易實際執行結果，但會增加部分延遲。
Client E2E 多地區
Client E2E 多地區是指在法蘭克福、弗吉尼亞和東京部署獨立的Bot Client以及Bot Server，Bot Client將交易請求發往Cloudflare開啟地理就近路由功能的多地區負載均衡器，Cloudflare會在收到報文後執行就近路由邏輯。如下圖
按照前述測試方法通過每個Bot Client發送一組測試交易，結果如下
- 法蘭克福: 平均142ms，50分位118ms
- 弗吉尼亞: 平均174ms，50分位179ms
- 東京：平均263ms，50分位272ms
將同地區的Client E2E和Server E2E進行比較，可以發現
Client E2E相比Server E2E在法蘭克福和東京地區的交易延遲平均高20-30ms。Client E2E的交易高延遲是由於增加了Bot Client和Bot Server間的請求交互，瀏覽器渲染、網絡代理和DNS域名解析等因素都會造成延遲抬升。
Client E2E 單地區 vs 多地區
Client E2E 單地區case中，我們在東京部署一台獨立的Bot Server，由部署於多地區的Bot Client將交易請求發往Cloudflare開啟地理就近路由功能的負載均衡器，Cloudflare在就近的PoP收到報文後會將請求統一路由到東京地區的Bot Server，如下圖
按照前述測試方法通過每個Bot Client發送一組測試交易，和Client E2E 多地區的對比結果如下
從數據分析可知，Client E2E 單地區相比Client E2E 多地區在法蘭克福平均交易延遲高335ms，在弗吉尼亞平均交易延遲高148ms，在東京平均交易延遲高23ms。由此可見，Client E2E 多地區在交易延遲方面存在顯著優勢，但多地區部署會增加系統複雜性和成本；Client E2E 單地區雖然在交易延遲較高，受限於地理位置，但適合低預算或者用戶地理位置集中度較高的Bot服務。
結論與展望
通過E2E測試，我們驗證了Solana Bot在不同場景下的極速潛力以及Bot地理位置優化的重要性。
我們建議強地緣屬性的Bot服務可以在用戶密集區就近部署，全球分佈部署的必要性不高。而對於面向全球客戶的Bot服務建議多地區分佈式部署，配置統一域名，將用戶交易請求通過負載均衡就近路由到相應服務，在交易請求側實現最低延遲路由。
在交易確認的技術選型方面，原生shred解析延遲較低，適用於對交易延遲敏感的自動化交易Bot；Yellowstone gRPC訂閱的延遲較高，但可以訂閱到交易的執行結果，適用於對交易延遲相對不敏感或需要交易執行結果的Bot服務。
我們已將本次測試的代碼開源，歡迎前往 ☞ https://github.com/BlockRazorinc/solana-e2e-benchmark 查看
如果您對測試細節、數據報告或更加極限的性能優化感興趣，也歡迎與我們☞ 聯繫，我們樂於提供更多insights和合作機會。