# MOVE言語初の燃料費設計:どのようにオンチェーン消費を計算するか燃料費の計量は多くのブロックチェーンの基本概念であり、それはオンチェーン取引を実行し、保存するために必要な計算および保存リソースの量の抽象的な計算を定義します。燃料費プランは、オンチェーンでのすべての実行に消費されるコストを特定し、取引実行中に使用される燃料費の支出を計算するために使用されます。### プロセス効果的に実行するために、オンチェーンのプロセスは:1. 原則を定義する2. 評価フレームワークを準備し、各実行の価格を決定する3. MOVEの燃料費計測システムと安全な燃料費代数を構築する4. 上流の燃料費フレームワークをインポートする5. 燃料費フレームワークにストレージ意識を持たせる6. 燃料費プランのさらなる詳細化###原則定義された原則は:1. 操作コストはネットワークの利用可能なリソース(に直接関連している必要があります。CPU、メモリ、ネットワーク、ストレージI/O、スペース使用など)。技術とプロセスの改善後、燃料費コストはそれに伴い低下する必要があります。2. 燃料費はオンチェーンガバナンスにより設定され、シームレスに構成できます。3. 燃料費はネットワークの固定資源に対するDoS攻撃を防ぐことができ、ネットワークの状況に応じてガバナンス提案を通じて迅速に調整する必要があるかもしれません。4. 燃料費の価格は、加速的な成長とブロックチェーンの普及を維持するビジョンを反映しています。5. 設計において良い選択を奨励すること、例えば、安全性、モジュール化、アサーションなどのイベントを優先すること。### 燃料費を計算するユーザーが取引を提出する際には、取引の中で2つの数量を指定する必要があります:**最大燃料費数量:** 燃料費単位で測定されます。これはユーザーが取引を実行するために支払う意思のある最大燃料費単位数です。**燃料費単価:** 各単位の燃料費を8進数で計算し、1 8進数=0.00000001 APT(=$10^{-8}$)。これはユーザーが支払う意志のある燃料費の価格です。実行中に、取引に対して次の手数料がかかります:1. 固定コスト、固定ベースに加えて大口取引の追加費用。2. 実行コスト、MOVE命令の実行に使用されます。3. 読み取りコスト、永続ストレージからデータを読み取るために使用されます。4. 書き込みコスト、データを永続ストレージに書き込むために使用されます。最終的な取引手数料は、消費された燃料費の総量に燃料費の単価を掛けて計算できます。例えば、もしある取引が670の燃料費単位を消費し、ユーザーが指定した燃料費の単価が1単位あたり100 Octaの場合、**最終的な取引手数料は670 * 100 = 67000 Octa = 0.00067 APT。**取引の実行中に燃料費が尽きた場合、送信者は最大燃料費に基づいて料金が請求され、その取引によって行われたすべての変更は元に戻されます。### 燃料費のスケジュールを立てる**1. 基本設定**燃料費プランには、取引のサイズやユーザーが取引で指定した最大燃料費量(とは異なる最大燃料費単位)を含む、個々の操作の詳細とは無関係な複数の構成要素があります。**2. 取引サイズ**大多数取引規模は千バイトのオーダーである。しかし、MOVEモジュールのリリースは簡単に数千バイトに達し、フレームワークは約100KBである。ほとんどのユーザーモジュールのサイズは一般的に4KBから40KBの間である。最初に取引規模の値を32KBに設定したが、コミュニティの反応に基づき、アプリケーション開発を簡素化するためにより多くのスペースを提供する要求があったため、取引規模を64KBに調整した。非常に大規模な取引は、ネットワーク全体の帯域幅コストを上昇させ、パフォーマンスに悪影響を及ぼす可能性があります。悪用されると、メモリプールはより大規模な取引を無視することが奨励されるため、私たちのアプローチは最大規模の取引のサイズとアクセス可能性の間でバランスを取ることです。**3. 最大燃料費単位**燃料費プランにおける最大燃料費単位は、1つの取引で実行できる操作の最大数を定義します。注意！これは、ユーザーが取引で指定した最大燃料費量とは異なります。燃料費プランの最大燃料費単位は、トランザクションが実行できる時間に直接影響します。設定が高すぎると、ブロックチェーンに対するパフォーマンスへの悪影響を引き起こす可能性があります。例えば、ユーザーが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言語初の燃料費設計:どのようにオンチェーン消費を計算するか
燃料費の計量は多くのブロックチェーンの基本概念であり、それはオンチェーン取引を実行し、保存するために必要な計算および保存リソースの量の抽象的な計算を定義します。燃料費プランは、オンチェーンでのすべての実行に消費されるコストを特定し、取引実行中に使用される燃料費の支出を計算するために使用されます。
プロセス
効果的に実行するために、オンチェーンのプロセスは:
###原則
定義された原則は:
操作コストはネットワークの利用可能なリソース(に直接関連している必要があります。CPU、メモリ、ネットワーク、ストレージI/O、スペース使用など)。技術とプロセスの改善後、燃料費コストはそれに伴い低下する必要があります。
燃料費はオンチェーンガバナンスにより設定され、シームレスに構成できます。
燃料費はネットワークの固定資源に対するDoS攻撃を防ぐことができ、ネットワークの状況に応じてガバナンス提案を通じて迅速に調整する必要があるかもしれません。
燃料費の価格は、加速的な成長とブロックチェーンの普及を維持するビジョンを反映しています。
設計において良い選択を奨励すること、例えば、安全性、モジュール化、アサーションなどのイベントを優先すること。
燃料費を計算する
ユーザーが取引を提出する際には、取引の中で2つの数量を指定する必要があります:
最大燃料費数量: 燃料費単位で測定されます。これはユーザーが取引を実行するために支払う意思のある最大燃料費単位数です。
燃料費単価: 各単位の燃料費を8進数で計算し、1 8進数=0.00000001 APT(=$10^{-8}$)。これはユーザーが支払う意志のある燃料費の価格です。
実行中に、取引に対して次の手数料がかかります:
最終的な取引手数料は、消費された燃料費の総量に燃料費の単価を掛けて計算できます。例えば、もしある取引が670の燃料費単位を消費し、ユーザーが指定した燃料費の単価が1単位あたり100 Octaの場合、最終的な取引手数料は670 * 100 = 67000 Octa = 0.00067 APT。
取引の実行中に燃料費が尽きた場合、送信者は最大燃料費に基づいて料金が請求され、その取引によって行われたすべての変更は元に戻されます。
燃料費のスケジュールを立てる
1. 基本設定
燃料費プランには、取引のサイズやユーザーが取引で指定した最大燃料費量(とは異なる最大燃料費単位)を含む、個々の操作の詳細とは無関係な複数の構成要素があります。
2. 取引サイズ
大多数取引規模は千バイトのオーダーである。しかし、MOVEモジュールのリリースは簡単に数千バイトに達し、フレームワークは約100KBである。ほとんどのユーザーモジュールのサイズは一般的に4KBから40KBの間である。最初に取引規模の値を32KBに設定したが、コミュニティの反応に基づき、アプリケーション開発を簡素化するためにより多くのスペースを提供する要求があったため、取引規模を64KBに調整した。
非常に大規模な取引は、ネットワーク全体の帯域幅コストを上昇させ、パフォーマンスに悪影響を及ぼす可能性があります。悪用されると、メモリプールはより大規模な取引を無視することが奨励されるため、私たちのアプローチは最大規模の取引のサイズとアクセス可能性の間でバランスを取ることです。
3. 最大燃料費単位
燃料費プランにおける最大燃料費単位は、1つの取引で実行できる操作の最大数を定義します。注意！これは、ユーザーが取引で指定した最大燃料費量とは異なります。
燃料費プランの最大燃料費単位は、トランザクションが実行できる時間に直接影響します。設定が高すぎると、ブロックチェーンに対するパフォーマンスへの悪影響を引き起こす可能性があります。例えば、ユーザーが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の概念を探求しています。