Glossar

Auf Grundlage von Anhang A des Buches „Due Diligence of a Layer 2 – The Bitcoin Hyper Case“ von Michele Stefanelli. 33 Einträge in 12 Kategorien.

33 Einträge

Anchoring

Settlement

Die periodische Veröffentlichung des State Commitment eines Rollups auf der Basisschicht von Bitcoin (L1). Die Verankerung hält das State Commitment fest und macht spätere Änderungen erkennbar; für sich genommen garantiert sie jedoch weder die Korrektheit des Zustands noch die Data Availability oder die Sicherheit der Bridge.

Kap. 11–12

OP_RETURN

Bitcoin L1

Ein Opcode der Bitcoin-Skriptsprache, der es erlaubt, bis zu 80 Byte beliebiger Daten in eine Transaktion einzubetten und den entstehenden Output nachweislich unausgebbar zu machen. Wird zur Verankerung von State Commitments genutzt.

Kap. 12

Taproot

Bitcoin L1

Ein Bitcoin-Upgrade (BIP 341/342, aktiviert im November 2021), das Schnorr-Signaturen und MAST einführt. Es verbessert Privatsphäre, Effizienz und Flexibilität von Skripten und ist für effizientere Verankerungsmechanismen relevant.

Kap. 12

UTXO

Bitcoin L1

Unspent Transaction Output. Das Buchungsmodell von Bitcoin: Statt „Konten“ gibt es „nicht ausgegebene Outputs“ bestimmter Beträge. Es unterscheidet sich vom Account-Modell, das die SVM und Ethereum verwenden.

Kap. 1

Rollup

Layer 2

Eine Layer-2-Lösung, die Transaktionen off-chain ausführt und den komprimierten Zustand periodisch auf der Basisschicht (L1) veröffentlicht. Sie verbindet Off-Chain-Skalierbarkeit mit Sicherheit, die sie — je nach gewähltem Modell — von der L1 ableitet.

Kap. 4–6

Sidechain

Layer 2

Eine eigenständige Blockchain, die über eine Bridge mit der L1 verbunden ist. Ihre Sicherheit hängt vor allem vom eigenen Konsens und von der Konstruktion der Bridge ab, nicht unmittelbar von der Sicherheit der L1.

Kap. 4

Validium

Layer 2

Eine Architektur ähnlich einem Rollup, bei der die zur Rekonstruktion des Zustands nötigen Daten ausserhalb der L1 vorgehalten werden. Das kann Kosten senken und den Durchsatz erhöhen, führt aber zusätzliche Annahmen zur Datenverfügbarkeit ein: Werden die Daten unzugänglich, können Nutzer den Zustand womöglich nicht mehr überprüfen oder ihre Mittel abziehen.

Kap. 14

Optimistic Rollup

Layer 2

Ein Rollup, das Zustandsübergänge standardmässig als gültig annimmt — daher „optimistic“. Es stützt sich auf Fraud Proofs, mit denen sich fehlerhafte Übergänge innerhalb eines festgelegten Zeitfensters anfechten lassen, auf Ethereum üblicherweise sieben Tage.

Kap. 6

ZK Rollup

Layer 2

Ein Rollup, das Gültigkeitsbeweise — häufig auf Basis von Zero-Knowledge-Kryptografie — nutzt, um nachzuweisen, dass Zustandsübergänge den Protokollregeln entsprechen. Es kann die Bestätigungsdauer gegenüber einem Optimistic Rollup verkürzen, wobei die tatsächliche Finalität auch hier von der L1 und der Systemkonstruktion abhängt.

Kap. 6

SVM (Solana Virtual Machine)

Ausführung

Eine von Solana Labs entwickelte Ausführungsumgebung (Runtime). Sie ermöglicht parallele Ausführung, indem jede Transaktion die von ihr berührten Accounts ausdrücklich deklarieren muss. Nach Angaben des Projekts nutzt Bitcoin Hyper sie als Ausführungsumgebung.

Kap. 7–8

Sealevel

Ausführung

Die Parallelisierungs-Laufzeitumgebung innerhalb der SVM. Sie analysiert die von den einzelnen Transaktionen deklarierten Accounts und erlaubt es, einander nicht überschneidende Transaktionen parallel auszuführen. Sie ist einer der Faktoren, die den Durchsatz von Solana und — nach Angaben des Projekts — die geplante Architektur von Bitcoin Hyper prägen.

Kap. 8

Anchor

Ausführung

Ein Framework in der Sprache Rust für die Entwicklung von SVM-Programmen. Es ergänzt Makros, Konventionen und Testwerkzeuge, die das Schreiben von Programmen für Solana erheblich vereinfachen. Nach Angaben des Projekts soll Bitcoin Hyper eine gleichwertige Toolchain bieten; die tatsächliche Kompatibilität bleibt zu überprüfen.

Kap. 9

SPL (Solana Program Library)

Ausführung

Eine Bibliothek von Standardprogrammen für die SVM: Token (SPL Token), Staking, Governance und weitere. Nach Angaben des Projekts strebt Bitcoin Hyper Kompatibilität mit SPL an, was die Wiederverwendung von Token und Programmen aus dem Solana-Ökosystem ermöglichen würde.

Kap. 9

Sequencer

Sequencing

Die Komponente eines Rollups, welche die Transaktionen vor ihrer Ausführung ordnet. Wer den Sequencer kontrolliert, kann über diese Reihenfolge bestimmen, was Folgen für MEV und Zensur hat. Zum Start von Bitcoin Hyper soll er zentralisiert sein.

Kap. 15–17

MEV (Maximal Extractable Value)

Sequencing

Der Wert, der sich durch Umordnen, Einfügen oder Auslassen von Transaktionen innerhalb eines Blocks oder Stapels abschöpfen lässt. Ein zentralisierter Sequencer kann beim Abschöpfen oder Beeinflussen des MEV eines Rollups über erheblichen Spielraum verfügen.

Kap. 15

Forced Inclusion

Sequencing

Ein Mechanismus, der es Nutzern erlaubt, die Aufnahme einer Transaktion über die Bitcoin-L1 zu „erzwingen“ und dabei einen zensierenden Sequencer zu umgehen. Zum 28.04.2026 befand sich diese Funktion bei Bitcoin Hyper weiterhin in Entwicklung.

Kap. 21

Canonical Bridge

Bridge

Die offizielle Bridge von Bitcoin Hyper für den Transfer von BTC von der L1 in das Rollup und zurück. Zum Start: föderierte oder zentralisierte Verwahrung mit allen daraus folgenden Vertrauensannahmen. Die Roadmap sieht eine schrittweise Dezentralisierung vor, was zu überprüfen bleibt.

Kap. 31, 34

Forced Exit

Bridge

Ein Mechanismus, der es Nutzern erlaubt, Mittel über die Bitcoin-L1 aus dem Rollup abzuziehen, auch wenn Sequencer oder Bridge nicht kooperieren. Eine zentrale Sicherheitsfunktion, weiterhin in Entwicklung.

Kap. 21

Data Availability (DA)

Data Availability

Die Gewähr, dass die Daten aller Transaktionen öffentlich zugänglich sind. Ohne diese Daten kann niemand den Zustand des Rollups rekonstruieren. Bei Bitcoin Hyper ist die endgültige Lösung weiterhin Gegenstand der Forschung.

Kap. 14

State Commitment

Settlement

Eine komprimierte Darstellung — typischerweise ein Merkle-Root — des vollständigen Rollup-Zustands zu einem bestimmten Zeitpunkt. Sie wird periodisch als Verankerung auf Bitcoin veröffentlicht; die Veröffentlichung allein bedeutet keine vollständige Überprüfung des Zustands.

Kap. 11

Merkle Tree

Kryptografie

Eine baumförmige Datenstruktur, in der jeder übergeordnete Knoten der Hash seiner Kindknoten ist. Sie ermöglicht effiziente Nachweise (Merkle Proofs) über die Zugehörigkeit von Daten, ohne den gesamten Datensatz offenzulegen.

Anh. A

$HYPER

Tokenomics

Der Token, den die Dokumentation des Projekts als nativen Token von Bitcoin Hyper ausweist. Das angegebene Gesamtangebot beträgt 21 Milliarden (eine bewusste Anspielung auf die 21 Millionen BTC). Nach der veröffentlichten Dokumentation soll er der Zahlung von Transaktionsgebühren, dem Staking und — in einer späteren Phase — der Governance dienen. Angegebene Allokation: 25 % Treasury, 30 % Entwicklung, 20 % Marketing, 15 % Rewards, 10 % Listings.

Kap. 30–33

Vesting

Tokenomics

Ein Mechanismus zur schrittweisen Freigabe von Token über die Zeit, der die Anreize von Team und Investoren mit dem langfristigen Erfolg des Projekts in Einklang bringen soll. Nach den für den Presale veröffentlichten Bedingungen wird bei $HYPER ein Vesting von sieben Tagen angegeben.

Kap. 33

TGE (Token Generation Event)

Tokenomics

Das Ereignis, bei dem ein Token erstmals erzeugt und verteilt wird. Dem Whitepaper zufolge sollen die Sicherheitsaudits vor dem TGE von Bitcoin Hyper abgeschlossen sein.

Kap. 33

TVL (Total Value Locked)

DeFi

Der Gesamtwert der in den DeFi-Protokollen eines Netzwerks hinterlegten Vermögenswerte. Eine Kennzahl zur Einschätzung der Verbreitung eines Ökosystems und des Vertrauens in dieses.

Anh. A

AMM (Automated Market Maker)

DeFi

Ein DeFi-Protokoll, das Wechselkurse über mathematische Formeln bestimmt — typischerweise x*y=k — und damit ein herkömmliches Orderbuch überflüssig macht.

Anh. A

Oracle

DeFi

Ein Dienst, der Daten aus der realen Welt (Preise, Ereignisse) auf die Blockchain bringt. Für DeFi ist er zentral: Kredite, Derivate und zahlreiche weitere Contracts hängen von verlässlichen externen Preisen ab.

Anh. A

Fraud Proof

Sicherheit

Ein kryptografischer Nachweis, dass ein bestimmter Zustandsübergang ungültig ist. Wird in Optimistic Rollups genutzt, um betrügerische Zustände innerhalb des Einspruchsfensters anzufechten.

Kap. 19

Sicherheitsaudit

Sicherheit

Die Prüfung des Quellcodes durch eine spezialisierte unabhängige Gesellschaft mit dem Ziel, Schwachstellen aufzudecken. Bei Bitcoin Hyper hat das Projekt die Veröffentlichung der Audits vor dem TGE zugesagt; zum 28.04.2026 war kein öffentlicher Auditbericht zum Protokoll oder zur Bridge bestätigt. Öffentlich verfügbar sind Audits des ERC-20-Token-Contracts (Coinsult, SolidProof), die jedoch ausschliesslich den Token-Contract betreffen.

Kap. 34

Finalität

Settlement

Der Zeitpunkt, ab dem eine Transaktion nach den Regeln und Annahmen des Systems als unumkehrbar gilt. In der für Bitcoin Hyper beschriebenen Architektur würden State Commitments nach ihrer Veröffentlichung Bestätigungen in Bitcoin ansammeln; das allein garantiert jedoch weder die Gültigkeit des Zustands noch die Möglichkeit, Mittel abzuziehen.

Kap. 13

Lightning Network

Wettbewerb

Ein auf Kanälen beruhendes Zahlungsnetzwerk für Bitcoin. Es ist vor allem auf schnelle und günstige Zahlungen ausgelegt und bietet keine universelle Smart-Contract-Umgebung, wie sie eine virtuelle Maschine bereitstellt. Im Produktivbetrieb seit 2018.

Kap. 25–26

Stacks

Wettbewerb

Ein mit Bitcoin verbundenes Smart-Contract-Netzwerk, das den PoX-Mechanismus (Proof of Transfer) nutzt. Es verfügt über eine eigene Sprache, Clarity, und schreibt Daten seiner Blöcke nach Bitcoin.

Kap. 27

Rootstock (RSK)

Wettbewerb

Eine EVM-kompatible Sidechain von Bitcoin, die Merged Mining nutzt. Für die Zahlung von Gas verwendet sie den Token RBTC — einen an den Kurs von BTC gekoppelten Vermögenswert. Im Produktivbetrieb seit 2018.

Kap. 28