À des fins éducatives uniquement ; ne constitue pas un conseil financier, d’investissement, de finalité des transactions ou de sécurité. Le comportement du séquenceur, les voies de repli et les garanties de règlement varient selon le réseau et peuvent changer après une mise à niveau.
Réponse directe
Dans de nombreux rollups, un séquenceur est le composant ou le participant qui accepte les transactions, choisit leur ordre et produit des blocs ou des lots. Il peut fournir rapidement un accusé de réception avant la publication des données ordonnées sur la couche de base. La répartition exacte varie : construction des blocs, exécution et publication des lots peuvent relever du même opérateur ou de services distincts.
Un séquenceur n’est pas la source du règlement final simplement parce qu’un portefeuille affiche une réussite. La solidité d’une confirmation dépend du fait que le séquenceur a seulement annoncé le bloc, que les données du protocole ont atteint L1 et que le bloc L1 ainsi que l’affirmation ou la preuve du rollup ont atteint l’état de finalité requis.
Fonctionnement
- Réception. Les utilisateurs ou applications soumettent des transactions signées à un point d’accès du séquenceur, mais le réseau peut aussi définir une voie de soumission par L1.
- Ordonnancement. Le séquenceur sélectionne les transactions et fixe leur ordre sous réserve des règles de validité du protocole. Ce choix peut affecter latence, frais, censure et MEV.
- Construction. Il assemble les transactions ordonnées en blocs du rollup et peut les exécuter pour calculer l’état obtenu.
- Préconfirmation. Le séquenceur diffuse rapidement un bloc ou un reçu. Il s’agit d’un signal d’ordre provisoire, pas automatiquement d’un résultat finalisé sur L1.
- Publication. Un publieur de lots ou service équivalent envoie les données définies par le protocole vers la couche de disponibilité des données, souvent L1. Les nœuds indépendants les utilisent avec les règles du protocole pour dériver la chaîne canonique du rollup.
- Règlement. Les engagements d’état, preuves de faute ou preuves de validité relient l’exécution au règlement. Ils vérifient ou établissent la correction des transitions d’état, mais ne décentralisent pas à eux seuls l’ordre des transactions.
Exemple
Un portefeuille affiche d’abord une transaction comme confirmée par le séquenceur. À ce stade, l’opérateur peut encore ne pas publier le lot correspondant ou remplacer un bloc non publié selon les règles du réseau. Une fois les données incluses sur L1, les nœuds indépendants peuvent dériver la place de la transaction dans le rollup, mais une réorganisation de L1 peut toujours l’affecter. L’application ne devrait attribuer le statut correspondant qu’après satisfaction des conditions de finalité de L1 et du rollup.
Cette séquence est un modèle d’états, pas une promesse de délai universelle. Les termes en attente, non sûr, sûr et finalisé dépendent du protocole, et un pont peut imposer un délai supplémentaire de preuve ou de contestation avant qu’un retrait soit exécutable.
Risques
- Indisponibilité. Si le séquenceur actif s’arrête, la soumission directe et la production rapide de blocs peuvent être suspendues même sans perte de fonds.
- Censure. Un opérateur peut retarder ou refuser certaines transactions. Une voie d’inclusion forcée ou de sortie n’aide que si elle est déployée, sans permission, utilisable et appuyée par des données disponibles.
- Réordonnancement et MEV. Le contrôle de l’ordre peut permettre front-running, back-running ou traitement préférentiel dans les limites du protocole.
- Réversion d’état provisoire. Une application qui considère le reçu du séquenceur comme final peut agir sur un bloc ensuite remplacé ou jamais publié.
- Défaillance de publication ou de la couche de base. Congestion, panne du publieur, données indisponibles ou réorganisation de L1 peuvent retarder ou modifier la chaîne dérivée par les vérificateurs.
- Concentration opérationnelle. Un opérateur, une clé de signature, un point RPC ou une autorité de mise à niveau uniques peuvent créer des points communs de panne et de contrôle même si les preuves vérifient l’exécution.
Idées reçues
- Le séquenceur décide du règlement final. Celui-ci suit les contrats du rollup, les règles de preuve ou de contestation, la disponibilité des données et le consensus de la couche de base.
- Un reçu rapide est irréversible. Une préconfirmation peut être utile sans offrir la même assurance que des données publiées et finalisées.
- L’inclusion forcée garantit une exécution immédiate. Le repli peut exiger une transaction L1, un délai, des calldata précises et une voie contractuelle fonctionnelle.
- Les preuves de validité éliminent le risque du séquenceur. Elles peuvent prouver une exécution correcte alors que l’ordre reste centralisé, censurable ou indisponible.
- Le séquençage décentralisé élimine toute confiance. Il peut répartir le pouvoir d’ordonner, mais ajoute ses propres hypothèses de consensus, disponibilité, gestion des clés et interopérabilité.
Sujets connexes
Sources
- Mise à l’échelle d’Ethereum - Ethereum.org (consulté : 2026-08-21)
- Dérivation - OP Stack Specification (consulté : 2026-08-21)
- Finalité des transactions - Optimism Documentation (consulté : 2026-08-21)
- Arbitrum Nitro : un rollup optimiste de deuxième génération - Arbitrum Documentation (consulté : 2026-08-21)