Bitcoin Hyper versus Lightning: to svar på det samme problem
Sammenligning mellem Lightning Network og den arkitektur, som Bitcoin Hyper foreslår: anvendelsesscenarier, operationel modenhed, programmerbarhed, likviditet og tillidsantagelser — uden at forudsætte funktionel ligeværdighed.
Uddannelsesmæssigt formål. Indholdet i denne artikel tjener udelukkende til informations- og oplysningsformål. Det udgør ikke finansiel rådgivning. Fuld ansvarsfraskrivelse.
Samme problem, forskellige filosofier
Både Lightning Network og Bitcoin Hyper forfølger det overordnede mål at udvide Bitcoins anvendelsesmuligheder, men de imødekommer forskellige behov med forskellige arkitekturer og tillidsantagelser. Denne sammenligning forudsætter ikke funktionel ligeværdighed.
De er ikke nødvendigvis direkte konkurrenter og kunne eksistere side om side, selv om deres eventuelle komplementaritet vil afhænge af implementeringen, udbredelsen og de faktiske anvendelsesscenarier.
Lightning: et netværk af kanaler
Lightning Network fungerer via betalingskanaler mellem noder. For at betale Bob kan Alice bruge sin egen kanal og lægge en rute gennem netværket; hun behøver ikke nødvendigvis at åbne en direkte kanal til Bob. Betalinger kan udføres meget hurtigt og som regel til lave omkostninger, forudsat at der findes en rute med tilstrækkelig likviditet. Når en kanal lukkes, afvikles slutsaldoen på Bitcoin. Lightning er først og fremmest rettet mod betalinger.
Stærke sider: hurtige betalinger; som regel lave omkostninger, om end de afhænger af ruten, likviditeten og nodernes politik; non-custodial funktion, forudsat at brugerne selv råder over deres nøgler; og et design, der bygger på Bitcoin-native kanaler. Systemet bevarer ikke desto mindre operationelle antagelser knyttet til tilgængeligheden, forvaltningen af kanalerne og routingen.
Strukturelle begrænsninger: betalingskapaciteten afhænger af kanalernes likviditet; routingen kan vise sig at være kompleks; og Lightning tilbyder ikke et universelt smart contract-miljø, der kan sammenlignes med en virtuel maskine. Disse aspekter udspringer af de designkompromiser, der er kendetegnende for et netværk af kanaler, og adskiller sig fra de risici, der er forbundet med en sequencer eller en bridge.
Bitcoin Hyper: et udførelseslag
Bitcoin Hyper præsenterer sig som en anden tilgang: et universelt udførelses- og smart contract-miljø, der efter planen skal anvende SVM. Ifølge den offentliggjorte arkitektur agter projektet desuden at forankre state commitments på Bitcoin. Disse funktioner var på skæringsdatoen endnu ikke i brug på et Mainnet.
Egenskaber angivet af projektet: universel programmerbarhed baseret på SVM; parallel udførelse via Sealevel; forudset kompatibilitet med Solanas værktøjer; og periodisk offentliggørelse af state commitments på Bitcoin. Implementeringen og den faktiske rækkevidde af disse funktioner mangler stadig at blive verificeret uafhængigt.
Strukturelle begrænsninger: en centraliseret sequencer ved starten; en Canonical Bridge, der medfører tillidsantagelser samt opbevarings- og protokolrisici; en datatilgængelighed, der endnu ikke er løst; en mekanisme til tvungen inklusion, der endnu ikke var i brug; og en ny protokol, der ikke er afprøvet i produktion. Hver arkitektur medfører en anden kombination af designkompromiser og tillidsantagelser.
Sammenligningstabellen
| Dimension | Lightning | Bitcoin Hyper |
|---|---|---|
| Anvendelsesscenarie | Betalinger | DeFi, smart contracts og applikationer, ifølge den forudsete arkitektur |
| Afvikling | Lukning af kanalerne på Bitcoin | State commitments forudset på Bitcoin |
| Programmerbarhed | Ikke universel; rettet mod betalinger | Forudset som universel (SVM) |
| Decentralisering | Distribueret netværk af noder og kanaler | Én enkelt sequencer forudset ved starten |
| Modenhed | I produktion siden 2018 | Devnet; fase før Mainnet |
| Påkrævet tillid | Non-custodial model med operationelle antagelser vedrørende kanaler og routing | Sequencer og bridge ifølge den oprindelige arkitektur |
| Likviditet | Kapacitet afhængig af kanalernes likviditet | Afhængig af bridgen og den likviditet, der er tilgængelig i økosystemet |
| Udviklingsmiljø | Core Lightning, LND, Eclair | Angivet kompatibilitet med Anchor, Rust og Solanas værktøjer |
Er de konkurrenter?
Ikke nødvendigvis: de betjener forskellige nicher. Lightning er optimeret til hurtige og hyppige betalinger mellem personer — eller mellem maskiner. Bitcoin Hyper tilbyder universel programmerbarhed. De to systemer er ikke ligeværdige, og ingen af dem er universelt overlegen i forhold til den anden.
Lightning er først og fremmest rettet mod betalinger, mens Bitcoin Hyper præsenterer sig som et bredere programmerbart miljø for applikationer baseret på smart contracts. De imødekommer forskellige behov, og ingen af dem erstatter nødvendigvis den anden. Deres operationelle modenhed er forskellig: Lightning var i produktion, mens Bitcoin Hyper på skæringsdatoen fortsat befandt sig i en fase før Mainnet.
Bitcoin Hyper skal desuden vurderes i sammenligning med de allerede operationelle universelle netværk og de øvrige projekter, der er knyttet til Bitcoin. Teamet er af den opfattelse, at brugen af Bitcoin til at forankre state commitments kan tilføre en særlig merværdi. Relevansen af denne tilgang må vise sig gennem den faktiske sikkerhed i bridgen og protokollen, datatilgængeligheden, udbredelsen blandt brugerne og udviklingen af applikationer.