xxネットワークの経済的調整–リアルタイムの障害の控除

電卓を持っている人

コミュニティのフィードバックに基づいて、チームは経済学の提案を行い、最終決定に役立つコミュニティを探しています

xxネットワークMainNetの立ち上げで明らかになった問題は、ネットワーク上で実行されているパフォーマンスの低いノードがいくつかあることです。

ネットワークの以前の化身(AlphaNet、BetaNet、およびProtoNet)では、これらの問題は、パフォーマンスの低いノードを無効にするだけでチームによって処理されていました。これは、nPoSによって制御されているMainNetでは明らかに不可能です。  

MainNetの立ち上げ以来、コミュニティはこの問題について話し合っています(#MainNetの非常に思慮深いスレッドを見つけることができます-のチャットチャネル 不和)。とりわけ、ペナルティのスライディングスケールを含むソリューションが提案されています。全体として、クライアント側の変更とともに、既存のソリューションを微調整することが正しいアプローチであるというのがチームの意見です。

現在の解決策を理解するには、経済学の詳細を確認する必要があります。各エポック(24時間)で、一定量のコインが授与されます(この決定のメカニズムは、 xx経済学論文)そしてすべてのノードに分散されます。特定のノードに授与されるこれらのコインの部分は、獲得したコインの合計のそれらの部分に等しくなります。たとえば、エポックアワードの合計が50,000xxで、特定のノードが合計10,000,000のうち10,000ポイントを獲得した場合、それらは(10,000 / 10,000,000)×(50,000xx)= 500xx(バリデーターとノミネーターの間で分割されます)を取得します。 。

しかし、これらのポイントはどのように獲得されますか?

ポイントは、xxネットワーク内の2つのことで獲得されます。ブロックの作成とcMixラウンドの実行です。インセンティブスキームが存在するのは、cMixラウンドを実行するためのメカニズムの範囲内です。

ラウンドが完了するたびに、チーム内の5つのノードすべてが10ポイントを獲得しますが、リアルタイムフェーズ中にラウンドが失敗すると、ノードは20ポイントを失います。このポイントの喪失は、悪い行動をやめさせることです。最初、これは非常に不公平に思えます。1つのノードが原因でラウンドが失敗した場合、なぜすべてのノードにペナルティが課せられるのでしょうか。

2つの理由があります:

1つ目は、BFT(ビザンチンフォールトトレランス)では、cMixプロトコル内で誰がフォールトしているのかを判断できないことです。これは、どのノードがポイントを失うべきかを証明することができないことを意味します。

The second is that in the aggregate, other nodes are not penalized. For example, imagine a network with 15 nodes and 5 node teams where all nodes except for one cause 0% of rounds to fail, with one failing 50%.  What will happen is that given enough rounds, all good nodes will work with the bad node equally and because points are distributed based upon the total ratio of points, not total points, all “good” nodes will get the same number of xx coins, while the bad node will be penalized. In the above case, a node will be in a team with the bad node 1/3rd of the time. It has a 50% failure rate, so all nodes will have an aggregate 16.667% failure rate. Assuming 100,000 rounds, and each participates in 1/3rd, that means that with the current economics, they will earn 10×100,000×⅓×(1-%16.667) =  277,778 points, and lose 20×100,000×⅓×(%16.667) = 111,111 points, making a total of 166,667 points. While in the same scenario, the offending node will earn 10×100,000×⅓×(%50) = 166,667 and lose 20×100,000×⅓×(%50) = 333,333 points, making a total of -166,667. Points cannot go negative, so the offending nodes get 0 points, and as a result all rewards are split between the other 14 good nodes evenly – as if the offending node was never there.

このソリューションは、ノードがすべての収益を失うはずの障害率をターゲットにする必要があることを除いて、機能します。非常に高い信頼性を備えたシステムが必要なことを考えると、50%よりもはるかに高い数をターゲットにする必要があります。

一般的に、目標故障率とポイントに関する式は次のとおりです。

ポイントの成功は常に10であるとすると、これにより次のことがわかります。

これは、地域の乗数、ノードが失敗したラウンドから回復するのにかかる時間、または異なるノードのハードウェアとインターネット構成がラウンド時間にどのように影響するかを考慮していないため、概算でもあります。ただし、現時点での分析には十分です。

残っている大きな問題は、適切な「ターゲットを絞った障害」とは何かということです。一般に、ノードの故障率が高く、それを満たさない場合でも、ポイント、つまり収益が大幅に低下するため、予想よりも高くなる可能性があります。

過去12時間で、リアルタイムの故障率が最も高かったのは次のとおりです。

27.22%, 3.79%, 3.58%, 1.64%, 1.19%

平均故障率は0.5%(中央値0.35%)です。 

このデータを考慮すると、チームは、33%の故障率の目標から5%に下げる必要があると考えています。これにより、リアルタイムの故障ごとのポイント控除が190になります。  

今後数日間、この問題をコミュニティで議論できるように公開したいと思います。再検討は、2021年12月6日の回答に基づいています。

チームが取り組んでいる二次的な一時的な解決策もあります。経済的な解決策の究極の欠点は、時間がかかる可能性があることです。これは、メッセージがxxメッセンジャーやxxDkの他のユーザーによって積極的にドロップされている場合には大きくありません。その結果、チームは、xxDKユーザーがオプションでそれらのノードを含むラウンドでメッセージを送信しないことを選択できる、現在パフォーマンスの低いノードオペレーターのリストを公開します。 xxDKユーザーが他の個別にキュレーションされたリストにオプトインすることも可能になります。

チームはまた、チームの乗数を最小のパフォーマンスに依存させることを検討しており、詳細は近日公開されます。

人気