Hvad er en rollup, og hvorfor havde Bitcoin brug for en?

Bitcoins skalerbarhedsproblem

Bitcoin er designet, så det prioriterer verificerbarhed, decentralisering og robusthed frem for at maksimere antallet af transaktioner per sekund. Hver full node validerer transaktionerne efter protokollens regler. På baselaget er kapaciteten begrænset og anslås ofte, som en vejledende værdi, til omkring 7 transaktioner per sekund, selv om den faktiske værdi afhænger af transaktionernes art og omfang.

I årevis kunne debatten koges ned til ét spørgsmål: hvordan øger man Bitcoins kapacitet uden at bringe det, der gør det unikt, i fare?

De hidtil afprøvede veje

Det første svar var Lightning Network, der har været i drift siden 2018: et netværk af betalingskanaler, som muliggør hurtige og typisk billige betalinger, også via ruter over flere kanaler. Det er først og fremmest rettet mod betalinger og tilbyder ikke et universelt miljø for smart contracts. Dets funktion afhænger desuden af den tilgængelige likviditet og af muligheden for at finde en egnet rute.

Stacks har valgt en anden tilgang: et smart contract-netværk, der er forbundet med Bitcoin via PoX-mekanismen og har sit eget sprog, Clarity. Dets sikkerhedsmodel og finalitet adskiller sig fra Bitcoins og afhænger desuden af de specifikke regler i Stacks-netværket.

Rootstock (RSK) har valgt EVM-kompatibilitet og merge-mining med Bitcoin. Netværket har været i drift siden 2018 og anvender en sidechain-model med egne sikkerheds- og bridge-antagelser.

Hvorfor en rollup er anderledes

En rollup er ikke en sidechain. Den tekniske sondring er vigtig:

• - En sidechain bevarer sin egen konsensus- eller valideringsmekanisme. Dens sikkerhed afhænger primært af dette system og af udformningen af den bridge, der forbinder den med Bitcoin.
• - I den arkitektur, der beskrives for Bitcoin Hyper, ville udførelsen finde sted uden for Bitcoin, og state commitments ville blive offentliggjort på baselaget. Den faktiske klassificering som rollup afhænger desuden af datatilgængeligheden og af bevissystemet.

Ifølge den arkitektur, som projektet har offentliggjort, ville den tilsigtede proces se således ud:

1. Brugerne ville sende deres transaktioner til sequenceren
2. Sequenceren ville ordne dem og udføre dem i batches
3. Periodisk ville en state commitment, beskrevet som Merkle-rod af den opdaterede tilstand, blive offentliggjort på Bitcoin via OP_RETURN eller Taproot
4. Muligheden for at verificere overgangen ville afhænge af datatilgængeligheden og af bevissystemet; commitment'et alene beviser ikke, at overgangen er korrekt

Så snart den er bekræftet på Bitcoin, nyder en state commitment godt af den praktiske uforanderlighed ved den transaktion, den indeholder. Det gør det vanskeligt at ændre denne registrering efterfølgende, men forhindrer ikke i sig selv offentliggørelsen af en fejlagtig commitment og garanterer hverken tilstandens gyldighed, datatilgængeligheden eller sikkerheden ved bridgen.

Datatilgængeligheden: et endnu åbent spørgsmål

Det kritiske punkt er følgende: hvor befinder transaktionsdataene sig i virkeligheden? Hvis kun commitment'et offentliggøres på Bitcoin, mens de fuldstændige data forbliver i sequencerens varetægt, ville arkitekturen ligge tættere på en model af Validium-typen end på en rollup med offentlig datatilgængelighed. Denne sondring er ikke rent akademisk: hvis sequenceren forsvandt med dataene, ville brugerne muligvis ikke længere være i stand til at dokumentere deres eget saldo.

Ifølge den dokumentation, som projektet har offentliggjort, undersøges den endelige løsning på datatilgængeligheden fortsat; en opdatering af 27. marts 2026 påpeger dette udtrykkeligt. Blandt de undersøgte muligheder er eksterne datatilgængelighedslag som Celestia, erasure coding og anvendelsen af distribuerede noder.

Opsummeret

En rollup på Bitcoin kan forfølge flere designmål: at bruge Bitcoin til at forankre state commitments; at øge kapaciteten via en off-chain-udførelse; at tilbyde et miljø for smart contracts; og at reducere omkostningerne for brugerne. I hvilket omfang disse mål kan nås, afhænger af den konkrete implementering, datatilgængeligheden, bevissystemet og udtrædelsesmekanismerne.

Prisen for denne tilgang ligger i en øget arkitektonisk kompleksitet og i flere endnu uafklarede designvalg: sequenceren, datatilgængeligheden, bridgen og bevissystemet. Projektet hævder, at disse elementer kan håndteres trinvist; der er her tale om projektets eget standpunkt, som endnu skal verificeres uafhængigt.