Bitcoin Hyper versus Lightning: twee antwoorden op hetzelfde probleem
Vergelijking tussen het Lightning Network en de door Bitcoin Hyper voorgestelde architectuur: gebruiksscenario's, operationele volwassenheid, programmeerbaarheid, liquiditeit en vertrouwensaannames, zonder een functionele gelijkwaardigheid te veronderstellen.
Educatief doel. De inhoud van dit artikel dient uitsluitend voor informatie- en toelichtingsdoeleinden. Het vormt geen financieel advies. Volledige disclaimer.
Hetzelfde probleem, verschillende filosofieën
Het Lightning Network en Bitcoin Hyper streven beide het algemene doel na om de gebruiksmogelijkheden van Bitcoin uit te breiden, maar beantwoorden verschillende behoeften met verschillende architecturen en vertrouwensaannames. Deze vergelijking veronderstelt geen functionele gelijkwaardigheid.
Ze zijn niet noodzakelijk directe concurrenten en zouden naast elkaar kunnen bestaan, ook al zal hun eventuele complementariteit afhangen van de implementatie, de acceptatie en de werkelijke gebruiksscenario's.
Lightning: een netwerk van kanalen
Het Lightning Network werkt via betaalkanalen tussen nodes. Om Bob te betalen kan Alice haar eigen kanaal gebruiken en een route door het netwerk nemen; ze hoeft niet noodzakelijk een direct kanaal met Bob te openen. Betalingen kunnen zeer snel en doorgaans tegen lage kosten worden uitgevoerd, mits er een route met voldoende liquiditeit bestaat. Wanneer een kanaal wordt gesloten, wordt het eindsaldo op Bitcoin afgewikkeld. Lightning is in de eerste plaats gericht op betalingen.
Sterke punten: snelle betalingen; doorgaans lage kosten, ook al hangen deze af van de route, de liquiditeit en het beleid van de nodes; niet-bewarende werking, mits de gebruikers hun eigen sleutels beheren; en een ontwerp dat berust op Bitcoin-native kanalen. Het systeem behoudt niettemin operationele aannames die samenhangen met de beschikbaarheid, het beheer van de kanalen en de routing.
Structurele beperkingen: de betaalcapaciteit hangt af van de liquiditeit van de kanalen; de routing kan complex blijken; en Lightning biedt geen universele smart-contract-omgeving die vergelijkbaar zou zijn met een virtuele machine. Deze aspecten vloeien voort uit de ontwerpcompromissen die eigen zijn aan een netwerk van kanalen, en verschillen van de risico's die verbonden zijn aan een sequencer of een bridge.
Bitcoin Hyper: een uitvoeringslaag
Bitcoin Hyper presenteert zich als een andere aanpak: een universele uitvoerings- en smart-contract-omgeving die de SVM zou gebruiken. Volgens de gepubliceerde architectuur is het project bovendien van plan state commitments op Bitcoin vast te leggen. Deze functies waren op de peildatum nog niet op een Mainnet in gebruik.
Door het project vermelde eigenschappen: universele programmeerbaarheid op basis van de SVM; parallelle uitvoering via Sealevel; voorziene compatibiliteit met de tools van Solana; en periodieke publicatie van state commitments op Bitcoin. De implementatie en de werkelijke reikwijdte van deze functies moeten nog onafhankelijk worden geverifieerd.
Structurele beperkingen: een gecentraliseerde sequencer bij de start; een Canonical Bridge die vertrouwensaannames alsook bewarings- en protocolrisico's met zich meebrengt; een nog op te lossen databeschikbaarheid; een mechanisme van geforceerde inclusie dat nog niet in gebruik was; en een nieuw, in productie niet beproefd protocol. Elke architectuur brengt een andere combinatie van ontwerpcompromissen en vertrouwensaannames met zich mee.
De vergelijkingstabel
| Dimensie | Lightning | Bitcoin Hyper |
|---|---|---|
| Gebruiksscenario | Betalingen | DeFi, smart contracts en toepassingen, volgens de voorziene architectuur |
| Settlement | Sluiting van de kanalen op Bitcoin | Op Bitcoin voorziene state commitments |
| Programmeerbaarheid | Niet universeel; gericht op betalingen | Als universeel voorzien (SVM) |
| Decentralisatie | Gedistribueerd netwerk van nodes en kanalen | Eén enkele sequencer bij de start voorzien |
| Volwassenheid | Sinds 2018 in productie | Devnet; fase vóór de Mainnet |
| Vereist vertrouwen | Niet-bewarend model met operationele aannames met betrekking tot kanalen en routing | Sequencer en bridge volgens de oorspronkelijke architectuur |
| Liquiditeit | Capaciteit afhankelijk van de liquiditeit van de kanalen | Afhankelijk van de bridge en de in het ecosysteem beschikbare liquiditeit |
| Ontwikkelomgeving | Core Lightning, LND, Eclair | Aangegeven compatibiliteit met Anchor, Rust en de tools van Solana |
Zijn het concurrenten?
Niet noodzakelijk: ze bedienen verschillende niches. Lightning is geoptimaliseerd voor snelle en frequente betalingen tussen personen — of tussen machines. Bitcoin Hyper biedt een universele programmeerbaarheid. De twee systemen zijn niet gelijkwaardig, en geen van beide is universeel superieur aan het andere.
Lightning is in de eerste plaats gericht op betalingen, terwijl Bitcoin Hyper zich presenteert als een bredere programmeerbare omgeving voor toepassingen op basis van smart contracts. Ze beantwoorden verschillende behoeften, en geen van beide vervangt noodzakelijk het andere. Hun operationele volwassenheid verschilt: Lightning was in productie, terwijl Bitcoin Hyper zich op de peildatum nog in een fase vóór de Mainnet bevond.
Bitcoin Hyper moet bovendien worden beoordeeld in vergelijking met de reeds operationele universele netwerken en de andere met Bitcoin verbonden projecten. Het team is van mening dat het gebruik van Bitcoin voor het vastleggen van state commitments een specifieke meerwaarde kan bieden. De relevantie van deze aanpak zal moeten blijken uit de werkelijke beveiliging van de bridge en het protocol, de databeschikbaarheid, de acceptatie door de gebruikers en de ontwikkeling van toepassingen.