平行鏈上线技術：Substrate交易費率...

首頁
專家專欄
平行鏈上线技術：Substrate交易費率和Benchmark

平行鏈上线技術：Substrate交易費率和Benchmark

發表於 2022-06-23 08:22 作者：區塊鏈情報速遞pro

Substrate Transaction fees

and Benchmark

交易費用存在的意義

我們需要爲我們的區塊鏈設計手續費，是爲了激勵參與方更加有效的協作，調節資源的利用率，畢竟天下沒有免費的午餐。

Substrate 的 Fees 如何計算

使用以下參數計算交易的最終費用：

base fee：這是用戶爲交易支付的最低金額。它在運行時被聲明爲base weight，在runtime下配置
WeightToFee即可。
weight fee：與交易消耗的執行時間（輸入輸出和計算）成比例的費用。
length fee：與交易的編碼長度成比例的費用。
tip：增加事務優先級的可選提示，使其有更高的機會被包含在事務隊列中。
base_fee、weight_fee 和 length_fee 構成inclusion fee(包含費用)。inclusion fee(包含費用)是交易被包含在一個區塊中必須可用的最低費用。

使用 transaction

payment pallet

pallet-transaction-payment提供了計算 inclusion fee的基本邏輯。

這個pallet提供以下配置項：

Config::WeightToFee 將weight轉換爲基於貨幣類型的可扣除費用
Config::FeeMultiplierUpdate通過定義一個乘數來更新下一個塊的費用，基於上一個塊結束時鏈的最終狀態。（動態交易費率的配置項）
Config::OnChargeTransaction管理transaction fee的取款、退款和存款。

ps: 交易費用在交易執行之前被提取。事務執行後，可以調整事務權重以反映事務使用的實際資源。如果交易使用的資源少於預期，則更正交易費用並存入調整後的交易費用。

交易費用的公式

inclusion_fee = base_fee + length_fee + [targeted_fee_adjustment * weight_fee];

final_fee = inclusion_fee + tip;

細化之後的公式 ->

在這個公式中，targeted_fee_adjustment是一個乘數，可以根據網絡的擁塞情況調整最終費用。

base_fee其實就是ExtrinsicBaseWeight的大小轉換爲Balance的值
length_fee是交易體存儲的費用。
weight_fee通過兩個參數計算：

a.在ExtrinsicBaseWeight運行時聲明並適用於所有外部變量的。（base fee）

b.#[pallet::weight]解釋外部復雜性的注釋。

要將權重轉換爲貨幣，運行時必須定義一個WeightToFee實現轉換函數的結構體Convert.,balance>

請注意，在調用外部發件人之前，會向外部發件人收取包含費用。即使交易在執行時失敗，費用也會從發件人的余額中扣除。

基礎費用（base_fee）

是用戶爲交易支付的最低費用。它在Runtime被聲明爲base weight，其實就是ExtrinsicBaseWeight的大小轉換爲Balance的值。所以需要設計Weight轉換爲Balance的公式 -- WeightToFee，WeightToFee在pallet-transaction-payment處進行配置即可。

關於ExtrinsicBaseWeight的配置

通過runtime下frame_system::Config的BlockWeights 的base_extrinsic進行配置。

關於WeightToFee：

WeightToFee 可以理解爲一單位Weight與一單位Balance之間的映射轉換。

Code 實現

在代碼實現那塊主要是對一個 pub struct LinearWeightToFee(sp_std::marker::PhantomData); 添加WeightToFeePolynomial 宏。

只需要實現這個宏裏的 polynomial() 方法即可

polynomial()其實是在定義weight轉換爲balance的多項式。

關於 WeightToFeeCoefficient 的配置細節

這個返回的是一個多項式公式

其中 negative值是控制整體多項式是加上該多項式還是減去該多項式

negative的對應關系：

true → -

flase → +

多項式的公式如下

例如：

如果我們想實現一個1:1的WeightToFee的轉換，那這裏的配置應該是：

對應的多項式爲：

小總結：

WeightToFee只是Weight轉換成Balance的映射轉換，只需要在pallet_transaction_payment指定WeightToFee即可。

因爲交易費中涉及到weight的內容不止base fee，還有weight fee，這兩個都是把pallet_transaction_payment指定的WeightToFee作爲轉換公式。

base fee公式：

字節費用（length_fee）

length fee主要計算的是交易體大小的費用。

對於length fee的計算公式：

Length_Fee = 交易體大小 * 每字節所需費用

每字節的費用可以在runtime下pallet_transaction_payment的

TransactionByteFee做定制。

TransactionByteFee => 指定每個字節值多少Balance。

其次就是交易體的大小，但是要了解交易體的大小，首先需要了解交易體的內容構造。

關於交易體的構造：

Substrate 入門 - 交易體 -（六）

在Substrate中的交易不再稱爲Transaction，而是稱爲了Extrinsic，中文翻譯就是“外部的；外表的；外源性”，意味着被稱爲Extrinsic的概念，對於區塊鏈而言是外部的輸入。這種定義脫離了本身“交易”的範疇（更像是轉账的概念），而是在鏈的狀態的角度下，認爲交易及類似概念是一種改變狀態的外部輸入（意味着不止轉账，只要是外部的操作都是，pallet func）。

一個“外部輸入”至少會具備以下兩個條件：

發送者的證明
外部輸入的行爲

其中第一點是顯然的，只要基於公私鑰體系，就一定需要發送者對這個發送的內容進行籤名，在鏈上通過這個籤名驗證合法性，解析出發送者的公鑰識別身份。等價於互聯網中客戶端持有的token這類的。而第二點就是這個“輸入”是到鏈上幹嘛的，其相當於是用戶發送到鏈上的指令行爲。

關於鏈下如何構造這個signature，

插曲：鏈下一個交易體的構成：

交易bytes內容的構造:

pallet-func index + 發起人的Account（公鑰）+ signature(signed, signature, extra) + call

pallet-func index是通過pallet name 和 function name在metadata裏查詢得到到index

交易執行之後可以在此處

explorer下觀察到signature的信息：

call裏的內容主要由call index和參數構造而成。

至此我們獲悉了交易體的byte信息

所以對於上述的例子，相對應的字節費用爲

其實在這裏可以觀察到由於交易體的設計，可以實現在發送之前就可以計算出交易的大小從而推導出交易的手續費。

還有其他的玩法：

交易版本與鏈上版本檢查
交易存活性檢查
特殊交易的額外信息檢查

例如如果一個交易是轉账transfer，可以直接檢查發送者的余額是否足夠，不用到區塊執行階段才判定。

權重費用(weight_fee)

在有限的區塊生成時間和鏈上狀態的限制下，權重被用來定義交易產生的計算復雜度即所消耗的計算資源，以及佔據的鏈上狀態。system模塊定義了區塊的總權重（BlockWeights）。

#[pallet::weight(200_000, xx, xx, xx)]

爲了保證在網絡繁忙的情況下，依然能夠實現對區塊鏈應用有效合理的管理，Substrate引入了三種不同級別的交易類型，既 Normal、Operational 和 Mandatory 類型。

Normal類型的交易是由網絡中的普通用戶提交，

Operational類型的交易是由網絡中的管理員或者管理委員會共同觸發。

Mandatory類型的交易表示網絡中區塊交易所必須的交易信息，通常是內在的交易，由驗證人觸發。

區塊資源如長度和總權重按照一定比例在這三種類型的交易中進行分配，這一比例稱爲可用區塊比（AvailableBlockRatio）。Kusama網絡的設置爲：

10^12 weight = 1s

1000weight = 1ns

區塊的總權重：2,000,000,000,000 weight(2秒)
可用區塊比：75%，即Normal交易最多只佔用75%的區塊資源，Operational類型的交易則可以佔用100%的區塊資源，新的交易如果導致對應資源使用率超過閾值後，會被拒絕。對於Mandatory類型的交易，即使在區塊已經滿了的情況下，依然可以把交易打包進區塊內。

1、默認weight注釋

Substrate 中的所有可調度函數都必須指定權重。你可以使用注釋的方式

#[pallet::weight(xxx_xxx)] ，這個規範允許你組合包括數據庫讀/寫，權重的固定值以及基於banchmark的固定值。下面是一個基本的demo

ps: ExtrinsicBaseWeight 會自動添加到聲明的權重中，以考慮將空的外部數據簡單地包含到塊中的成本。

對數據庫訪問進行參數化

爲了使權重注釋獨立於部署的數據庫後端，它們被定義爲一個常量，然後在表示可調度執行的數據庫訪問時在‘注釋’中使用：

2、自定義weight

可以創建自定義重量計算類型，而不是使用上述默認重量注釋。此類型必須實現以下特徵：

WeighData: 確定發貨重量。
ClassifyDispatch：確定調度的類。
PaysFee：確定可調度的發件人是否支付費用。

最後，weight fee的公式：

動態調節費率

（targeted_fee_adjustment）

設置 FeeMultiplierUpdate 參數即可

細節深入—— Relay-chain transaction fees and per-block transaction limits

Token Economics - Research at W3F

區塊鏈上的交易需求通常非常不規則。一方面，在一天內的小時或一個月內的天數範圍內存在活動高峰。另一方面，有長期趨勢的交易量增長趨勢。我們需要一種機制，在考慮這些因素的情況下，隨着時間的推移自動更新交易費用。

根據供求規律，提高費用就可以減少需求，降低費用就可以促進需求。

爲了應對活動高峰，我們面臨着在快速提高交易費用或可能有很長的交易包含時間之間進行權衡——兩者都是不良影響。我們提出了兩種機制。第一種快速調節機制（Fast adjusting mechanism），可以非常迅速地調整價格，與活動的高峰和低谷同步。第二種慢速調整機制（Slow adjusting mechanism），是以長期趨勢的速度進行緩慢調整，並使用小費爲用戶提供在高峰時段控制等待時間的可能性。parity官方建議使用帶有tips的慢速調整機制。

關於動態調整機制的設置，也是在pallet_transaction_payment下進行配置。

小費（tip）

小費不是必須的的，具體數量是由交易發送者決定的，並且完全由區塊生產着獲得；

而交易費用的其他組成部分會根據一定的比例進行分配，國庫80%，區塊生產者20%。

題外話：最後的手續費去哪裏了

至此關於交易手續費的內容，就全部介紹完畢，我們也進一步了理解了各個參數的含義，這個時候我們再回頭看細化之後的公式，就能理解底層計算的計算邏輯了。

關於手續費最終計算的代碼：https://github.com/paritytech/substrate/blob/polkadot-v0.9.18/frame/transaction-payment/src/lib.rs#L505-L537

關於 Benchmark

Substrate Benchmarking Documentation

benchmark主要是用於調整weight的內容，字節費用通過配置pallet_transaction_payment的runtime即可解決。

在 Substrate 中，10^12 個weight單位 = 1 秒，或 1,000 個weight單位 = 1 納秒。

爲什么需要使用benchmark

拒絕服務 (DoS) 是分布式系統（包括區塊鏈網絡）的常見攻擊媒介。這種攻擊的一個簡單示例是用戶重復執行涉及密集計算的外部函數。爲了防止用戶向網絡發送垃圾信息，我們向用戶收取發送cal的費用。調用成本應反映系統產生的計算和存儲成本，調用越復雜，費用越高。但是，我們仍然希望鼓勵用戶使用我們的區塊鏈系統，所以我們也希望這個估算成本相對准確，這樣我們就不會向用戶收取不必要的費用。

基准測試允許开發人員向最終用戶收取適當的交易費用，以更准確地表示系統上的外部成本。設置合適的權重函數，准確反映底層計算和存儲，也是 Substrate 中重要的安全保障。

簡單的理解：weight可以手動設置，但是每台機器的性能可能不一致，可以使用benchmark做一個測試然後測算出指定機器下 weight的大致範圍。

確定機器配置

在進行benchmark之前，我們需要先確定機器的配置信息。

Benchmark的可用選項