Qlyphs 検証できる設計
購入の証明が、信頼された証人の署名した状態にオファーをどう結びつけるのか。そして、何がまだ信頼に頼っているのか。
ウォレットは、支払う前に、オファーが本物だとどうやって知るのでしょう？
トークンの残高と予約は、Quantus の上で計算されます。偽の予約があれば、買い手は受け取れないトークンにお金を払わされるかもしれません。だから署名するウォレットは、購入の前に、署名のないサーバーの応答以上のものを求めます。
固定されたチェックポイントからリプレイする
QLYP は、公表された有効化アンカーより後のブロックを、順番に解釈します。アンカーそのものは含みません。入力とルールが同じなら、状態も同じになります。暫定の表示は再編成（リオーグ）で変わることがありますが、購入の証明は確定したチェックポイントに結びついています。
- 3 QTC 送金ブロック #184,222
- 12.5 QTC 受け取りブロック #184,220
- 01 / 05
ブロックは次々と届く
新しい Quantus のブロックは暫定のことがあり、再編成で置き換わる可能性があります。設定されたノードは、最新のヘッドと確定済みのチェックポイントの両方を報告します。この図では、その間の差を縮めて描いています。
- 02 / 05
確定と暫定は別もの
証人の証明は確定済みの状態を表します。ファイナリティは設定されたノードが報告するもので、新しいブロックが1つ来たから確定とみなすわけではありません。サービスが暫定の状態を見せることもありますが、それは確定前に変わる可能性があります。
- 03 / 05
決まった起点から順番に読む
リプレイは、対象外のアクティベーション・アンカーで、空の QLYP 状態から始まります。次のブロックが最初に解釈されるブロックで、その後の確定済みブロックは抜けなく順番に処理されます。
- 04 / 05
同じチェーンからは同じ結果
同じブロックと同じプロトコルルールからは、同じ状態が得られます。そのためリプレイは再現できますが、ノードの合意を独自に検証するものではなく、証人の実装が正しいことを示すものでもありません。
- 05 / 05
証明用の鍵は支払い用の鍵ではない
インデクサーが残高を求めるのに、ユーザーの支払い用の鍵は必要ありません。証人は自分専用の証明用の鍵を持ち、それで状態を認証しますが、ユーザーのアカウントからお金を使うことはできません。
ファイナリティ（確定）は、設定されたノードから得ます。状態をリプレイできることは再現性であって、合意を独自に検証することではありません。サービスは暫定の状態を持ちながら、確定したチェックポイントを別に、消えない形で保てます。
信頼された 2 つの証人
開発用のデプロイには、TypeScript と Python の証人の実装があります。購入のポリシーでは、設定された 2 つの証人の運営者が、同じ状態ルートと同じ確定チェックポイントに署名していることを求めます。どちらも ML-DSA-87 を使います。ポリシーは、公開鍵、ネットワーク、ランタイム、ルール、鮮度の上限をウォレットのビルドに組み込みます。Web サイトが鍵を差し替えることはできません。
実装を分けることで、同じ実装の不具合を共有するリスクは減ります。ただし、別々の運営と別々のノード基盤は、デプロイに求められる条件であり、コードだけで保証されるものではありません。署名が裏づけるのは、証人が証明した内容です。証人が誠実であることを証明するものでも、チェーンの合意の代わりになるものでもありません。
新しく、結びつき、後戻りしない
証人の声明はそれぞれ、状態ルートを、ネットワークのジェネシス、有効化アンカー、ランタイム、ルール、確定したブロック、そしてウォレットが選んだ新しい 256 ビットのチャレンジ（使い捨ての乱数）に結びつけます。声明が有効なのは最大 60 秒です。ウォレットは受け入れた中で一番高いチェックポイントも覚えているので、証人があとから古い状態を見せたり、同じ高さで 2 つの違う状態を見せたりすることはできません。
選択的証明：買うものだけを証明する
開発中
選択的証明（QPA2）は、オープン出品と一緒に、開発用のトラックで作られています。
今のところ、ウォレットは署名された状態全体の中で予約を確かめています。次の証明形式では、その状態を 8 つのセクションに分けてコミットします（資産、残高、連番、マルチシグ、予約のチケット、シンボル、刻印、出品）。各セクションには、それぞれ SHA-512 のマークルツリーがあります。証人は、セクションのルートとそのサイズをまとめた 1 つのルートに署名します。こうすればウォレットは、スナップショット全体ではなく、買う出品とその資産、それらが含まれていることを示す経路だけを受け取れば済みます。
- 01 / 05
1つのエントリーが届く
ウォレットは、これから買う予約と、それを確かめるのに必要な証明データを受け取ります。この小さなツリーは、1つのエントリーが署名済みの状態ルートにどう結びつくかを示しています。
- 02 / 05
隣のエントリーと組む
出品と一緒に、ツリーの各段につき1つのハッシュが届きます。ウォレットは、出品とそのすぐ隣のエントリーを合わせてハッシュします。結果は、両方を表す新しいハッシュです。
- 03 / 05
1段ずつ繰り返す
同じ手順を繰り返します。結果を次に受け取ったハッシュと組み合わせ、1段ずつ上へ登っていきます。証明の大きさはツリーの深さに応じて増えます。この図のエントリーはわずかで、応答速度を保証するものではありません。
- 04 / 05
ルートにたどり着く
一番上にはハッシュが1つだけあり、これがルートです。ウォレットはそれを、まさに支払う対象の出品から自分で計算しました。ルートは市場全体の指紋のようなもので、エントリーが1つでも変われば変わります。
- 05 / 05
証人のルートと一致すること
そのルートは、信頼された2つの証人がそれぞれ ML-DSA-87 で署名したチェックポイントと一致しなければなりません。書き換えられたエントリーは、証明の確認を通りません。有効な署名が裏づけるのは、証人が証明した内容です。証人が不正をするリスクや、実装が乗っ取られるリスクは残ります。
経路に必要なのは、ツリーの 1 段につき最大 1 つの兄弟ハッシュです。そのため経路の長さは、セクションの大きさの対数に比例して増えます。
- 1つの経路の兄弟ハッシュ（最大）
- 17
- 経路のサイズ、SHA-512
- 1,088 バイト
100,000 エントリーのセクションでも、兄弟ハッシュは最大 17 個で足ります。応答全体にはヘッダー、エントリー、署名も含まれ、上限は 256 KiB です。証明を集めてくるサービスは信頼されていません。証人の鍵を差し替えることはできず、エントリーが欠けていればエラーになります。残高ゼロとして扱われることはありません。
チェックごとに、防げることがある
| チェック | 防げること |
|---|---|
| ウォレットに組み込まれた鍵による 2 つの署名 | Web サイトやサーバーが状態をでっち上げること |
| 両方の証人が同じルートに署名している | 1 つのリプレイエンジンが故障したり、乗っ取られたりすること |
| 新しいチャレンジで、60 秒以内のもの | 以前は正しかった古い声明を使い回すこと |
| 確定したブロックで、前に見たものより古くない | まだ再編成や巻き戻しが起こりうる状態で支払うこと |
| 署名された状態の中に予約が見つかる | 書き換えられたエントリーや、作り話のエントリー |
| 購入が、証明された条件から組み立てられる | サイトが価格、数量、受取人を変えること |
支払う前にウォレットが確かめること
- 必要な証人の署名が、組み込まれた信頼ポリシーに合っていること。
- 状態ルート、確定チェックポイント、結びつけられたネットワーク・ランタイム・ルールが一致していて、ポリシーの鮮度の上限内であること。
- 予約の証明と指定された買い手。続いて、設定された Quantus ノードを通して、ネイティブの提案の正確な呼び出し内容、メンバー、承認の状況、有効期限。
- ウォレットが組み立てる購入が、コミットされた条件どおりであること。そのうえで、ウォレット自身の画面であなたが承認します。
必須のチェックが 1 つでも通らなければ、購入は断られます。購入ポリシーを含まないビルドは購入を断ります。また、証人はメインネットでは無効のままです。有効な証明が裏づけるのは、証明されたチェックポイントです。そのあとの取引が成功し続けることまでは保証できません。最終的な取引の結果とファイナリティを確認してください。