Blockchain: Zustand, Konsens und Verifizierung

Eine Blockchain ist ein versioniertes Protokoll zum Ordnen und Validieren von Zustandsübergängen über Replikate hinweg. Hash-Links sind nur eine Komponente; Vertrauen hängt von Konsens, Berechtigungen, unabhängiger Überprüfung, Datenverfügbarkeit, Governance und Wiederherstellung ab.

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Eine Blockchain ist ein versioniertes Protokoll, das es mehreren Replikaten ermöglicht, vorgeschlagene Transaktionen zu ordnen, Zustandsübergänge zu validieren und unter festgelegten Konsens- und Netzwerkannahmen auf einen akzeptierten Verlauf zu konvergieren. Ein Block ist ein protokolldefinierter Container mit Transaktionen oder anderen Daten sowie Verpflichtungen zur Vorgeschichte und zum resultierenden Zustand; Die Kette oder der gerichtete Verlauf verbindet akzeptierte Container durch kryptografische Verpflichtungen.

Hash-Verknüpfungen machen unbefugte nachträgliche Änderungen erkennbar, machen ein System für sich genommen jedoch weder dezentral noch unveränderlich oder korrekt. Diese Eigenschaften hängen davon ab, wer vorschlagen und validieren darf, ob Benutzer unabhängig prüfen können, sowie von Fork-Choice- und Finalitätsregeln, Datenverfügbarkeit, Client-Vielfalt, Governance, Schlüsselkontrolle, Anreizen und Wiederherstellungsverfahren.

Blockchains können UTXO-, Konto-, Objekt- oder anwendungsspezifische Zustandsmodelle verwenden; Proof of Work, Proof of Stake, byzantinisch fehlertolerante Abstimmungen oder einen zugangsbeschränkten Konsens; sowie probabilistische oder checkpointbasierte Finalität. Das Wort „Blockchain“ bezeichnet daher eine breite Familie von Architekturen, keine Sicherheitsgarantie und kein einzelnes Datenbankprodukt.

Erstellen

Eine Wallet erstellt eine Transaktion mit Ziel, Wert, Gebührenparametern und Replay-Schutzdaten wie ausgegebenen UTXOs oder einer Nonce.

Wie es funktioniert

Legen Sie Chain, Netzwerk, Protokollversion, Berechtigungsmodell, Zustandsmodell und die zu prüfende Behauptung eindeutig fest. Dokumentieren Sie Genesis oder vertrauenswürdigen Checkpoint, Chain-ID, Client-Implementierung und Upgrade-Berechtigung.
Erzeugen Sie die exakten Transaktions- und Autorisierungsbytes. Prüfen Sie vor der Übertragung Absender- oder Input-Eigentum, Nonce oder Verweise auf nicht ausgegebene Outputs, Betrag, Ziel, Gebührenlimits, Gültigkeitsfenster, Signaturen und Anwendungsaufrufe.
Verteilen Sie die Transaktion über Peers oder Gateways. Unterscheiden Sie lokale Zulassungs- und Mempool-Richtlinien von der Konsensgültigkeit. Ein Knoten kann eine Transaktion, die in einem Block gültig sein könnte, ablehnen, verzögern, ersetzen oder nie empfangen.
Ein Proposer wählt Transaktionen aus, ordnet sie in einem Kandidatenblock an und bindet sich an Protokollfelder wie den Parent-Block sowie Transaktions-, Beleg-, Zustands- oder Datenwurzeln. Die Reihenfolge kann Ausführungsergebnisse, Gebühren, Liquidationen und extrahierbaren Wert beeinflussen.
Unabhängige Knoten deserialisieren den Block, überprüfen die Konsensautorisierung und jeden erforderlichen Zustandsübergang, berechnen Verpflichtungen neu und lehnen ungültige oder nicht verfügbare Eingaben gemäß ihren Regeln ab. Unterschriften des Herstellers oder Arbeitsnachweise haben keinen Vorrang vor einer fehlgeschlagenen Validierung.
Bei der Fork-Auswahl wird zwischen konkurrierenden gültigen Historien ausgewählt, während Bestätigungen, Abstimmungen oder Kontrollpunkte das Reorganisationsrisiko im Laufe der Zeit ändern. „Eingeschlossen“, „sicher“ und „abgeschlossen“ sind unterschiedliche Zustände und bleiben protokollspezifisch.
Gleichen Sie den Protokollzustand mit der Anwendungsabsicht, der Verwahrung, der Buchhaltung einer Bridge oder Handelsplattform und den Archivierungsanforderungen ab. Bewahren Sie Transaktionsbytes, Block-Hash, Höhe oder Slot, Beleg, Logs, Zustandsnachweis, Finalitätsstatus, Client-Version und Nachweise eines unabhängigen Endpunkts auf.

Ausgearbeitete Beispiele

Abgleich des Kontozustands. Ein Konto beginnt mit 10 ETH und Nonce 41. Eine gültige Transaktion mit Nonce 41 überträgt 2 ETH und verbraucht 0.00042 ETH an Gebühren. Der vereinfachte Folgezustand beträgt damit 10 - 2 - 0.00042 = 7.99958 ETH; der Empfänger erhält 2 ETH, und die Nonce des Absenders wird 42. Eine gültige Signatur allein beweist weder den vorherigen Kontostand noch die erfolgreiche Ausführung.
UTXO-Erhaltung. Eine Transaktion verbraucht Eingaben von 0.80 BTC und 0.35 BTC, insgesamt 1.15 BTC. Ausgaben von 1.00 BTC und 0.1496 BTC insgesamt 1.1496 BTC; Die Differenz beträgt 1.15 - 1.1496 = 0.0004 BTC an Gebühren. Knoten müssen außerdem überprüfen, ob jede referenzierte Ausgabe vorhanden ist, nicht ausgegeben wurde und ihre Ausgabebedingungen erfüllt.
Commitment-Proof-Größe. In einem anschaulichen ausgewogenen binären Merkle-Baum mit 8 leaves benötigt ein Einschlusspfad log2(8) = 3 sibling hashes. Bei 256-bit = 32-byte-Hashes belegen diese Geschwister 3 * 32 = 96 bytes vor Indizes und Codierung. Der Beweis bindet ein Blatt an eine behauptete Wurzel; es beweist nicht, dass die Quelldaten wahrheitsgemäß oder aktuell verfügbar sind.
Gewicht ist nicht die Anzahl der Knoten. In einem beispielhaften Abstimmungsprotokoll, dessen angegebene Finalitätsregel >= 2/3 Gewicht ist, halten Validatoren 30%, 25%, 20%, 15%, 10%. Die ersten drei ergeben insgesamt 30 + 25 + 20 = 75% und überschreiten die Regel, während die ersten beiden insgesamt 55% ergeben und dies nicht tun. Echte Schwellenwerte, Korrelations-, Äquivokations- und Wiederherstellungsregeln müssen aus dem genannten Protokoll stammen.

Risiken

Verwendung der falschen Kette, des falschen Netzwerks, der Verzweigung, des falschen Kontrollpunkts oder der falschen Kettenkennung.
Behandlung eines Markennamens als vollständige Protokoll- oder Vertrauensmodellspezifikation.
Annehmen, dass Hash-Verknüpfungen allein autorisierte oder durch Konsens beschlossene Umschreibungen verhindern.
Verwechslung des Blockvorschlags eines Produzenten mit der unabhängigen Knotenvalidierung.
Behandeln von Mempool-Akzeptanz, Übertragung, Inklusion, Ausführungserfolg und Endgültigkeit als ein Zustand.
Signieren von Bytes, Domänen oder Zielen, die sich von denen unterscheiden, die auf der Schnittstelle angezeigt werden.
Nonces wiederverwenden, veraltete UTXOs ausgeben oder Gebühren und Wechselgeld falsch berechnen.
Token-Symbolen, Beschriftungen, Ereignissen oder Explorer-Interpretationen statt Protokoll-IDs und -Zustand vertrauen.
Behandeln signierter Oracle-, Bridge- oder Dokumenteingaben als Beweis dafür, dass Off-Chain-Behauptungen wahr sind.
Ignorieren von Transaktionsanordnungen, Zensur, Front-Running und Konzentration von Antragstellern oder Bauherren.
Zählen von Knoten oder Validatoren, ohne gemeinsame Operatoren, Gewichtungen und Infrastruktur aufzulösen.
Ignorieren von Client-, Cloud-, Geografie-, Governance-, Schlüssel- und Software-Supply-Chain-Konzentration.
Annehmen, dass alle Konsensmodelle dieselben Fehlerschwellen oder dieselbe Finalitätssemantik haben.
Ignorieren von Partitionen, verzögerter Endgültigkeit, Reorganisationen, Mehrdeutigkeiten und Wiederherstellungsverfahren.
Akzeptieren von Blockheadern oder Beweisen ohne die erforderlichen Datenverfügbarkeitsannahmen.
Abhängig von einem RPC, Explorer, Wallet, Indexer oder einer Depotplattform als Quelle der Wahrheit.
Verwechslung von Protokollbesitz oder -kontrolle mit Rechtsanspruch, Rückgriff oder Rückforderungsfähigkeit.
Unterschätzung des Zustandswachstums, des Archivverlusts, der Synchronisierungskosten und der Hardware-Barrieren.
Ignorieren von Upgrade-Schlüsseln, Notfallpausen, sozialer Erholung und umstrittenen Forks.
Ableitung von Datenschutz, Skalierbarkeit, Investitionswert oder Anwendungssicherheit aus dem Blockchain-Label.

Häufige Irrtümer

Jede Blockchain ist dezentralisiert und unveränderlich. Berechtigungen, Betreiberunabhängigkeit, Fork-Auswahl, Governance und Wiederherstellung bestimmen, wer den Verlauf ändern oder ablehnen kann.
In der Kette aufgezeichnete Daten müssen wahr sein. Es besteht Konsens darüber, einen falschen Preis, ein gefälschtes Dokument oder eine böswillige Anwendungseingabe getreu zu erfassen.
Eine gültige Transaktion beweist das beabsichtigte Ergebnis. Sie zielt möglicherweise auf die falsche Adresse ab, wird nach Verbrauch von Gebühren rückgängig gemacht, sendet irreführende Ereignisse oder hängt von späteren Überbrückungs- und Verwahrungsschritten ab.
Mehr Replikate verbessern immer die Sicherheit. Replikate unter einem Betreiber, Client, einer Cloud oder einem Schlüssel können gemeinsam fehlschlagen und bieten möglicherweise keine unabhängige Überprüfung.
Eine Blockchain ist immer besser als eine herkömmliche Datenbank. Ein vertrauenswürdiger Betreiber, eine erforderliche Löschung, ein hoher Durchsatz oder eine einfache Streitbeilegung können ein herkömmliches System geeigneter machen.