Zum Hauptinhalt springen

Sicherheitsgarantien

Diese Seite sagt genau, was PiNS garantiert und was nicht. Genauigkeit ist hier nützlicher als Beruhigung: Was stark ist, ist wirklich stark, und zu wissen, wo die Grenzen verlaufen, ist gerade das, was Verlass darauf erlaubt.

Die Eigenschaft: Betrug wird sichtbar​

PiNS ist betrugsevident (fraud-evident). Jeder Regelverstoß ist entweder von vornherein nicht beweisbar oder für jeden, der hinsieht, öffentlich erkennbar — und die dafür nötigen Daten sind veröffentlicht, sodass das Hinsehen weder Erlaubnis noch Mitwirkung des Betreibers erfordert.

Wichtig ist die Unterscheidung zwischen den beiden Hälften. Eigentum und Zustandsübergänge werden kryptografisch durchgesetzt und können schlicht nicht verletzt werden. Alles Übrige wird durch unabhängige Replikation festgestellt, wo eine Abweichung von sämtlichen Replikaten zugleich widerlegt wird. Beides ist stark — auf unterschiedliche Weise, und diese Seite sagt ausdrücklich, was wo gilt.

Was überhaupt nicht passieren kann​

Dies wird durch Mathematik durchgesetzt. Keine Handlung des Betreibers kann es umgehen.

  • Eine Domain kann ihrem Inhaber nicht entzogen werden. Jede Zustandsänderung erfordert eine Ed25519-Signatur mit dem Schlüssel, den die Operation verlangt, geprüft innerhalb der Schaltung mit strenger Verifikation. Die Registrierungsstelle besitzt Ihren Schlüssel nicht und kann keinen fälschen.
  • Ein Name kann nicht zweimal registriert werden. REG erfordert einen Nichtzugehörigkeitsbeweis; ein bereits existierender Name kann keinen erbringen.
  • Ein Verkauf zu einem Preis, den der Verkäufer nicht signiert hat, ist unmöglich. BUY verlangt, dass der gezahlte Preis dem angebotenen entspricht, der durch das signierte LST des Verkäufers im Baum festgeschrieben ist.
  • Ohne gültigen Beweis kann kein Zustands-Root verankert werden. Der Anchor-Vertrag auf der BNB Smart Chain prüft jeden Beweis gegen programVkey, bevor er einen Root annimmt. Ein ungültiger Übergang lässt sich schlicht nicht beweisen.
  • Die Schaltung kann nicht heimlich ausgetauscht werden. programVkey legt sich auf das exakt kompilierte Programm fest. Eine geänderte Zeile ändert den Schlüssel, und den Schlüssel on-chain zu ändern ist eine Zwei-Parteien-Handlung, die Sequencer und Eigentümer gemeinsam erfordert.

Was durch Beobachtung statt durch die Schaltung verifiziert wird​

Manche Eigenschaften werden nicht im Beweis durchgesetzt, sondern von jedem festgestellt, der die öffentlichen Daten wiedergibt. Das ist ein anderer Mechanismus, kein schwächeres Ergebnis: Diese Punkte kann jeder Beobachter ohne Erlaubnis prüfen, und eine Abweichung ist allen zugleich sichtbar statt nur wenigen Privilegierten.

  • Aufnahme und Reihenfolge der Befehle. Die Batches stellt die Registrierungsstelle zusammen, sie bringt die Befehle also in eine Reihenfolge. Da Protokolladresse und Viewing Key veröffentlicht sind, leitet jeder unabhängige Indexer dieselbe Reihenfolge aus der Kette selbst ab und berechnet denselben Root. Ein ausgelassener oder umsortierter Befehl erzeugt einen Root, den jedes Replikat widerlegt — sofort und ohne dass jemand danach suchen müsste.
  • Die von einem Batch gemeldete end_block_height. Sie wird an die öffentlichen Ausgaben durchgereicht statt in der Schaltung eingeschränkt, weil die Replikation sie ohnehin feststellt: Ein Indexer, der die Kette wiedergibt, weiß, welchen Block der Batch abdeckte, sodass eine falsche Höhe genauso auffällt wie jede andere Abweichung.
  • Auszahlungsziele. Auszahlungsbeträge, Gebühren und Verpflichtungen sind über den veröffentlichten Viewing Key vollständig prüfbar — jede Auszahlung trägt ein Memo, das das abgerechnete Konto nennt, sodass jeder das Guthabenbuch rekonstruieren kann. Nicht im öffentlichen Datenbestand steht, welche Zieladresse der Nutzer angegeben hat, denn diese Anfrage erfolgt auf der Website. Diesen Teil bestätigt der Empfänger unmittelbar selbst, da er die von ihm signierte Anfrage besitzt. Siehe Vertrauen & Privatsphäre.

Warum die Replikation die eigentliche Garantie ist​

Der ZK-Beweis beantwortet: Wurden bei diesen Eingaben die Regeln eingehalten?

Die Replikation beantwortet: Waren das die echten Eingaben?

Die zweite Frage ist in der Praxis die wichtigere, und sie wird nicht von der Kryptografie beantwortet — sondern dadurch, dass die Registrierungsstelle ihre Protokolladresse und ihren Viewing Key veröffentlicht. So kann jeder die gesamte Befehlshistorie ab Genesis entschlüsseln, sie durch den quelloffenen Indexer wiedergeben und Roots vergleichen. Eine abweichende Registrierungsstelle erzeugt einen Root, den jedes unabhängige Replikat widerlegt.

Deshalb ist der öffentliche Viewing Key kein Detail. Er ist der Mechanismus.

Ein souveräner Rollup, genau gesagt​

Strukturell ist PiNS ein ZK-Rollup:

  • Datenverfügbarkeit — jeder Befehl liegt im Memo einer PIVX-Transaktion, mit der Zahlung in derselben abgeschirmten Note, sodass Absicht und Zahlung untrennbar verbunden sind.
  • Ausführung — off-chain, in der SP1 zkVM.
  • Abwicklung — die BNB Smart Chain speichert den verankerten Root und prüft Beweise in Sekunden.

Anders als bei einem typischen Rollup ist die Datenverfügbarkeitsschicht eine Privacy-Chain, sodass „jeder kann die Eingaben lesen“ die Veröffentlichung des Viewing Key voraussetzt — die erfolgt ist.

Das selbst überprüfen​

Nichts davon muss man glauben:

  • Reproduzieren Sie programVkey, indem Sie den Prover kompilieren und mit dem Vertrag vergleichen.
  • Geben Sie die Kette mit dem veröffentlichten Viewing Key durch Ihren eigenen Indexer wieder und vergleichen Sie Roots.
  • Prüfen Sie jede einzelne Auflösung mit einem Merkle-Beweis plus On-Chain-Root-Abgleich — siehe Beweise prüfen.