ZooBC ウィキ
Proof of Participation

レシートとネットワークトポロジー

ブロックチェーンは、ノード同士がブロックとトランザクションを互いに渡し合うことで成り立っています。Proof of Participation が計測するのはまさにその働きです。登録済みノードが別の登録済みノードからデータを受け取ると、自分のノード鍵で署名した短い声明であるレシートを返します。したがって仕事の証明は、それを主張するノードではなく、データを受け取ったピアから生まれます。どのピアが数えられるかもノードが決めるのではありません。40 ブロックごとに、プロトコルがブロックシードでレジストリをシャッフルし、各ノードに優先ピアを割り当てます。

ノード A がブロックをノード B に中継し、B は B が署名したレシートを返します。A の次のブロックがそのレシートを運び、それが A の参加スコアを動かし、ひいては新しい ZBC の取り分を動かします。
ノード A がブロックをノード B に中継し、B は B が署名したレシートを返します。A の次のブロックがそのレシートを運び、それが A の参加スコアを動かし、ひいては新しい ZBC の取り分を動かします。

優先ピア:トポロジー

レジストリは 40 ブロック(topology_period_blocks)、約 10 分の期間ごとに 1 回シャッフルされます。期間の最初のブロックで、各登録済みノードはソートキーを受け取ります。

key = SHA3-256(seed of the period's first block (64 bytes)
               ‖ node id (8 bytes, little-endian)
               ‖ period height (8 bytes, little-endian)
               ‖ "zbc-topology-v2")

レジストリをこれらのキーで並べ替えると、シャッフルされたリストができます。各ノードには、そこから連続する P 個のノードからなるウィンドウが優先ピアとして割り当てられます。P は max_assigned_peers で、mainnet では 12、devnet では 8 です。位置 i にあるノードのウィンドウは位置 (i × P) mod L から始まります(L はリストの長さ)。ウィンドウは常にちょうど P 個のノードを含み、P と L が公約数を持つ場合はウィンドウの開始位置が分散されます。この関係は一方向です。A が B の優先ピアであっても、B が A の優先ピアになるとは限りません。

順序は誰も制御できないシードに依存し、10 分ごとに変わるため、共謀するノードのグループが互いのピアになるよう仕組み、仲間内だけで保証し合うことはできません。接続速度は何の役割も果たさず、誰もピアのリストを公開しません。

ノード ID 順のレジストリを、シード、ノード ID、期間、タグの SHA3-256 キーで並べ替えます。シャッフルされたリストの中に、あるノードの 12 の優先ピアのウィンドウが示されており、40 ブロックごとにシャッフルし直されます。
ノード ID 順のレジストリを、シード、ノード ID、期間、タグの SHA3-256 キーで並べ替えます。シャッフルされたリストの中に、あるノードの 12 の優先ピアのウィンドウが示されており、40 ブロックごとにシャッフルし直されます。

レシートの内容

レシートは 232 バイトです。

フィールドバイト数
送信者のノード鍵(データを送ったノード)32
受信者のノード鍵(署名するノード)32
参照ブロック:受信者の最新ブロックの高さ4
参照ブロック:ハッシュ32
データの種類:ブロックなら 1、トランザクションなら 24
データのハッシュ:どのブロックまたはトランザクションを受け取ったか32
受信者の最新のレシートバッチのルート32
上記 168 バイトに対する受信者の Ed25519 署名64

レシートを与えたり保持したりするのは登録済みノードだけで、しかも別の登録済みノードから送られたデータに対してだけです。登録されていないノードはチェーンを追跡して確認できますが、レシートを与えることも獲得することもありません。レシートはチェーンを指定しないため、トランザクションとは異なり(チェーン束縛署名 を参照)、チェーンへの束縛を持ちません。

レシートは、ウォレットの確認表示や手数料の返金とは何の関係もありません。それらはトランザクションと残高の通常の記録です。

バッチと公開

送信者は獲得したレシートを保管します。高さごとに、それらを署名順に並べて最大 1,000 件のバッチにまとめ、マークルルートの下に置きます。自分のブロックを作るとき、そこにレシートのサンプルを公開します。サンプルには 2 種類あります。そのまま提示されるリンクされていないレシートと、以前のバッチルートに対するマークル証明とともに提示されるリンクされたレシートです。リファレンスソフトウェアは約 40 ブロック前のレシートからサンプルを取りますが、これはその実装の動作であって、有効性のルールではありません。

バリデーターが確認すること

ブロックで公開された各レシートについて、すべてのノードは次のことを確認します(n は登録済みノードの数です)。

  • 受信者の署名
  • 参照ブロックのハッシュが、その高さにあるこのチェーンのブロックであること
  • 古さ:レシートは max(max(100, 2 × n) + 1, receipt_lifecycle) ブロック後に失効します。mainnet では 518,400 ブロック(約 90 日)です。
  • 高さ 40 以降は、リンクされていないレシートの署名者が、そのレシートが属する期間においてブロックの生成者の優先ピアであったこと
  • 高さ 80 以降は、リンクされたすべてのレシートのマークル証明
  • 件数:最大 2 × min(n − 1, P) 件で、200 件を超えることはありません。

有効性のルールではないものもあり、それらを読み込むべきではありません。バリデーターは、レシートの送信者がブロックの生成者であること、レシートが新しいこと、そのデータが約 40 ブロック前のものであること、リンクされたルートが以前にチェーン上に現れたことは確認しません。

レシートからスコアへ

中継で得られるのはレシートであって、スコアではありません。スコアが動くのは、ノードが自分のブロックでレシートを公開したときだけです。提示できる数のおよそ半分であるピボットより多く提示すればスコアは上がり、少なければ下がります。高さ 40 より前にはスコアは動きません。詳細は 参加スコア を、スコアがどのように収入になるかは コインベース抽選 を参照してください。

関連項目