リリースとアップデート
ZooBC は、チェーンを変えずにソフトウェアを変えます。新しいバージョンはチェーン上で告知され、各ノードはオーナーが管理するアップデーターを通じてそれをインストールし、新しいコンセンサスルールは生成者の 3 分の 2 がすでにそれを実行しているときにはじめて有効になります。誰もノードにソフトウェアを押し込むことはできず、新しいバージョンのために新しいチェーンが必要になることもありません。
リリースの登録簿
チェーンのジェネシスで指定された 1 つの鍵であるリリース権限者が、RegisterRelease（タイプ 32）で各リリースを登録します。登録には、バージョン文字列、32 バイトのマニフェストハッシュ（リリースのファイルのフィンガープリント）、そしてリリースアドレスが含まれます。リリースはアーキテクチャごと、チェーンごとに登録され、バージョン文字列がその両方を示します。1 つのバージョン文字列は一度しか登録できないため、修正には新しいバージョンが必要で、取り消されたバージョンが復活することは決してありません。権限者はリリースを取り消すこと（タイプ 35）や、その役割を別の鍵に引き渡すこともできます。引き渡しは提案（タイプ 33）と受諾（タイプ 34）の 2 段階で行われます。
登録済みの席は、この鍵に対する抑止力を持っています。
- 拒否。 登録済みの席の 3 分の 2 があるバージョンについて「拒否」のアテステーションを送ると、権限者が取り消した場合とまったく同じようにそのバージョンは取り消されます。自動更新するノードはそれをスキップし、インストーラーはそれを拒否します。一時停止中の席は集計から除かれるため、アクティブな席が 11 なら拒否には 8 席が必要です。各票はノード鍵で署名された手数料不要のアテステーションで、運用者が自ら投じます。自動的に投票するものはありません。
- 交代。 新しいリリース権限者を指名する投票は、最も古い票が 1 週間（40,320 ブロック）経過してはじめて集計されるため、現在の権限者は事前にそれを察知できます。3 分の 2 に達すると、役割は投票先のアドレスに移ります。
登録や取り消しは助言的なものです。自動更新を選んだオーナーのノードを案内するもので、自分で選んだバイナリを動かす運用者がそれに動かされることはありません。ダウンロードしたリリースは、誰でも登録簿と照合できます（ダウンロードしたファイルの確認）。
アップデーター
ZooBC のインストーラーは、ノードの内部ではなくノードの横で動く小さなアップデーターを追加します。アップデーターはマシンの起動から 15 分後に初めて実行され、その後はおよそ 10 分ごと（± 2 分）に実行されます。実行のたびにローカルノードに /api/v1/release/list を問い合わせ、自分のチェーンとマシン種別（amd64 または arm64）に対応する、登録済みで取り消されていないリリースのうち、稼働中のものより新しい最新のものを探します。
アップデーターがそのリリースをインストールするのは、その時期が来たときだけです。リリースの登録の高さに、更新遅延と、このノード自身のスロットを加えた時点です。その後リリースをダウンロードし、その署名とマニフェストハッシュをチェーンと照合し、稼働中のバージョンの横にインストールし、ノードを再起動してヘルスチェックを行います。チェックに失敗すると古いバージョンにロールバックし、失敗した更新は 12 時間後に再試行します。
- 遅延は、mainnet では既定で 2 日（11,520 ブロック）です。各ノードが自分で設定し、リリース権限者がそれを短くすることはできません。不適切なリリースが広がる前に取り消す時間を確保します。
- スロットはノードを鍵の順に並べて開始時刻を分散させ、既定では 1 つのブロックで更新を始めるノードが最大 2 つになるようにします。チェーンが一度に多くの生成者を失うことはありません。
- オーナーのスイッチ
auto_updateは、on（既定値）、off、chainのいずれかです。chainの場合、アップデーターはオーナーがウォレットからチェーン上で署名した設定に従うため、オーナーはサーバーにログインせずに更新のオンとオフを切り替えられます。
新しいリリースが存在すると、すべての運用者に知らされます。アップデーターはオフにされていても準備判定ゲートの状態とともにそのリリースを示し、ノードは毎日ログに警告を書き、ノードの /node/info ルートがそれを報告し、ウェブウォレットはバナーを表示し、エクスプローラーは各ノードのバージョンを表示します。
準備判定ゲート
新しいコンセンサスルールは、0 より大きいバンドル ID を持つバンドルとしてリリースに含まれて配布されます。すべてのブロックはその生成者のソフトウェアバージョンを運んでおり、準備判定ゲートがそれを読みます。バンドルのルールは、次のすべてを満たす最初の高さで、すべてのノードで一斉に有効になります。
- バンドルの予定の高さ以降であり、かつリリースの登録から少なくとも 5,760 ブロック（1 日）後であること
- 登録済みの席（切り上げ、一時停止中の席は除く）の少なくとも 3 分の 2 が、それぞれ集計の時間枠の中で、バンドル ID 以上のバージョンでブロックを作っていること。時間枠は 720 ブロックとノードあたり 5 ブロックの大きい方です。
- リリースが取り消されていないこと。取り消しは保留中のバンドルを止めます。
その高さ以降、古いバージョンのブロックは拒否されます。更新しなかったノードに猶予はありません。最初に拒否された番から、番を逃し、何も稼げず、スコアを失います（逃した番、一時停止、除名）。だからこそ、運用者は新しいリリースのたびに警告を受けるのです。
数えられるのはブロックではなく生成者なので、他から切り離された少数派が単独で 3 分の 2 に達することはできません。どの鍵も有効化を強制することはできません。リリース権限者は有効化メッセージに署名せず、生成者が移行していない間は高さだけで決まることもありません。ゲートには既知の限界があります。期限がないため、3 分の 1 をわずかに超える席でアップグレードを止めることができます。また、欠陥のあるリリースは見抜けません。そのために遅延と拒否があるのです。
バージョン 0.5.8 で立ち上げられたチェーンでは、121 のコンセンサスルールがすべてブロック 0 から有効で、バンドルされたルールはないため、ゲートが初めて意味を持つのは後のリリースです。また、ノードはバイナリがルールの有効化の位置をチェーンの記録と異なる位置に置いている場合、起動を拒否します。リリースは、既知のスパインブロックに結び付ける リリースピン を同梱することもできます。