コミュニティからのフィードバックに基づき、チームは経済性に関する提案を行っており、最終的な決定に向けてコミュニティの協力を仰いでいます
xx network MainNetの発売で明らかになった課題として、ネットワーク上で低性能なノードが稼働していることが挙げられます。
以前のネットワーク（AlphaNet、BetaNet、ProtoNet）では、こうした問題は、パフォーマンスの悪いノードを無効化することで対処していました。nPoSによって制御されているMainNetでは、これは明らかに不可能です。
MainNetの発売以来、コミュニティはこの問題について議論してきました（#MainNet-chatチャンネルに非常に丁寧なスレッドがあります）。 軋轢).罰則のスライディングスケールを含む解決策などが提案されています。全体として、既存のソリューションに手を加え、クライアント側を修正することが正しいアプローチであるというのが、チームの意見です。
現在の解決策を理解するために、経済学のいくつかの詳細を確認する必要があります。各エポック（24時間）では、一定量のコインが付与される（この決定のメカニズムは xx経済学論文) を獲得し、全ノードに分配する。 このコインのうち、特定のノードに与えられる割合は、獲得したコインの合計の割合に等しくなります。例えば、あるエポックにおいて賞の合計が50,000xxで、あるノードが10,000,000点のうち10,000点を獲得した場合、（10,000/10,000,000）×（50,000xx）=500xxを獲得します（バリデータとノミネータに分配されます）。
しかし、このポイントはどのように獲得するのでしょうか？
xx networkでは、ブロックを作ることと、cMixのラウンドを走ることの2つでポイントを獲得することができます。cMixラウンドを実行する仕組みにこそ、インセンティブの仕組みがあります。
ラウンドが終了するたびに、チーム内の5つのノードが10ポイントを獲得し、リアルタイムフェーズでラウンドが失敗すると、ノードは20ポイントを失います。この失点は、悪い行いを抑制するためのものである。あるノードが原因でラウンドが失敗した場合、なぜすべてのノードがペナルティを受けなければならないのでしょうか？
理由は2つあります。
1つ目は、BFT（Byzantine Fault Tolerance）の下では、cMixプロトコル内で誰が故障しているかを判断することができないことです。つまり、どのノードがポイントを失うべきかを証明することができないのです。
もう1つは、全体として他のノードがペナルティを受けないことである。例えば、15ノード5チームのネットワークで、1つのノードを除くすべてのノードが0%のラウンドを失敗させ、1つのノードが50%のラウンドを失敗させたとします。 十分なラウンド数が与えられれば、すべての「よい」ノードは悪いノードと等しく協力し、ポイントは合計ポイントではなく合計比率に基づいて配分されるため、すべての「よい」ノードは同じ数のxx coinを獲得し、悪いノードはペナルティを受けることになります。上記の場合、あるノードは1/3の確率で悪いノードとチームを組むことになります。このノードの故障率は50%なので、すべてのノードの故障率は合計で16.667%となります。仮に100,000ラウンドを戦い、各ノードが1/3に参加すると仮定すると、現在の経済学では10×100,000×⅓×(1-.667) = 277,778ポイントを獲得し、20×100,000×⅓×(.667) = 111,111ポイントを失い、合計166,667ポイントを獲得することになる。同じシナリオで、違反したノードは10×100,000×⅓×() = 166,667ポイントを獲得し、20×100,000×⅓×() = 333,333ポイントを失い、合計-166,667ポイントとなる。ポイントをマイナスにすることはできないので、違反したノードは0ポイントを獲得し、その結果、すべての報酬は他の14の良いノードに均等に分配されます。
この解決策はうまくいきますが、例外として、ノードがすべての収益を失うような故障率を目標にしなければなりません。非常に高い信頼性を持つシステムにしたいので、50%よりはるかに高い数値を目標にしたい。
一般に、目標とする故障率と点数の関係式は次のようになる。
ポイントサクセスが常に10であることを考えると、このようになります。
また、地域別の倍率や、失敗したラウンドからノードが回復するまでの時間、ノードのハードウェアやインターネット設定の違いによるラウンド時間への影響も考慮されていないため、これも近似値であると言えます。しかし、現時点での分析には十分です。
残る大きな問題は、適切な「目標とする故障」をどの程度にするかということです。 一般に、ノードの故障率が高く、それを満たさない場合、ポイント、つまり収益は大幅に減少するため、予想以上に高くなることがあります。
過去12時間で、リアルタイム障害率が高いのは以下の通りです。
27.22%, 3.79%, 3.58%, 1.64%, 1.19%
平均故障率0.5%（中央値0.35%）となっています。
このデータから、故障率33%の目標を5%に下げ、リアルタイム故障1件あたりの減点を190にすべきだとチームは考えています。
この問題は、今後数日間、コミュニティでの議論に委ね、12月6日の反響を踏まえて再検討したいと思います。
また、チームが取り組んでいる二次的な応急処置的な解決策もあります。経済的な解決策の究極の欠点は、時間がかかることで、xx messengerや他のxxDkのユーザーによってメッセージが積極的に落とされている場合には、あまり良いことではありません。その結果、チームは現在パフォーマンスの悪いノードオペレータのリストを公開し、xxDKユーザはオプションでそれらのノードを含むラウンドにメッセージを送信しないように選択できるようにする予定です。また、xxDKのユーザは、別途作成された他のリストにも参加することができます。
また、チーム倍率を最低性能の条件とすることも検討しており、近日中に詳細を発表する予定です。
