Ordonner les transactions est une forme de pouvoir

Tout rollup a besoin de quelqu’un — ou de quelque chose — qui décide de l’ordre dans lequel les transactions sont traitées. C’est la fonction du séquenceur.

L’ordonnancement n’est pas neutre. Celui qui contrôle le séquenceur peut : extraire de la MEV (Maximal Extractable Value) en insérant ou en réordonnant des transactions à son propre avantage ; censurer des transactions en ignorant celles qu’il ne souhaite pas traiter ; et pratiquer le front-running, en devançant les transactions d’autres utilisateurs.

Dans un système décentralisé, aucun acteur ne concentre à lui seul ce pouvoir. Dans un système doté d’un séquenceur centralisé, ce pouvoir revient à l’équipe qui l’exploite. Les risques associés à cette concentration comprennent la censure des transactions, les retards, l’indisponibilité du service, le contrôle de l’ordonnancement, l’extraction de MEV et l’existence d’un point de défaillance unique.

Pourquoi de nombreux rollups commencent avec un séquenceur centralisé

La réponse la plus directe est que cette architecture est plus simple sur le plan opérationnel. Durant une phase initiale, un opérateur unique pourrait simplifier la coordination, les mises à jour et le diagnostic des incidents. Il concentrerait toutefois également le pouvoir et les dépendances entre les mains d’un seul acteur.

Un séquenceur décentralisé exige un protocole de consensus entre plusieurs séquenceurs, des mécanismes contre la collusion, des systèmes d’élection ou de rotation du leader ainsi que des incitations économiques robustes et difficiles à attaquer.

Construire l’ensemble de ces mécanismes avant le lancement peut nécessiter une période de développement supplémentaire considérable. Arbitrum, Optimism et Base — trois rollups importants d’Ethereum — ont été lancés avec un séquenceur centralisé et poursuivent encore, plusieurs années plus tard, leur processus de décentralisation. Cette comparaison est uniquement contextuelle : elle n’implique aucune équivalence architecturale ni de sécurité avec l’architecture décrite pour Bitcoin Hyper.

Selon la documentation du projet analysée au chapitre 34.2 du livre, lors du lancement de la mainnet, le séquenceur serait centralisé et exploité par l’équipe. À la date de référence, Bitcoin Hyper se trouvait encore dans une phase antérieure à la mainnet : le séquenceur unique fait partie du modèle de lancement prévu et non d’un composant opérationnel déjà vérifié. La feuille de route envisage une décentralisation progressive sur une période de deux à quatre ans, au moyen de mécanismes de rotation, d’enchères et d’élection du leader. Il s’agit d’une intention déclarée et non d’une fonctionnalité achevée.

Comment le risque de censure serait-il atténué ?

Le principal mécanisme architectural prévu est l’inclusion forcée (forced inclusion) : une transaction pourrait être « forcée » dans le rollup via la couche de base de Bitcoin, sans passer par le séquenceur. Si le séquenceur censurait une transaction, l’utilisateur pourrait la faire traiter en payant directement les frais sur Bitcoin. Un séquenceur unique introduit un point central de contrôle opérationnel ; l’inclusion forcée constitue le mécanisme de sécurité prévu afin que ce contrôle ne devienne pas absolu. Elle doit être considérée comme une fonctionnalité documentée restant à vérifier, et non comme une garantie déjà disponible.

La réserve essentielle est que l’inclusion forcée demeure en cours de développement dans Bitcoin Hyper (situation au 28 avril 2026). Elle n’était pas disponible sur la devnet. Tant qu’elle n’aura pas été publiée et soumise à des tests, la protection qu’elle est censée offrir restera à vérifier. Cette information se rapporte à la documentation disponible à cette date.

Signaux à surveiller

Avant d’envisager toute exposition à Bitcoin Hyper, voici les signaux qui indiqueraient une progression réelle de la décentralisation du séquenceur. À la date de référence, aucune spécification publique suffisamment détaillée du mécanisme définitif n’a été identifiée :

Des spécifications techniques publiques du mécanisme de décentralisation retenu
Une inclusion forcée opérationnelle sur testnet ou mainnet
Une feuille de route comportant des jalons vérifiables (et non simplement « dans les prochaines années »)
Un audit du code du séquenceur réalisé par des sociétés indépendantes reconnues
Un calendrier crédible comportant des dépendances explicites

Conclusion

Un séquenceur centralisé au lancement peut constituer un choix pragmatique et compréhensible, sans être nécessairement un signal d’alarme. Il n’implique pas à lui seul une perte de fonds, mais pourrait affecter la disponibilité du service, l’ordonnancement des transactions et la résistance à la censure. Il devient problématique en l’absence d’une feuille de route concrète vers la décentralisation, si l’inclusion forcée n’est jamais mise en œuvre ou si l’opérateur du séquenceur utilise sa position pour extraire de la MEV de manière opaque.

Le projet affirme que la séquenciation sera décentralisée lors d’une phase ultérieure. À la date de rédaction, cette transition demeure un objectif de la feuille de route, et une promesse générale de décentralisation ne constitue pas une feuille de route vérifiable. Le séquenceur, le pont, la disponibilité des données et le système de preuves représentent des niveaux distincts : décentraliser le séquenceur n’éliminerait pas automatiquement les risques liés au pont ni ceux associés à la disponibilité des données. L’inclusion forcée, la sortie forcée et l’escape hatch doivent être considérés comme des fonctionnalités documentées ou restant à vérifier. Un séquenceur unique peut constituer un point de départ pragmatique, mais il ne doit pas être présenté comme un point d’arrivée : l’évaluation dépendra des limites publiées, des contrôles existants et des procédures alternatives. La crédibilité de la décentralisation dépendra de jalons vérifiables et non de simples déclarations d’intention.

Un séquenceur unique au lancement : risque ou pragmatisme ?