LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH-- Cardano & Midnight 総合情報ポータル
SIPO
速報 RealFi がCardanoメインネットで本稼働開始 30分前 速報一覧 →
HOME › Deep Dive › 🔬 Deep Dive|CIP-202と203で読むCardanoの多様性
Deep Dive

🔬 Deep Dive|CIP-202と203で読むCardanoの多様性

Cardanoでは、ノードの状態を外部へ伝えるCIP-202と、ブロックを作った実装の識別を扱うCIP-203のレビューが進んでいます。10月1日に確認した両提案は、まだ未マージのProposedです。多様性を観測する入口が増える一方、ブロックの割合とノードの台数は同じ数字にはなりません。何を数えた結果なのかを、二つの提案から整理します。

ブロックに残る申告とリレーの応答

CIP-203の正式な題名はBlock Producer Identifier Registryです。ブロックを作るノード実装を識別する番号と、その読み方を登録する仕組みを提案しています。CIP-202のNode Observability Snapshot Protocolは、外部の観測者が公開リレーから小さな状態情報を受け取る仕組みです。

前者では、ブロックに残った値を後から集計できます。後者では、その時点で到達できたリレーが、公開するよう選んだ情報を読みます。データが得られる経路も、結果に含まれる対象も違います。

たとえば、ある実装のブロック生成比率が高くても、その実装を動かすノード台数が同じ割合だとは言えません。ステークの分布や生成機会、集計期間がブロック数に影響するからです。一方、公開リレーの応答を100件集めても、ネットワーク全体から無作為に100台を選んだ調査にはなりません。到達できなかったリレー、参加しない運営者、外から直接見えないブロック生成ノードが残ります。

二つを併せて使う価値は、同じ数字を二度確かめることより、違う対象を照らせることにあります。ブロック生成の申告と、リレーが提供する状態情報を、互いの不足を把握しながら読む構図です。

なお、番号が付いたことと標準が採用されたことは分けてください。今回確認したPR #1275と#1276はopen、merged=falseでした。固定して読んだ本文はどちらもStatus: Proposed、Implementorsは空欄の配列です。CIPの番号やConfirmedというレビュー上の表示を、Activeや全実装への導入済みという意味にはできません。

CIP-203の識別番号は実行中のソフトの証明か

CIP-203は、ブロックヘッダーにある32ビットのminor値を、実装識別子8ビット、実装ごとの追加情報22ビット、方式の版2ビットに分ける案です。既存のフィールドを使うため、提案ではハードフォークや既存ノードの変更なしに役立つ設計として説明されています。

追加情報の意味は、識別子だけでは分かりません。実装側が公開した定義を、観測側が理解している必要があります。知らない方式の版であれば、残りのビットを現在の規則で解読しない。追加情報の定義を持たなければ、不透明な値として扱う。こうした規則は、見慣れた数字へ無理に名前を当てる誤りを避けるためのものです。

草案は、識別子0を信号なし、255を明示的な不参加として区別します。1から15は旧cardano-nodeとの混同を避けるための予約領域です。0だからHaskell実装だと推定してよい、という規則ではありません。申告なし、意図的な非開示、未対応、解読できない値を、ひとつの既知実装へ吸収しないことが大切です。

ブロックヘッダーには、プールの運用証明書の下でKES署名が付いています。そのため、記録された申告を特定のプールが発行したものとして結び付けられます。ただし、署名が正しいことは、その名前のバイナリが実際に動いていた証明とは別です。信号は自己申告で、実行ファイルの検証をこの提案が提供するわけではありません。

草案の登録簿にはGerolamoの67、Dingoの69という値が記載されています。しかし、今回の固定版ではmaintainersが空、payloadの仕様もnullでした。記載例や提案者による実績説明から、正式登録の完了や観測したすべてのブロックの実装帰属まで確定させることはできません。本稿では、現在の実装別シェアを独自に算出していません。

CIP-202は公開する範囲を運営者に残す

CIP-202では、公開リレーが、あらかじめ作成した状態情報のスナップショットを返します。通常のローカル監視で使うPrometheusやトレース、ログを置き換える提案ではありません。外部から、異なる実装に共通する小さな情報を問い合わせられるようにする案です。

草案の基本周期は600スロットです。1スロットが1秒のネットワークなら10分に相当します。問い合わせのたびに計測し直したり、暗号化したり、内部のブロック生成ノードへ問い合わせたりせず、保存済みの結果を返す設計です。外部の要求が内部の仕事を増幅させないよう、生成と読み取りを分けています。

情報には公開するものと、特定の観測者向けに暗号化するものがあります。内部のブロック生成ノードが作った暗号化情報を、リレーが中身を読まずに転送する仕組みも提案されています。公開の外側にプール識別子を必須で置かず、必要なら暗号化された内容の中へ含める構造です。

ここで暗号化が担うのは、主に誰が内容を読めるかという機密性です。草案が使うsealed boxは、それだけで発行者の身元を認証したり、申告された実装と実際のバイナリが一致することを証明したりするものではありません。暗号化されていることと、情報が正確だと確認できることを分ける必要があります。

非公開情報が守られる設計でも、公開される情報の個数や暗号文の長さは外から見えます。また、参加や開示する項目を選べる以上、全体が同じ項目を必ず返すとは限りません。開示の自由は運営者にとって意味があり、観測側には欠損を扱う仕事が残ります。既定で参加するかどうかも、実装・レビュー上の論点を含むため、全ノード共通の設定として確定したとは扱えません。

時刻と分母をそろえると比較が変わる

スナップショットには、観測の予定枠を示すsnapshot_slotがあります。ノードが現在選んでいるチェーンの先端、chain_tip_slotとは別です。予定枠が同じでも、同期の遅れで先端が違うことがあります。二つを混ぜると、いつの観測かと、どこまで追い付いているかが分からなくなります。

多様性の数字を並べるなら、少なくとも次の違いを残したいところです。

観測 主に数えるもの 数字を読む条件
ブロックの実装信号 期間内の生成ブロック 期間、方式の版、未申告・未知の値、登録簿の版
リレーの応答 到達し、情報を返した対象 対象の発見方法、到達率、参加・開示範囲、情報の時点
実際のノード台数 稼働する実体 重複や役割、非公開ノード、未観測範囲を含む別の調査

たとえば、既知の信号があるブロックだけを分母にして割合を出すと、未申告の部分が見えなくなります。期間内の全ブロックを分母にした割合とは、答えている問いが違います。どちらを使う場合も、未申告や解読不能の件数を併記する方が、観測の届いた範囲を判断できます。

リレー側でも、応答した対象だけで割合を出す場合と、発見した対象全体に対する到達率を示す場合では意味が変わります。同じ運営者の複数リレーや、同じ生成ノードを代理する応答をどう扱うかも必要です。情報を得られるようになっただけで、重複や偏りが自動的に消えるわけではありません。

実装の名前が複数見えることは、多様性を考える入口です。障害に対する強さまで評価するには、独立したコードや依存関係、運用の分布、共通する失敗要因なども関わります。ブロック比率ひとつから、ネットワークの耐障害性が実証されたとは言えません。

採用前に見る相互運用の実証

CIP-202の現稿には、通信形式の草案CDDLへのリンクがあります。PR冒頭に残る「CDDLはまだない」という説明だけで、最新本文を評価しないようにしたいところです。一方、草案があることと、通信方式の合意や実装間の試験が終わることも別です。

Activeへの条件には、版を持つ通信形式、公開テストベクトル、独立した少なくとも2つのノード実装、両方に対応する独立した観測クライアント、運営者向け文書、公衆ネットワークでのリレー規模の試験が並びます。負荷を抑える設計が書かれたことを、実際の負荷が十分小さいという測定結果としては扱えません。

CIP-203では、識別子と追加情報の意味を保ち、過去のブロックも同じ版の規則で読めることが重要になります。10月1日には追加情報の形式を扱う別の粗い草案PR #1282も開かれていました。登録の仕組みと、その中身の意味を一度に完成済みと見なさない方が、進行中の議論を追えます。

次に確認する具体的な一点は、PR #1275と#1276のレビュー更新と、CIP-202が掲げる実装間の試験記録です。提案の状態が変われば、観測に使える仕組みも読み直せます。観測の入口ができた後は、表示された割合に、分母、期間、識別の強さ、欠損が添えられているかが、数字の使いやすさを決めます。

ことば

リレー:ネットワークとの通信を中継するノード。公開リレーの観測は、すべての内部ノードの調査とは異なります。

自己申告の信号:発行者が自分の情報として載せた値。署名で発行元を結び付けても、実行環境の証明とは区別します。

CDDL:通信するデータの形を定義する記述言語。草案の存在と、異なる実装間での動作確認は別の段階です。

🔗 一次ソース