Kas yra rollup ir kodėl Bitcoin jo prireikė?
Bitcoin pirmenybę teikia saugumui ir decentralizacijai, tačiau bazinio sluoksnio pralaidumas išlieka ribotas. Straipsnyje paaiškinama, kas yra rollup, kuo jis skiriasi nuo sidechain ir kokias papildomas prielaidas įveda Bitcoin Hyper aprašyta architektūra.
Šviečiamasis tikslas. Šio straipsnio turinys teikiamas išimtinai informaciniais ir paaiškinamaisiais tikslais. Jis nėra finansinė konsultacija. Visas pareiškimas.
Bitcoin mastelio problema
Bitcoin sukurtas taip, kad pirmenybę teiktų patikrinamumui, decentralizacijai ir atsparumui, o ne operacijų per sekundę skaičiaus maksimizavimui. Kiekvienas pilnasis mazgas patikrina operacijas pagal protokolo taisykles. Bazinio sluoksnio pralaidumas yra ribotas ir orientaciniais skaičiavimais dažnai vertinamas maždaug 7 operacijomis per sekundę, nors faktinis skaičius priklauso nuo operacijų tipo ir dydžio.
Daugelį metų diskusija susivedė į vieną klausimą: kaip padidinti Bitcoin pralaidumą neprarandant to, kas jį daro išskirtinį?
Jau išbandyti keliai
Pirmasis atsakymas buvo Lightning Network, veikiantis nuo 2018 m.: mokėjimo kanalų tinklas, leidžiantis atlikti greitus ir paprastai nedidelių kaštų mokėjimus, taip pat maršrutais, sudarytais iš kelių kanalų. Jis pirmiausia orientuotas į mokėjimus ir nesuteikia bendrosios paskirties smart contract aplinkos. Jo veikimas taip pat priklauso nuo prieinamo likvidumo ir galimybės rasti tinkamą maršrutą.
Stacks pasirinko kitokį būdą: smart contract tinklą, su Bitcoin susietą PoX mechanizmu ir turintį savo kalbą Clarity. Jo saugumo modelis ir galutinumas skiriasi nuo Bitcoin ir taip pat priklauso nuo paties Stacks tinklo taisyklių.
Rootstock (RSK) pasirinko suderinamumą su EVM ir merge-mining su Bitcoin. Tinklas veikia nuo 2018 m. ir naudoja sidechain modelį su savomis saugumo ir bridge prielaidomis.
Kodėl rollup yra kitoks
Rollup nėra sidechain. Techninis atskyrimas yra svarbus:
- - Sidechain išlaiko savo konsensuso arba validavimo mechanizmą. Jos saugumas pirmiausia priklauso nuo šios sistemos ir nuo bridge architektūros, kuri ją sieja su Bitcoin.
- - Bitcoin Hyper aprašytoje architektūroje vykdymas būtų atliekamas už Bitcoin ribų, o būklės įsipareigojimai būtų skelbiami baziniame sluoksnyje. Faktinis kvalifikavimas kaip rollup taip pat priklausys nuo Data Availability ir įrodymų sistemos.
Pagal projekto paskelbtą architektūrą, numatomas procesas būtų toks:
- Naudotojai savo operacijas siųstų sequenceriui
- Sequenceris nustatytų jų eiliškumą ir vykdytų paketais
- Periodiškai būklės įsipareigojimas (state commitment), apibūdinamas kaip atnaujintos būklės Merkle šaknis, būtų skelbiamas Bitcoin tinkle per OP_RETURN arba Taproot
- Galimybė patikrinti perėjimą priklausytų nuo Data Availability ir įrodymų sistemos; vien įsipareigojimas neįrodo, kad perėjimas yra teisingas
Patvirtintas Bitcoin tinkle, būklės įsipareigojimas įgyja praktinį jį apimančios operacijos nekintamumą. Tai apsunkina vėlesnį šio įrašo pakeitimą, tačiau vien tai nesutrukdo paskelbti neteisingo įsipareigojimo ir negarantuoja nei būklės galiojimo, nei Data Availability, nei bridge saugumo.
Data Availability: vis dar atviras klausimas
Kritinis klausimas yra toks: kur iš tikrųjų saugomi operacijų duomenys? Jei Bitcoin tinkle būtų skelbiamas tik įsipareigojimas, o visi duomenys liktų sequencerio rankose, architektūra labiau priartėtų prie validium tipo modelio nei prie rollup su viešai prieinamais duomenimis. Šis atskyrimas nėra vien akademinis: jei sequenceris išnyktų kartu su duomenimis, naudotojai galėtų nebeturėti galimybės įrodyti savo pačių likučio.
Pagal projekto paskelbtą dokumentaciją, galutinis Data Availability sprendimas dar nagrinėjamas; 2026 m. kovo 27 d. atnaujinimas tai nurodo aiškiai. Tarp nagrinėjamų variantų yra išoriniai Data Availability sluoksniai, tokie kaip Celestia, erasure coding ir paskirstytų mazgų naudojimas.
Apibendrinant
Rollup Bitcoin tinkle gali kelti kelis architektūrinius tikslus: naudoti Bitcoin būklės įsipareigojimams registruoti; padidinti pralaidumą vykdant operacijas už grandinės ribų; suteikti smart contract aplinką; ir sumažinti kaštus naudotojui. Kiek šie tikslai bus pasiekti, priklauso nuo konkretaus įgyvendinimo, Data Availability, įrodymų sistemos ir išėjimo mechanizmų.
Šio požiūrio kaina — didesnis architektūrinis sudėtingumas ir keli vis dar atviri architektūriniai pasirinkimai: sequenceris, Data Availability, bridge ir įrodymų sistema. Projektas tvirtina, kad šie elementai galės būti sprendžiami palaipsniui; tai yra paties projekto pozicija, kurią dar reikia nepriklausomai patikrinti.