リレーチェーンのトランザクション手数料とブロックごとのトランザクション制限
リソース使用量の制限
取引手数料を設定する
時間に基づいて取引手数料を調整する
財務省
要約:
前回のWeb3研究シリーズ|ポルカドットトークンエコノミクス(前編)では、以下について詳しく説明しました。
1. トークンDOTの組織構造と主な機能
副題
文章
リレーチェーンのトランザクション手数料とブロックごとのトランザクション制限
リレー チェーン トランザクションに実装したいプロパティの一部は次のとおりです。
1. 各リレー チェーン ブロックには、ブロック応答生成の遅延を避けるために、ブロック上のリクエストが、たとえ非強力なノードであっても効率的に処理されるように、一定量のリソースが与えられる必要があります。
2. リレーチェーン状態の増加率には制限があります。 2'. リレー チェーン状態の絶対サイズが制限されていれば良いでしょう。
3. 各ブロック ペアには、可用性が保証された一定数の操作と優先度の高いトランザクション (不正行為レポートなど) があります。
4. 通常、ブロックはまだ埋まっていないため、活動の急増に効率的に対処でき、封じ込め時間が短くなります。
5. 料金の変化が遅いため、特定のトランザクション TX の料金を数分以内に正確に予測できます
6. どのようなトランザクションでも、トランザクション手数料のレベルは、ブロックの作成者がブロックの実行に対して受け取る報酬よりも厳密に大きくなければなりません。そうしないと、ブロック作成者は偽のトランザクションでブロックを埋めるよう奨励されます。
7. どのようなトランザクションでも、十分に高い操作報酬がブロックプロデューサーの合意であり、その報酬はトランザクションをブロックに含めることを奨励するには十分ですが、ブロックプロデューサーがフォークを作成してブロックを盗む動機になるには十分ではありません。前のブロックのトランザクション。
実際には、これは、追加のトランザクションを含めることで知覚される限界報酬が、それを処理するための対応する限界コストよりも高いことを意味しますが、完全なブロックを生成することによる総報酬は、空のブロックを生成することによる報酬よりもそれほど大きくはありません(たとえチップがカウントされるとき)。
現在、属性 1 ~ 6 (2' を除く) を満たすことに重点を置き、属性 2' と 7 は今後の更新のために保持します。属性 2 についてもさらに分析を行う必要があります。
リレー チェーン ブロックで処理されるトランザクションの量は、制限を課すこととトランザクション手数料レベルを調整するという 2 つの方法で規制できます。上記の特性 1 ~ 3 はリソース使用量に厳格な制限を課すことで確実に満たされますが、特性 4 ~ 6 は料金を調整することで実現されます。これら 2 つの手法については、次の 2 つのサブセクションで説明します。
リソース使用量の制限
トランザクションの処理時に消費される可能性がある 4 つのリソースを特定しました。
1. 長さ: リレー チェーン ブロック内の tx のデータ サイズ (バイト単位)、
2. 時間: インポート時間 (I/O および CPU)、
3. メモリ: 必要なときに実行するメモリの量
4. 状態: 状態ストレージの増加。
一度だけ消費される他の 3 つのリソースとは異なり、状態ストレージにはネットワーク上で永続的なコストがかかることに注意してください。したがって、状態ストレージの場合は、リースまたは他のメカニズムを使用して、料金をトランザクションの実際のコストとより適切に一致させ、状態のサイズが制限されないようにすることができます。これにはさらなる検討が必要です。状態の成長に厳しい制限を課さず、代わりに料金によって制御する別のメカニズムを検討することもできますが、私たち (WEB3 財団) は、状態が極端に制御できなくなることを避けるために、強力な制限制度を追加することを好みます。起きます。
調整可能なパラメーター: 現在、ブロックを処理する際のリソース使用量に次の制限を設けることをお勧めします。これらのパラメータが渡されますが、現時点では、チャンクを処理する際のリソース使用量に次の制限を設けることをお勧めします。これらのパラメーターは、実際のデータまたはより複雑なメカニズムに基づくガバナンスを通じてさらに調整されます。
1.長さ: 5MB、
2.時間: 2秒
3.メモリ: 10GB
4. ステータス: 1MB の増加
原則として、トランザクションは、その長さ、タイプ、入力パラメータ、および現在の状態に応じて、次の 3 つのリソースを一定量消費します。ただし、簡単にするために、各トランザクション タイプの最悪の状態とその入力パラメータのバイト長のみを考慮することにしました。したがって、長さ、タイプ、パラメータの長さによってトランザクションを分類し、(最悪のシナリオに基づいて)テストを実行して、典型的なリソース使用量を確認します。
現在、ブロックが各トランザクションを順番に処理するモデルに取り組んでいます。したがって、上記のブロックのメモリ制限を確保するには、すべてのトランザクションがメモリ制限を遵守していることを確認するだけで十分です。私たちはそれがすべて確実に起こるようにします。ただし、将来的には並列処理を検討する可能性があります。
モデルをさらに単純化するために、トランザクションの占有時間と状態の増加を捉えるパラメーターとしてトランザクションの重みを定義します。具体的には、トランザクションの重みを典型的なエポックおよび状態の使用量の最大値として定義し、各重みは対応するブロック制限の一部として測定されます。次に、トランザクションのコレクションが与えられた場合、一方ではそれらの長さを合計し、他方ではそれらの重みを合計し、両方の制約が尊重される場合にのみ、それらが同じブロック内に存在することを許可します。これはリソース使用量に対する厳しい制約であり、すべてのチャンクで尊重する必要があります。
リソースの使用にさらなる制限を追加しました。当社は、「通常の」取引と、漁師によって報告される優先度の高い取引である「実行可能」取引を区別します。通常のトランザクションは、長さの合計と重みの合計が両方とも対応する制限の 75% 未満である場合にのみ、同じブロック内に収集してパッケージ化することができます。これは、各ブロックに、実行可能なトランザクション用の保証された領域 (少なくとも 25% のリソースが残っている) を確保するためです。
問題のトランザクションに対して確立された一般的なリソース使用量の詳細。長さは検査によって簡単に決定できます。時間とメモリの使用量を考慮して、リレー チェーンの最悪の状態を準備しました (このトランザクション タイプをインポートするための時間とメモリの要件は最大の状態にする必要があります)。特定のトランザクション タイプについて、10,000 個のトランザクションを生成するのに最も長いインポート時間がかかる状態を使用し、Wasm 環境でのリソース使用量の平均と標準偏差を測定します。標準偏差が平均の 10% より大きい場合、サンプル空間を 10k より大きくします。最後に、最悪のケースのトランザクションの大規模なサンプルと照合して状態を改善します。
取引手数料を設定する
上記のモデルに従って、取引タイプ、取引時間の長さ、重みの 3 つのパラメータに基づいて取引手数料を設定します (パラメータは上ですでに定義されています)。この手数料の差は、各取引で発生するリソースコストの差を反映するために使用され、これに基づいて、特定の取引市場の行動が決定され、奨励または抑制されます。
前述したように、包括性を促進するためにトランザクション手数料の一部はブロックプロデューサーに支払われる必要がありますが、すべてではないため、ブロックプロデューサーは偽のトランザクションでブロックを埋めないようにする必要があります。話を簡単にするために、私たちは当初、各取引手数料の 20% をブロック作成者に、残りの 80% を国庫に与えることを提案しました。燃焼にはより小さい値を設定することも可能ですが、インフレ率をより適切に制御するために設定しないことを選択します。将来的には、ブロックプロデューサーが手数料を調整せずに特定のトランザクションタイプを含めることを奨励するために、この割合を調整し、トランザクションタイプに固有にすることができます。
取引手数料の計算式は次のとおりです。
では、ネットワーク トラフィックに応じて時間の経過とともに変化する、トランザクションに依存しないパラメータです。このパラメータについては、次のセクションで説明します。パラメータ
取引の種類にのみ依存します。特にビジネス取引の場合、現在、
ゼロに設定します。
直感的には、ブロックプロデューサーの処理コストをカバーし、
,
ブロック内のトランザクションを処理する場合と、ブロック内の別のトランザクションを処理する場合の機会費用をカバーします。
時間に基づいて取引手数料を調整する
ブロックチェーンでは、トランザクション需要は非常に不規則であることがよくあります。一方で、取引の活動のピークは 1 日の時間帯または月の数日間にあります。一方で、長期的な傾向も見られます。これらの要素を念頭に置いて、取引手数料を時間の経過とともに自動的に更新するメカニズムが必要です。需要と供給の法則によれば、料金を上げると需要は減り、その逆も同様です。
アクティビティの急増に対処するには、取引手数料の急速な増加や取引処理時間の延長の可能性とのバランスを取る必要がありますが、どちらも悪影響です。私たちは 2 つのメカニズムを提案します。 1 つ目は、活動の山と谷と同じペースで非常に迅速に価格を調整します。 2 つ目は、長期的な傾向に応じてゆっくりと調整し、ピーク時の待ち時間をユーザーが制御できるようにヒントを使用することです。ヒント付きの低速調整メカニズムを使用することをお勧めしますが、両方のメカニズムの整合性に関する詳細を提供します。
価格を迅速に調整する
このメカニズムでは、取引手数料は時間の経過とともに大きく異なりますが、すべてのユーザーのブロックごとに固定されています (チップはありません)。
ブロックで許可されるすべてのトランザクションの長さと重みの合計に厳しい制限を設けたことを思い出してください。また、2 番目のハード制限も設定しました。今回は、「通常の」トランザクション (非運用トランザクション) の長さと重みの合計で、最初の制限の 75% に相当します。
定義: ブロックの飽和レベル (通常のトランザクションに対する) を 0 から 1 までの 10 進数 s として定義します。これは、通常のトランザクションの限界が飽和からどの程度離れているかを示します。具体的には、ブロック B の彩度は です。
通常の長さの範囲内では、通常のトランザクションのブロック長制限は全長制限の 75%、通常の重み制限は総重み制限の 75% です。
調整可能なパラメータ: s* をターゲット ブロックの飽和度とします。これは、予想されるブロック飽和レベルの (通常のトランザクションと比較した) 長期平均です。私たちは当初、ブロックが平均 25% 使用され、システムが通常のトランザクションの平均数の最大 4 倍のバースト スパイクを処理できるように、s* = 0.25 を提案しました。調整は、観察された取引量とピーク時の平均取引量に基づいて行うことができ、通常、ピーク時の平均手数料の高さと取引の取り込み時間の延長の間にはトレードオフがあります。
取引手数料は次のように計算されることを思い出してください。
非トランザクション型。 s を現在のブロックの彩度とします。 s > s∗ の場合、流量をわずかに増加させます。
調整可能なパラメータ: v を取引手数料の変動係数とし、取引手数料の調整速度を制御します。私達はしますブロックから次のように更新します。
、これには次のプロパティがあります。
v の値が小さいと仮定すると、パラメータは
の相対変化は差 (ss∗) にほぼ比例します。つまり、
一定期間にわたって生成されたブロックが k 個あり、平均飽和度が
、その後、
パラメータの相対的な変化は、差の k 倍 (平均 - s*) にほぼ比例します。
変動係数 v はどうやって選ぶのですか?たとえその期間中に 100% の飽和があったとしても、k ブロックの期間にわたって料金が一部 p を超えて変化しないようにしたいとします。式が得られます
一定期間にわたって生成されたブロックが k 個あり、平均飽和度が
、その後、
パラメータの相対的な変化は、差の k 倍 (平均 - s*) にほぼ比例します。
変動係数 v はどうやって選ぶのですか?たとえその期間中に 100% の飽和があったとしても、k ブロックの期間にわたって料金が一部 p を超えて変化しないようにしたいとします。式が得られます
たとえば、ピーク時に特定のトランザクションが最大 k = 20 ブロック待機する必要があることが検出され、この期間中に手数料が 5% (p = 0.05) 増加した場合、これはユーザーにとって不公平であると考えられます。 s* = 0.25 の場合、上記の式は次のようになります。
このメカニズムの下では、手数料は短期的にはほぼ一定のままであり、長期的な傾向にのみ適応します。ピーク時には包含時間が長くなる可能性があり、包含を優先する市場を構築するための貿易包含のヒントを可能にするという事実を受け入れる必要があります。
上記と同じ式を使用して、各ブロックの取引手数料を更新します。
より小さい変動係数 v を選択しない限り。たとえば、料金を 1 日あたり最大 30% 変化させ、1 日に約 k = 14000 ブロックが生成されるとします。 s ∗ = 0.25 の場合、次のようになります。
取引手数料は基本価格とみなされます。トランザクションには「チップ」と呼ばれる別のフィールドがあり、ユーザーはそこに任意の量のトークンを自由に入れるか、ゼロのままにすることができます。ブロックプロデューサーは標準の 20% 手数料に加えて 100% のチップを受け取るため、多額のチップで取引をポケットに入れるインセンティブが得られます。この場合、市場の状況や取引規模に基づいてヒントに関するアドバイスをユーザーにリアルタイムで提供できるソフトウェアが必要です。ただし、ほとんどの場合、プロンプトは表示されません。
財務省
このシステムは、私たちが財務省と呼ぶ資金を継続的に調達する必要があります。これらの資金は、ソフトウェアのアップデートを提供し、住民投票で決定された変更を適用し、パラメータを調整し、通常はシステムをスムーズに実行し続ける開発者に支払うために使用されます。
財務資金は 2 つの方法で調達されます。
新しいトークンを鋳造することによって、しかしインフレを引き起こす
取引手数料を削除し、そうでなければ燃焼するように設定されていたトークンを大幅に削減することによって。
注目すべきことに、これらの資金調達方法は、通貨を鋳造し、税金や罰金でインフレを制御するという、政府が資金を調達する伝統的な方法を模倣しています。
新しいトークンを鋳造するだけで資金を調達することもできますが、取引手数料やスラッシュからトークンを財務省にリダイレクトするのが理にかなっていると考えます。そうしなければ財務省は破棄されてしまいます。
これにより、実際のステーク バーンの量が減り、インフレ率をより適切に制御できるようになります (ステーク バーンはデフレであり、バーンを引き起こすイベントを制御したり予測したりすることはできないことに注意してください)。
多額の賭け金の削減をもたらすイベントの後、コードにバグがある場合や酌量すべき事情がある場合には、多くの場合、削減された賭け金の一部を返済することが望まれます。したがって、DOT を最初に燃やしてから鋳造するよりも、国庫で DOT を使用する方が合理的です。
不正行為や取引手数料により大量のステークが燃えている期間があったとします。この事実は、システムに問題があり、修正する必要があることを示しています。したがって、今はまさに、開発費や問題解決のためにより多くの財政資金が必要な時期なのです。
編集/こっそり Zhiyao
オリジナル/WEB3基盤
