BlockRazor
151 posts
BlockRazor
@BlockRazor_Inc
Navigate Your Transactions with BlockRazor. Provide Global Lighting-speed Network Service for Ethereum, BSC, and Solana.
Katılım Nisan 2024
88 Takip Edilen1.1K Takipçiler
As Solana scales, the battle for block building is heating up. We dive deep into the three major contenders challenging the status quo:
🛡 Paladin: Aligning incentives to make honesty more profitable via $PAL.
🔒 BAM: Using TEEs (AMD SEV-SNP) for private, front-running protected transactions.
⚖️ Harmonic: Bringing the PBS model to Solana to maximize validator revenue through open competition.
👉blockrazor.io/#/blogs/202602…
English
@donglan19951 @seaify1 从Header.Timestamp字段拿区块时间的秒数，Header.MixHash字段拿毫秒数
中文
其实很讽刺的，很多经典好文，阅读量非常的低，情绪化的东西，撕逼的东西，阅读量非常的高.
bsc链，很火热，但是足以和bnb48齐名的blockrazor，却异常的低调，推荐宝藏博主, @BlockRazor_Inc . 还有他们的博客, blockrazor.io/#/blogs
本质上来讲，没有人比bnb48和blockrazor这种，会对bsc链理解更深刻的。我们大部分开发者，都是从表象推演猜测，而他们是builder，对外对接bot, 系统内，对接validator, 最关键的角色.
最近bsc 750 ms -> 450 ms了，在这之前，我记得感觉， builder的重要些会降低，因为区块时间太短了，走builder bundle会来不及，但是现在看，想多了，😄，当前区块赶不上，但你钱给少了，下个区块头，也没你啊。
BlockRazor@BlockRazor_Inc
1 BSC 區塊廣播機制詳解 (Full Block Gossip) 在 Solana 上，您習慣了 Turbine 協議——一個基於 UDP、將區塊「切碎」並通過 Stake 加權樹狀結構以 O(logn)O(logn) 延遲高效廣播的機制。 BSC 則完全不同，它採用的是一種更接近傳統 EVM 鏈的 TCP Gossip 協議，廣播的是完整區塊。 當一個驗證者（Proposer）選定區塊後，它會立即開始廣播，這個過程主要依賴 TCP Gossip 協議。 1\ 準備與封裝： 驗證者對區塊進行最終計算（如封印雜湊 Seal Hash），附加其 BLS 簽名，並將區塊寫入本地節點。 2\ 選擇性全區塊廣播 (Propagate Block)： 驗證者不會立即向所有 Peers 廣播完整區塊。它會選擇一個子集（通常是 NN 個 Peers）並透過 TCP 發送完整的、RLP 編碼的區塊體（BlockAnnouncement 訊息）。 3\ 哈希公告廣播 (Announce Hash)： 對於網路中剩餘的 Peers，驗證者只發送區塊哈希（BlockHashAnnouncement 訊息）。這是一種帶寬優化策略，避免網路擁塞。 4\ Peers 接收與鏈式轉發： - 收到全區塊的 Peers： 立即進行驗證。如果有效，它們會重複步驟 2 和 3，將區塊（或哈希）轉發給它們自己的 Peers。 - 收到哈希的 Peers： 如果自己沒有這個區塊，會向發送方請求拉取 (pull) 完整的區塊。 5\ 投票與最終性 (Finality)： 網路中其他活躍驗證者收到並驗證該區塊後，會生成自己的 BLS 簽名投票（broadcastVote），並通過 Gossip 協議廣播這些投票。當一個區塊獲得了 2/3 的驗證者投票（Justification），它就接近最終確認。當它的子區塊也被 Justified 後，該區塊即被視為 Finalized（不可逆轉）。
中文
BlockRazor retweetledi
❤️Service on Monad is now available on BlockRazor!
🚀We provide the FASTEST network service on Monad for Sending Transaction!
😀Feel free to contact us if you have custom requirements.
docs: blockrazor.gitbook.io/blockrazor/tc/…
English
BlockRazor retweetledi
BITNEST | CORRECT CONNECTION USING THE WEB BROWSER VERSION youtu.be/GglinTfkhBE?si… via @TOKENPOCKET @BlockRazor_Inc @brave @BitNest_ @linuxmint
YouTube
English
@BlockRazor_Inc warmly welcomes everyone to @BNBCHAIN with their lightning-speed network service and a thoughtful, practical guidebook 👏
BlockRazor@BlockRazor_Inc
Wanna know more about how BSC work? Hope This Guide Book may help you ! 🔽Block Broadcast Mechanism blockrazor.io/#/blogs/202510…
English
2 給 Solana 交易者的核心啟示：信號源的根本差異
在 Solana 中： 狀態更新強依賴於 Shreds。通過預執行 Shreds 來更新世界狀態，再透過 geyser 插件進行交易訂閱，或者透過工具進行 deshred 獲得交易原文。由於沒有公共 Mempool，Shreds 既是「區塊廣播」，也是您能獲取的最早的「交易信號」。您的競爭優勢來自於多快能解析 Shreds。
在 BSC 中： 信號源是一分為二，必須同時監控Pending訊號和Confirmation訊號。
Pending 訊號（「即將發生什麼？」）：
來源： 公共 Mempool（NewPooledTransactionHashes 廣播）。
意義： 這是在區塊被確認前的訊號。高速獲取這些 pending 交易，是您建構交易策略的基礎。您需要以最低延遲接入 P2P 網路，以便在其他人之前捕獲 pending 交易。
Confirmation 訊號（「已經發生了什麼？」）：
來源： 區塊廣播（BlockAnnouncement 廣播）。
意義： 這是最終狀態的確認。當您收到這個完整區塊時，您可以 100% 確認交易的執行結果，並立即觸發您的下一筆交易（例如，為下一個區塊的競爭做準備）。您需要與驗證者建立最直接的網路連接，以便在其他人之前接收到已確認的區塊。
在 BSC 上，如果您的 Mempool 訊號比對手慢，您就無法建構最優的 Bundle；如果您的區塊確認訊號比對手慢，您在下一個區塊的競爭中就會失去先機。這就是為什麼在 BSC 生態中，像 BlockRazor 這樣提供高速👉 P2P 交易和區塊廣播的專業網路服務至關重要的原因。
中文
1 BSC 區塊廣播機制詳解 (Full Block Gossip)
在 Solana 上，您習慣了 Turbine 協議——一個基於 UDP、將區塊「切碎」並通過 Stake 加權樹狀結構以 O(logn)O(logn) 延遲高效廣播的機制。
BSC 則完全不同，它採用的是一種更接近傳統 EVM 鏈的 TCP Gossip 協議，廣播的是完整區塊。
當一個驗證者（Proposer）選定區塊後，它會立即開始廣播，這個過程主要依賴 TCP Gossip 協議。
1\ 準備與封裝： 驗證者對區塊進行最終計算（如封印雜湊 Seal Hash），附加其 BLS 簽名，並將區塊寫入本地節點。
2\ 選擇性全區塊廣播 (Propagate Block)： 驗證者不會立即向所有 Peers 廣播完整區塊。它會選擇一個子集（通常是 NN 個 Peers）並透過 TCP 發送完整的、RLP 編碼的區塊體（BlockAnnouncement 訊息）。
3\ 哈希公告廣播 (Announce Hash)： 對於網路中剩餘的 Peers，驗證者只發送區塊哈希（BlockHashAnnouncement 訊息）。這是一種帶寬優化策略，避免網路擁塞。
4\ Peers 接收與鏈式轉發：
- 收到全區塊的 Peers： 立即進行驗證。如果有效，它們會重複步驟 2 和 3，將區塊（或哈希）轉發給它們自己的 Peers。
- 收到哈希的 Peers： 如果自己沒有這個區塊，會向發送方請求拉取 (pull) 完整的區塊。
5\ 投票與最終性 (Finality)： 網路中其他活躍驗證者收到並驗證該區塊後，會生成自己的 BLS 簽名投票（broadcastVote），並通過 Gossip 協議廣播這些投票。當一個區塊獲得了 2/3 的驗證者投票（Justification），它就接近最終確認。當它的子區塊也被 Justified 後，該區塊即被視為 Finalized（不可逆轉）。
中文
Hi Solana玩家，歡迎來到BSC.
我們準備了一份快速導覽，幫助你快速了解BSC底層機制。
🔽一文速通 BSC 網絡（3） —— 區塊廣播機制
中文
3 給 Solana 開發者的新認知
從「Jito 獨大」到「多 Builder 市場」： 在 BSC，您不能只依賴一個 MEV 基礎設施。您需要同時對接多個 Builder（如 BlockRazor, 48Club 等），因為您不知道哪個 Builder 會贏得下一個區塊的競標。這提高了網路的穩定性和去中心化程度，但也增加了您的集成和開發成本。
核心差異：「區塊截止時間」—— BSC MEV 是有截止時間的批次競爭，您的策略必須圍繞「如何在 Builder 提交區塊 Bid 前將最有價值的 Bundle 發送給所有主流 Builder」來建構。
中文
2 與 Solana Jito 機制的對比
提交： Searcher 將 Bundle 提交到 Jito 的 Block Engine。
拍賣： Block Engine 模擬執行，並按帳戶衝突分組，進行並行拍賣。
選擇： Jito 選擇在 Compute Unit （CU）限制內，每 CU Tip 最高的 Bundle 組合。
流式傳輸： 優化的 Bundle 透過 gRPC 流式傳輸到驗證者的 BundleStage。
支付： 驗證者執行 Bundle，Tip 被收集到 Tip Payment Program，並在 Epoch 結束時分配。
中文
Hi Solana玩家，歡迎來到BSC.
我們準備了一份快速導覽，幫助你快速了解BSC底層機制。
🔽一文速通 BSC 網絡（2） —— MEV 鏈路 (PBS vs Jito)
中文
3 給 Solana 開發者的新認知
對於習慣了 Solana 確定性轉發 (SWQoS) 的開發者來說，理解 BSC 鏈路的核心要點是：
不再是「Leader 直達」： 您的交易不再是直接發送給 Leader，而是需要在P2P網絡中廣播，等待被所有驗證者「發現」和「拉取」。
高不確定性： 您的交易從提交到被驗證者收錄的時間，高度依賴 P2P 網絡的拓撲結構和傳播速度，這帶來了更高的上鏈不確定性和延遲。
第三方解決方案至關重要： 就像 Solana 的 SWQoS 鏈路可以顯著提高上鏈速度一樣，在 BSC 上，BlockRazor 等第三方服務正是通過建立類似於 SWQoS 的低延遲直連渠道（直接橋接到驗證者節點），來解決原生 P2P 廣播帶來的延遲和丟包問題。若您追求極致的交易速度和成功率，應考慮使用這些服務。
中文
2 BSC 交易排序規則（原生機制）
在 Solana 中，交易排序主要基於CU Price和賬戶鎖競爭。在 BSC 中，當驗證者從 Mempool 中選擇交易構建區塊時（在 PBS 機制引入前或 Builder 未介入時），其原生排序規則嚴格遵循 EVM 規範：
Nonce：同一賬戶的交易必須嚴格按 Nonce 升序 執行。這是 EVM 強制的數據一致性規則。
GasPrice ：在 Nonce 排序的基礎上，跨賬戶的交易按 Gas Price 降序 優先。這類似於 Solana 中的CU Price，高 Gas Price 的交易會被優先打包，以最大化驗證者收益。
ArrivalTime：如果兩筆不同賬戶的交易 Gas Price 相同，則先到達驗證者 Mempool 的交易優先。
中文
Hi Solana玩家，歡迎來到BSC.
我們準備了一份快速導覽，幫助你快速了解BSC底層機制。
🔽一文速通 BSC 網絡（1） —— 交易廣播鏈路
中文