Bitcoin Hyper gegenüber Lightning: zwei Antworten auf dasselbe Problem
Vergleich zwischen dem Lightning Network und der von Bitcoin Hyper vorgeschlagenen Architektur: Anwendungsfälle, operative Reife, Programmierbarkeit, Liquidität und Vertrauensannahmen, ohne eine funktionale Äquivalenz zu unterstellen.
Bildungszweck. Der Inhalt dieses Artikels dient ausschliesslich Informations- und Erläuterungszwecken. Er stellt keine Finanzberatung dar. Vollständiger Haftungsausschluss.
Dasselbe Problem, unterschiedliche Philosophien
Das Lightning Network und Bitcoin Hyper verfolgen beide das allgemeine Ziel, die Nutzungsmöglichkeiten von Bitcoin zu erweitern, beantworten jedoch unterschiedliche Bedürfnisse mit unterschiedlichen Architekturen und Vertrauensannahmen. Dieser Vergleich unterstellt keine funktionale Äquivalenz.
Sie sind nicht zwingend direkte Wettbewerber und könnten koexistieren, auch wenn ihre allfällige Komplementarität von der Umsetzung, der Akzeptanz und den tatsächlichen Anwendungsfällen abhängen wird.
Lightning: ein Netzwerk aus Kanälen
Das Lightning Network funktioniert über Zahlungskanäle zwischen Knoten. Um Bob zu bezahlen, kann Alice ihren eigenen Kanal nutzen und eine Route durch das Netzwerk verwenden; sie muss nicht zwingend einen direkten Kanal mit Bob eröffnen. Zahlungen lassen sich sehr schnell und mit in der Regel niedrigen Gebühren ausführen, sofern eine Route mit ausreichender Liquidität besteht. Wird ein Kanal geschlossen, wird der Endsaldo auf Bitcoin abgewickelt. Lightning ist in erster Linie auf Zahlungen ausgerichtet.
Stärken: schnelle Zahlungen; in der Regel niedrige Gebühren, auch wenn diese von der Route, der Liquidität und den Richtlinien der Knoten abhängen; nicht-verwahrender Betrieb, sofern die Nutzer ihre eigenen Schlüssel kontrollieren; und ein Design, das auf Bitcoin-nativen Kanälen beruht. Das System behält gleichwohl operative Annahmen bei, die mit der Verfügbarkeit, der Verwaltung der Kanäle und dem Routing zusammenhängen.
Strukturelle Grenzen: die Zahlungskapazität hängt von der Liquidität der Kanäle ab; das Routing kann sich als komplex erweisen; und Lightning bietet keine universelle Smart-Contract-Umgebung, die mit einer virtuellen Maschine vergleichbar wäre. Diese Aspekte ergeben sich aus den Designkompromissen, die einem Netzwerk aus Kanälen eigen sind, und unterscheiden sich von den Risiken, die mit einem Sequencer oder einer Bridge verbunden sind.
Bitcoin Hyper: eine Ausführungsschicht
Bitcoin Hyper präsentiert sich als ein anderer Ansatz: eine universelle Ausführungs- und Smart-Contract-Umgebung, die die SVM nutzen würde. Gemäss der veröffentlichten Architektur sieht das Projekt zudem vor, Zustandsverpflichtungen auf Bitcoin festzuhalten. Diese Funktionen waren zum Stichtag noch nicht auf einer Mainnet in Betrieb.
Vom Projekt angegebene Eigenschaften: universelle Programmierbarkeit auf Basis der SVM; parallele Ausführung über Sealevel; vorgesehene Kompatibilität mit den Werkzeugen von Solana; und periodische Veröffentlichung von Zustandsverpflichtungen auf Bitcoin. Die Umsetzung und die tatsächliche Reichweite dieser Funktionen sind noch unabhängig zu überprüfen.
Strukturelle Grenzen: ein zentralisierter Sequencer zum Start; eine Canonical Bridge, die Vertrauensannahmen sowie Verwahrungs- und Protokollrisiken mit sich bringt; eine noch zu lösende Datenverfügbarkeit; ein Mechanismus der erzwungenen Inklusion, der noch nicht in Betrieb war; und ein neues, in der Produktion nicht erprobtes Protokoll. Jede Architektur bringt eine andere Kombination von Designkompromissen und Vertrauensannahmen mit sich.
Die Vergleichstabelle
| Dimension | Lightning | Bitcoin Hyper |
|---|---|---|
| Anwendungsfall | Zahlungen | DeFi, Smart Contracts und Anwendungen, gemäss der vorgesehenen Architektur |
| Settlement | Schliessung der Kanäle auf Bitcoin | Auf Bitcoin vorgesehene Zustandsverpflichtungen |
| Programmierbarkeit | Nicht universell; auf Zahlungen ausgerichtet | Als universell vorgesehen (SVM) |
| Dezentralisierung | Verteiltes Netzwerk aus Knoten und Kanälen | Einzelner Sequencer zum Start vorgesehen |
| Reife | Seit 2018 in Produktion | Devnet; Phase vor der Mainnet |
| Erforderliches Vertrauen | Nicht-verwahrendes Modell mit operativen Annahmen in Bezug auf Kanäle und Routing | Sequencer und Bridge gemäss der ursprünglichen Architektur |
| Liquidität | Kapazität abhängig von der Liquidität der Kanäle | Abhängig von der Bridge und der im Ökosystem verfügbaren Liquidität |
| Entwicklungsumgebung | Core Lightning, LND, Eclair | Angegebene Kompatibilität mit Anchor, Rust und den Werkzeugen von Solana |
Sind sie Wettbewerber?
Nicht zwingend: Sie bedienen unterschiedliche Nischen. Lightning ist für schnelle und häufige Zahlungen zwischen Personen — oder zwischen Maschinen — optimiert. Bitcoin Hyper bietet eine universelle Programmierbarkeit. Die beiden Systeme sind nicht gleichwertig, und keines ist dem anderen universell überlegen.
Lightning ist in erster Linie auf Zahlungen ausgerichtet, während sich Bitcoin Hyper als eine breitere programmierbare Umgebung für Anwendungen auf Basis von Smart Contracts präsentiert. Sie beantworten unterschiedliche Bedürfnisse, und keines der beiden ersetzt zwingend das andere. Ihre operative Reife unterscheidet sich: Lightning war in Produktion, während sich Bitcoin Hyper zum Stichtag noch in einer Phase vor der Mainnet befand.
Bitcoin Hyper muss zudem im Vergleich zu den bereits betriebenen universellen Netzwerken und den anderen mit Bitcoin verbundenen Projekten bewertet werden. Das Team vertritt die Auffassung, dass die Nutzung von Bitcoin zur Festhaltung von Zustandsverpflichtungen einen spezifischen Mehrwert bringen kann. Die Relevanz dieses Ansatzes wird sich an der tatsächlichen Sicherheit der Bridge und des Protokolls, der Datenverfügbarkeit, der Akzeptanz durch die Nutzer und der Entwicklung von Anwendungen erweisen müssen.