メインコンテンツまでスキップ

しくみ

PIVX ネームサービス（PiNS）を使うと、人が読めるドメイン名（myname.pivx など）を登録し、解決先アドレスを変更し、他の保有者へ移転し、マーケットプレイスに出品でき、それらを PIVX アドレスへ安全に対応づけられます。

PIVX は汎用スマートコントラクトを持たない UTXO ベースのブロックチェーンなので、ドメイン台帳のような複雑なデータベースシステムを自前で動かすことはできません。これを解決するために PiNS はロールアップ型のアーキテクチャを採用しています。処理はオフチェーンで実行し、データは PIVX に置き、セキュリティは BNB Smart Chain にアンカーします。

システムは相互に連携する 5 つのコンポーネントで構成されます：

1. PIVX ブロックチェーン：データ可用性レイヤー​

ユーザーのあらゆる操作 — 名前の登録（REG）、アドレスの変更（UPD）、所有権の移転（CHG）、マーケットプレイスへの出品（LST）、取り下げ（ULT）、購入（BUY）— は、通常の PIVX トランザクションとして始まります。トランザクションはメモ欄に構造化されたテキストコマンドを含みます（例：PiNS:1:REG:domain:address:pubkey:nonce:signature）。

  • 真実の源は PIVX チェーンです。 すべてのドメインコマンドを恒久的に保存します。記録された PIVX トランザクションなしには、いかなる状態変化も起こりません。

2. レジストラノード：シーケンサー​

自動化されたレジストラノードが PIVX ブロックチェーンをスキャンします。ドメインコマンドを読み取り、ユーザーが正しい手数料を支払ったかを確認し、操作をキューに入れます。10 分ごとに、レジストラはこれらの操作を 1 つのバッチにまとめます。

3. SP1 zkVM：ゼロ知識エンジン（Succinct 提供）​

トランザクションのバッチは **SP1 ゼロ知識仮想マシン（zkVM）**へ送られます。zkVM は厳格なプロトコルの審判として振る舞う専用の Rust ゲストプログラムを実行します。証明生成器はバッチ内の各トランザクションを検査します：

  • 署名は有効で、実際のドメイン保有者によるものか？
  • リプレイ攻撃を防ぐために nonce は厳密に増加しているか？
  • ドメインの接頭辞は正しく整形されているか？
  • BUY トランザクションは LST トランザクションに指定された価格をちょうど支払っているか？
  • 数学的なマークル証明に基づき、old_root は new_root へ正しく遷移しているか？

すべてのルールが満たされると、zkVM は（Groth16 を用いて）ZK-SNARK の暗号学的証明を生成します。この証明は次のことを数学的に宣言する、ごく小さな証書です：「状態ルート A から出発し、この有効なトランザクションバッチを適用すると、新しい状態ルートは B である。」

このゲストプログラムのコンパイル結果はそれぞれ、**検証鍵（vkey）**と呼ばれる一意の暗号学的識別子を生みます。vkey はコンパイル済みゲストプログラムの構造そのものの 32 バイトハッシュです。検証コードを 1 行変えるだけで、プログラムはまったく別の vkey にコンパイルされます。

4. BNB Smart Chain 上のコントラクト：アンカー​

生成された ZK 証明とその公開入力は、BNB Smart Chain 上の PiNSAnchor スマートコントラクトへ送られます。コントラクトは決済ゲートウェイとして機能します。

  • 暗号学的な結びつき：スマートコントラクト内部には programVkey（ゲストプログラムの期待される 32 バイトハッシュ）がオンチェーンに保存されています。証明が提出されると、コントラクトはそれを programVkey とともに Succinct の SP1 検証ゲートウェイへ転送します。
  • 鍵と錠の照合：検証ゲートウェイは、証明が登録済みの programVkey に一致するまさにそのゲストプログラムで生成された場合にのみ承認します。
  • 証明が有効で、登録済みの programVkey に対して検証されれば、コントラクトは公式かつ広く認められた状態ルートを B に更新し、履歴に保存します。
  • ルールが 1 つでも破られていたり、証明が改変されたゲストプログラムで生成されていたりすれば（その場合は別の vkey になります）、コントラクトはトランザクションを拒否し、許可されていない状態遷移を防ぎます。

なぜ BNB Smart Chain なのか​

アンカーチェーンの唯一の役割はルートを保存し証明を検証することなので、重要なのは、チェックポイントが どれだけ速く確定するか、そしてそれが確定のままであるとどれだけ確信できるか、その 2 点だけです。

  • ブロック時間はおよそ 2 秒なので、バッチは証明されるとほぼ同時にアンカーされ、インデクサーも新しい チェックポイントへ素早く収束します。
  • 実運用では深い再編成が起きないため、インデクサーが同期済みのチェックポイントが足元から抜き取られる ことはありません。深い再編成が起きるアンカーチェーンなら、インデクサーはすでに確定とみなした状態を 巻き戻さざるを得なくなります。
  • 証明の検証はバッチの大きさに関係なく、オンチェーンで固定かつ低コストです — 1 回の Groth16 検証が バッチ内のすべての操作をカバーします。

5. 分散インデクサー：リゾルバー​

誰でも独立したインデクサーノードを運用できます。インデクサーはドメイントランザクションを求めて PIVX ブロックチェーンをスキャンし、検証済みのルートチェックポイントを求めて BNB Smart Chain のコントラクトをスキャンします。トランザクションをローカルで適用し、自前のマークルツリーを計算し、ローカルのルートがオンチェーンのチェックポイントと一致するか確認します。

  • これにより、どこで動いていようとすべてのインデクサーが、ドメインを常にまったく同じ宛先アドレスへ解決することが保証されます（分散した各所で単一の統一された状態を保ちます）。