Transacties ordenen is een vorm van macht

Elk rollup heeft iemand — of iets — nodig die de volgorde bepaalt waarin de transacties worden verwerkt. Dat is de taak van de sequencer.

De ordening is niet neutraal. Wie de sequencer controleert, kan: MEV extraheren (Maximal Extractable Value) door transacties in eigen voordeel in te voegen of te herordenen; transacties censureren door die te negeren welke niet verwerkt mogen worden; en aan front-running doen door de transacties van andere gebruikers voor te zijn.

In een gedecentraliseerd systeem bundelt geen enkele actor deze macht alleen. In een systeem met een gecentraliseerde sequencer ligt deze macht bij het team dat hem exploiteert. Tot de aan deze concentratie verbonden risico's behoren de censuur van transacties, vertragingen, de onbeschikbaarheid van de dienst, de controle over de volgorde, de extractie van MEV en het bestaan van een enkel storingspunt.

Waarom veel rollups met een gecentraliseerde sequencer beginnen

Het meest directe antwoord luidt dat deze architectuur operationeel eenvoudiger is. In een beginfase zou een enkele beheerder de coördinatie, de updates en de diagnose van storingen kunnen vereenvoudigen. Tegelijkertijd zou hij echter de macht en de afhankelijkheden in de handen van één enkele actor bundelen.

Een gedecentraliseerde sequencer vereist een consensusprotocol tussen meerdere sequencers, mechanismen tegen collusie, systemen voor de verkiezing of rotatie van de leader alsook robuuste en moeilijk aan te vallen economische prikkels.

Al deze mechanismen vóór de start bouwen kan een aanzienlijke extra ontwikkeltijd vergen. Arbitrum, Optimism en Base — drie belangrijke rollups op Ethereum — zijn met een gecentraliseerde sequencer gestart en zetten hun decentralisatieproces ook meerdere jaren later nog voort. Deze vergelijking is louter contextueel: zij veronderstelt geen enkele architectonische of beveiligingsgerelateerde gelijkwaardigheid met de voor Bitcoin Hyper beschreven architectuur.

Volgens de in hoofdstuk 34.2 van het boek geanalyseerde projectdocumentatie zou de sequencer bij de start van het Mainnet gecentraliseerd zijn en door het team worden geëxploiteerd. Op de peildatum bevond Bitcoin Hyper zich nog in een fase vóór het Mainnet: de enkele sequencer maakt deel uit van het voorziene startmodel en niet van een reeds geverifieerde operationele component. De roadmap voorziet in een geleidelijke decentralisatie over een periode van twee tot vier jaar door middel van rotatie-, veiling- en leaderverkiezingsmechanismen. Het gaat daarbij om een verklaarde intentie en niet om een voltooide functie.

Hoe zou het censuurrisico worden beperkt?

Het belangrijkste voorziene architectonische mechanisme is de geforceerde inclusie (forced inclusion): een transactie zou via de basislaag van Bitcoin in het rollup kunnen worden «geforceerd», zonder de sequencer te doorlopen. Zou de sequencer een transactie censureren, dan zou de gebruiker haar kunnen laten verwerken door de fees rechtstreeks op Bitcoin te betalen. Een enkele sequencer voert een centraal punt van operationele controle in; de geforceerde inclusie is het voorziene beveiligingsmechanisme opdat deze controle niet absoluut wordt. Zij dient te worden beschouwd als een gedocumenteerde, nog te verifiëren functie en niet als een reeds beschikbare garantie.

Het doorslaggevende voorbehoud is dat de geforceerde inclusie in Bitcoin Hyper zich nog steeds in ontwikkeling bevindt (stand 28 april 2026). Op de Devnet was zij niet beschikbaar. Zolang zij niet is gepubliceerd en getest, blijft de bescherming die zij zou moeten bieden te verifiëren. Deze vermelding heeft betrekking op de op dat moment beschikbare documentatie.

Te observeren signalen

Voordat je een positie in Bitcoin Hyper overweegt, zijn dit de signalen die een echte vooruitgang in de decentralisatie van de sequencer zouden aangeven. Op de peildatum werd geen openbare, voldoende gedetailleerde specificatie van het definitieve mechanisme vastgesteld:

Openbare technische specificaties van het gekozen decentralisatiemechanisme
Een operationele geforceerde inclusie op Testnet of Mainnet
Een roadmap met verifieerbare mijlpalen (en niet slechts «in de komende jaren»)
Een audit van de sequencer-code door erkende onafhankelijke bedrijven
Een geloofwaardig tijdschema met expliciete afhankelijkheden

Conclusie

Een gecentraliseerde sequencer bij de start kan een pragmatische en navolgbare keuze zijn, zonder noodzakelijkerwijs een alarmsignaal te vormen. Op zichzelf betekent hij geen verlies van middelen, maar hij zou de beschikbaarheid van de dienst, de ordening van de transacties en de censuurbestendigheid kunnen aantasten. Problematisch wordt hij wanneer een concrete roadmap voor de decentralisatie ontbreekt, wanneer de geforceerde inclusie nooit wordt geïmplementeerd of wanneer de beheerder van de sequencer zijn positie gebruikt om MEV op ondoorzichtige wijze te extraheren.

Het project verklaart dat de sequencing in een latere fase wordt gedecentraliseerd. Op het moment van schrijven blijft deze overgang een doel van de roadmap, en een algemene decentralisatiebelofte vormt geen verifieerbare roadmap. De sequencer, de bridge, de databeschikbaarheid en het bewijssysteem vormen verschillende lagen: het decentraliseren van de sequencer zou de aan de bridge verbonden risico's evenmin automatisch wegnemen als die welke met de databeschikbaarheid samenhangen. De geforceerde inclusie, de geforceerde uitstap en de Escape Hatch dienen te worden beschouwd als gedocumenteerde of nog te verifiëren functies. Een enkele sequencer kan een pragmatisch uitgangspunt zijn, maar mag niet als eindpunt worden voorgesteld: de beoordeling zal afhangen van de gepubliceerde grenzen, de bestaande controles en de alternatieve procedures. De geloofwaardigheid van de decentralisatie zal afhangen van verifieerbare mijlpalen en niet van loutere intentieverklaringen.

Eén enkele sequencer bij de start: risico of pragmatisme?