En enkelt sequencer ved lanceringen: risiko eller pragmatisme?

At ordne transaktioner er en form for magt

Ethvert rollup har brug for nogen — eller noget — der bestemmer den rækkefølge, transaktionerne behandles i. Det er sequencerens opgave.

Rækkefølgen er ikke neutral. Den, der kontrollerer sequenceren, kan: udtrække MEV (Maximal Extractable Value) ved at indsætte eller omordne transaktioner til egen fordel; censurere transaktioner ved at ignorere dem, der ikke må behandles; og udføre front-running ved at komme andre brugeres transaktioner i forkøbet.

I et decentraliseret system samler ingen enkelt aktør denne magt alene. I et system med en centraliseret sequencer ligger denne magt hos det team, der driver den. Blandt de risici, der er forbundet med denne koncentration, er censur af transaktioner, forsinkelser, manglende tilgængelighed af tjenesten, kontrol over rækkefølgen, udtrækning af MEV og eksistensen af et enkelt fejlpunkt.

Hvorfor mange rollups begynder med en centraliseret sequencer

Det mest direkte svar er, at denne arkitektur er operationelt enklere. I en indledende fase ville en enkelt operatør kunne forenkle koordineringen, opdateringerne og fejlfindingen. Samtidig ville en sådan model dog koncentrere magten og afhængighederne i hænderne på én enkelt aktør.

En decentraliseret sequencer kræver en konsensusprotokol mellem flere sequencere, mekanismer mod kollusion, systemer til valg eller rotation af lederen samt robuste økonomiske incitamenter, der er vanskelige at angribe.

At bygge alle disse mekanismer inden lanceringen kan kræve betydelig ekstra udviklingstid. Arbitrum, Optimism og Base — tre vigtige rollups på Ethereum — blev lanceret med en centraliseret sequencer og fortsætter deres decentraliseringsproces flere år senere. Denne sammenligning er rent kontekstuel: den forudsætter ingen arkitektonisk eller sikkerhedsmæssig ækvivalens med den arkitektur, der er beskrevet for Bitcoin Hyper.

Ifølge den projektdokumentation, der analyseres i kapitel 34.2 i bogen, ville sequenceren være centraliseret ved lanceringen af Mainnet og drevet af teamet. På skæringsdatoen befandt Bitcoin Hyper sig fortsat i en fase forud for Mainnet: den enkelte sequencer indgår i den planlagte lanceringsmodel og ikke i en allerede verificeret operationel komponent. Roadmappen lægger op til en gradvis decentralisering over en periode på to til fire år ved hjælp af mekanismer til rotation, auktion og ledervalg. Der er tale om en erklæret hensigt og ikke om en færdig funktion.

Hvordan ville censurrisikoen blive begrænset?

Den vigtigste planlagte arkitektoniske mekanisme er tvungen inklusion (forced inclusion): en transaktion ville via Bitcoins basislag kunne «tvinges» ind i rollup'et uden om sequenceren. Hvis sequenceren censurerede en transaktion, ville brugeren kunne få den behandlet ved at betale gebyrerne direkte på Bitcoin. En enkelt sequencer indfører et centralt punkt for operationel kontrol; den tvungne inklusion er den planlagte sikkerhedsmekanisme, der skal forhindre, at denne kontrol bliver absolut. Den bør betragtes som en dokumenteret funktion, der endnu skal verificeres, og ikke som en allerede tilgængelig garanti.

Det afgørende forbehold er, at den tvungne inklusion i Bitcoin Hyper fortsat er under udvikling (pr. 28 april 2026). På Devnet var den ikke tilgængelig. Så længe den ikke er offentliggjort og testet, er den beskyttelse, den bør give, fortsat uverificeret. Denne oplysning vedrører den dokumentation, der var tilgængelig på det pågældende tidspunkt.

Signaler, der bør observeres

Før du overvejer en position i Bitcoin Hyper, er dette de signaler, der ville indikere reelle fremskridt i decentraliseringen af sequenceren. På skæringsdatoen forelå der ingen offentlig og tilstrækkeligt detaljeret specifikation af den endelige mekanisme:

1. Offentlige tekniske specifikationer af den valgte decentraliseringsmekanisme
2. En operationel tvungen inklusion på Testnet eller Mainnet
3. En roadmap med verificerbare milepæle (og ikke blot «i de kommende år»)
4. En audit af sequencer-koden udført af anerkendte uafhængige virksomheder
5. En troværdig tidsplan med eksplicitte afhængigheder

Konklusion

En centraliseret sequencer ved lanceringen kan være et pragmatisk og forståeligt valg uden nødvendigvis at udgøre et alarmsignal. I sig selv indebærer den ikke tab af midler, men den vil kunne svække tjenestens tilgængelighed, rækkefølgen af transaktionerne og censurmodstanden. Den bliver problematisk, når der mangler en konkret roadmap for decentraliseringen, når den tvungne inklusion aldrig implementeres, eller når den, der driver sequenceren, bruger sin position til at udtrække MEV på en uigennemsigtig måde.

Projektet erklærer, at sequencing vil blive decentraliseret i en senere fase. På skrivende tidspunkt forbliver denne overgang et mål i roadmappen, og et generelt løfte om decentralisering udgør ikke en verificerbar roadmap. Sequenceren, bridgen, datatilgængeligheden og bevissystemet udgør forskellige lag: at decentralisere sequenceren ville ikke automatisk fjerne de risici, der er forbundet med bridgen, lige så lidt som dem, der knytter sig til datatilgængeligheden. Den tvungne inklusion, den tvungne udtræden og Escape Hatch bør betragtes som dokumenterede funktioner eller funktioner, der endnu skal verificeres. En enkelt sequencer kan være et pragmatisk udgangspunkt, men bør ikke fremstilles som et endepunkt: vurderingen vil afhænge af de offentliggjorte begrænsninger, de eksisterende kontroller og de alternative procedurer. Decentraliseringens troværdighed vil afhænge af verificerbare milepæle og ikke af blotte hensigtserklæringer.