Pagrindinis vadovas

Kas yra Bitcoin Hyper?

Bitcoin Hyper pateikiamas kaip siūlomas Bitcoin Layer 2 rollup sprendimas, kuris kaip vykdymo aplinką naudotų Solana Virtual Machine. Šiame puslapyje pristatomi jo pagrindai ir siūloma architektūra.

⚠ Dokumentuota ar paskelbta

Ši svetainė nuosekliai atskiria tai, kas yra dokumentuota ir patikrinama — pavyzdžiui, DevNet aplinkoje stebimus elementus — nuo to, kas yra paskelbta ar dar kuriama. Šis atskyrimas aiškiai nurodomas visame puslapyje.

Trijų sluoksnių architektūra

Layer 3 — Taikomosios programos DeFi · NFT · DEX · Skolinimas · Piniginės · Žaidimai · Oracle · Atitiktis SVM programos (Rust/Anchor) Layer 2 — Hyper Rollup Vykdymas SVM / Sealevel Eiliškumas Iš pradžių centralizuotas Data Availability Nagrinėjama ⚠ Bridge Canonical Bridge · testai Layer 1 — Bitcoin (atsiskaitymas) Saugumas · Nekintamumas · Galutinumas · OP_RETURN · Taproot
1

Bitcoin — atsiskaitymo sluoksnis

Siūlomoje architektūroje Bitcoin atlieka atsiskaitymo ir įtvirtinimo sluoksnio funkciją. Pagal projekto dokumentaciją, Hyper rollup periodiškai skelbtų Bitcoin tinkle savo state commitment — esamos būklės Merkle šaknį — per OP_RETURN arba Taproot. Šis įtvirtinimas leistų registruoti būklės įsipareigojimus ir aptikti vėlesnius pakeitimus, tačiau vien jis negarantuoja nei būklės teisingumo, nei Data Availability, nei bridge saugumo.

Deklaruojama būklė: whitepaper aprašyta architektūra | periodinis įtvirtinimas dar kuriamas

2

Hyper Rollup — vykdymo sluoksnis

Siūlomą architektūrą sudaro keturi pagrindiniai komponentai: vykdymas (SVM su Sealevel paralelizavimu), eiliškumo nustatymas (operacijų rikiavimas, paleidimo metu centralizuotas), Data Availability (vieta, kurioje saugomi visi operacijų duomenys, dar nagrinėjama) ir bridge (Canonical Bridge BTC↔Hyper, testuojamas DevNet aplinkoje).

Deklaruojama būklė: pagal projekto pateiktą informaciją SVM veikia DevNet aplinkoje | Data Availability ir priverstinis įtraukimas dar kuriami

3

Taikomosios programos — naudotojo sluoksnis

Sluoksnis, skirtas taikomosioms programoms: DeFi protokolams, DEX platformoms, NFT rinkoms, skolinimui, stablecoin sprendimams, žaidimams ir reguliavimo atitikties priemonėms. Pagal projekto dokumentaciją, programos būtų kuriamos Rust kalba su Anchor ir į Solana panašia priemonių grandine. Faktinį suderinamumą ir būtinus pritaikymus reikės patikrinti technine dokumentacija ir nepriklausomais testais.

Deklaruojama būklė: pagal projekto pateiktą informaciją DevNet aplinkoje išbandytos pirmosios SVM programos | taikomųjų programų ekosistema formuojasi

Keturi rollup komponentai

Kiekvienas rollup, ne tik Bitcoin Hyper, grindžiamas šiais keturiais pagrindais.

⚡

Vykdymas

Virtualioji mašina, vykdanti smart contract programas. Hyper siūlomoje architektūroje naudojama SVM su Sealevel vykdymo aplinka paralelizavimui. Operacijos, susijusios su skirtingomis paskyromis, gali būti vykdomos paraleliai, o tai gali padidinti pralaidumą.

◎ Veikia DevNet · pagal projektą
⬡

Eiliškumo nustatymas

Komponentas, nustatantis operacijų rikiavimą. Jis apibrėžia jų eiliškumą, o tai turi pasekmių MEV ir cenzūros požiūriu. Iš pradžių projektas numato vieną centralizuotą sequencerį. Pagal plėtros planą, decentralizacija įvyktų per dvejus–ketverius metus.

⚠ Centralizuotas paleidimo metu
⚓

Atsiskaitymas

Periodinis state commitment įtvirtinimas Bitcoin tinkle. Kiekvienas įtvirtinimas paskelbtų atnaujintos būklės Merkle šaknį. Dokumentacijoje aprašomas adaptyvus periodiškumas: dažnesnis įtvirtinimas galėtų sutrumpinti laiką iki galutinumo, tačiau padidintų Bitcoin mokesčių kaštus.

◎ Kuriama
📦

Data Availability

Data Availability nustato, kur saugomi ir kaip pateikiami duomenys, būtini operacijoms ir būklei atkurti. Jei šie duomenys nebūtų viešai prieinami, sistema atsitrauktų nuo rollup modelio su viešai prieinamais duomenimis ir priartėtų prie validium tipo schemos. 2026 m. balandžio 28 d. galutinis sprendimas dar buvo nagrinėjamas.

⚠ Nagrinėjama

💡 Pagrindiniai aspektai

  • • Bitcoin Hyper pateikiamas kaip rollup su vykdymu už grandinės ribų ir Bitcoin tinkle įtvirtintais būklės įsipareigojimais
  • • Pagal projekto pateiktą informaciją, SVM turėtų suteikti programuojamumą ir suderinamumą su Solana kūrimo ekosistema; abu šiuos elementus reikės patikrinti
  • • Pradinė architektūra numato centralizuotą sequencerį ir federuotą bridge, o decentralizacijos planas apima dvejus–ketverius metus
  • • Data Availability ir priverstinis įtraukimas dar kuriami: tai kritiniai etapai prieš mainnet
  • • Projektas jį pateikia kaip rollup, o ne kaip sidechain. Iš Bitcoin perimtas saugumo lygis priklausys nuo faktinės įtvirtinimo, Data Availability, bridge ir patikrinimo mechanizmų architektūros