仕組みの解説2026-10-19約 4分

IoTeX Zanzibar：投票者の報酬は誰が計算するのか

IoTeXの報酬送金は以前からチェーンに記録されていた。Zanzibarは計算と分配をチェーンの規則に組み込む。鍵となるのはスナップショット、参加条件、複数ブロックへの処理分割だ。

AI生成の概念イラスト。2人が固定された参照表から同じ配分を再現している。駒は共通の計算規則の比喩であり、実際の支払いや全投票者への均等な報酬を表してはいない。

要点

IoTeXScanはZanzibarの有効化ブロック53,533,081を2026年10月19日02:28:37 UTCと記録している。告知の02:00は予想時刻だった。
IIP-59は対象となるデリゲートの投票者報酬の計算と分配をプロトコル規則に組み込む。Hermesも送金自体は以前からオンチェーンに記録していた。
リリース済み設定は報酬期間を24エポック、ブロック当たりの処理枠を投票者256人とする。移行、配分率、支払先には引き続き条件がある。

出来事のタイムライン

2026-09-24有効化する高さを変更

公式ノートが10月8日の予想を、ブロック53,533,081と10月19日の予想に変更した。

2026-10-04予定を維持する保守リリース

v2.5.1を公開。Zanzibarの高さは変わらず、別のハードフォークも追加しなかった。

2026-10-19予定のブロックを記録

IoTeXScanと財団の公開RPCが、ブロック53,533,081の時刻を同じ02:28:37 UTCと返した。

報酬がウォレットに届くまで

ウォレットに届く報酬は、長い計算の最後の結果だ。どのステークを数え、どのデリゲートに投票し、そのデリゲートが投票者にどれだけの割合を割り当て、どこへ支払うのか。IoTeXのHermesサービスは参加するデリゲートのために、この作業を自動化していた。分配にはすでにスマートコントラクトを使い、オンチェーンの記録を残していた。Zanzibarを「報酬が初めてチェーン上で見えるようになった出来事」と説明すると、変化の核心を見失う。^[5]

Zanzibarは参加するデリゲートの報酬計算と分配をプロトコル自体に移す。別のサービスが計算して分配処理を送信するのを待つ代わりに、検証者が確定済みの状態から結果を導き、チェーンを処理する。支払いに先立つ作業まで、ノードが共通して再現する規則に組み込む。それがIIP-59の中心的な考え方だ。^[1][3]

時刻は予想、ブロックは記録

メインネットの有効化地点はブロック53,533,081だった。IoTeXScanによる記録は2026年10月19日02:28:37 UTC。リリース済みコードもZanzibar、Zanzibar Beta、Zanzibar Gammaを同じ高さに設定している。このブロック記録は有効化地点への到達を裏付ける。先に告知された02:00 UTCは予想であり、観測されたブロック時刻ではない。^[2][4]

途中で予定も変更された。9月24日の文書コミットは、10月8日を想定していたブロック53,155,801から、より後の高さへ変更した。10月4日公開の保守版v2.5.1も新しい予定を維持した。テストネットでは各段階が別々に有効になったが、メインネットにはBetaとGammaの修正がZanzibarと同時に入る。ソフトウェアの公開日、フォークの予想時刻、記録された有効化ブロックは、それぞれ違う段階を示している。^[9][8][1]

入力を固定し、処理を分ける

報酬処理には蓄積と精算の段階がある。デリゲートの取り分は直ちに支払い、投票者の取り分はそのデリゲートに対応するプールへ蓄積する。報酬期間の境界で、デリゲートの設定やステーキング状態など、精算に必要な入力を固定する。リリース済み設定では1期間が24エポックだ。毎日決まった時刻に支払うという約束ではない。^[3][4]

その後、複数のブロックで上限付きの処理を繰り返して支払う。リリース済みの既定値では、1つの処理単位が扱う異なる投票者は最大256人。全分配を1ブロックに詰め込まず、仕事を分ける仕組みだ。その間にステーキングが変化しても、スナップショットは当該精算を以前の基準に結び付ける。固定した配分表を何回かに分けて処理すると考えると分かりやすい。現在の台帳への後の変更が、精算中の表をひそかに書き換えることはない。^[3][4]

1回のフォークで全員が同じ経路に移るわけではない

Hermesからの自動移行は、有効化時に1回だけ行う。指定されたHermes保管アドレスを報酬アドレスとする候補を選ぶが、DelegateProfileに投票者報酬の配分率フィールドが2つとも必要だ。設定を欠く候補は既存のHermes経路に残る。他の候補も、所有者が承認する操作で参加できる。リリースノートにある過去の候補集計はフォーク前の一時点の観測であり、10月19日に実際に移行した対象を監査した数ではない。^[1][6]

複数のデリゲートから計算した1人の投票者の取り分は、1回の支払いにまとめられる。支払処理は設定された受取先アカウントの残高を増やすか、自動入金条件を満たす場合に対象のネイティブ・ステーキング・バケットへ金額を加える。割り当て済み報酬の到着先が異なる。IOTXを保有するだけで、参加資格、報酬額、自動再ステーキングの権利が決まるわけではない。^[3][7]

有効化の後に確かめること

有効化ブロックとリリース済み規則が示すのは、予定した切替地点に到達したことだ。対象となるすべての投票者への支払い完了までを示すわけではない。フォーク後も報酬期間の境界、段階的な処理、デリゲートの設定が関係する。本稿は有効化の記録を確認し、リリースされた設計を説明している。個別の支払いを監査したり、実現収益を測定したりした結果ではない。^[1][2][4]

特定の支払いでは、具体的に問う必要がある。デリゲートは新方式に入ったのか。その精算にどの設定とステークが固定されたのか。どの残高加算や入金が記録されたのか。Zanzibarはその計算の連なりを共通の実行規則に組み込む。条件を満たしたステークから記録済み支払いまでの道筋を、共通ルールに照らして検証できることに意味がある。誰がいくら受け取るかは、引き続きその規則と入力が決める。^[3][6][7]

次の疑問へ