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

ワークフロー

ZCash ネーミング サービス (zNS) を使用すると、ユーザーは、解決アドレスの登録、更新、別の所有者への転送、人間が判読できるドメイン名 (myname.zcash など) をマーケットプレイスにリストし、それらを ZCash アドレスに安全にマッピングできます。

ZCash は汎用スマート コントラクトを持たない UTXO ベースのブロックチェーンであるため、ドメイン レジストリのような複雑なデータベース システムをネイティブに実行できません。これを解決するために、zNS はオフチェーンで操作を実行し、ZCash にデータを保存し、Arbitrum にセキュリティを固定する ロールアップ スタイルのアーキテクチャ を使用します。

このシステムは、相互接続された 5 つのコンポーネントによって駆動されます。

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

ユーザーが行うすべてのアクション (名前の登録 (REG)、住所の更新 (UPD)、所有権の譲渡 (CHG)、マーケットプレイスへの上場 (LST)、上場解除 (ULT)、または購入 (BUY) は、ネイティブ ZCash トランザクションとして開始されます。トランザクションには、トランザクション メモ フィールドに構造化テキスト コマンドが含まれています (例: zNS:1:REG:domain:address:pubkey:nonce:signature)。

  • ZCash チェーンは真実の情報源です。 すべてのドメイン コマンドが永続的に保存されます。記録された ZCash トランザクションがなければ、状態の変更は発生しません。

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

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

3. SP1 zkVM: ゼロ知識エンジン (Succinct による)​

トランザクションのバッチは SP1 ゼロナレッジ仮想マシン (zkVM) に送信されます。 zkVM は、厳密なプロトコル審判として機能する特殊な Rust ゲスト プログラム を実行します。証明者はバッチ内のすべてのトランザクションをチェックします。

  • 署名は有効であり、実際のドメイン所有者によって署名されていますか?
  • リプレイ攻撃を防ぐためにナンスは厳密に増加していますか?
  • ドメインプレフィックスは正しくフォーマットされていますか?
  • BUY トランザクションは、LST トランザクションで指定された正確な価格を支払いますか?
  • 数学的なマークル証明を使用して、old_root は new_root に正しく遷移しますか?

すべてのルールが満たされる場合、zkVM は ZK-SNARK 暗号証明を生成します (Groth16 を使用)。この証明は、数学的に宣言する小さな証明書です: 「状態ルート A から始めて、この有効なトランザクションのバッチを適用した後、新しい状態ルートは B になります。」

このゲスト プログラムのコンパイルされたバージョンごとに、検証キー (vkey) と呼ばれる一意の暗号化識別子が生成されます。 vkey は、コンパイルされたゲスト プログラムの構造自体の 32 バイトのハッシュです。検証コードが 1 行でも変更されると、プログラムは完全に異なる vkey にコンパイルされます。

4. Arbitrum スマート コントラクト: アンカー​

生成された ZK 証明とそのパブリック入力は、Arbitrum 上の zNSAnchor スマート コントラクト に送信されます。契約は決済ゲートウェイとして機能します。

  • 暗号バインド: スマート コントラクト内では、programVkey (ゲスト プログラムの予想される 32 バイトのハッシュ) がオンチェーンに保存されます。プルーフが送信されると、コントラクトはプルーフと programVkey を Succinct SP1 Verifier Gateway に転送します。
  • キーロック検証: 検証ゲートウェイは、登録された programVkey と 正確に一致する ゲスト プログラムによって生成された証明のみを承認します。
  • 証明が有効で、登録された programVkey と照合して検証された場合、契約は、世界的に受け入れられている公式の州ルートを B に更新し、履歴に保存します。
  • 単一のルールに違反した場合、または変更されたゲスト プログラムを使用してプルーフが生成された場合 (別の vkey が生成される)、コントラクトはトランザクションを拒否し、不正な状態遷移を防ぎます。

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

誰でも独立した インデクサー ノード を実行できます。インデクサーは、ドメイン トランザクションの ZCash ブロックチェーンをスキャンし、検証済みのルート チェックポイントの Arbitrum コントラクトをスキャンします。彼らはトランザクションをローカルに適用し、独自のマークル ツリーを計算し、ローカル ルートが Arbitrum チェックポイントと一致することを確認します。

  • これにより、すべてのインデクサーがどこで実行されているかに関係なく、常にドメインを まったく同じターゲット アドレスに解決することが保証されます (分散エンドで単一の統合された状態が維持されます)。