見出し画像

【Jaguar's Blog 12】非中央集権の理解

Symbol コミュニティ情報

この記事は2024年2月16日にNEM/Symgolのコア開発者Jaguar氏によって投稿された記事「Understanding Decentralization」をChatGPTを用いて翻訳したものです。


Symbolでは、ネットワークが攻撃に対して強靭であるためには、投票とハーベスティングが十分に分散している必要があります。この記事では、現在のネットワーク統計を見直し、ハーベスティングと投票の実際の分散度を確認します。

安全なネットワーク運用のためには、2つの重要な閾値を満たさなければならない：

  1. ブロックが強制的に巻き戻されるのを防ぐためには、ハーベスティングパワーの51%が正直である必要があります（51%攻撃）。

  2. ブロックの確定を許可するには、投票パワーの67%が正直であり、かつオンラインである必要があります（確定停滞）。

Nakamoto係数は分散度の尺度です。これは、ネットワークの機能を妨げることができる最小限の共謀エンティティの数です。Symbolネットワークのさまざまな側面に対してこれを計算することができます。

Harvesting

SymbolBlogが提供するデータを分析することで、Symbolのハーベスティングがどれだけ分散しているかを推定できます。このデータはピアノードを含まないため不完全ですが、説明の目的には十分です。この分析では、ピアノードを無視します。

まず最初に、デリゲートが存在せず、メインアカウントだけがハーベスティングできると仮定しましょう。このシナリオでは、約485M XYMがハーベスティングされています。ノードをメインアカウントの残高でソートすると、最初の50ノードが累計でハーベスティングパワーの50%以上を制御していることがわかります。

もちろん、Symbolではデリゲートされたハーベスターも可能ですので、メインとデリゲートのステークを考慮したより現実的な計算を行いましょう。このシナリオでは、約2531M XYMがハーベスティングされています。ノードを合算残高でソートすると、最初の41ノードが累計でハーベスティングパワーの50%以上を制御していることがわかります。これは前回よりもやや悪い結果です。

上記で少し簡略化を行ったことに気付いたかもしれません。私たちは各ノードが独立したエンティティであると仮定しましたが、実際にはエンティティが必ずしも単一のノードではありません。エンティティは単一の組織やインフラ提供者（例：AWS、AllNodesなど）であり、これは単一障害点であり、複数のノードに影響を与える可能性があります。

二つの人気のあるインフラ提供者、AllNodesとStirの影響を考えてみましょう。メインとデリゲートのステークを合算すると、AllNodesが約882M XYM（メイン251M XYM）、Stirが約481M XYM（メイン37M XYM）になります。これを合わせると、ハーベスティングパワーの約53%です。実際には、これらの二つの組織は基本的に協力すればネットワークを制御できる可能性があります。

Lessons

ハーベスティングパワーのほぼ80%はデリゲートされたハーベスターから派生しています。彼らがどこにデリゲートするかは、ネットワークの分散度に直接影響を与える可能性があります。多くの人が同じノードや/またはインフラプロバイダにデリゲートすると、ネットワークはより中央集権化されます。代わりに、異質なミックスのノードにデリゲートすることを選択すると、ネットワークはより分散化されます。

Voting

nodewatchのデータを分析することで、シンボルの投票がどの程度分散化されているかを推定することができます。

現在、約444M XYMが投票されています。ノードをメインアカウントの残高でソートすると、最初の5ノードが累計で投票パワーの33%以上を制御していることがわかります。

実際の状況は少し悪いです。投票可能な7つのノードがもはや投票していないため（約26M XYM）、これにより67%が削減され、したがって33%の閾値は実質的に約27%に減少しています。この低下を避けるためには、ノードが長期間停止する前に投票キーの登録を解除することが重要です。

AllNodesとStirの投票ノードを考えてみましょう。これらのノードはそれぞれAllNodesが約105M XYM、Stirが約3M XYMの投票パワーを持っています。これを合わせると、投票パワーの24%であり、削減された27%の閾値の直下にあります。最も高い投票パワーを持つノードを含めると、簡単に合算された投票パワーが閾値を上回るでしょう。

Lessons

投票ステークの量はかなり低いため、それを増やす方法を調査する必要があります。それまでの間は、計画されたダウンタイムの前に常に投票キーを登録解除することが重要です。さらに、投票パワーを単一のインフラプロバイダに集中させないよう心がけることは常に有益です。

この記事が気に入ったらサポートをしてみませんか？