所有語言
分享
導讀: 本文深入探討了區塊鏈交易費⽤模型的重要性及其在確保網絡安全和有效運行中的關鍵作用。通過對以太坊和Solana區塊鏈網絡的交易費⽤模型進行比較分析,揭示了不安全的交易計費可能引發的網絡安全風險。特別關注了 CertiK團隊發現並協助修復的Solana網絡中大整數模冪運算的CU計算錯誤,這一錯誤可能導致潛在的DOS攻擊 。文章詳細分析了Solana的智能合約計價模型、POH共識機制、并行事務處理方式,並通過在Solana私有集群上的實驗,復現了遠程DOS攻擊的過程和成本。
區塊鏈的計費模式是確保網絡安全和有效運行的關鍵機制,通過收取用戶執行操作所需的費用(如Gas費用),防止惡意行為和資源濫用,保護用戶利益,並推動整個區塊鏈生態系統的發展和創新。一個有效的計費系統不僅是財務基礎,也是促進技術進步和社區信任的重要因素。
本文將深入分析以太坊(ETH)和Solana區塊鏈網絡的交易費用模型,以及不安全的交易計費可能引發的網絡安全風險。重點討論CertiK團隊發現並修復的Solana網絡中大整數模冪運算CU(計算單元)計算錯誤所引發的潛在遠程DOS攻擊漏洞,並通過此案例探討區塊鏈計費模型中的安全隱患。
在Web3.0領域中,底層基礎設施運行在去中心化的區塊鏈網絡上。這些網絡由全球驗證者共同維護和運營。用戶通過交易和智能合約進行互動,所有的交易都被記錄在分佈式賬本上,並且這些記錄是永久不可篡改的。
驗證者們憑藉有限的資源共同維護着這龐大的區塊鏈網絡,而交易費用在確保網絡穩定性和安全性方面起到關鍵作用。這些費用不僅激勵着網絡參与者,還是推動區塊鏈成功發展的動力。有效的交易費用模型能夠確保網絡資源的合理分配,防止惡意行為和資源濫用,同時保護用戶利益,促進技術的持續創新和社區的健康發展。
交易費用模型的安全性對於區塊鏈的長期健康和穩定至關重要。這種模型不僅僅是對網絡資源的有效管理,還直接影響用戶的信任和參与度。一個健全的交易費用模型能夠有效地防止網絡遭受惡意行為,如拒絕服務攻擊(DDoS),通過設定適當的費用門檻使攻擊者難以濫用網絡資源。
合理的費用結構能夠激勵驗證者和礦工投入足夠的資源來維護區塊鏈的安全性和穩定性,因為他們通過收取交易費用來獲取獎勵和補償。此外,透明和公平的計費機制還可以保護用戶免受不當收費和資源耗費,增強他們對區塊鏈生態系統的信任感。因此,一個經過良好設計的交易費用模型不僅是經濟上的基礎,更是確保區塊鏈網絡安全和用戶權益的重要保障。
在BTC網絡中,所有交易的複雜度相對一致,並採用單一的交易計費模型。相比之下,ETH和Solana網絡採用圖靈完備的腳本語言,其交易計費模型設計更為複雜,涵蓋帶寬消耗、存儲消耗和計算消耗等多個方面。智能合約可以消耗任意數量的帶寬、存儲和計算資源,而Gas費用則是衡量合約執行所需計算工作量的單位。通過限制Gas費用的消耗,可以有效控制智能合約對資源的過度利用。
在以太坊(ETH)網絡中,交易計費模型設計如下:
3.1.1:單位和概念解釋
•Wei和Gwei單位:Wei是以太幣(ether)的最小單位,1 ether = 1 x 10^18 wei。Gwei是Gas的計量單位,1 gwei = 1 x 10^9 wei。
3.1.2:Gas費用計算系統
•Gas Limit:用戶願意為確認交易或執行操作支付的最大Gas量。在倫敦升級[1]后,Gas Limit可以根據網絡需求在15M至30M之間動態調整。
•Gas Used:實際消耗的Gas數量,不超過Gas Limit。對於未使用的Gas部分,將會自動退回到用戶的錢包餘額。
•Gas Price:用戶願意為每單位Gas支付的價格。Gas Price隨着以太坊網絡上交易擁堵情況而變化,通常是動態調整的,當前查詢[2]Gas Price約為10gwei左右。倫敦升級引入了改進的EIP-1559[3]新增兩個參數(基礎費用BaseFee和優先級費用PriorityFee),改進后的Gas Price計算為BaseFee + PriorityFee。
3.1.3:ETH網絡交易費用計算示例
•例如,如果Gas Price為35 gwei/Gas,交易手續費計算如下:
交易手續費 = Gas Price (10 gwei) * Gas Limit (21000) / 10^9 = 0.00021 ETH如果以每ETH單價3500美元計算,這筆交易手續費大約為0.735美元。在網絡極度擁堵時,Gas Price可能會上升至100 gwei/Gas以上,導致單筆交易費用超過10美元。
3.1.4:ETH網絡的TPS
•在區塊鏈領域中,每秒事務數(TPS)是指網絡每秒處理或執行的事務數量。當前查詢[4]显示以太坊網絡的TPS約為12.7。
這些特性和參數使得以太坊網絡能夠根據需求動態調整交易費用,並有效管理網絡資源,從而支持其廣泛的智能合約和分佈式應用生態系統的運行和發展。
3.2.1:Gas費計算系統
•本地代幣SOL和Lamport:Lamports是Solana網絡中的本地代幣,相當於SOL的最小單位。一個SOL等於1,000,000,000 Lamports。MicroLamport是Lamports的最小單位,等於0.000001 Lamports,用於計算優先級費用。
•簽名費用:每筆交易必須包含一個簽名,每個簽名的基本費用固定為5000 Lamports(0.000005 SOL)。
•計算單元(CU):用於衡量Solana區塊鏈智能合約執行資源消耗的最小單位。在Solana 1.9.2中引入了類似ETH的Gas Limit的功能,每筆交易默認具有200,000 CU預算,並且可以設置最大的1,400,000 CU。
3.2.2:Solana經濟學設計
•基礎費用:在2020年推出后的前兩年,Solana的交易基礎費用固定為0.000005 SOL每筆(每筆交易一個簽名)。
•優先費用:自2022年起,Solana引入了額外的優先費用機制,允許在交易時支付額外費用以優先處理。計算優先費用的方法是將請求的最大計算單元(CU)乘以每個計算單元0.000001 Lamports的價格,四舍五入到最接近的Lamports。
•租金費用:每個Solana賬戶在區塊鏈上存儲數據的費用稱為“租金”。驗證者根據賬戶在內存中維護的數據收取基於時間和空間的租金費用。賬戶需要足夠的Lamports餘額以免除租金並保留在Solana區塊鏈上。賬戶若無法支付租金,則可能會通過垃圾收集過程從網絡中刪除。
•例如:如果一個賬戶持有至少 2 年的租金,則該賬戶被視為免租。每次賬戶餘額減少時都會檢查此項,將餘額 減少到最低金額以下的交易將會失敗,目前的免租費用為每 MB 6.96 SOL。創建新賬戶時,費用會分配給該賬戶;刪除賬戶時,可重新收取免租費用,假如一個大小為15,000字節的可執行程序需要105,290,880個lamports (=~ 0.105 SOL) 的餘額才能免租。
3.2.3:Solana交易費用計算示例
•交易總費用計算:假設一筆交易請求1,000,000 CU,並設置每個CU的優先費用為10,000 MicroLamports。則交易總費用為5000 Lamports(簽名費用) + 1,000,000 CU * 10,000 MicroLamports * 0.000001 Lamports = 0.000015 SOL。當前Solana平均費用查詢[5]显示,平均費用約為0.000021 SOL,額外費用約為0.000025 SOL。以每SOL 100美元的價格計算,單筆交易費用大約為0.0021美元。
•計算單元時間限制:計算單元CU也可以取決於在Solana SVM中執行時間的定價,每33 ns的計算時間等價於1 CU。假設默認上限為200,000 CU,那麼在Solana SVM中執行200,000 CU的智能合約時間約為6.6毫秒。最大1,400,000 CU的執行時間約為46.2毫秒。
•交易費用分配:Solana網絡將所有交易費用的50%燒毀,其餘50%分配給處理交易的驗證者。
3.2.4:Solana網絡的TPS
•根據Solana的白皮書,理論上Solana每秒可以處理多達710,000筆交易。在實際場景中,Solana已經表現出超過5,000 TPS的能力,並且在測試期間達到了65,000 TPS。當前查詢[6]显示Solana的TPS約為3300。
這些設計和參數使得Solana網絡能夠高效處理大量交易,並提供靈活的費用和資源管理機制,以支持其快速發展和廣泛應用的智能合約和分佈式應用生態系統。
根據平均費用查詢,Solana的單筆交易費用為0.0021美元,遠低於ETH的0.7美元交易費。ETH的交易費用隨着網絡擁堵而上升,而Solana相對於ETH網絡,其單筆交易費用非常低,大約500筆交易的總費用才相當於1美元。
目前,Solana的TPS約為ETH網絡的250倍至500倍(ETH的tps為3000至5000的12分之一)。
總體而言,Solana相對於ETH網絡在極低的Gas費用下能夠處理大量交易。然而,Solana網絡面臨垃圾交易的風險高於ETH網絡,這對其穩定性和冗餘性構成了相當大的考驗。
前面了解並對比了ETH網絡和Solana網絡計費系統設計的細節和差異性,計費系統設計有缺陷會帶來嚴重的網絡安全風險,拒絕服務攻擊是圖靈完備的區塊鏈網絡備受困擾的網絡安全風險之一,後續將會詳細討論ETH網絡和Solana網絡面臨計費系統缺陷帶來的網絡安全風險。
ETH網絡在歷史上遭遇了兩次拒絕服務攻擊,並導致網絡性能下降或者崩潰,解決方案分別是2016年10月18日的橘子哨(Tangerine Whistle)分叉[7]和2016年11月22日的偽龍(Spurious Dragon)分叉[8]。
5.1.1:EXTCODESIZE操作碼攻擊的原因:
造成這次拒絕服務攻擊的罪魁禍首是EXTCODESIZE操作碼,由於EXTCODESIZE操作碼的Gas Price相當低,並且需要節點從磁盤讀取狀態信息,只要這些操作的Gas加起來不超過區塊的Gas Limit,每個區塊的攻擊交易可調用此操作碼大約50,000次。這一個區塊內的交易所佔用的計算時間就被大大延長,從而導致了整個以太坊網絡的癱瘓。
修復方案EIP-150[9]:通過增加EXTCODESIZE操作碼的Gas成本,從20增加到700,以此防止類似的攻擊再次發生。
5.1.2:SELFDESTRUCT 操作碼攻擊的原因:
攻擊者利用SELFDESTRUCT操作碼生成了大量空賬戶。每次SELFDESTRUCT操作會花費90 Gas生成一個空賬戶,這些賬戶需要存儲在以太坊的狀態樹中。攻擊者總共創建了約1900萬個空賬戶,導致狀態樹的存儲空間大幅膨脹,超過了實際創建賬戶所需的存儲空間,最終導致節點存儲壓力爆炸。
修復方案EIP-161[10]:EIP-161通過清除空賬戶和優化狀態樹的存儲機制,減少了存儲空間的浪費。現在創建新賬戶時需要額外支付25,000 Gas,空賬戶功能上等同於不存在的賬戶,可以通過交易與空賬戶交互來刪除它們。
5.1.3:總結:
ETH 網絡這兩次拒絕服務攻擊都利用了某些操作碼的低Gas成本,從而放大了攻擊的效果。攻擊者可以用很少的資源對網絡造成極大的負擔,暴露了區塊鏈網絡在低Gas機制下的潛在脆弱性。
ETH網絡在2016年經歷了重大的拒絕服務攻擊,成為當時的重要挑戰之一。而彼時Solana還處於創始階段,被視為潛在的“以太坊殺手”。Solana在2022年經歷了嚴峻的網絡中斷考驗(總計中斷5次),但在2023年僅有一次中斷。作為超高性能的區塊鏈網絡,Solana引入了8項關鍵創新[11],雖然帶來了技術進步,也引發了許多未知的風險。
在數次中斷事件中,2022年1月和2022年4月,Solana網絡分別因大量垃圾交易遭遇拒絕服務攻擊。
5.2.1:2022年1月 – 嚴重的網絡擁塞[12]:
由於重複交易過多導致緩存耗盡,網絡性能嚴重下降,部分節點的處理能力受限,持續了較長時間。
5.2.2:2022年4月和5月 – 短暫的中斷[13]:
2022年4月,Solana網絡中斷了2小時42分鐘,主要原因是NFT機器人大量發送垃圾郵件,導致網絡過載。同年5月,Solana再度因垃圾郵件攻擊中斷了5小時31分鐘,每秒600萬次的垃圾郵件交易使驗證器內存不足,網絡流量超出100 Gbps,最終導致主網Beta集群的共識停滯。投票不足以清理舊區塊,進一步加劇了內存使用問題,導致驗證器崩潰。
與2016年ETH網絡拒絕服務攻擊類似,Solana在幾次中斷後也通過提高Gas費用來緩解攻擊問題。特別是引入了優先級費用,允許用戶為交易支付額外費用,以確保其交易優先處理。這種機制有效增加了攻擊成本,降低了垃圾郵件攻擊的可行性。
5.2.3:總結:
無論是ETH還是Solana網絡,正確設計計費系統對於防範拒絕服務攻擊至關重要。攻擊者往往會利用Gas費用機制中的漏洞發起攻擊。雖然Solana引入了優先級費用來提高攻擊成本,但其交易成本仍然非常低,這可能意味着未來仍存在未知的攻擊面。
Solana虛擬機(SVM)在Solana區塊鏈上運行合約至關重要,因其高效的計算單元(CU)模型和快速執行速度。SVM通過精確的計費結構和優化的執行引擎,支持高吞吐量和低延遲的應用程序需求,同時保障了合約的安全性和穩定性。
Solana的合約計費模式採用精確計算單元(CU)模型。每33納秒的計算時間對應消耗1 CU,CU是衡量Solana虛擬機中資源消耗的標準單位。合約的執行成本是基於SVM中運行的字節碼所消耗的CU來計算的。
SVM的CU計算模型對於Solana生態系統至關重要。根據CertiK團隊於5月24日發布的一篇關於SVM的CU計算漏洞的研究文章,SVM的CU計算指令在某些情況下可能會出現錯誤翻譯,導致智能合約在SVM中出現無限計算消耗,嚴重時可能會導致整個Solana區塊鏈網絡的崩潰。
隨着Solana的發展,可能會引入新的功能或補丁來改變集群的行為和程序的運行方式。這些更改可以通過增加或減少syscall功能來實現。
Solana支持一種稱為運行時功能的機制,類似於熱補丁,用於在集群發生行為更改時調整程序的行為。這些更改通過syscall功能門實現,默認情況下這些功能是禁用的,除非開啟了相應的syscall功能。
syscall的計費通過為每個特定的系統調用功能分配固定的CU值來實現,這些值被定義在計算預算中。
在Solana的CU計費研究中,syscall功能的執行並不完全依賴於SVM標準模型,而是採用預估計算模型,某些情況下可能涉及第三方庫的支持。syscall的這一特性使其在功能引入時更靈活,但同時也帶來了一定的複雜性。
Solana的Gas成本限制通過CU資源限制來實現的,CU計算的錯誤會導致合約在Solana鏈上執行消耗的資源(cpu、time)嚴重超出了限制,進一步導致潛在的Solana區塊鏈上遠程DOS攻擊。
在對Solana的syscall功能研究中,結合ETH網絡和Solana歷史漏洞同時,CertiK團隊針對syscall功能的Gas成本做了深入研究,研究發現big_mod_exp syscall功能在CU成本計算存在漏洞,bits和bytes的混用,導致CU計算出問題,嚴重偏移了資源限制消耗,最終會導致Solana區塊鏈遠程DOS攻擊。
7.1.1:引入的pull提案
Solana的syscall中引入了大整數模冪運算功能,詳細見提案:add big_mod_exp syscall #28503[14]。該功能類似於EIP-198[15]中的實現。big_mod_exp的CU計算模型如下:
7.1.2:CU計算與消耗時間預期測試結果
由於該系統調用適用於使用RSA算法的程序,輸入數據最大支持2048位(支持的位數包括32、64、128、256、512、1024、2048)。CU的計算公式如下:
以2048位為例,預期輸入的執行時間為4,194,304納秒,其CU計算結果為:
注:Solana這裏最高引入了4096位的計算,對於4096位的輸入,計算時間為52毫秒,對應的CU為:
由此可以看出,big_mod_exp的CU消耗基於輸入的位長度進行計算,位數越高,CU的消耗也越大。
Solana引入#28503時,big_mod_exp功能4096 bits 的CU預算是1,575,757,而測試發現CU預算只有8043,big_mod_exp功能的CU計算出現了問題。big_mod_exp的關鍵代碼位於SyscallBigModExp
中,三個主要輸入參數為base、exponent和modulus,分別對應的長度為params.base_len
、params.exponent_len
和params.modulus_len
。需要注意的是,這些參數的單位是bytes:
big_mod_exp功能關鍵 CU計算:
從代碼中可以推導出CU的計算公式為:
對比Solana在引入#28503[16]時的原始計算公式:
這揭示了漏洞的核心問題:輸入的單位為bytes,但應轉換為bits。正確的CU計算方式應為:
以4096位輸入為例,正確的CU計算為:
在當前存在漏洞的情況下,CU預算為200,000時,調用4096位的big_mod_exp功能合約的執行時間為:
而在最大CU上限為1,400,000的情況下,單個合約的執行時間約為6.23秒。
Solana的平均出塊時間約為400ms~600ms,具體出塊時間可在Solana Explorer[17]中查看,目前約為400ms。考慮到Solana通過Proof of History(PoH)實現的共識機制及其并行事務處理能力,單個最高6.23s的合約能造成Solana集群的遠程DOS攻擊嗎?或者并行執行多個合約呢?後續將會對Solana共識機制和事務處理展開討論,結合有問題的big_mod_exp合約實現對本地Solana集群的遠程DOS攻擊。
Slot和Epoch是Solana網絡中的時間單位。Slot是最小的單位,432,000個Slot組成一個Epoch。PoH(Proof of History)通過可驗證延遲函數(VDF)生成一系列不可預測的時間序列,用於給每個Slot中生成的區塊打上時間戳。
Solana每筆交易都有時間作為交易生命周期[18]:每筆交易都包含一個“最近的區塊哈希”,用作PoH時鐘時間戳,並在該區塊哈希不再足夠“最新”時過期,在150個Slot周期內。
Solana驗證器會查找他們希望在區塊中處理的每筆交易的區塊鏈相應時隙編號。如果驗證器找不到區塊哈希的插槽號,或者查找到的插槽號比正在處理的區塊的插槽號高150個以上,交易就會被拒絕:
Solana區塊鏈的工作原理涉及以下6個基本步驟:
(1)領導者選舉與時隙分配
Solana網絡通過基於PoS的選舉機制輪流選出一個領導者(Leader)。每個領導者被分配四個連續的時間槽(Slot)來處理數據,總共持續約1.6秒(4個區塊,每個區塊400毫秒)。領導者的選舉是隨機的,概率與驗證者的權益權重成正比,選舉周期約為2-3天(即432,000個時隙)。
(2)領導者消息排序與數據流最大化
領導者使用Proof of History(PoH)生成一條可驗證的時間序列,確保了全網的讀一致性和時間的可驗證性。領導者對用戶提交的交易進行排序,確保驗證者能夠以一致的順序處理交易,從而最大化數據流的效率並保持網絡高效運行。
(3)領導者執行交易
領導者將用戶提交的交易存儲在RAM中,並在當前狀態上執行這些交易,處理諸如代幣轉移、智能合約執行等操作。交易數據在RAM中的臨時存儲提高了處理速度和吞吐量。
(4)領導者發布交易結果
領導者在執行完交易並更新狀態后,對交易集的哈希和最終狀態進行簽名,然後將這些信息發布給驗證者(也稱為複製節點),確保交易結果的不可篡改性和可驗證性。
(5)驗證者驗證交易與最終狀態
驗證者接收到領導者發布的交易和狀態簽名后,在其本地狀態副本上重複執行相同的交易,以確認最終狀態的正確性。驗證者通過應用分叉選擇規則(Fork Choice Rule)評估領導者提出的區塊,並確保其與網絡的整體一致性。
(6)共識確認
驗證者通過Gossip網絡發布其狀態簽名,作為共識算法的一部分,確保網絡達成一致。這些簽名作為投票,用於確認區塊的有效性,最終形成全網共識。
Solana驗證器中通過多線程來執行多隊列的,單個線程執行單筆隊列,其中參數NUM_THREADS和MIN_TOTAL_THREADS用於控制線程數量:
Solana事務處理是在一個多線程中進行的,通過調用process_loop[19]函數來循環處理交易事務。
在process_loop裏面[20]通過unprocessed_transaction_storage:
UnprocessedTransactionStorage循環獲取待處理的交易hash,函數process_buffered_packets將帶出來的交易hash傳遞到下層函數,最終到Solana的SVM虛擬機進行處理,receive_and_buffer_packets則循環接收待處理交易hash。
Solana處理交易的關鍵在execute_and_commit_transactions_locked[21],通過在SVM虛擬機執行指令,並檢查錯誤后,將完整的交易commit提交,返回被正確記錄的交易到上層process,調用了record_transactions記錄交易,committer.commit_transactions提交完整的事務:
正常合約完整執行過程為(SVM虛擬機執行->記錄交易->提交交易):
分析完Solana的POH共識機制和并行事務處理方式,這裏引入帶有CU計算漏洞的big_mod_exp合約,結合漏洞探究其對Solana鏈上執行合約造成的影響和原理。
當執行一次帶有4096位big_mod_exp功能的合約,在默認200,000CU上限中,執行時間890ms的可以跨越1-2個Slot,當跨越Slot將會導致record[22]失敗,是因為交易後傳入的原始Slot比當前slot慢1-2個Slot,返回PohRecorderError::MaxHeightReached錯誤:
上文我們分析了Solana的交易是存在生命周期[23]的,而其生命周期的控制是通過參數 MAX_PROCESSING_AGE,MAX_PROCESSING_AGE的值為150也就是對比是否小於150 Slot,帶有big_mod_exp漏洞的合約因為跨了Slot導致事務失敗,失敗后Solana會比較當前Slot和 MAX_PROCESSING_AGE,只要小於150 Slot,Solana會設置
retryable_transaction_indexes為0,並且返 回到process_packets填充retryable_packets,重新retry當前交易:
所以最後帶有CU計算漏洞的bid_mod_exp合約將會重複執行150次后,最後導致交易過期失敗,而 MAX_PROCESSING_AGE的檢查在chek_transaction_age[24]調用4096位的big_mod_exp功能合約:200_000 / 8043 ~= 24, time : 24 * 37 ms ~= 890 ms,而retry 150次后,整個交易將會在133,500ms,約130s后結束,長期佔用資源將會導致隊列堵塞。將會是以下過程:
本地測試準備了10-20個獨立賬戶,每個獨立賬戶調用一次帶有4096位的big_mod_exp功能的合約,都是默認200,000CU上限,同時運行多個獨立賬戶的正常合約進行對比:
私有集群測試
私有集群總計4個節點,包括Leader Node、User RPC Node、Attacker RPC Node、Node4 , User界面通過10個獨立賬戶調用正常合約執行,正常合約調用從rpc客戶端請求到返回結束平均花費740ms左右,Attacker是模擬攻擊者的界面,通過20個獨立賬戶,每個賬戶調用20次帶有4096位的big_mod_exp功能合約,以下截圖是模擬攻擊攻擊發送了20次惡意合約的場景,可以觀察到Leader Node的cpu已經是滿負荷運行, 並且User界面已沒有正常合約調用的rpc返回:
測試結果显示私有集群和本地集群在一次性處理多個(20)獨立賬戶帶有4096位的big_mod_exp功能的合約時,總計調用20次,出現了長時間高達(133s)的堵塞,反覆攻擊將會造成嚴重的DOS攻擊!
一次攻擊成本預估:帶有4096位的big_mod_exp功能的合約在本地集群運行時,由於交易過期被drop掉,Gas費後續都為0,Solana的CU計算成本類似ETH的Gas計算,通過限制合約消耗的網絡資源來防止遠程DOS攻擊,Solana 引入的預估費用計算模型存在的缺陷帶來了CU計算漏洞,導致了嚴重的資源消耗偏移,最終導致潛在的遠程DOS攻擊。
幸運的是Solana在引入syscall新功能前會經過大量測試和驗證並且包括了和外部安全研究員漏洞賞金合作的模式,確保了上線后的穩定性,這次提前發現了Solana的syscall的big_mod_exp功能存在嚴重的漏洞,維護了Solana網絡的穩定性和安全性!
Solana確認了CertiK團隊提交的大整數模冪運算(big_mod_exp)中CU計算錯誤將會導致潛在的遠程DOS攻擊,並分類為DOS攻擊漏洞,Solana開發者修復方案[25]重新計算了big_mod_exp的CU成本,通過重新基準測試模冪運算的性能,調整計算單位(CU)為 N^2/2 + 190,雖然修復不是把bytes置換成bits,但是重新計算了大整數模冪運算的CU成本最終修復了安全漏洞,根據安全公告未來可能還會優化算法以提高性能。
[1]
倫敦升級:https://ethereum.org/zh/history/#london
[2]
當前查詢:https://cn.etherscan.com/Gastracker
[3]
EIP-1559:https://eips.ethereum.org/EIPS/eip-1559
[4]
當前查詢:https://etherscan.io/
[5]
查詢:https://beta-analysis.solscan.io/public/dashboard/06d689e1-dcd7-4175-a16a-efc074ad5ce2
[6]
查詢:https://solscan.io/analytics
[7]
橘子哨(Tangerine Whistle)分叉:https://ethereum.org/zh/history/#tangerine-whistle
[8]
偽龍(Spurious Dragon)分叉:https://ethereum.org/zh/history/#spurious-dragon
[9]
EIP-150:https://eips.ethereum.org/EIPS/eip-150
[10]
EIP-161:https://eips.ethereum.org/EIPS/eip-161
[11]
8項關鍵創新:https://medium.com/Solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274
[12]
2022年1月 – 嚴重的網絡擁塞:https://twitter.com/SolanaStatus/status/1484947431796219906?s=20&t=x6Itu5Yn_8-HtapAyLBrfA
[13]
2022年4月和5月 – 短暫的中斷:https://solana.com/news/04-30-22-Solana-mainnet-beta-outage-report-mitigation
[14]
add big_mod_exp syscall #28503:https://github.com/Solana-labs/Solana/pull/28503
[15]
EIP-198:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-198.md
[16]
#28503:https://github.com/Solana-labs/Solana/pull/28503
[17]
Solana Explorer:https://explorer.solana.com/
[18]
交易生命周期:https://docs.solana.com/developing/transaction_confirmation
[19]
process_loop:https://github.com/anza-xyz/agave/blob/5263c9d61f3af060ac995956120bef11c1bbf182/core/src/banking_stage.rs#L644C8-L656C22
[20]
process_loop裏面:https://github.com/anza-xyz/agave/blob/5263c9d61f3af060ac995956120bef11c1bbf182/core/src/banking_stage.rs#L742
[21]
execute_and_commit_transactions_locked:https://github.com/anza-xyz/agave/blob/5263c9d61f3af060ac995956120bef11c1bbf182/core/src/banking_stage/consumer.rs#L569
[22]
record:https://github.com/anza-xyz/agave/blob/master/poh/src/poh_recorder.rs#L942
[23]
生命周期:https://solana.com/docs/advanced/confirmation
[24]
chek_transaction_age:https://github.com/anza-xyz/agave/blob/5263c9d61f3af060ac995956120bef11c1bbf182/runtime/src/bank.rs#L3513
[25]
修復方案:https://github.com/anza-xyz/agave/commit/eb37b21d4d5ed29d1bf40c9ca7c64509681a2a09