Vad är en rollup, och varför behövde Bitcoin en?
Bitcoin prioriterar säkerhet och decentralisering, men bearbetningskapaciteten på baslagret förblir begränsad. Den här artikeln förklarar vad en rollup är, hur den skiljer sig från en sidechain och vilka ytterligare antaganden som arkitekturen för Bitcoin Hyper introducerar.
Utbildningssyfte. Innehållet i denna artikel tjänar uteslutande till information och förklaring. Det utgör inte finansiell rådgivning. Fullständig ansvarsfriskrivning.
Bitcoins skalbarhetsproblem
Bitcoin är utformat så att det prioriterar verifierbarhet, decentralisering och robusthet framför att maximera antalet transaktioner per sekund. Varje full node validerar transaktionerna enligt protokollets regler. På baslagret är kapaciteten begränsad och uppskattas ofta, som ett vägledande värde, till omkring 7 transaktioner per sekund, även om det faktiska värdet beror på transaktionernas art och omfattning.
I åratal kunde debatten kokas ner till en enda fråga: hur ökar man Bitcoins kapacitet utan att äventyra det som gör det unikt?
De vägar som hittills har prövats
Det första svaret var Lightning Network, som har varit i drift sedan 2018: ett nätverk av betalningskanaler som möjliggör snabba och vanligtvis billiga betalningar, även via rutter över flera kanaler. Det är i första hand inriktat på betalningar och erbjuder inte en universell miljö för smarta kontrakt. Dess funktion beror dessutom på den tillgängliga likviditeten och på möjligheten att hitta en lämplig rutt.
Stacks har valt ett annat tillvägagångssätt: ett nätverk för smarta kontrakt som är kopplat till Bitcoin via PoX-mekanismen och har sitt eget språk, Clarity. Dess säkerhetsmodell och finalitet skiljer sig från Bitcoins och beror dessutom på de specifika reglerna i Stacks-nätverket.
Rootstock (RSK) har valt EVM-kompatibilitet och merge-mining med Bitcoin. Nätverket har varit i drift sedan 2018 och använder en sidechain-modell med egna säkerhets- och bridge-antaganden.
Varför en rollup är annorlunda
En rollup är inte en sidechain. Den tekniska distinktionen är viktig:
- - En sidechain behåller sin egen konsensus- eller valideringsmekanism. Dess säkerhet beror främst på detta system och på utformningen av den bridge som förbinder den med Bitcoin.
- - I den arkitektur som beskrivs för Bitcoin Hyper skulle exekveringen ske utanför Bitcoin, och state commitments skulle offentliggöras på baslagret. Den faktiska klassificeringen som rollup beror dessutom på datatillgängligheten och på bevissystemet.
Enligt den arkitektur som projektet har offentliggjort skulle den avsedda processen se ut så här:
- Användarna skulle skicka sina transaktioner till sequencern
- Sequencern skulle ordna dem och utföra dem i batcher
- Med jämna mellanrum skulle ett state commitment, beskrivet som Merkle-roten av det uppdaterade tillståndet, offentliggöras på Bitcoin via OP_RETURN eller Taproot
- Möjligheten att verifiera övergången skulle bero på datatillgängligheten och på bevissystemet; commitmentet i sig bevisar inte att övergången är korrekt
Så snart det har bekräftats på Bitcoin drar ett state commitment nytta av den praktiska oföränderligheten hos den transaktion som det innehåller. Det gör det svårt att i efterhand ändra denna registrering, men förhindrar inte i sig att ett felaktigt commitment offentliggörs och garanterar varken tillståndets giltighet, datatillgängligheten eller bridgens säkerhet.
Datatillgängligheten: en ännu öppen fråga
Den kritiska punkten är följande: var befinner sig transaktionsdatan i verkligheten? Om endast commitmentet offentliggörs på Bitcoin medan de fullständiga uppgifterna förblir i sequencerns förvar, skulle arkitekturen ligga närmare en modell av Validium-typ än en rollup med offentlig datatillgänglighet. Denna distinktion är inte rent akademisk: om sequencern försvann med datan skulle användarna kanske inte längre kunna styrka sitt eget saldo.
Enligt den dokumentation som projektet har offentliggjort utreds den slutliga lösningen på datatillgängligheten fortfarande; en uppdatering av den 27 mars 2026 påpekar detta uttryckligen. Bland de alternativ som undersöks finns externa datatillgänglighetslager som Celestia, erasure coding och användningen av distribuerade noder.
Sammanfattning
En rollup på Bitcoin kan eftersträva flera designmål: att använda Bitcoin för att förankra state commitments; att öka kapaciteten genom en off-chain-exekvering; att erbjuda en miljö för smarta kontrakt; och att sänka kostnaderna för användarna. I vilken utsträckning dessa mål kan uppnås beror på den konkreta implementeringen, datatillgängligheten, bevissystemet och utträdesmekanismerna.
Priset för detta tillvägagångssätt ligger i en ökad arkitektonisk komplexitet och i flera ännu olösta designval: sequencern, datatillgängligheten, bridgen och bevissystemet. Projektet hävdar att dessa element kan hanteras stegvis; det rör sig här om projektets egen ståndpunkt, som ännu återstår att verifiera oberoende.