MOVE語言首個燃料費設計:鏈上燃料費如何計算?

燃料費計量是許多區塊鏈的基本概念,它定義了執行和存儲鏈上交易所需的計算和存儲資源量的抽象計算。燃料費計劃將鏈上所有執行所消耗的成本確定,用於計算執行交易期間使用的燃料費花費。

流程

爲了有效執行,鏈上的流程是:

1. 定義原則;

2. 準備評估框架,以確定每個執行的價格;

3. 爲Move建立燃料費計量系統和安全燃料費代數;

4. 將上遊燃料費框架導入;

5. 使燃料費框架具有存儲意識;

6. 進一步細化燃料費計劃。

原則

定義的原則是:

1. 操作的成本應與網路上的可用資源直接相關(如CPU、內存、網路、存儲I/O和空間使用等)。當技術和流程改進後,燃料費所需的成本應隨之降低。

2. 燃料費應由鏈上治理設置,並可無縫配置。

3. 燃料費可防止對網路中固定資源集的DoS攻擊,可能需要根據網路情況通過治理建議迅速調整。

4. 燃料費價格反映了加速增長和保持區塊鏈人人可及的願望。

5. 鼓勵在設計中做出好的選擇 - 例如優先考慮安全性、模塊化、斷言等事件。

計算燃料費

當用戶提交交易時,他們還必須在事務中指定兩個數量:

**最大燃料費數量:**以燃料費單位計量。這是用戶願意爲執行交易花費的最大燃料費單位數。

**燃料費單價:**以每單位燃料費的八進制計算,其中1八進制=0.00000001 APT(=$10^{-8}$)。這是用戶願意支付的燃料費價格。

在執行過程中,交易將被收取:

1. 固定成本,固定基數加上大額交易的額外費用。

2. 執行成本,用於執行Move指令。

3. 讀取成本,用於從持久存儲讀取數據。

4. 寫入成本,用於將數據寫入持久存儲。

最終的交易費用可以用消耗的燃料費總量(以燃料費單位計算)乘以燃料費單價來計算。例如,如果一筆交易消耗670個燃料費單位,而用戶在交易中指定的燃料費單價爲每單位100 Octa,那麼最終的交易費用爲670 * 100 = 67000 Octa = 0.00067 APT。

如果一個交易在執行過程中耗盡了燃料費,那麼發送方將根據最大燃料費量收取費用,並且該交易所做的所有更改都將被恢復。

建立燃料費計劃表

1. 基本配置

燃料費計劃中有幾個組成部分與單個操作的細節無關,包括交易大小和最大燃料費單位(不同於用戶在交易中指定的最大燃料費量)。

2. 交易規模

對於大多數交易,交易規模可能在千字節的數量級。然而,Move模塊的發布很容易就有幾千字節,而框架大約有100 KB。大多數用戶模塊的大小一般在4KB到40KB之間。最初,我們將交易規模的值設置爲32KB,但根據社區的反應,要求提供更多空間以簡化應用程序開發,因此我們將交易規模調整爲64KB。

非常大規模的交易會導致整個網路的帶寬成本提高,並可能對性能產生負面影響。如果被濫用,內存池會被鼓勵忽略規模更大的交易,因此我們的方法是在最大規模交易的大小和可訪問性之間取得平衡。

3. 最大燃料費單位

燃料費計劃中的的最大燃料費單位定義了一個交易最多可以執行多少操作。注意!這不同於用戶在交易中指定的最大燃料費量。

燃料費計劃的最大燃料費單位直接影響到一個交易可以執行多長時間,將其設置過高可能會導致對區塊鏈產生負面性能影響交易。例如,用戶可能忘記在while循環中有一個增量,從而導致無限循環,這是一個常見錯誤。我們發現,即使我們進行了最大的框架升級,我們仍然不到燃料費計劃的最大燃料費單位(設定爲1,000,000)的90%。

4. 執行

爲了評估執行成本,我們構建了一個基準框架,並在執行該框架時使用Valgrind來分析Move VM。它的輸出是一組帶注釋的原始碼,它告訴我們每行代碼產生了多少機器指令。

在上述分析的幫助下,我們粗略估計了所有Move指令和本機函數的相對成本。然而,我們注意到這個方法與內聯函數存在一些問題:它們不會自動包含在調用者的計數中。我們還看到,這只發生在我們分析某些Move指令時,我們可以通過將數字相加來解決這個問題。

隨後,通過考慮增強系統穩健性和安全性的編碼範例,團隊得出了最終執行的機器指令數量。這個數字依次與存儲和最大燃料費單位進行權衡,以確定它們在燃料費計劃中的當前值。

5. 存儲

每當訪問存儲在持久存儲中的帳本狀態項或數據時,節點都會向存儲設備發出讀取或寫入。每秒的數據訪問總數取決於存儲設備的帶寬和IOPS容量。與燃料費調度計算部分的CPU週期類似,數據訪問是區塊鏈用戶在系統負載時通過費用市場競爭的瞬時稀缺性,此外,寫入數據的磁盤佔用成本在鏈上是永久的。團隊通過考慮這些成本來設計存儲燃料費計劃。

訪問和存儲任何狀態項都會產生與驗證整個區塊鏈狀態的數據結構水母默克爾樹相關的成本。此成本與不同狀態項的基數有關($2^{256}$)。還有一個成本與每個項目的大小成正比。要對一個狀態項進行操作,費用爲(下一節中描述的例外情況除外):

存儲燃料費 = item_fee + (byte_fee * bytes)

讀、創建和寫

對狀態項的任何訪問都屬於以下三種類型之一:讀、創建或寫。訪問按項目費和字節費收費,如上面的等式所示。

讀操作是最常見的操作,它只受瞬時資源稀缺的限制。因此,讀取費用是根據磁盤IOPS(項目費用)和參考硬件規範的帶寬容量進行校準的。

create是在狀態存儲中添加一個新項。因此,create增加了身分驗證數據結構,使一切都變得更昂貴,因此成本最高。創建費用是根據網路擁有的參考磁盤空間進行校準的。因此,用項目(item_fee)和字節(byte_fee)填滿磁盤需要大量的燃料費。

寫操作更新狀態存儲中的現有項。因此,寫操作不會在身分驗證數據結構中產生額外的開銷。然而,通過修改現有的條目到更大的字節,仍然可以破壞磁盤。因此,我們對更新項中的字節收取與創建時相同的費用。

應該注意的是,與存儲相關的成本是基於每一筆交易進行評估的:即使您多次讀取/寫入相同的資源,也只需要支付一次費用。

基於上述考慮,我們定義了6個燃料費參數,它們構成了燃料費總費用的組成部分。見以下:

per_item_read:根據IOPs進行校正

per_byte_read:根據實際帶寬校準

per_item_create:根據目標總項目進行校準

per_byte_create:根據目標總大小進行校準-每個項目包含的第一個1KB

per_item_write:與per_item_read相同

per_byte_write:與per_byte_create相同

穩定的燃料費單位成本

無論以APT或法定貨幣的市場價值計算執行操作的成本如何,每個操作和交易本身都需要相對於存儲和執行成本的固定單位成本。固定的燃料費單位成本有助於保持燃料費計劃不變,並與APT的自由市場價值脫鉤。此外,正確選擇燃料費單位的精確位數有助於保持燃料費計劃不變。考慮到這一點,團隊以大約3位數的精度來表示燃料費單位。因此,轉帳交易的成本大約是700個燃料費單位。

社區參與

即使我們對燃料費計劃投入了大量的精力,但是它還遠遠不夠完善。作爲一個社區項目,社區成員可以選擇:

1. 根據你的經驗,找出燃料費計劃不合理的地方;

2. 說出你對燃料費計劃的擔憂,並參與社區討論。

3. 就與燃料費相關的治理提案進行投票。

如何調整燃料費成本?

燃料費計劃作爲鏈上配置被存儲,但是可以通過治理提案進行更改,並且可以無縫添加新指令或原生功能。

燃料費計劃被設計爲可擴展的,允許通過治理提案對其進行升級。隨着不斷改進Move VM並納入用戶反饋,燃料費參數可以隨着時間的推移進行調整。

有時,燃料費公式可能需要超出鏈上配置的復雜更改。這些燃料費公式通常用Rust編碼,並通過鏈上燃料費特徵標志來區分。要升級這些公式,必須使用新公式更新節點軟件,並以不同的燃料費特徵標志進行區分。然後必須發布節點軟件並爲節點運營商大量採用,最後,必須發布並批準治理提案才能使用新的燃料費版本。

未來的工作

這是Move的第一個可行的燃料費框架。它需要對Move VM和Core進行大量修改。我們希望這項工作爲今後的工作鋪平道路:

1) 降低執行成本,擁有一個真實的燃料費模型表明編譯器和虛擬機在哪裏有效率,團隊可以改進其中的大部分以降低執行成本。

2) 多維燃料費計算,允許用戶爲執行和存儲指定單獨的預算。這樣,用戶就不必爲因爲代碼編寫不佳的應用程序花費過長的執行時間,支付高昂的燃料費價格。它還將允許對區塊鏈端交易的最大燃料費價格進行更細粒度的定義;

3) 緩解臃腫狀態,目前沒有簡單的方法來縮小狀態集,除了合約(或用戶)顯式刪除事物。用戶付錢刪除數據可能會帶來套利機會,用戶在便宜的時候創建存儲,在昂貴的時候刪除它。推遲了解決這一挑戰,這可能會削弱開發人員刪除鏈上數據的動力。團隊正在探索每個項目TTL的概念,該概念將在TTL到期時刪除未訪問的狀態項目。