Zum Hauptinhalt springen

Funktionsweise

Der PIVX Naming Service (PiNS) erlaubt es, menschenlesbare Domainnamen (etwa myname.pivx) zu registrieren, die Auflösungsadresse zu ändern, sie an andere Inhaber zu übertragen und auf dem Marktplatz anzubieten — und sie sicher auf PIVX-Adressen abzubilden.

Da PIVX eine UTXO-basierte Blockchain ohne universelle Smart Contracts ist, kann sie ein komplexes Datenbanksystem wie ein Domainregister nicht selbst betreiben. Deshalb nutzt PiNS eine Rollup-artige Architektur: Operationen werden off-chain ausgeführt, Daten liegen auf PIVX, und die Sicherheit wird auf der BNB Smart Chain verankert.

Das System besteht aus fünf miteinander verbundenen Komponenten:

1. Die PIVX-Blockchain: die Datenverfügbarkeitsschicht​

Jede Nutzeraktion — einen Namen registrieren (REG), eine Adresse ändern (UPD), Eigentum übertragen (CHG), auf dem Marktplatz anbieten (LST), vom Markt nehmen (ULT) oder kaufen (BUY) — beginnt als gewöhnliche PIVX-Transaktion. Die Transaktion enthält im Memo-Feld einen strukturierten Textbefehl (z. B. PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • Die PIVX-Kette ist die Quelle der Wahrheit. Sie speichert jeden Domainbefehl dauerhaft. Ohne eine aufgezeichnete PIVX-Transaktion kann sich kein Zustand ändern.

2. Der Registrar-Knoten: der Sequencer​

Ein automatischer Registrar-Knoten scannt die PIVX-Blockchain. Er liest die Domainbefehle, prüft, ob der Nutzer die korrekte Gebühr gezahlt hat, und stellt die Operationen in eine Warteschlange. Alle 10 Minuten bündelt der Registrar diese Operationen zu einem einzigen Batch.

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

Der Transaktions-Batch geht an die SP1 Zero-Knowledge Virtual Machine (zkVM). Die zkVM führt ein spezialisiertes Rust-Gastprogramm aus, das als strenger Protokoll-Schiedsrichter arbeitet. Der Prover prüft jede Transaktion im Batch:

  • Sind die Signaturen gültig und von den tatsächlichen Domaininhabern erstellt?
  • Sind die Nonces streng aufsteigend, um Replay-Angriffe zu verhindern?
  • Sind die Domain-Präfixe korrekt formatiert?
  • Zahlt eine BUY-Transaktion exakt den in der LST-Transaktion angegebenen Preis?
  • Geht old_root mittels mathematischer Merkle-Beweise korrekt in new_root über?

Sind alle Regeln erfüllt, erzeugt die zkVM einen kryptografischen ZK-SNARK-Beweis (mit Groth16). Dieser Beweis ist ein winziges Zertifikat, das mathematisch erklärt: „Ausgehend von Zustands-Root A ist der neue Zustands-Root nach Anwendung dieses gültigen Transaktions-Batches B.“

Jede kompilierte Fassung dieses Gastprogramms ergibt eine eindeutige kryptografische Kennung, den Verification Key (vkey). Der vkey ist ein 32-Byte-Hash der Struktur des kompilierten Gastprogramms selbst. Wird auch nur eine Zeile des Prüfcodes geändert, kompiliert das Programm zu einem völlig anderen vkey.

4. Der Vertrag auf der BNB Smart Chain: der Anker​

Der erzeugte ZK-Beweis und seine öffentlichen Eingaben gehen an den PiNSAnchor-Smart-Contract auf der BNB Smart Chain. Der Vertrag fungiert als Abwicklungs-Gateway.

  • Die kryptografische Bindung: Im Smart Contract ist der programVkey (der erwartete 32-Byte-Hash des Gastprogramms) on-chain hinterlegt. Wird ein Beweis eingereicht, leitet der Vertrag ihn zusammen mit dem programVkey an das SP1 Verifier Gateway von Succinct weiter.
  • Schlüssel-Schloss-Prüfung: Das Verifier-Gateway akzeptiert den Beweis nur, wenn er von genau dem Gastprogramm erzeugt wurde, das dem hinterlegten programVkey entspricht.
  • Ist der Beweis gültig und gegen den hinterlegten programVkey verifiziert, aktualisiert der Vertrag den offiziellen, allgemein anerkannten Zustands-Root auf B und speichert ihn in seiner Historie.
  • Wurde auch nur eine Regel verletzt oder der Beweis mit einem veränderten Gastprogramm erzeugt (was einen anderen vkey ergäbe), weist der Vertrag die Transaktion zurück und verhindert so unbefugte Zustandsübergänge.

Warum die BNB Smart Chain​

Die Ankerkette hat nur eine Aufgabe: einen Root speichern und einen Beweis prüfen. Entscheidend ist daher allein, wie schnell ein Checkpoint endgültig wird und wie sicher man sein kann, dass er es bleibt.

  • Blockzeiten von rund 2 Sekunden, sodass ein Batch fast unmittelbar nach dem Beweis verankert ist und Indexer schnell auf einem neuen Checkpoint konvergieren.
  • In der Praxis keine tiefen Reorganisationen, sodass einem Indexer der Checkpoint, auf den er synchronisiert hat, nicht unter den Füßen weggezogen wird. Eine Ankerkette mit tiefen Reorganisationen würde Indexer zwingen, bereits als abgeschlossen behandelten Zustand zurückzurollen.
  • Die Beweisprüfung ist ein fester, günstiger On-Chain-Kostenpunkt, unabhängig von der Batch-Größe — eine Groth16-Prüfung deckt alle Operationen des Batches ab.

5. Verteilte Indexer: die Resolver​

Jeder kann einen unabhängigen Indexer-Knoten betreiben. Indexer durchsuchen die PIVX-Blockchain nach Domaintransaktionen und den Vertrag auf der BNB Smart Chain nach verifizierten Root-Checkpoints. Sie wenden die Transaktionen lokal an, berechnen ihren eigenen Merkle Tree und prüfen, ob ihr lokaler Root mit dem On-Chain-Checkpoint übereinstimmt.

  • So ist sichergestellt, dass alle Indexer, wo immer sie laufen, Domains stets auf exakt dieselbe Zieladresse auflösen (ein einheitlicher Zustand über alle verteilten Knoten hinweg).