1/ Nous venons de briser le goulot d'étranglement de l'engagement d'état chez Eclipse : AlDBaran soutient 48M mises à jour/sec sur une machine AWS à 96 cœurs, accélérant le rollup GigaCompute d'Eclipse.

2/ Pourquoi c'est important : 1M TPS -> 3M mises à jour d'état/sec (~3 clés/tx sur Eclipse). Les moteurs ADS standard s'effondrent en dessous de 0,6 M/s, un écart de 5x que nous avons refusé d'accepter.

3/ Rencontrez AlDBaran : deux moteurs spécialement conçus pour l'état. 🔹 Pleiades - mises à jour ultra-rapides en DRAM 🔹 Hyades - stockage de preuves asynchrone et en ajout uniquement

4/ Les cinq règles de conception de Pleiades : 1️⃣ Exécution uniquement DRAM (pas de fsync/de fautes de page) 2️⃣ Partage de threads (0 verrous) 3️⃣ Mise en mémoire tampon Twig (différer le hachage de l'arbre supérieur) 4️⃣ Regroupement SIMD (16 hachages/opération vectorielle) 5️⃣ Disposition prévisible + préchargement (hits du cache L2)

5/ Points forts de l'évaluation : - 48M ups sur 96 cœurs pour Pleiades à environ 1B clés (0,5 M/cœur ≈ 78 % de pic solo) et 40M ups même à 8B clés - 24M ups avec historique pour Hyades - Les racines d'état passent maintenant par un lien de 50 Gbps.

6/ C'est un bond de 20× par rapport aux 2,3M/s de QMDB et 30× plus rapide que nos tests internes de QMDB. Notre exigence de 3 M/s consomme maintenant < 7 % de la capacité, ce qui laisse une marge énorme.

7/ Hyades fonctionne entièrement de manière asynchrone, ingérant des entrées de preuve compactes de 40B hors chemin dans un journal en ajout uniquement, tandis que les charges utiles complètes des comptes atterrissent dans un journal séparé. Le chemin chaud reste impeccable.

8/ Pour en savoir plus sur l’architecture d’AlDBaran et les principaux résultats, rendez-vous sur :