Proovik
Zertifizieren
Öffentlicher Verifizierer · PVK-PROOF/1

Wie man einen Proovik-Nachweis überprüft, ohne Proovik zu vertrauen

Sie brauchen die Nachweisdatei (oder das PDF des Zertifikats) und Ihre Kopie des Originaldokuments. Nichts wird hochgeladen: Der Hash wird in Ihrem Browser berechnet. Darunter finden Sie die vollständige Spezifikation, Schritt für Schritt und mit echten Werten.

Version 1 Netz: Kaspa mainnet Referenzverifizierer: 248 Zeilen Python, ohne Abhängigkeiten
Werkzeug

Einen Nachweis online überprüfen

Prüfen Sie hier ein Zertifikat mit derselben Engine, die unten beschrieben wird. Das Dokument verlässt Ihr Gerät nicht: Sein SHA-256 wird in Ihrem Browser berechnet, und nur der Hash geht auf die Reise. Den Hash liefern Sie; er wird nie der Nachweisdatei entnommen. Wenn Sie das PDF des Zertifikats ablegen, wird das angehängte Beweispaket in Ihrem Browser entnommen, und auch das PDF wird nicht gesendet.

1 · Nachweisdatei

2 · Originaldokument

Der Verifizierer nimmt den Hash nie aus der Nachweisdatei: Sie liefern ihn.

Das Paket und der Hash gehen an POST /api/verify/proof. Ohne Konto. Limit: 120 Überprüfungen pro Stunde und IP.

Sie steht im PDF-Zertifikat und im Kaspa-Explorer.

Sie können ihn berechnen, indem Sie das Dokument im anderen Reiter ablegen: Der Wert wird geteilt.

Dieser Modus rekonstruiert das Paket über eine Abfrage an api.kaspa.org. Kaspa liefert den vollständigen Header nur etwa 40 Stunden nach der Verankerung: Danach lassen sich Kettenglied 3 und 4 nicht mehr neu berechnen, und der Befund lautet Nicht schlüssig, niemals „Belegt“. Für eine vollständige Überprüfung nutzen Sie die seinerzeit erfasste Nachweisdatei.

GET /api/verify/proof/{txid}?hash=…. Limit: 30 pro Stunde und IP (es wird das Netz abgefragt).

Befund ·

Belegt Nicht schlüssig Nicht belegt

Die vier Kettenglieder stimmen: Das Dokument mit diesem SHA-256 existierte, als der angegebene Block geschürft wurde. Denken Sie daran, was der Nachweis nicht belegt: weder Urheberschaft noch Wahrheitsgehalt des Inhalts.

Was neu berechnet werden konnte, stimmt, doch es fehlt eine Angabe (meist der vollständige Blockheader, außerhalb des Pruning-Fensters), um die Kette zu schließen. Das ist kein Mangel des Nachweises: Es ist eine teilweise Überprüfung. Mit der seinerzeit erfassten Nachweisdatei oder mit dem vollständigen Beweispaket lässt sie sich abschließen.

Mindestens ein Kettenglied stimmt nicht zum angegebenen Hash. Am häufigsten: Das Dokument ist nicht genau das, was versiegelt wurde (ein einziges anderes Byte verändert den SHA-256), oder die Nachweisdatei gehört nicht zu diesem Dokument. Prüfen Sie die Einzelheiten jedes Kettenglieds.

Die Transaktion im Netz ansehen
Dokument
txid
block_hash
Netz
Modus
Header
überprüft

Die Kettenglieder, eines nach dem anderen

  1. Akzeptanz-Zeuge (KIP-15)

    Das Paket enthält keinen Akzeptanz-Zeugen. Er ist optional: Er wirkt sich nicht auf den Befund aus.

Hinweise

Was jedes Kettenglied bedeutet

Tragweite des Nachweises

Was genau behauptet wird

Genauigkeit zählt hier mehr als Eloquenz, denn davon hängt ab, ob der Nachweis einer streitigen Auseinandersetzung standhält.

Was der Nachweis belegt

Dass eine Bytefolge, deren SHA-256 einen bestimmten Wert hat, in eine Transaktion des Kaspa-Netzes aufgenommen wurde, dass diese Transaktion im Header eines Blocks festgeschrieben wurde und dass über diesem Header —der einen Zeitstempel enthält— ein gültiger Proof of Work ausgeführt wurde. Da der Zeitstempel innerhalb der Daten liegt, über denen die Arbeit geleistet wurde, macht jede Änderung daran die Arbeit ungültig. Das Datum ist niemandes Erklärung: Es ist eine bereits aufgewendete physikalische Größe.

Was der Nachweis NICHT belegt

Wer das Dokument erstellt hat, ob sein Inhalt zutrifft, ob sein Urheber berechtigt war, es zu erstellen, und auch nicht, dass das Dokument nicht schon früher existierte. Er belegt Priorität zu einem Zeitpunkt, nicht Urheberschaft oder Wahrheitsgehalt. Proovik sieht das Dokument zu keinem Zeitpunkt: Es erhält nur dessen Hash.

Zum Hash

SHA-256 ist eine Hashfunktion mit 256 Bit. Zwei verschiedene Dokumente mit demselben Hashwert zu finden ist noch nie gelungen, und der geschätzte Aufwand übersteigt das, was die Menschheit berechnen kann. Stimmt der Hashwert des vorgelegten Dokuments mit dem in der Kette überein, ist es deshalb dasselbe Dokument, ohne praktischen Zweifelsspielraum.

Echtes Beispiel · 20.09.2026

Die vier Kettenglieder

Die Überprüfung ist eine Kette. Jedes Glied greift ins nächste, und es genügt, dass eines versagt, damit der Nachweis nichts wert ist. Die im Folgenden gezeigten Werte sind echt: Sie stammen aus einem am 20. September 2026 ausgestellten Zertifikat.

1 2 3 4

1 · Die Nutzdaten der Transaktion sind der Hashwert des Dokuments

Stimmt überein
Was geprüft wird
Dass der Hash Ihrer Datei genau derjenige ist, der in Kaspa steht.
Wenn es fehlschlüge
Dann hätte jemand das Dokument verändert, und sei es um ein Byte.
Wie
Jede Kaspa-Transaktion erlaubt ein freies Feld, payload. Proovik schreibt dort die 32 Bytes des SHA-256 des Dokuments hinein, und sonst nichts. Die Prüfung ist ein wörtlicher Vergleich.
Die Berechnung ansehen 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · Die Transaktion ist im Blockheader festgeschrieben

Stimmt überein
Was geprüft wird
Dass diese Transaktion zu dem Block gehört, den der Nachweis angibt, und zu keinem anderen.
Wenn es fehlschlüge
Die Transaktion gäbe es, aber nicht in diesem Block und nicht mit diesem Datum.
Wie
Kaspa hält in jedem Header der Kette eine Festlegung auf die Transaktionen fest, die dieser Block akzeptiert. Seit dem Inkrafttreten von KIP-15 ist dieses Feld, acceptedIdMerkleRoot, keine einfache Merkle-Wurzel mehr, sondern ein verketteter Wert: Er verbindet die Festlegung des Elternblocks mit der Wurzel der akzeptierten Transaktionen. Eine Neuberechnung, die diese Verkettung ignoriert, schlägt fehl, und genau das ist die häufigste Ursache fehlerhafter Überprüfungen.
Die Berechnung ansehen 
nodo(a,b) = blake2b-256( clave = "MerkleBranchHash", a ‖ b )

AIMR      = raiz Merkle sobre las transacciones aceptadas, en orden canonico
SeqCommit = nodo( SeqCommit_del_padre_seleccionado , AIMR )

valido ⟹ SeqCommit == cabecera.acceptedIdMerkleRoot
AIMRb3bc256951640ff6468511fb62ec8fb280dafb99ebf7ecd00245d0cc3c9debb3
Eltern-Seq.2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
berechnet7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
im Header7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
Zwei nachgewiesene Fallstricke

Die Reihenfolge der akzeptierten Transaktionen ist die kanonische, die KIP-15 festlegt, nicht die Reihenfolge, in der eine API sie zurückgibt, und auch nicht die Reihenfolge nach Hash. Und die Blätter des Baums eines Blocks —wenn statt der Akzeptanz die Aufnahme überprüft wird— sind nicht die txid, sondern die tx::hash, berechnet mit der vollständigen Kodierung (einschließlich der Signature Scripts und der Festlegung auf die Speichermasse).

3 · Der Header ergibt den angegebenen Block-Hash

Stimmt überein
Was geprüft wird
Dass der empfangene Header, Byte für Byte neu berechnet, genau diesen Block-Hash ergibt.
Wenn es fehlschlüge
Der Header wäre nicht der des Blocks: Das Datum darin wäre wertlos.
Wie
Der Hash eines Blocks ist der Hashwert seines serialisierten Headers. Ihn neu zu berechnen zeigt, dass der vorgelegte Header genau der ist, der er zu sein vorgibt, und dass keines seiner Felder —einschließlich des Zeitstempels— angetastet wurde.
Die Berechnung ansehen 
h = blake2b-256( clave = "BlockHash" )

h ← version                    u16  little-endian
h ← numero de niveles          u64  little-endian
para cada nivel:
    h ← numero de padres       u64  little-endian
    h ← cada hash de padre      32 bytes
h ← hashMerkleRoot             32 bytes
h ← acceptedIdMerkleRoot       32 bytes
h ← utxoCommitment             32 bytes
h ← timestamp                  u64  little-endian   ← la marca temporal
h ← bits                       u32  little-endian
h ← nonce                      u64  little-endian
h ← daaScore                   u64  little-endian
h ← blueScore                  u64  little-endian
h ← longitud de blueWork       u64  little-endian
h ← blueWork      big-endian, sin ceros a la izquierda
h ← pruningPoint               32 bytes
Block77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
Nicht verhandelbare Voraussetzung

Der Header legt sich auf alle Elternebenen fest —heute sind es 56, mit mehr als zweihundert Hashes—. Fehlt auch nur eine, lässt sich der Hashwert nicht rekonstruieren. Deshalb muss die Nachweisdatei den vollständigen Header im Moment der Verankerung erfassen: Nach etwa dreißig Stunden verwirft das Netz diese Daten, und öffentliche Dienste liefern den Header nur noch gekürzt.

4 · Über diesem Header wurde ein gültiger Proof of Work ausgeführt

Gültige Arbeit
Was geprüft wird
Dass die Arbeit über diesem Header geleistet wurde, mit diesem Datum darin. Das Datum zu ändern macht die Arbeit ungültig.
Wenn es fehlschlüge
Das Datum wäre eine Erklärung, keine bereits aufgewendete physikalische Größe.
Wie
Hier hört der Nachweis auf, eine Behauptung zu sein, und wird zur Feststellung. Kaspa verlangt, dass das Ergebnis seiner Arbeitsfunktion (kHeavyHash), angewandt auf den Header, unter einem Schwellenwert liegt. Das zu erreichen erfordert Billiarden von Versuchen: echte, unwiederbringlich aufgewendete Energie.
Die Berechnung ansehen 
pre = hash_de_cabecera( con timestamp = 0 y nonce = 0 )
M   = matriz 64x64 generada con xoshiro256++ sembrado con pre,
      regenerada hasta que su rango sea 64
p   = cSHAKE256("ProofOfWorkHash")( pre ‖ timestamp ‖ 32 ceros ‖ nonce )
r   = cSHAKE256("HeavyHash")( (M · nibbles(p)) ⊕ p )

valido  ⟹  entero_little_endian(r)  ≤  objetivo(bits)
pre6e4f2ca8feb279a54f2c4ac8d57c867917f1766a7936a5bd7bd9351557d3c6f7
Ergebnis0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
Zielwert0x2345b0000000000000000000000000000000000000000000000
verankert2026-09-20 00:03:00 UTC
Das Datum

Warum das Datum eine physikalische Größe ist und keine Erklärung

Das ist der Punkt, den die streitige Auseinandersetzung meist verlangt, und deshalb zeigt man ihn besser, als dass man über ihn argumentiert. Der Zeitstempel liegt innerhalb des Headers, und der Header ist die Eingabe des Proof of Work. Wer die Uhrzeit ändert, ändert die Eingabe, und die Arbeit ist nicht mehr gültig. Das lässt sich experimentell prüfen, indem man den in Schritt 4 überprüften Header verändert und die Berechnung wiederholt:

Wirkung einer Veränderung des Headers auf das Ergebnis des Proof of Work
Header Ergebnis der Arbeit Befund
Original, unangetastet0x15222b53caabb3b049ec…Gültig
nonce + 10x6775abc19ba960657f66…Ungültig
timestamp um eine Sekunde vorgestellt0xaee1e8274b1d268866ed…Ungültig
Die Folge

Um das Dokument mit einem anderen Datum vorzulegen, müsste man den Proof of Work dieses Headers gegen die tatsächliche Schwierigkeit des Netzes neu leisten. Das ist keine Kostenhürde: Es ist eine Rechenhürde in der Größenordnung der gesamten Netzleistung über den Zeitraum, den man fälschen will. Niemand erklärt das Datum. Das Datum wird bezahlt.

Beständigkeit

Funktioniert das auch nach künftigen Hardforks?

Die ehrliche Antwort lautet ja, und es lohnt sich zu verstehen, warum. Ein erfasster Nachweis ist keine laufende Abfrage an das Netz: Er ist eine historische Tatsache, überprüft nach den Regeln, die im Moment der Verankerung galten. Kaspa verändert sich mit der Zeit —der Übergang Crescendo/Toccata änderte etwa den Takt des DAA und die Schwierigkeitszählung—, doch das löscht die Vergangenheit nicht: Es bedeutet nur, dass ein Block vom Januar 2026 mit den Regeln vom Januar 2026 überprüft wird und einer in drei Jahren mit denen von in drei Jahren.

Der Referenzverifizierer ist genau dafür gebaut: Er unterscheidet Epochen. Er kennt den Aktivierungspunkt jeder Konsensänderung (zum Beispiel die Konstante CRESCENDO_DAA_MAINNET) und wendet auf jeden Block die Regeln seiner Epoche an, nicht die von heute. Ein späterer Hardfork fügt eine neue Epoche hinzu; er macht die früheren nicht ungültig.

Die Beständigkeit des Nachweises beruht demnach auf drei Bedingungen, die alle in der Hand dessen liegen, der ihn besitzt:

1

Innerhalb des Zeitfensters erfassen

Den vollständigen Header im Moment der Verankerung speichern, bevor das Netz die vollständigen Daten verwirft (etwa 30 bis 40 Stunden).

2

Den Nachweis aufbewahren

Die Nachweisdatei (oder das PDF, in das sie eingebettet ist) ist in sich geschlossen: Sie verweist auf keinen Server und keine Online-Abfrage.

3

Den Referenzverifizierer erhalten

248 Zeilen offener Code, ohne Abhängigkeiten, aus dem öffentlichen Quellcode von Kaspa neu ableitbar. Selbst wenn er verloren ginge, ließe er sich neu schreiben.

Prüfen Sie es selbst

Machen Sie es ohne Proovik

Der Referenzverifizierer besteht aus 248 Zeilen Python ohne externe Abhängigkeiten: Er implementiert blake2b mit Schlüssel, die Keccak-f[1600]-Permutation, den Generator xoshiro256++ und die Matrixarithmetik. Man liest ihn an einem Nachmittag und prüft ihn an zweien.

Terminal 
$ python3 verificador_kaspa.py prueba.json 0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

  OK    1. El payload on-chain es el hash del documento
  OK    2. La transaccion esta en el arbol Merkle del bloque
  OK    3. La cabecera produce el hash de bloque declarado
  OK    4. La prueba de trabajo de esa cabecera es valida

RESULTADO: PRUEBA VALIDA

Den Referenzverifizierer herunterladen

Zwei Dateien. Legen Sie sie in denselben Ordner und führen Sie die erste aus. Sie installieren nichts und gehen nie ins Netz.

verificador_kaspa.py kaspa_pow.py

Wer fremden Code lieber nicht ausführt, kann ihn neu implementieren: Die vier Algorithmen sind oben unmissverständlich beschrieben, und alle Parameter stammen aus dem öffentlichen Quellcode von rusty-kaspa. Ebenso legitim ist es, die Transaktion zum Abgleich in einem beliebigen öffentlichen Kaspa-Explorer nachzuschlagen, doch der Unterschied will verstanden sein: Der Explorer ist ein Zeugnis; die Berechnung ist ein Beweis. Diese Spezifikation gibt es, um vom Ersteren unabhängig zu sein.

Rechtlicher Rahmen

Rechtliche Tragweite

Proovik erbringt einen nicht qualifizierten elektronischen Zeitstempeldienst im Sinne von Artikel 3 Nr. 16 Buchst. i) der Verordnung (EU) Nr. 910/2014. Es lohnt sich, ausdrücklich zu sagen, was das bedeutet.

  • Nach Artikel 41 Abs. 1 der genannten Verordnung darf einem elektronischen Zeitstempel die Rechtswirkung und die Zulässigkeit als Beweismittel in Gerichtsverfahren nicht allein deshalb abgesprochen werden, weil er in elektronischer Form vorliegt oder nicht qualifiziert ist.
  • Ein nicht qualifizierter Zeitstempel genießt nicht die Vermutung der Richtigkeit von Datum und Uhrzeit nach Artikel 41 Abs. 2, die den qualifizierten vorbehalten ist. Im Bestreitensfall trägt derjenige, der den Nachweis vorlegt, die Last, ihn zu belegen.
  • Genau deshalb gibt es diese Spezifikation: damit diese Last mit einer arithmetischen Prüfung erfüllt werden kann, die jeder nachvollziehen kann, statt mit der Erklärung des Anbieters.

Proovik prüft weder Inhalt noch Urheberschaft noch Rechtmäßigkeit der Dokumente und greift zu keinem Zeitpunkt auf sie zu: Es erhält allein ihren kryptografischen Hashwert. Belegt wird ein Existenz- und Prioritätsnachweis zu einem bestimmten Zeitpunkt.

Quellen

Serialisierung von Header und Transaktion, Aufbau des Merkle-Baums und Proof of Work, nach dem Quellcode der Referenzimplementierung von Kaspa (rusty-kaspa): consensus/core/src/hashing/header.rs, consensus/core/src/hashing/tx.rs, consensus/core/src/merkle.rs, crypto/hashes/src/pow_hashers.rs, consensus/pow/.

Die als Beispiel verwendeten Werte stammen aus echten Zertifikaten und sind von jedermann überprüfbar. Diese Spezifikation wird versioniert: Die Nachweise geben in ihrem Inneren an, mit welcher Version sie ausgestellt wurden.