Die wichtigsten kryptografischen Primitive hinter jeder Blockchain

Jede Aussage einer Blockchain — „Diese Transaktion ist endgültig“, „Diese Adresse besitzt diesen Vermögenswert“, „Dieser Verlauf wurde nicht verändert“ — lässt sich letztlich auf eine Handvoll kryptografischer Primitive zurückführen, die enge, klar definierte Aufgaben erfüllen. Keine von ihnen ist eine Erfindung der Blockchain. Hashfunktionen, digitale Signaturen und Merkle-Bäume gab es schon Jahrzehnte vor Bitcoin. Blockchains kombinierten sie zu einem System, in dem für keine dieser Aussagen einer einzelnen Partei vertraut werden muss.

Dieser Leitfaden behandelt die Primitive, die tatsächlich die Last tragen: Hashfunktionen, die Daten mit einem Fingerabdruck versehen, digitale Signaturen, die Transaktionen autorisieren, Merkle-Bäume, die riesige Datensätze stückweise überprüfbar machen, die Mathematik elliptischer Kurven, auf der diese Signaturen beruhen, sowie Commitment-Schemata — die Grundlage, die zu Zero-Knowledge-Proofs führt. Jede einzelne zu verstehen, ist der schnellste Weg zu verstehen, was eine Blockchain unter der Haube wirklich tut.

Kryptografische Hashfunktionen (SHA-256, Keccak)

Eine Hashfunktion nimmt eine Eingabe beliebiger Größe und erzeugt deterministisch eine Ausgabe fester Größe — einen „Digest“. Das Ändern eines einzigen Bits der Eingabe verändert die Ausgabe vollständig, und zwei verschiedene Eingaben zu finden, die denselben Hashwert ergeben, ist rechnerisch nicht praktikabel. Diese Eigenschaft, die Kollisionsresistenz, macht einen Hash als kompakten, manipulationssichtbaren Fingerabdruck für beliebig große Daten nutzbar.

Bitcoin verwendet SHA-256 überall: Block-Header werden verkettet, indem der Hash SHA256(SHA256()) des vorherigen Headers in jeden neuen eingebettet wird. Eine Änderung an einem vergangenen Block verändert damit seinen Hash und bricht jeden folgenden Header (Bitcoin Developer Guide). Dieselbe Double-SHA-256-Konstruktion hasht Transaktionen in den Merkle-Baum des Blocks (Bitcoin.org-Referenz).

Ethereum standardisiert stattdessen Keccak-256 als Hashfunktion für allgemeine Zwecke — die ursprüngliche Keccak-Einreichung und nicht den späteren NIST-Standard SHA-3. Jede Kontoadresse wird aus den letzten 20 Byte des Keccak-256-Hashs des öffentlichen Schlüssels des Kontos abgeleitet (ethereum.org). Dieselbe Funktion liegt der Schlüssel/Wert-Content-Adressierung im Merkle Patricia Trie zugrunde, der den Zustand von Ethereum speichert.

Hashing verknüpft Block-Header außerdem zu einer Kette statt zu einer losen Sammlung von Datensätzen: Eine Änderung an einem Header verändert seinen Hash und macht die Verweise in nachfolgenden Headern ungültig. Die zusätzliche Anforderung, spätere Arbeit neu zu leisten und das ehrliche Netzwerk einzuholen, gilt speziell für Bitcoins Proof-of-Work-Konsens. Ein Angreifer, der einen vergangenen Block ändert, muss den Proof of Work dieses Blocks und die gesamte nachfolgende Arbeit erneut erbringen und anschließend die ehrliche Chain einholen (Bitcoin-Whitepaper, Abschnitt 4). Andere Blockchains authentisieren und finalisieren ihren Verlauf nach anderen Konsensregeln; die Hash-Verkettung allein erzeugt diese Proof-of-Work-Kosten nicht. Die verknüpften Header-Hashes sind der wörtliche Grund, warum diese Datenstruktur Blockchain heißt.

Public-Key-Kryptografie und digitale Signaturen (ECDSA, EdDSA, BLS)

Eine Blockchain hat kein Anmeldeformular und braucht daher einen anderen Weg, um zu beweisen: „Diese Transaktion stammt wirklich vom Eigentümer dieses Kontos.“ Public-Key-Kryptografie löst dies mit einem Schlüsselpaar: einem geheim gehaltenen privaten Schlüssel und einem frei teilbaren öffentlichen Schlüssel. Das Signieren einer Transaktion mit dem privaten Schlüssel erzeugt eine digitale Signatur, die jeder gegen den öffentlichen Schlüssel prüfen kann. Damit wird die Autorisierung nachgewiesen, ohne den privaten Schlüssel selbst offenzulegen.

Ethereum-Konten leiten ihren öffentlichen Schlüssel aus dem privaten Schlüssel ab, indem sie den Elliptic Curve Digital Signature Algorithm, ECDSA, über der Kurve secp256k1 verwenden — derselben Kurve wie Bitcoin (ethereum.org-Dokumentation zu Konten; EIP-2, Korrektur der Formbarkeit von secp256k1-Signaturen). ECDSA ist schnell zu verifizieren und wurde jahrzehntelang geprüft, hat aber eine für neuere Entwürfe relevante operative Schwäche: Einzelne ECDSA-Signaturen lassen sich nicht effizient aggregieren. Tausende zu prüfen bedeutet daher Tausende getrennte Prüfungen.

Genau diese Lücke schließen EdDSA- und BLS-Signaturen. EdDSA, verwendet von Chains wie Solana und Stellar, nutzt eine andere Kurvenkonstruktion, die deterministisch ist und bestimmten Implementierungsfallen widersteht, welche historisch ECDSA-Fehler durch Wiederverwendung von Nonces verursachten. BLS-Signaturen gehen weiter: Aufgrund der mathematischen Pairing-Eigenschaft ihrer Kurven lassen sich viele BLS-Signaturen zu einer einzigen aggregierten Signatur verbinden, die sie alle zugleich prüft. Die Proof-of-Stake-Konsensschicht von Ethereum beruht genau darauf. Validatoren signieren Attestierungen mit BLS-Schlüsseln, sodass die Beacon Chain Stimmen von Hunderttausenden Validatoren in Signaturen aggregieren kann, die kompakt genug für eine schnelle Verifizierung sind. Das macht Proof of Stake in großem Maßstab überhaupt erst praktikabel (ethereum.org, The Beacon Chain). Ethereum stellt BLS12-381-Kurvenoperationen außerdem als EVM-Precompiles bereit, um insbesondere die Verifizierung von BLS-Signaturen in Smart Contracts zu unterstützen (EIP-2537).

Merkle-Bäume

Ein Merkle-Baum ermöglicht es einer Blockchain, Tausende Transaktionen in einem einzigen 32-Byte-Hash zusammenzufassen, ohne jeden Teilnehmer zum Speichern jeder Transaktion zu zwingen. Blätter sind Hashwerte einzelner Datenelemente (Transaktionen, Kontozustände); jedes Hashpaar wird verkettet und erneut gehasht, bis ein Hash — die Wurzel — übrig bleibt (Bitcoin Developer Guide). Diese Wurzel wird direkt im Block-Header gespeichert. So kann ein Full Node sich mit fast keinem zusätzlichen Speicherplatz auf den gesamten Inhalt eines Blocks festlegen.

Der Gewinn liegt in der Größe des Beweises. Um zu zeigen, dass eine Transaktion in einem Block enthalten ist, benötigt man nicht den gesamten Block, sondern nur die Transaktion plus einen „Merkle-Zweig“, also die Geschwister-Hashes entlang des Pfads von diesem Blatt zur Wurzel, typischerweise in der Größenordnung von log₂(n) Hashes bei n Transaktionen. Darauf basiert Simplified Payment Verification (SPV): Ein schlanker Client, der nur Block-Header besitzt, kann weiterhin prüfen, ob eine konkrete Transaktion stattgefunden hat, indem er ihren Merkle-Zweig gegen die Wurzel des Headers prüft, ohne die gesamte Blockchain herunterzuladen (Bitcoin Developer Guide).

Ethereum erweitert die Idee mit dem Merkle Patricia Trie, einem Hybrid aus Merkle-Baum und Präfix- oder Radix-Trie, der den gesamten Kontozustand statt nur einer Transaktionsliste speichert. Jeder Block-Header enthält drei getrennte Trie-Wurzeln — stateRoot, transactionsRoot und receiptsRoot —, die jeweils unabhängig nachweisbar sind (ethereum.org). Dies erlaubt einem Smart Contract oder einem Light Client, einen einzelnen Kontostand oder Storage-Slot zu überprüfen, ohne die gesamte Chain erneut auszuführen.

Elliptische-Kurven-Kryptografie

Die Elliptische-Kurven-Kryptografie (ECC) ist die mathematische Grundlage von ECDSA, EdDSA und BLS. Statt sich auf die Schwierigkeit der Faktorisierung großer Zahlen zu stützen, wie klassisches RSA, beruht ECC auf der Schwierigkeit des diskreten Logarithmusproblems auf elliptischen Kurven: Ist ein Punkt auf der Kurve gegeben, der durch vielfaches Addieren eines Basispunkts zu sich selbst erreicht wurde, ist es rechnerisch nicht praktikabel zu bestimmen, wie oft addiert wurde. Den Punkt selbst vorwärts zu berechnen ist dagegen einfach. Diese Asymmetrie — in eine Richtung leicht, rückwärts schwer — macht einen privaten Schlüssel für Signaturen sicher nutzbar, während der daraus abgeleitete öffentliche Schlüssel sicher veröffentlicht werden kann.

Die konkrete Kurve und das Signaturverfahren sind entscheidend. Bitcoin und Ethereum verwenden beide secp256k1, eine Koblitz-Kurve, die von der Standards for Efficient Cryptography Group mit gut untersuchten 256-Bit-Parametern standardisiert wurde (SEC 2: Recommended Elliptic Curve Domain Parameters). Andere Ökosysteme treffen andere Abwägungen: Ed25519 ist ein konkretes EdDSA-Signaturverfahren auf der Edwards25519-Kurve (RFC 8032, Abschnitt 5.1); RFC 8032 ordnet es einem klassischen Sicherheitsniveau von etwa 128 Bit zu (Abschnitt 8.5). BLS12-381 ist eine pairingfreundliche Kurve, die für Operationen wie die Aggregation von BLS-Signaturen gewählt wurde; EIP-2537 beschreibt ein Sicherheitsniveau von mehr als 120 Bit (EIP-2537). Diese Schätzungen behaupten nicht, die Systeme böten dieselbe „Sicherheit pro Schlüsselbit“: Sie verwenden unterschiedliche Gruppen, Kodierungen und Annahmen, und die nominelle Schlüssellänge ist nicht selbst die Sicherheitsstärke. NIST ordnet beispielsweise 128 Bit klassischer Sicherheit gewöhnlichen ECC-Schlüsseln mit 256–383 Bit, aber RSA-Schlüsseln mit 3.072 Bit zu (NIST SP 800-57 Part 1 Rev. 5, Tabelle 2). Das trägt dazu bei zu erklären, warum Systeme mit elliptischen Kurven zum Standard für Blockchain-Konten wurden.

Commitment-Schemata (eine Brücke zu Zero Knowledge)

Ein Commitment-Schema ermöglicht es, einen Wert „festzulegen“: Sie veröffentlichen etwas, das Sie an ein konkretes Datenelement bindet, ohne das Datenelement selbst offenzulegen, und können das Commitment später „öffnen“, um zu beweisen, was es war. Die Alltagsanalogie ist ein versiegelter Umschlag. Sie können heute jemandem einen verschlossenen Umschlag geben als Beweis, dass Sie bereits eine Antwort entschieden haben, ohne dass diese Person sie sieht, bis Sie sich später zum Öffnen entschließen. Nach dem Versiegeln können Sie die darin enthaltene Antwort nicht mehr austauschen.

Das klingt wie ein kleines Primitiv, ist jedoch das tragende Bauteil unter den meisten Zero-Knowledge-Proof-Systemen. Das blobbasierte Data-Availability-Design von Ethereum verwendet beispielsweise polynomiale KZG-Commitments, um jeden Blob auf ein kleines kryptografisches Commitment zu reduzieren. Ein KZG-Beweis kann eine Auswertung oder eine als Stichprobe ausgewählte Zelle gegenüber diesem Commitment authentisieren, beweist aber nicht für sich allein, dass der vollständige Blob verfügbar ist. Die Verfügbarkeit entsteht durch die Verteilungs- und Stichprobenregeln der Konsensschicht, während KZG die Integrität der empfangenen Daten prüft (EIP-4844; EIP-7594, PeerDAS). Durch diese Trennung kann ein Verifier einen kleinen Teil eines Blobs prüfen, ohne einen kompakten Auswertungsbeweis mit dem Nachweis zu verwechseln, dass sämtliche Blob-Daten veröffentlicht wurden. Eine Merkle-Wurzel ist selbst ein einfaches Commitment-Schema: Sie bindet einen gesamten Datensatz über ihren Root-Hash, und ein Merkle-Zweig ist die „Öffnung“, die ein einzelnes Element enthüllt. ZK-Rollups bauen auf fortgeschritteneren Commitment-Schemata (polynomialen und Vektor-Commitments) auf, um die Ausführung eines ganzen Transaktionsbatches in einen günstig On-Chain prüfbaren Beweis zu komprimieren. Dieses Thema behandelt Perfektes vs. computationelles Zero Knowledge ausführlich.

Vergleich: kryptografische Primitive der Blockchain

Verbindung zu tokenisierten Domains

Jedes dieser Primitive kommt direkt zum Einsatz, wenn Sie eine Domain tokenisieren. Das NFT, das Eigentum repräsentiert, wird durch die Autorisierungsregeln der Chain für Konten und Token geschützt. Wird es von einem extern geführten Konto (EOA) gehalten, autorisiert der private Schlüssel dieses Kontos dessen Aktionen; ein Vertragskonto besitzt dagegen keinen privaten Schlüssel und wird von seinem Code gesteuert (ethereum.org, Ethereum-Konten). Bei einem ERC-721-Token kann außerdem eine genehmigte Adresse oder ein Operator eine Übertragung einleiten (ERC-721). Deshalb sind Hardware-Wallets und die sorgfältige Verwahrung einer Seed Phrase wichtig, wenn Sie Eigentum über ein selbst kontrolliertes EOA halten, während Smart-Contract- und Custodial-Wallets andere Autorisierungs- und Vertrauensgrenzen mit sich bringen. Der Eigentumsdatensatz der Domain lebt in demselben durch Merkle-Commitments abgesicherten Zustand, der jeden anderen Kontostand und Smart Contract auf der Chain sichert. Genau das verleiht einer tokenisierten Domain dieselbe Manipulationssichtbarkeit wie jedem anderen On-Chain-Vermögenswert: Sie ist übertragbar, überprüfbar und ihr Eigentum ist nachweisbar, ohne dass die Datenbank eines Registrars die einzige Quelle der Wahrheit ist.

Das Verständnis dieser Primitive macht auch klar, was Tokenisierung verändert und was nicht: DNS-Eintrag und Registry-Status der Domain folgen weiterhin den ICANN-Regeln, aber ihr Eigentumsnachweis beruht nun auf der oben beschriebenen Kryptografie statt auf einem durch Login geschützten Registrar-Konto. Das größere Bild finden Sie in Blockchain-Konsensmechanismen und Ansätze zur Skalierung von Blockchains, oder beginnen Sie die Tokenisierung bei namefi.io.

Quellen und weiterführende Lektüre

• Bitcoin Developer Guide — Block Chain, Verkettung über SHA256(SHA256()) des vorherigen Headers
• Bitcoin — Bitcoin: A Peer-to-Peer Electronic Cash System, Umschreiben der Proof-of-Work-Historie und kumulierte Arbeit
• Bitcoin Developer Reference — Block Chain, Aufbau der Merkle-Wurzel
• Bitcoin Developer Guide — Operating Modes, SPV und Merkle-Zweige
• ethereum.org — Ethereum Accounts, ECDSA und Ableitung von Keccak-256-Adressen; Steuerung von EOAs und Vertragskonten
• ethereum.org — Merkle Patricia Trie, Wurzeln für Zustand/Transaktionen/Receipts
• ethereum.org — Danksharding, polynomiale KZG-Commitments
• EIP-4844 — Shard Blob Transactions, Blob-Commitments, Beweise und Verfügbarkeit auf der Konsensschicht
• EIP-7594 — PeerDAS, Zellenbeweise und Data-Availability-Sampling
• ERC-721 — Non-Fungible Token Standard, Token-Eigentum, Genehmigungen und Operatoren
• EIP-2 — Homestead Hard-fork Changes, Einschränkungen für secp256k1-Signaturen
• EIP-2537 — Precompile for BLS12-381 curve operations
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA), Verfahren, Kurve und Sicherheitsniveau von Ed25519
• SEC 2: Recommended Elliptic Curve Domain Parameters — secg.org
• NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management, vergleichbare Sicherheitsstärken von ECC und RSA
• The Eth2 Book — Signatures and BLS aggregation
• NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards