為什麼當前 Solana 之上的交易總是在失敗？
讓我們從最基本的概念開始逐步解析。
從使用者的角度來看，當我們在Solana 上進行交易時，本質上會出現三種潛在結果：
交易執行成功，一切正常;
交易執行失敗
，使用者已支付gas 費用，但執行結果回饋錯誤。當交易未滿足條件時，就會發生這種情況，例如用戶嘗試購買的代幣已售罄，或者價格波動過快（超出了預設滑點）等等；
：交易無跡可尋，即交易未能抵達「區塊領導節點」（Odaily 註：每4 個區塊輪值一次的當值節點）。 這是目前大多數使用者正在遇到的情況，本質上這是一個網路層的問題，而非共識層或執行層的問題。
執行問題並非壅塞主因
現在你可能會問，什麼是網路層？ 交易為什麼會遺失？為什麼說它們才是當前 Solana 擁塞的主要原因？
那些執行失敗的交易（即第二種情況），並解釋為什麼說執行失敗的交易並非擁擠的主要原因。
結合鏈上資料可見，所有執行失敗的交易中，只有約 8% 係由真實用戶提交，剩餘的都是鏈上機器人所發起的套利交易。
套利者之所以會持續不斷地發起「垃圾」交易，是因為與成功套利可所得的潛在利潤相比，頻繁發起交易的成本可以說是微乎其微。
具體而言，套利者可以在一天時間內持續不斷地發起交易，這麼做的成本大概是每天幾百美元（因為Solana 的網路費用較低），但只要能成功一筆，就可能賺到數十萬美元等級的利潤。
現在，讓我們來討論一下Solana 在過去幾天裡擁擠的真正主要原因——「交易遺失」。
如前所述，這些都是未能抵達「區塊領導節點」的交易，而交易之所為未能到達，是因為它們在網路層中被丟棄了。
網路層是網際網路的通訊層，它被用來將封包從一個端點傳送至另一個端點，常見的網路層協定包括TCP、UDP、QUIC（由Google開發） 等等。 Solana 先前將其網路層協定升級成了 QUIC，這有助於在用戶與「區塊領導節點」之間建立連結。
由於Solana 採用了連續出塊機制，且不存在用以暫存未確認交易的mempool，這意味著一旦連接丟失，交易將再也不會被包含至某個區塊之內。
QUIC 協定的優點在於，「區塊領導節點」可藉此獲得一種新功能：根據特定的標準來切段某有些用戶的連接，或限制它們的資料傳輸速率。
這項功能的意義在於，當網路需求高峰期出現時，「區塊領導節點」可以主動切斷某些連接，從而防止了Solana 會因網絡活動增加而完全宕機。
你可能又要疑惑了，如果 QUIC 協定的設計這麼完善，為什麼 Solana 現在還是這麼堵呢？
真正的問題在於，儘管「區塊領導節點」現在可以選擇主動調節某些連接，但決定哪些連接需要被調節的邏輯卻有問題。
為了更具像地理解這個問題，我們可以腦補這麼一種情況，每個「區塊領導節點」都有X個可以進行通訊的連接，但當網路需求高峰期出現時，該節點所接受到的連接請求是其承載能力的10 至100 倍…這時該節點就需要去選擇切斷某些連接。 然而當前的情況是，如何選擇將被切斷的連接並沒有一套既定的標準（例如切斷所有費用低於xxx 的連接），所有連接是否會被切斷都是隨機性的… …
說到底，當前情況下如果你想要交易被確認，你能做的就是發送更多的交易請求，但由於有許多機器人也會不斷地向網絡發送大量的連線請求，普通用戶建立連線並完成交易就變得越來越困難。
這就是 Solana 現在所面臨的問題。
當下，Jump （Firedancer 用戶端開發團隊）、Anza（Agave 用戶端開發團隊）、Solana Labs 等團隊正致力於對網路層進行修復。修復補丁將在本週逐步推出，據悉未來幾週將會有一些重量級的更新發布。
這能夠有效解決問題嗎？ Solana 會再次「 to da moon」嗎…這並沒有絕對答案。
為什麼目前仍存在著許多不確定性，主要有三個原因：
一是關於即將的修復補丁究竟能否生效，沒有人能夠保證。只有在它實際運作起來後，我們才能觀察實際情況。
二是 Jump 開發的Firedancer 用戶端看起來似乎能夠解決問題，但它要到今年年底才能正式發布。
三是關於「垃圾」交易的問題，Solana 的經濟機制使得該網路很難阻止惡意行為者對鏈持續進行「垃圾」交易攻擊。
最後，我想呼籲大家認識一件事：我相信Solana 正在為做出正確的權衡（Odaily 註：因指設定合理的連結切段標準）而戰鬥，就像以太坊曾經擺脫了諸多問題一樣，Solana 也終會擺脫這些問題。
以上是深度解析：Solana 究竟是如何堵住的？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
