XODE ステーキング
Xode コンセンサス
Polkadot はハイブリッドコンセンサスモデルを採用しています。この方式では、ブロックのファイナリティガジェットとブロック生成メカニズムが分離されています。そのため、パラチェーンはブロックの生成に専念し、状態遷移の検証はリレーチェーンに任せることができます。
Xode Blockchain はパラチェーンとして、次の課題をトラストレスかつ分散型の方法で解決する必要があります。
- どのノードがブロックの作成を許可されるのか？
- 複数のノードがブロックの作成を許可されている場合、任意の時点で作成者は 1 つだけであるべきなので、特定の時点でどのノードが作成を許可されるのか？
そこで登場するのが Xode コンセンサスです。Xode コンセンサスは、Cumulus ベースのパラチェーン上でスロットベースのコンセンサスアルゴリズムを構築するためのフレームワークです。このようなコンセンサスエンジンの運用面について標準的な実装を提供するとともに、研究者や開発者がカスタマイズしたい要素（フィルター）を実装するための便利なトレイトを提供することを目指しています。これらのフィルターは、ブロック作成スロットの定義をカスタマイズでき、組み合わせることも可能なため、複数の段階を経てブロック作成をコレーターのサブセットに限定できます。
Xode Blockchain では、2 層のフィルター方式を採用します。
- ステーキング：第 1 層はパラチェーンのステーキングフィルターで構成されており、ステーク量に基づくランキングを用いて、すべてのコレーター候補の中からアクティブなコレータープールを選出します。
- 割り当て：第 2 層では別のフィルターを追加し、スロットごとにコレーターの数をサブセットに絞り込みます。
Xode コンセンサスが答えられるのは、次に利用可能なスロットでパラチェーンブロックを生成する資格があるのはどのコレーターかという点のみです。このパラチェーンブロックをベストとしてマークするのは Cumulus のコンセンサスメカニズムであり、最終的にこのパラチェーンブロックをリレーチェーンに取り込んでファイナライズするのは、（リレーチェーンの）BABE と GRANDPA のハイブリッドコンセンサスモデルです。リレーチェーンのフォークがリレーチェーンレベルで解決されると、そのパラチェーンブロックは決定論的にファイナライズされます。
ステーキング
コレーターは、エクストリンシックを介して一定量の XON をボンドするだけで候補者プールに参加できます。プールに参加すると、XON 保有者はデリゲーション（ステーキングとも呼ばれます）によって候補者のステークに追加できます。
Nimbus は、候補者自身のボンドと XON 保有者からのデリゲーションを含む、ネットワーク上でステークされた XON の量が上位 36 の候補者を選出します。このフィルタリングされたプールは「選出候補者」と呼ばれ、選出候補者はラウンド（1,200 ブロック続きます）ごとに更新されます。
割り当て
Aura プロトコル（PoA）は、Xode Blockchain のブロック生成メカニズムにおいて重要な役割を果たします。具体的には、Nimbus によって生成された候補者リストに対して、Xode Blockchain は Polkadot の標準 Aura プロトコルを採用し、ブロック作成の役割を割り当てます。この構成では、各タイムスロットのブロック作成者は、決定論的かつラウンドロビン方式で決定されます。
つまり、Xode のコレーターセットに含まれる 36 の候補者すべてが固定された順序で並べられ、各タイムスロットはリスト内の次のコレーターに割り当てられます。ラウンドロビン方式により、すべてのコレーターがブロックを生成する機会を平等かつ予測可能な形で得られます。最後のコレーターがブロックを生成すると、順序は最初のコレーターから再開されます。
Aura を活用することで、Xode Blockchain は Polkadot のコンセンサス設計との互換性を保ちながら、ブロック生成における公平性、効率性、予測可能性を確保します。また、このプロトコルでは特定のスロットに割り当てられたコレーターのみがブロックの作成を許可されるため、ブロック生成の競合リスクが最小限に抑えられ、ブロックチェーンの安定性と継続性が確保されます。
不可侵候補者（Invulnerable Candidates）
Xode Blockchain のコンセンサスにおける不可侵候補者とは、ネットワークの運用に不可欠なものとして指定された特定のコレーターノードを指します。これらのノードは、コンセンサスの維持において特別な役割を持ち、特定の条件下でスラッシュや強制的な削除から保護されているため、「不可侵（invulnerable）」とされています。詳細は次のとおりです。
ネットワーク運用に不可欠：
- これらのコレーターは Xode Blockchain にあらかじめ設定されています。
- ネットワークの初期段階やテストネットの運用時に、安定性と信頼性を確保するうえで重要です。
スラッシュされない：
- 他の候補者とは異なり、不可侵ノードは、誤った動作（例：オフラインになる、二重署名を行う）をした場合でも、スラッシュなどのペナルティを受けません。
- この保護により、ネットワークが重要なコレーターノードを失わないことが保証されます。
Nimbus による候補者選出への組み込み：
- 不可侵ノードは、通常の Nimbus による候補者選出プロセスの対象外です。
- これらはアクティブなバリデーターセットに自動的に含まれます。
Xaver 不可侵ノード
Xaver ノードは Xode Blockchain において指定された不可侵ノードであり、ネットワークの安定性と信頼性を確保するうえで極めて重要な役割を果たします。専用アプライアンスにインストールされたライトクライアントで構成されており、効率的かつ軽量な形でネットワークに参加できます。不可侵ノードである Xaver はスラッシュの対象とならず、標準的なコレーター候補の選出プロセスを経由しないため、継続的な稼働が保証されます。この設計により、利用可能なコレーターが減少した場合やネットワーク障害が発生した場合でも、Xaver ノードはブロック生成を維持でき、停止の可能性を防ぎます。また、クライアント構成の軽量性を活かすことで、Xaver ノードはリソース効率を高めると同時に、Xode ネットワークにおけるトラストレスで分散型の運用を支える基盤として機能します。
ステーキングプロセス
ステーキングプロセスは、ノードがネットワークに参加するために不可欠なノードキーの生成とセッションキーの設定から始まります。ノードが有効なセッションキーを持っていることを確認した後、ノードを登録して、ブロック作成とステーキング活動への参加を開始します。登録後は、ノードをさまざまな方法で管理できます。一時的にオフラインにする、再びオンラインに戻す、必要に応じてネットワークから完全に削除する、といった操作が可能です。
ノードが登録されてアクティブになった後、作成プロセスに参加するにはボンドが必要です。ノードがセッション中にブロックを作成した場合、そのノードはアクティブのまま参加を続けます。しかし、ノードがセッション中にブロックを作成できなかった場合は、スラッシュされて自動的にオフラインに設定され、今後のセッションに参加する機会が減少します。この仕組みにより、アクティブで信頼性の高いノードのみがネットワークに残ることが保証されます。
さらに、ノードオペレーターはコミッション率を設定できます。コミッション率は、ノードとそのステーカー（デリゲーター）の間で報酬をどのように分配するかを決定します。ステーカーは XON トークンをノードにデリゲートすることで、ステーク量に応じた報酬を獲得できます。報酬は、ノードのコミッションを差し引いた後に付与されます。ステーカーが参加内容を変更したい場合は、XON トークンをアンステークしてデリゲーションを解除し、トークンを取り戻すことができます。このプロセスにより、アクティブなノードと参加者が継続的に報酬を得られる、動的で安全なステーキングシステムが維持されます。
作成プロセス
ノードを登録して一定量をボンドすると、自動的に Waiting ステータスが割り当てられます。次のセッションで、Waiting ステータスかつ有効なセッションキーを持つノードが Aura バリデーターキューに追加されます。これらのノードは、その次のセッションからブロックを作成する資格を得ます。ただし、キューに入ったバリデーターのうち、2 セッション経過後もブロック作成を開始していないものは、現在のセッションのブロック作成に参加しません。この段階的なプロセスにより、適切に構成されたアクティブなノードのみがブロック生成に貢献することが保証されます。
ノードがブロックの作成に成功すると、報酬はトレジャリー、作成者、ステーカーに分配されます。具体的には、報酬の 20% がトレジャリーに、残りの 80% が作成者とステーカーの間で分配されます。ステーカーは総ステーク量に対する自身のステーク量の比率に基づいて報酬を受け取り、作成者は、作成者のコミッションからステーカーへの報酬が差し引かれた後の残額を受け取ります。反対に、ノードがセッション中にブロックを作成できなかった場合は、slashedAuthors メカニズムがそのパフォーマンスを追跡します。指定された最大期間にわたって停滞したままのノードは、自動的に Offline に設定されます。オフラインのノードは段階的に格下げされ、最終的にはネットワークから削除されることで、ステーキングシステムの完全性と信頼性が維持されます。
報酬計算の例
報酬の分配は、総報酬 22,114,400 を基に計算されます。まず、報酬の 20%（4,422,880）がトレジャリーに割り当てられ、残りの 80%（17,691,520）が作成者とステーカーの間で分配されます。作成者のコミッションは 50% に設定されており、残りの半分（8,845,760）がそれぞれのステーク比率に基づいてステーカーに分配されます。たとえば、比率 6%（1/15）のステーカー 1 は 530,746 を受け取り、これが初期残高 90,000,000,000,000 に加算されます。以降のステーカーもそれぞれの比率に応じた取り分を受け取り（例：13% のステーカー 2 は 1,115,451、20% のステーカー 3 は 1,604,533 を受け取るなど）、各計算ごとに次のステーカーへの残額が減っていきます。
最後に、すべてのステーカーへの報酬の分配が終わると、残額の 10,490,511 が作成者の残高に加算されます。これは作成者のコミッション分と未分配の報酬を反映したものです。これにより、ステーク比率に基づく正確かつ公平な分配が保証されるとともに、計算された残高と期待値を比較するアサーションによって結果が検証されます。
候補者のソート
sort_proposed_candidates 関数は、公平かつ論理的な順序を確保するために、3 つの基準に基づいて候補者リストを整理します。まず、オフラインステータスに基づいて候補者を優先順位付けし、オフラインとしてマークされていない候補者を優先します。次に、候補者のボンドと総ステークの合計値を考慮し、値が大きい候補者を優先します。それでも同順位の場合は、最終更新タイムスタンプを使用し、タイムスタンプが古い候補者を優先します。このソートロジックにより、アクティブで、十分にステークされ、経験豊富な候補者が上位にランク付けされます。
ソート後、更新されたリストはブロックチェーンの状態に保存されます。ソートには then_with メソッドを使用してこれらの基準を順番に適用し、前の基準で順序が決まらない場合にのみ次の基準に進みます。この方式により、決定論的かつ公平なランキングが保証され、ステーキングやバリデーションなどのタスクにおける候補者の選出が最適化されます。