Zum Hauptinhalt springen

Arbeitsablauf

Mit dem PIVX Naming Service (PiNS) können Benutzer menschenlesbare Domänennamen (z. B. myname.pivx) registrieren, aktualisieren, auflisten und übertragen und sie sicher PIVX shielded (Sapling)-Adressen zuordnen.

Da es sich bei PIVX um eine UTXO-basierte Blockchain ohne universelle Smart Contracts handelt, kann ein komplexes Datenbanksystem wie eine Domänenregistrierung nicht nativ ausgeführt werden. Um dieses Problem zu lösen, verwendet PiNS eine Architektur im Rollup-Stil, die Operationen außerhalb der Kette ausführt, Daten auf PIVX speichert und die Sicherheit auf Arbitrum verankert.

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

1. PIVX Blockchain: Die Datenverfügbarkeitsschicht​

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

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

2. Der Registrar-Knoten: Der Sequenzer​

Ein automatisierter Registrarknoten scannt die PIVX-Blockchain. 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 REG0__ mithilfe mathematischer Merkle-Beweise korrekt in den REG1__ ü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 REG2__ 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 REG3__.

4. Arbitrum Smart Contract: Der Anker​

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

  • Die kryptografische Bindung: Innerhalb des Smart-Vertrags wird der REG4__ (der erwartete 32-Byte-Hash des Gastprogramms) in der Kette gespeichert. Wenn ein Beweis eingereicht wird, leitet der Vertrag den Beweis und den REG5__ 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 REG6__ übereinstimmt.
  • Wenn der Nachweis gültig ist und anhand des registrierten REG7__ überprüft wird, aktualisiert der Vertrag die offizielle, weltweit akzeptierte Staatswurzel auf REG8__ 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 REG9__ 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 PIVX-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).