Bitcoin Hyper ir Lightning: du atsakymai į tą pačią problemą
Lightning Network ir Bitcoin Hyper siūlomos architektūros palyginimas: naudojimo atvejai, veiklos branda, programuojamumas, likvidumas ir pasitikėjimo prielaidos — nedarant prielaidos apie funkcinį lygiavertiškumą.
Šviečiamasis tikslas. Šio straipsnio turinys teikiamas išimtinai informaciniais ir paaiškinamaisiais tikslais. Jis nėra finansinė konsultacija. Visas pareiškimas.
Ta pati problema, skirtingos filosofijos
Lightning Network ir Bitcoin Hyper kyla iš bendro tikslo išplėsti Bitcoin naudojimo galimybes, tačiau tenkina skirtingus poreikius pasitelkdami skirtingas architektūras ir pasitikėjimo prielaidas. Šis palyginimas nereiškia funkcinio lygiavertiškumo.
Jie nebūtinai yra tiesioginiai konkurentai ir galėtų egzistuoti kartu, nors galimas jų vienas kitą papildantis pobūdis priklausys nuo įgyvendinimo, pritaikymo ir realių naudojimo atvejų.
Lightning: kanalų tinklas
Lightning Network veikia per mazgų tarpusavio mokėjimo kanalus. Kad sumokėtų Bobui, Alisa gali naudoti savo kanalą ir maršrutą per tinklą; jai nebūtinai reikia atverti tiesioginį kanalą su Bobu. Mokėjimai gali būti atliekami labai greitai ir paprastai su nedideliais mokesčiais, jei egzistuoja pakankamą likvidumą turintis maršrutas. Uždarius kanalą, galutinis likutis atsiskaitomas Bitcoin tinkle. Lightning pirmiausia orientuotas į mokėjimus.
Stipriosios pusės: greiti mokėjimai; paprastai nedideli mokesčiai, nors jie priklauso nuo maršruto, likvidumo ir mazgų politikos; ne saugotojo (non-custodial) veikimas, kai naudotojai kontroliuoja savo raktus; ir architektūra, grindžiama savaisiais Bitcoin kanalais. Vis dėlto sistema išlaiko veiklos prielaidas, susijusias su prieinamumu, kanalų valdymu ir maršrutizavimu.
Struktūrinės ribos: mokėjimų pralaidumas priklauso nuo kanalų likvidumo; maršrutizavimas gali būti sudėtingas; o Lightning nesuteikia bendrosios paskirties smart contract aplinkos, prilygstančios virtualiajai mašinai. Šie aspektai kyla iš kanalų tinklui būdingų architektūrinių kompromisų ir skiriasi nuo rizikų, susijusių su sequenceriu ar bridge.
Bitcoin Hyper: vykdymo sluoksnis
Bitcoin Hyper pateikiamas kaip kitoks pasiūlymas: bendrosios paskirties vykdymo ir smart contract aplinka, naudojanti SVM. Pagal paskelbtą architektūrą, projektas taip pat numato registruoti būklės įsipareigojimus Bitcoin tinkle. Atskaitos dieną šios funkcijos mainnet aplinkoje dar neveikė.
Projekto deklaruotos savybės: bendrosios paskirties programuojamumas SVM pagrindu; paralelusis vykdymas per Sealevel; numatytas suderinamumas su Solana priemonėmis; ir periodinis būklės įsipareigojimų skelbimas Bitcoin tinkle. Šių funkcijų įgyvendinimą ir faktinę apimtį dar reikia nepriklausomai patikrinti.
Struktūrinės ribos: centralizuotas sequenceris paleidimo metu; Canonical Bridge, kuris apima pasitikėjimo prielaidas bei saugojimo ir protokolo rizikas; dar neišspręstas Data Availability klausimas; priverstinio įtraukimo mechanizmas, kuris dar neveikė; ir naujas, gamybinėje aplinkoje neišbandytas protokolas. Kiekviena architektūra įveda skirtingą architektūrinių kompromisų ir pasitikėjimo prielaidų rinkinį.
Lyginamoji lentelė
| Aspektas | Lightning | Bitcoin Hyper |
|---|---|---|
| Cas d’usage | Paiements | DeFi, smart contract programos ir taikomosios programos pagal numatytą architektūrą |
| Atsiskaitymas | Kanalų uždarymas Bitcoin tinkle | Numatyti būklės įsipareigojimai Bitcoin tinkle |
| Programuojamumas | Ne bendrosios paskirties; orientuota į mokėjimus | Numatoma kaip bendrosios paskirties (SVM) |
| Decentralizacija | Paskirstytas mazgų ir kanalų tinklas | Paleidimo metu numatytas vienas sequenceris |
| Branda | Gamybinėje aplinkoje nuo 2018 m. | DevNet; iki mainnet einanti fazė |
| Confiance requise | Non-custodial modelis su veiklos prielaidomis dėl kanalų ir maršrutizavimo | Sequenceris ir bridge pagal pradinę architektūrą |
| Likvidumas | Pralaidumas, priklausantis nuo kanalų likvidumo | Priklauso nuo bridge ir ekosistemoje prieinamo likvidumo |
| Kūrimo aplinka | Core Lightning, LND, Eclair | Deklaruotas suderinamumas su Anchor, Rust ir Solana priemonėmis |
Ar jie konkurentai?
Nebūtinai: jie tenkina skirtingas nišas. Lightning optimizuotas greitiems ir dažniems mokėjimams tarp žmonių arba tarp mašinų. Bitcoin Hyper siūlo bendrosios paskirties programuojamumą. Šios dvi sistemos nėra lygiavertės ir nė viena nėra visais atžvilgiais pranašesnė už kitą.
Lightning pirmiausia orientuotas į mokėjimus, o Bitcoin Hyper pateikiamas kaip platesnė programuojama aplinka, skirta smart contract pagrindu veikiančioms programoms. Jie tenkina skirtingus poreikius, ir nė vienas nebūtinai pakeičia kito. Jų veiklos branda skiriasi: Lightning veikė gamybinėje aplinkoje, o Bitcoin Hyper atskaitos dieną vis dar buvo iki mainnet einančioje fazėje.
Bitcoin Hyper taip pat reikia vertinti jau veikiančių bendrosios paskirties tinklų ir kitų su Bitcoin susijusių projektų kontekste. Komanda teigia, kad Bitcoin naudojimas būklės įsipareigojimams registruoti gali suteikti savitą vertę. Šio pasiūlymo aktualumą turės parodyti faktinis bridge ir protokolo saugumas, Data Availability, naudotojų pritaikymas ir taikomųjų programų kūrimas.