L'architecture Voyager de Celestia dépasse 21 millions de TPS lors d'un test portant sur 100 millions de comptes
Points clés
- •L'architecture Voyager de Celestia aurait soutenu plus de 21 millions de transferts de compte à compte par seconde lors de tests impliquant 100 millions de comptes.
- •Voyager s'écarte de l'exécution parallèle en faisant fonctionner sa fonction de transition d'état principale sur un seul thread, afin de maintenir des accès mémoire prévisibles et d'accroître l'efficacité du processeur.
- •Le système coordonne ses composants via un tampon circulaire partagé adapté de la bibliothèque de messagerie LMAX Disruptor, réduisant les goulots d'étranglement liés à la synchronisation.
- •Le traitement des transactions est organisé en étapes de pipeline indépendantes, comprenant la journalisation, l'exécution, l'écriture en base de données et la publication de la disponibilité des données, avec un traitement par lots pouvant combiner jusqu'à 128 emplacements du tampon circulaire.
- •Celestia a présenté ce benchmark comme la preuve d'une scalabilité spécifique à l'application, tout en soulignant que l'adoption pratique dépend de facteurs tels que les exigences matérielles, la sécurité, la décentralisation et les charges de travail réelles.

Celestia, le projet à l'origine du réseau modulaire de disponibilité des données du même nom, a annoncé que son architecture blockchain Voyager a démontré sa capacité à soutenir plus de 21 millions de transferts de compte à compte par seconde (TPS) lors de tests de performance impliquant 100 millions de comptes. Ce benchmark a été réalisé à l'aide de transactions de paiement générées aléatoirement, un résultat que le projet présente comme illustrant le potentiel des architectures blockchain spécifiques à une application pour soutenir des opérations financières à haut volume.
Ce jalon reflète une approche architecturale centrée sur la réduction des coûts de coordination, l'amélioration de l'efficacité du processeur et l'optimisation du traitement des transactions entre les différents composants du système. Plutôt que de recourir aux méthodes conventionnelles d'exécution parallèle, Voyager utilise un pipeline de traitement coordonné conçu pour minimiser les dépendances entre les composants individuels, offrant une voie potentielle pour faire évoluer l'infrastructure blockchain vers des applications de paiement à haute fréquence.
Une architecture à tampon circulaire réduit la coordination du système
La performance de Voyager repose sur une philosophie de conception qui sépare les composants du système et minimise les dépendances directes entre eux. Au lieu de permettre aux composants de communiquer via des mécanismes de synchronisation partagés ou des mutex, l'architecture utilise un tampon circulaire commun adapté du modèle LMAX Disruptor. Le LMAX Disruptor est une bibliothèque open source de messagerie inter-threads développée à l'origine pour LMAX Exchange, une plateforme de trading financier, afin de soutenir un débit de transactions élevé avec une faible latence.
Le tampon circulaire agit comme un mécanisme de coordination par lequel les différents composants de traitement échangent des données de transactions. Cette disposition réduit le besoin de synchronisations fréquentes entre les threads et contribue à limiter les goulots d'étranglement liés à la coordination.
L'architecture suit également un modèle de performance dans lequel le débit global du système dépend du composant de traitement le plus lent. En minimisant les interactions inutiles entre les composants, Voyager vise à améliorer l'efficacité opérationnelle et à rendre les goulots d'étranglement plus faciles à identifier.
Ses principaux éléments architecturaux comprennent le tampon circulaire partagé, une fonction de transition d'état mono-thread, des opérations disque et réseau par lots, et des mécanismes de contre-pression conçus pour contrôler la consommation de mémoire.
Le traitement mono-thread améliore l'efficacité du CPU
L'une des décisions de conception les plus notables de Voyager est l'utilisation d'une fonction de transition d'état (STF) mono-thread, ce qui s'écarte des architectures blockchain qui dépendent fortement de l'exécution parallèle des transactions. La STF effectue les opérations essentielles à la mise à jour de l'état de la blockchain, notamment la vérification des soldes des comptes, l'application des transferts et la génération des changements d'état qui en résultent.
Plutôt que de répartir ces opérations sur plusieurs threads d'exécution, Voyager les exécute sur un seul thread de traitement afin de maintenir des schémas d'accès à la mémoire prévisibles. Cette approche vise à éviter la dégradation des performances qui se produit lorsque plusieurs threads se disputent des ressources mémoire partagées.
Le système exploite également l'exécution dans le désordre au niveau du processeur et la mise en cache des données pour améliorer l'efficacité des calculs. Ces techniques permettent au processeur d'exécuter les instructions plus efficacement tout en réduisant les délais liés à la récupération des informations fréquemment nécessaires.
En limitant la concurrence entre les threads de traitement, Voyager cherche à maintenir des performances d'exécution constantes, même lorsqu'il traite des volumes de transactions extrêmement élevés.
Traitement en pipeline et opérations par lots
Voyager organise le traitement des transactions en plusieurs étapes, notamment la journalisation, l'exécution, l'écriture en base de données et la publication de la disponibilité des données. Chaque étape fonctionne de manière indépendante tout en communiquant avec les autres composants via le tampon circulaire partagé, ce qui permet à différents lots de transactions de progresser simultanément dans des étapes distinctes plutôt que d'exiger que l'ensemble du système termine une opération avant d'en commencer une autre.
L'architecture intègre le traitement par lots à deux niveaux : chaque emplacement du tampon circulaire peut contenir plusieurs transactions, tandis que les composants de traitement en aval peuvent combiner jusqu'à 128 emplacements avant de soumettre leurs opérations.
Celestia a expliqué la rationale de cette conception dans une publication sur X le 12 novembre 2026 :
Most chains have attempted to scale by parallelizing execution. Voyager takes the opposite approach with the core state transition function running on a single core. This works because the execution isn't the bottleneck, memory access is.
— Celestia (@celestia), November 12, 2026 (https://x.com/celestia/status/2120928085277331607?ref_src=twsrc%5Etfw)
Cette approche réduit la fréquence des activités gourmandes en ressources, notamment la synchronisation du journal et les soumissions en base de données. Le traitement de lots plus importants peut réduire les coûts opérationnels et améliorer le débit global.
Voyager intègre également des mécanismes de contre-pression pour éviter une consommation excessive de mémoire. Lorsque les composants en aval subissent des retards, le traitement en amont est ralenti afin de maintenir une charge de travail gérable et d'empêcher la saturation des ressources du système.
Implications pour la scalabilité de la blockchain
Le benchmark rapporté met en évidence le potentiel des architectures blockchain spécialisées, conçues autour de charges de travail particulières plutôt que d'exigences d'exécution à usage général. Les systèmes de paiement à haute fréquence nécessitent une infrastructure capable de traiter de grands volumes de transactions tout en maintenant des performances prévisibles et des mises à jour d'état fiables.
L'étape finale du pipeline, la publication de la disponibilité des données, est également liée au rôle plus large de Celestia en tant que réseau modulaire de disponibilité des données, où le maintien de l'accessibilité des données de transactions à des fins de vérification constitue une préoccupation de conception centrale.
Les architectures blockchain conventionnelles peuvent rencontrer des limites lorsque l'exécution des transactions, les opérations de stockage et la communication réseau se disputent les ressources du système. Voyager tente de relever ces défis par la séparation des composants, le traitement par lots coordonné et l'optimisation du traitement de l'état.
En combinant un tampon circulaire partagé, une exécution d'état mono-thread et des pipelines de traitement indépendants, l'architecture Voyager de Celestia cherche à réduire les goulots d'étranglement de calcul tout en soutenant un débit de transactions exceptionnellement élevé.
Le résultat rapporté de 21 millions de TPS représente un jalon de performance important pour le projet. Cependant, l'adoption pratique dépendra également de facteurs tels que les conditions du réseau, les exigences matérielles, la sécurité, la décentralisation et les performances sous des charges de travail de transactions réelles.
Ce développement s'inscrit dans les efforts continus de l'industrie pour améliorer la scalabilité de la blockchain, en particulier pour les applications de paiement nécessitant une capacité de transaction extrêmement élevée.