Statt alle Vertragsdaten global zu veröffentlichen, übermitteln Beteiligte die nötige Historie off-chain, prüfen die Regeln selbst und kontrollieren kryptografische Commitments sowie geschlossene Single-Use Seals auf Bitcoin.
Jeder Empfänger prüft nach den Regeln des konkreten Protokolls nur den Teil der Historie, der zum empfangenen Zustand führt. Das ist partielle Replikation: Andere müssen nicht den gesamten privaten Vertragsgraphen kennen oder speichern. [4]
Die erforderlichen Daten werden außerhalb von Bitcoin als Paket aus Historie und Beweisen weitergegeben. Ein Empfänger darf nicht nur einen aktuellen Saldo akzeptieren, sondern muss die Folge der Zustandsübergänge bis zu einem vertrauenswürdigen Ursprung und die Bindung jedes Schritts an sein On-Chain-Commitment prüfen. [4]
Ein Single-Use Seal ist ein abstraktes Commitment, das über einer gewählten Nachricht nur einmal gültig geschlossen werden kann. Ein Bitcoin-UTXO kann als solches Siegel dienen: Seine Ausgabe beweist die Schließung öffentlich und in Konsensreihenfolge, während Bitcoin die Bedeutung privater Daten nicht bewertet. [3]
Proof-of-Publication verankert ein kompaktes Commitment in der öffentlichen Transaktionsreihenfolge und macht den Versuch erkennbar, dasselbe Siegel für unvereinbare Übergänge zu verwenden. Miner und Full Nodes prüfen Bitcoins Regeln, nicht die hinter dem Hash verborgene Geschäftslogik. [2]
Client-Side Validation ist ein allgemeines Entwurfsmodell und kein Synonym für RGB. Das LNP/BP-Register führt LNPBP-9 als informativen Entwurf; zugehörige Bibliotheken bieten Schnittstellen für Commitments, Serialisierung und Single-Use Seals, auf denen Protokolle eigene Zustände und Regeln definieren. [5]
Datenschutz und Skalierung verlagern die Pflicht zur Datenaufbewahrung auf deren Eigentümer. Liefert ein Absender die vollständige Historie nicht oder verliert der Empfänger einen nötigen Teil, kann die öffentliche Blockchain ihn nicht aus dem Commitment rekonstruieren und die lokale Prüfung endet womöglich ohne belegbaren Zustand. [4]
Öffentlich sichtbar sind meist nur eine Bitcoin-Transaktion und ein kurzes Commitment, nicht der ganze Vertrag. Das reduziert die globale Datenlast, garantiert aber keine Anonymität: Zeitpunkt, Gegenparteien, Datenübergabe und erkennbare Anchor-Strukturen können Metadaten erzeugen. [1]
Zu prüfen sind das genaue Protokoll, vertrauenswürdige Genesis oder Schema, Seal-Definition, Commitment Scheme, vollständige verknüpfte Historie, Status der Bitcoin-Transaktion und Softwareversion. Ein Hash on-chain beweist allein weder Gültigkeit noch Wert oder Eigentum eines Assets. [5]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit UTXO, Double Spend, Hash, Taproot, Sidechain, Konsensregeln. Auf diesen Eintrag verweisen außerdem RGB Protocol, Taproot Assets.
01Führen Bitcoin Full Nodes Client-Side Validation aus?+
Nein. Full Nodes prüfen die Bitcoin-Transaktion und ihre Konsensregeln; private Daten und darauf beruhende Regeln prüft der Empfänger lokal mit dem passenden Client.