En enda sequencer vid lanseringen: risk eller pragmatism?

Att ordna transaktioner är en form av makt

Varje rollup behöver någon — eller något — som bestämmer den ordning som transaktionerna behandlas i. Det är sequencerns uppgift.

Ordningen är inte neutral. Den som kontrollerar sequencern kan: utvinna MEV (Maximal Extractable Value) genom att infoga eller omordna transaktioner till egen fördel; censurera transaktioner genom att ignorera dem som inte får behandlas; och utföra front-running genom att förekomma andra användares transaktioner.

I ett decentraliserat system samlar ingen enskild aktör denna makt på egen hand. I ett system med en centraliserad sequencer ligger denna makt hos det team som driver den. Bland de risker som är förknippade med denna koncentration finns censur av transaktioner, förseningar, bristande tillgänglighet i tjänsten, kontroll över ordningen, utvinning av MEV och förekomsten av en enda felpunkt.

Varför många rollups börjar med en centraliserad sequencer

Det mest direkta svaret är att denna arkitektur är operativt enklare. I en inledande fas skulle en enda operatör kunna förenkla koordineringen, uppdateringarna och felsökningen. Samtidigt skulle en sådan modell dock koncentrera makten och beroendena i händerna på en enda aktör.

En decentraliserad sequencer kräver ett konsensusprotokoll mellan flera sequencrar, mekanismer mot kollusion, system för val eller rotation av ledaren samt robusta ekonomiska incitament som är svåra att angripa.

Att bygga alla dessa mekanismer före lanseringen kan kräva avsevärd extra utvecklingstid. Arbitrum, Optimism och Base — tre viktiga rollups på Ethereum — lanserades med en centraliserad sequencer och fortsätter sin decentraliseringsprocess flera år senare. Denna jämförelse är rent kontextuell: den förutsätter ingen arkitektonisk eller säkerhetsmässig ekvivalens med den arkitektur som beskrivs för Bitcoin Hyper.

Enligt den projektdokumentation som analyseras i kapitel 34.2 i boken skulle sequencern vara centraliserad vid lanseringen av Mainnet och drivas av teamet. Vid brytdatumet befann sig Bitcoin Hyper fortfarande i en fas före Mainnet: den enda sequencern ingår i den planerade lanseringsmodellen och inte i en redan verifierad operativ komponent. Roadmappen förutser en gradvis decentralisering över en period på två till fyra år med hjälp av mekanismer för rotation, auktion och ledarval. Det rör sig om en uttalad avsikt och inte om en färdig funktion.

Hur skulle censurrisken begränsas?

Den viktigaste planerade arkitektoniska mekanismen är tvingad inkludering (forced inclusion): en transaktion skulle via Bitcoins baslager kunna «tvingas» in i rollupen förbi sequencern. Om sequencern censurerade en transaktion skulle användaren kunna få den behandlad genom att betala avgifterna direkt på Bitcoin. En enda sequencer inför en central punkt för operativ kontroll; den tvingade inkluderingen är den planerade säkerhetsmekanism som ska förhindra att denna kontroll blir absolut. Den bör betraktas som en dokumenterad funktion som ännu återstår att verifiera, och inte som en redan tillgänglig garanti.

Det avgörande förbehållet är att den tvingade inkluderingen i Bitcoin Hyper fortfarande är under utveckling (per den 28 april 2026). På Devnet var den inte tillgänglig. Så länge den inte är publicerad och testad förblir det skydd den bör ge overifierat. Denna uppgift avser den dokumentation som var tillgänglig vid den aktuella tidpunkten.

Signaler som bör observeras

Innan du överväger en position i Bitcoin Hyper är detta de signaler som skulle indikera verkliga framsteg i decentraliseringen av sequencern. Vid brytdatumet förelåg ingen offentlig och tillräckligt detaljerad specifikation av den slutliga mekanismen:

1. Offentliga tekniska specifikationer av den valda decentraliseringsmekanismen
2. En operativ tvingad inkludering på Testnet eller Mainnet
3. En roadmap med verifierbara milstolpar (och inte bara «under de kommande åren»)
4. En granskning av sequencer-koden utförd av erkända oberoende företag
5. En trovärdig tidsplan med explicita beroenden

Slutsats

En centraliserad sequencer vid lanseringen kan vara ett pragmatiskt och begripligt val utan att nödvändigtvis utgöra en varningssignal. I sig innebär den inte förlust av medel, men den skulle kunna försvaga tjänstens tillgänglighet, ordningen på transaktionerna och censurmotståndet. Den blir problematisk när det saknas en konkret roadmap för decentraliseringen, när den tvingade inkluderingen aldrig implementeras, eller när den som driver sequencern använder sin position för att utvinna MEV på ett ogenomskinligt sätt.

Projektet förklarar att sequencing kommer att decentraliseras i en senare fas. I skrivande stund förblir denna övergång ett mål i roadmappen, och ett allmänt löfte om decentralisering utgör inte en verifierbar roadmap. Sequencern, bridgen, datatillgängligheten och bevissystemet utgör olika lager: att decentralisera sequencern skulle inte automatiskt undanröja de risker som är förknippade med bridgen, lika lite som dem som knyter an till datatillgängligheten. Den tvingade inkluderingen, det tvingade utträdet och Escape Hatch bör betraktas som dokumenterade funktioner eller funktioner som ännu återstår att verifiera. En enda sequencer kan vara en pragmatisk utgångspunkt, men bör inte framställas som en slutpunkt: bedömningen kommer att bero på de publicerade begränsningarna, de befintliga kontrollerna och de alternativa procedurerna. Decentraliseringens trovärdighet kommer att bero på verifierbara milstolpar och inte på enbart avsiktsförklaringar.