加入ペース
ZooBC は新しいノードを ノードレジストリとその席 に 1 つずつ加入させます。そのタイマーは意図的にゆっくり進みます。運用者のブロック生成の取り分は席の取り分に等しいため、席を獲得できるペースは、誰かがチェーンに対する力を得られるペースそのものです。プロトコルがそのペースを固定しており、誰でもそれを見守ることができます。
ゆっくりである理由
Proof of Work ではブロック生成の取り分をハードウェアの調達と同じ速さで、Proof of Stake ではコインの購入と同じ速さで買うことができます。ZooBC では、その取り分は加入サイクルごとに 1 ノードずつ、プロトコルが定める速さで加入を認められなければなりません。そのため、たとえば支払いを取り消すための突然の乗っ取りは、単に高コストなのではなく、原理的に不可能です（Proof of Participation が防ぐもの）。
この遅さはチェーンの速度とは関係ありません。新しいノードは全履歴ではなく最近のスナップショットから開始できますし、運用者を面接する人もおらず、チェーンはノード数がいくつであっても 15 秒ごとに 1 ブロックを作ります。
式
2 回の加入の間隔は次のとおりです。
delay = clamp(base ÷ counted seats, minimum, maximum)mainnet では基準期間が 600 日、最小値が 7 日、最大値が 90 日です。testnet も同じ値を使います。最初の新規ノードはジェネシスの 7 日後に加入できます。タイマーはブロックのタイムスタンプを読み、1 サイクルにつき最大 1 ノードを加入させます。ノードをキューに入れたブロックで加入させることはありません。どのノードを加入させるかは キュー が決めます。
次の加入までの間隔は、新規ノードが加入したときに、その新規ノードより前の席を数えて決められます。
集計対象の席
- ジェネシス席は最大 11 までしか数えられません（ジェネシス値で、どのチェーンでも 11 です）。
- 新規ノードは全数数えられます。
- 一時停止中の席はどちらのグループにも数えられません。
この上限によって、大きなジェネシスがレジストリを速く開いてしまうことを防ぎます。上限がなければ、100 のジェネシス席で立ち上げられたチェーンは 600 ÷ 100 = 6 日と計算し、それが最小値の 7 日に引き上げられ、最初から毎週 1 つの新規ノードを加入させることになります。上限があれば集計は 11 から始まり、スケジュールは 11 席のチェーンと同じになります。一時停止中の席を除くことで、ペースを決めるのは働いている席だけになります。
スケジュール
キューが空にならず誰も離脱しなければ、新規ノードは次のように到着します。
| 新規ノード | 到着するおよその時期 |
|---|---|
| 1 番目 | 7 日目 |
| 2 番目 | 61.5 日目 |
| 7 番目 | 278 日目 |
| 11 番目 | 408 日目 |
これにより、最初の 1 年で 9、2 年目の終わりまでに 25、3 年目までに 54、5 年目までに約 155 の新規ノードが加わります。集計対象の席が 86 になると、600 ÷ 86 は 7 日を下回るため最小値が適用され、約 77 番目の新規ノードから、つまりジェネシスから約 3.5 年後から、加入は毎週になります。すべての加入を勝ち取った応募者でも、11 のジェネシス席を上回るのに十分な 12 番目の席を得るのは 437 日目ごろになります。
基準期間が間隔を決めている間、レジストリは単位時間あたり一定の割合で成長します。各加入が席を 1 つ加え、間隔は基準期間を席数で割ったものだからです。したがってレジストリが 2 倍になるには、規模にかかわらず基準期間 × ln 2、mainnet ではおよそ 416 日かかります。
特別な場合
- 小さなレジストリ。 アクティブなノードが
min_registry_size（mainnet では 7）より少ない間は、最大の間隔が 7 日に制限されます。 - 長い停止の後は、 タイマーが 1 ノードを加入させてから通常のペースに戻ります。
- 開発用チェーンである devnet は同じ式を、基準期間 180 秒、最小値 60 秒、最大値 300 秒で使うため、加入は数分おきに行われます。
すべての入力はチェーン上にあるため、誰でも次の加入がいつになるかを再計算できます。