# MOVE言語初の燃料費設計:オンチェーン燃料費はどのように計算されるか?燃料費の計量は多くのブロックチェーンの基本概念であり、それはオンチェーン取引を実行および保存するために必要な計算および保存リソースの量の抽象的な計算を定義します。燃料費プランは、オンチェーンのすべての実行に消費されるコストを決定し、取引実行中に使用される燃料費の支出を計算するために使用されます。### プロセス効率的に実行するために、オンチェーンのプロセスは:1) 定義の原則。2) 評価フレームワークを準備して、各実行の価格を決定します；3) のためにMOVEの燃料費計量システムと安全な燃料費代数を構築する;4) 上流の燃料費フレームを導入する;5) 燃料費フレームワークにストレージ意識を持たせる;6) 燃料費計画をさらに詳細化します。###原則定義された原則は:1. 操作のコストはネットワーク上の利用可能なリソース(に直接関連するべきであり、CPU、メモリ、ネットワーク、ストレージI/O、スペースの使用など)が含まれます。技術とプロセスが改善されると、燃料費に必要なコストも低下するべきです。2. 燃料費はオンチェーンガバナンスによって設定され、シームレスに構成可能です。3. 燃料費はネットワーク内の固定リソースセットへのDoS攻撃を防ぐことができ、ネットワークの状況に応じてガバナンス提案を通じて迅速に調整する必要があるかもしれません。4. 燃料費の価格は、加速的な成長とブロックチェーンを誰もが利用できるようにするという願望を反映しています。5. 設計において良い選択を奨励する - 例えば、安全性、モジュール化、アサーションなどのイベントを優先すること。### 燃料費を計算するユーザーが取引を提出する際、彼らはトランザクション内で二つの数量を指定する必要があります:**最大燃料費数量:**燃料費単位で測定されます。これはユーザーが取引を実行するために支払う意志のある最大燃料費単位数です。**燃料費単価:**各単位の燃料費を8進数で計算し、1八進数=0.00000001 APT(=$10^{-8}$)です。これはユーザーが支払う意志のある燃料費の価格です。実行中に、取引には次の手数料がかかります:1) 固定コスト、固定ベースに大額取引の追加費用を加えたもの。2) 実行コスト、MOVE命令を実行するために使用されます。3) 読み取りコスト、永続ストレージからデータを読み取るために使用されます。4) 書き込みコスト、データを永続ストレージに書き込むために使用されます。最終的な取引手数料は、消費された燃料費の総量(を燃料費単位で計算し)に燃料費単価を掛けることで算出されます。例えば、ある取引で670個の燃料費単位が消費され、ユーザーが取引で指定した燃料費単価が1単位あたり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)**### 読む、作成する、書くステータス項へのアクセスは、次の3つのタイプのいずれかに分類されます: 読み取り、作成、または書き込み。アクセスは、上記の等式に示されているように、項目料金とバイト料金に基づいて請求されます。読み取り操作は最も一般的な操作であり、それは瞬時のリソースの不足によってのみ制限されます。したがって、読み取り料金はディスクIOPS(プロジェクト料金)と参照ハードウェア仕様の帯域幅容量に基づいて調整されます。createは状態ストレージに新しい項目を追加します。したがって、createは認証データ構造を増加させ、すべてがより高価になり、したがってコストが最も高くなります。作成費用は、ネットワークが持つ参照ディスクスペースに基づいて調整されます。したがって、項目(item_fee)とバイト(byte_fee)でディスクを満たすには、多くの燃料費が必要です。書き込み操作は、状態ストレージ内の既存の項目を更新します。したがって、書き込み操作は認証データ構造に追加のオーバーヘッドを生じさせません。しかし、既存の項目をより大きなバイトに変更することによって、ディスクが壊れる可能性があります。そのため、更新項目のバイトに対しては、作成時と同じ料金を請求します。注意が必要なのは、ストレージ関連のコストが各トランザクションごとに評価されることです：同じリソースを何度も読み書きしても、料金は一度だけ支払う必要があります。**上記の考慮に基づき、私たちは6つの燃料費パラメータを定義しました。これらは燃料費の総費用の構成要素となります。以下を参照してください:**per_item_read:IOPSに基づく補正per_byte_read:実際の帯域幅に基づいてキャリブレーションper_item_create:目標の合計プロジェクトに基づいて調整するper_byte_create:目標の総サイズに基づいて調整-各アイテムに含まれる最初の1KBper_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の概念を探求しています。
MOVE言語の推奨燃料費メカニズム：オンチェーン実行コストの正確な計算方法
MOVE言語初の燃料費設計:オンチェーン燃料費はどのように計算されるか?
燃料費の計量は多くのブロックチェーンの基本概念であり、それはオンチェーン取引を実行および保存するために必要な計算および保存リソースの量の抽象的な計算を定義します。燃料費プランは、オンチェーンのすべての実行に消費されるコストを決定し、取引実行中に使用される燃料費の支出を計算するために使用されます。
プロセス
効率的に実行するために、オンチェーンのプロセスは:
定義の原則。
評価フレームワークを準備して、各実行の価格を決定します；
のためにMOVEの燃料費計量システムと安全な燃料費代数を構築する;
上流の燃料費フレームを導入する;
燃料費フレームワークにストレージ意識を持たせる;
燃料費計画をさらに詳細化します。
###原則
定義された原則は:
操作のコストはネットワーク上の利用可能なリソース(に直接関連するべきであり、CPU、メモリ、ネットワーク、ストレージI/O、スペースの使用など)が含まれます。技術とプロセスが改善されると、燃料費に必要なコストも低下するべきです。
燃料費はオンチェーンガバナンスによって設定され、シームレスに構成可能です。
燃料費はネットワーク内の固定リソースセットへのDoS攻撃を防ぐことができ、ネットワークの状況に応じてガバナンス提案を通じて迅速に調整する必要があるかもしれません。
燃料費の価格は、加速的な成長とブロックチェーンを誰もが利用できるようにするという願望を反映しています。
設計において良い選択を奨励する - 例えば、安全性、モジュール化、アサーションなどのイベントを優先すること。
燃料費を計算する
ユーザーが取引を提出する際、彼らはトランザクション内で二つの数量を指定する必要があります:
**最大燃料費数量:**燃料費単位で測定されます。これはユーザーが取引を実行するために支払う意志のある最大燃料費単位数です。
**燃料費単価:**各単位の燃料費を8進数で計算し、1八進数=0.00000001 APT(=$10^{-8}$)です。これはユーザーが支払う意志のある燃料費の価格です。
実行中に、取引には次の手数料がかかります:
固定コスト、固定ベースに大額取引の追加費用を加えたもの。
実行コスト、MOVE命令を実行するために使用されます。
読み取りコスト、永続ストレージからデータを読み取るために使用されます。
書き込みコスト、データを永続ストレージに書き込むために使用されます。
最終的な取引手数料は、消費された燃料費の総量(を燃料費単位で計算し)に燃料費単価を掛けることで算出されます。例えば、ある取引で670個の燃料費単位が消費され、ユーザーが取引で指定した燃料費単価が1単位あたり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)
読む、作成する、書く
ステータス項へのアクセスは、次の3つのタイプのいずれかに分類されます: 読み取り、作成、または書き込み。アクセスは、上記の等式に示されているように、項目料金とバイト料金に基づいて請求されます。
読み取り操作は最も一般的な操作であり、それは瞬時のリソースの不足によってのみ制限されます。したがって、読み取り料金はディスク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の燃料費単位です。
コミュニティ参加
私たちが燃料費プランに多くの努力を注いでも、それだけではまだ不十分です。コミュニティプロジェクトとして、コミュニティメンバーは次の選択ができます:
あなたの経験に基づいて、燃料費の計画の不合理な点を見つけてください。
燃料費プランに対する懸念を述べ、コミュニティディスカッションに参加してください。
は燃料費に関連するガバナンス提案に投票します。
燃料費のコストをどのように調整しますか？
燃料費プランはオンチェーン設定として保存されますが、ガバナンス提案を通じて変更可能であり、新しい命令やネイティブ機能をシームレスに追加することができます。
燃料費プランは拡張可能なように設計されており、ガバナンス提案を通じてアップグレードできるようになっています。Move VMの継続的な改善とユーザーからのフィードバックの取り入れに伴い、燃料費のパラメータは時間の経過とともに調整可能です。
時には、燃料費の公式がオンチェーン設定を超える複雑な変更を必要とすることがあります。これらの燃料費の公式は通常Rustでコーディングされ、オンチェーン燃料費の特徴旗によって区別されます。これらの公式をアップグレードするには、新しい公式でノードソフトウェアを更新し、異なる燃料費の特徴旗で区別する必要があります。その後、ノードソフトウェアを公開し、ノードオペレーターによる大規模な採用を促進し、最後に、新しい燃料費バージョンを使用するために、ガバナンス提案を公開して承認を得る必要があります。
仕事の未来
これはMOVEの最初の実行可能な燃料費フレームワークです。これにはMOVE VMとCoreに対する大規模な変更が必要です。この作業が今後の作業への道を開くことを願っています:
1) 実行コストを削減する, 実際の燃料費モデルを持つことで、コンパイラと仮想マシンがどこで効率的であるかを示し、チームは実行コストを削減するためにその大部分を改善することができます。
2) マルチディメンショナル燃料費計算, ユーザーが実行とストレージのために個別の予算を指定できるようにします。これにより、ユーザーはコードが不十分なアプリケーションのために長時間実行されることによる高額な燃料費を支払う必要がなくなります。また、ブロックチェーン側の取引に対する最大燃料費価格をより細かく定義できるようになります;
3) 状態の肥大化を緩和する, 現在、状態セットを小さくする簡単な方法はなく、契約(またはユーザー)が明示的にアイテムを削除することを除いては。ユーザーがデータを削除するために支払うことはアービトラージの機会をもたらす可能性があり、ユーザーは安いときにストレージを作成し、高いときにそれを削除します。この課題の解決を遅らせることは、開発者がオンチェーンデータを削除する動機を弱める可能性があります。チームは、TTLが期限切れになったときに未アクセスの状態アイテムを削除するという各プロジェクトのTTLの概念を探求しています。