Zum Hauptinhalt springen

Arbeitsablauf

Der ZCash Naming Service (zNS) ermöglicht es Benutzern, sich zu registrieren, die auflösende Adresse zu aktualisieren, auf einen anderen Eigentümer zu übertragen und auf dem Marktplatz menschenlesbare Domainnamen (z. B. myname.zcash) aufzulisten und sie sicher ZCash-Adressen zuzuordnen.

Da ZCash eine UTXO-basierte Blockchain ohne universelle Smart Contracts ist, kann sie ein komplexes Datenbanksystem wie eine Domänenregistrierung nicht nativ ausführen. Um dieses Problem zu lösen, verwendet zNS eine Architektur im Rollup-Stil, die Operationen außerhalb der Kette ausführt, Daten auf ZCash speichert und die Sicherheit auf Arbitrum verankert.

Das System wird von fünf miteinander verbundenen Komponenten angetrieben:

1. ZCash Blockchain: Die Datenverfügbarkeitsschicht​

Jede Aktion, die ein Benutzer ausführt – Registrierung eines Namens (REG), Aktualisierung einer Adresse (UPD), Übertragung des Eigentums (CHG), Auflistung auf dem Marktplatz (LST), Aufhebung der Auflistung (ULT) oder Kauf (BUY) – beginnt als native ZCash-Transaktion. Die Transaktion enthält einen strukturierten Textbefehl im Transaktionsmemofeld (z. B. zNS:1:REG:domain:address:pubkey:nonce:signature).

  • Die ZCash-Kette ist die Quelle der Wahrheit. Sie speichert dauerhaft jeden Domänenbefehl. Ohne eine aufgezeichnete ZCash-Transaktion können keine Statusänderungen stattfinden.

2. Der Registrar-Knoten: Der Sequenzer​

Ein automatisierter Registrarknoten scannt die Blockchain ZCash. Es liest die Domänenbefehle, überprüft, ob der Benutzer die korrekte Transaktionsgebühr bezahlt hat, und stellt die Vorgänge in die Warteschlange. Alle 10 Minuten bündelt der Registrar diese Vorgänge in einem einzigen Batch.

3. SP1 zkVM: Die Zero-Knowledge Engine (von Succinct)​

Der Transaktionsstapel wird an die SP1 Zero-Knowledge Virtual Machine (zkVM) gesendet. Die zkVM führt ein spezielles Rust-Gastprogramm aus, das als strenger Protokoll-Schiedsrichter fungiert. Der Prüfer prüft jede Transaktion im Stapel:

  • Sind die Signaturen gültig und von den tatsächlichen Domaininhabern unterzeichnet?
  • Werden die Nonces strikt erhöht, um Wiederholungsangriffe zu verhindern?
  • Sind die Domänenpräfixe korrekt formatiert?
  • Zahlt eine BUY-Transaktion genau den Preis, der in der LST-Transaktion angegeben ist?
  • Geht der old_root mithilfe mathematischer Merkle-Beweise korrekt in den new_root über?

Wenn alle Regeln erfüllt sind, generiert die zkVM einen ZK-SNARK-Kryptografienachweis (unter Verwendung von Groth16). Bei diesem Beweis handelt es sich um ein kleines Zertifikat, das mathematisch erklärt: * „Beginnend mit der Statuswurzel A und nach Anwendung dieses gültigen Transaktionsstapels ist die neue Statuswurzel B.“*

Jede kompilierte Version dieses Gastprogramms liefert eine eindeutige kryptografische Kennung namens Verification Key (vkey). Der vkey ist ein 32-Byte-Hash der Struktur des kompilierten Gastprogramms selbst. Wenn auch nur eine einzige Zeile des Bestätigungscodes geändert wird, kompiliert das Programm zu einem völlig anderen vkey.

4. Arbitrum Smart Contract: Der Anker​

Der generierte ZK-Beweis und seine öffentlichen Eingaben werden an den zNSAnchor Smart Contract auf Arbitrum gesendet. Der Vertrag fungiert als Abwicklungsgateway.

  • Die kryptografische Bindung: Innerhalb des Smart-Vertrags wird der programVkey (der erwartete 32-Byte-Hash des Gastprogramms) in der Kette gespeichert. Wenn ein Beweis eingereicht wird, leitet der Vertrag den Beweis und den programVkey an das Succinct SP1 Verifier Gateway weiter.
  • Key-Lock-Validierung: Das Verifizierungs-Gateway genehmigt den Nachweis nur, wenn er vom exakten Gastprogramm generiert wurde, das mit dem registrierten programVkey übereinstimmt.
  • Wenn der Nachweis gültig ist und anhand des registrierten programVkey überprüft wird, aktualisiert der Vertrag die offizielle, weltweit akzeptierte Staatswurzel auf B und speichert sie in seinem Verlauf.
  • Wenn eine einzelne Regel verletzt wurde oder der Beweis mit einem modifizierten Gastprogramm generiert wurde (was zu einem anderen vkey führen würde), lehnt der Vertrag die Transaktion ab und verhindert so unbefugte Zustandsübergänge.

5. Verteilte Indexer: Die Resolver​

Jeder kann einen unabhängigen Indexerknoten ausführen. Indexer durchsuchen die ZCash-Blockchain nach Domänentransaktionen und durchsuchen den Arbitrum-Vertrag nach verifizierten Root-Checkpoints. Sie wenden die Transaktionen lokal an, berechnen ihren eigenen Merkle-Baum und überprüfen, ob ihr lokaler Stamm mit dem Arbitrum-Prüfpunkt übereinstimmt.

  • Dadurch wird sichergestellt, dass alle Indexer, unabhängig davon, wo sie ausgeführt werden, Domänen immer in die genau gleiche Zieladresse auflösen (wodurch ein einziger einheitlicher Status auf verteilten Enden aufrechterhalten wird).