Aymen Gnaba

Posted on Oct 11

40 millions de TPS, reconstruits depuis la chaîne

#blockchain #crypto #performance

Ce que le record de Sui à Basecamp a réellement mesuré, reconstruit à partir des règlements inscrits sur le mainnet.

En bref

Je n'ai pas attendu l'audit. J'ai retrouvé le contrat derrière le record de 40 614 180 TPS annoncé par Sui, récupéré chaque règlement qu'il a inscrit sur le mainnet, et reconstruit la courbe de débit seconde par seconde. La chaîne donne un pic de 39,86 millions de TPS à 08:46:10 UTC le 7 octobre, à moins de 2 % du chiffre officiel. Et la courbe suit, à une marche près, les chiffres annoncés sur scène.

Le record tient donc. Mais ce qu'il mesure est plus précis que « des transactions par seconde » :

Un seul opérateur, des vagues planifiées. Les 7 680 tunnels qui ont produit le record ont tous été ouverts et financés par une même adresse, puis activés en dix vagues, chacune un multiple de 256 tunnels. Chacun tournait à environ 5 230 mises à jour hors chaîne par seconde. 7 680 × 5 230 ≈ 40 millions.
Sui a ancré l'activité, il ne l'a pas exécutée. Les 15,2 milliards de mises à jour hors chaîne du run ont été engagées via 11 502 transactions mainnet, pour environ 86 SUI de gas net.
C'est à la fermeture qu'un agent doit regarder. Les tunnels actifs ont été réglés onchain environ 0,4 s après leur dernière mise à jour. 593 tunnels dont la contrepartie n'a jamais envoyé une seule mise à jour n'ont été clôturés de force qu'après une fenêtre fixe de 3 ou 6 heures.

Une image résume tout : un tunnel de paiement qui a enchaîné 3 132 986 transferts, et s'est refermé avec exactement les 100 MTPS de départ de chaque côté.

Ce qui a été annoncé

Le record a clôturé la première journée de Sui Basecamp, sur la Summit Stage, lors d'une session de 16 h 35 menée par Adeniyi Abiodun, cofondateur et CPO de Mysten Labs (livestream du jour 1, à partir d'environ 5:35:00). Il espérait dépasser largement 12 ou 15 millions, et a rappelé que la médiane des pronostics du public était de 9,04 millions. Puis il a commenté le compteur en direct, jusqu'au passage des 40 millions.

Le compte rendu officiel donne les détails (blog Sui) :

40 614 180 TPS, mesurés à l'intérieur des tunnels Sui : des canaux d'état et de paiement hors chaîne, programmables, proches des canaux Lightning.
Un tunnel coûte deux transactions onchain, une à l'ouverture et une à la fermeture, et chaque tunnel fermé est cosigné et vérifiable onchain.
Plus de 10 000 tunnels ouverts sur le mainnet. CertiK examinera preuves, logs et journaux avant de publier un rapport.
Le record précédent, 6 086 766 TPS le 4 juillet, avait aussi été mesuré dans des tunnels (blog Sui).

Sur scène, Abiodun a présenté Sui comme un « plan de confiance » pour les agents IA. Dans le blog, il va plus loin : Sui n'a pas besoin de traiter chaque interaction entre agents, il doit être la couche de confiance de toutes. C'est une affirmation vérifiable. Et comme cette couche de confiance est une blockchain publique, je suis allé la lire.

Comment je l'ai reconstruit

Je n'ai pas trouvé de SDK public pour les tunnels, mais l'explorateur de l'événement est public. Sa configuration de production nomme le contrat auquel il parle : un package « arena tunnel » à l'adresse 0x9498…7eb1 sur le mainnet, publié le 2 octobre, accompagné d'un registre et d'un jeton de test (MTPS). Tout le reste, ce sont des données publiques de la chaîne.

Récupérer chaque événement émis par le package via l'endpoint GraphQL de Sui : 43 327 tunnels créés, 43 037 activés, 40 330 réglés et 868 litiges ouverts entre le 2 et le 9 octobre.
Lire chaque enregistrement de règlement. Chaque tunnel réglé laisse un SettledOutcomeRecord qui contient un transcript_root (un engagement sur chaque étape hors chaîne), un receipt_count, l'état final et l'horodatage de la dernière mise à jour hors chaîne.
Isoler le run en direct. Les créations de tunnels se regroupent en répétitions du 4 au 6 octobre et à 12 h 03 heure de Singapour le jour J. Le run en direct, c'est la salve de 16 h 41 à 16 h 48 (08:41–08:48 UTC). 10 376 tunnels ont été créés dans l'heure qui l'entoure ; 8 657 ont été réglés, et 7 680 ont réellement tourné.
Reconstruire la courbe. Les reçus de chaque tunnel sont répartis uniformément entre son activation et sa dernière mise à jour, puis additionnés seconde par seconde.

L'étape 4 repose sur une hypothèse, alors je l'ai vérifiée. Sur les 7 680 tunnels actifs, le débit est presque constant : une médiane de 5 231 reçus par seconde, un 99e centile de 5 933. Quand tous les tunnels tournent à un rythme quasi identique, la répartition uniforme ne coûte presque rien.

Les 977 autres tunnels réglés se sont fermés avec zéro reçu. 384 d'entre eux affichent en plus un horodatage final qui n'est pas une heure réelle (des valeurs 64 bits apparemment aléatoires) ; je les ai exclus de la courbe. Leurs nonces cumulés ne représentent que 260 358 mises à jour, moins de 0,01 % du total.

Ce que montre la chaîne

La courbe reconstruite culmine à 39 862 531 TPS à 08:46:10 UTC, soit 1,85 % sous les 40 614 180 officiels. Ma courbe lisse chaque tunnel sur toute sa session, donc un petit écart avec un compteur en direct n'a rien d'étonnant. La montée est plus parlante encore : les points orange sont les chiffres annoncés sur scène, placés selon l'horloge du stream, et ils tombent sur les marches, ou juste à côté, d'une courbe construite uniquement à partir des règlements. Un seul paramètre libre : j'ai calé l'horloge du stream sur l'annonce finale des « 40 millions », les autres points tombent où ils tombent.

Le run est resté au-dessus de 20 millions pendant environ 6 min 30, et proche du pic pendant environ 2 min 30. Il est redescendu par paliers à mesure que les tunnels se fermaient ; le dernier tunnel actif s'est arrêté à 08:53 UTC.

Run en direct, 7 oct. (08:30–09:30 UTC)	Valeur
Tunnels créés	10 376
Tunnels réglés	8 657
Tunnels ayant tourné (avec reçus)	7 680, tous à deux parties
Reçus hors chaîne engagés	15,24 milliards
Transactions mainnet portant les événements du package	11 502
Gas net, remboursements de stockage inclus	85,74 SUI
Adresses ayant ouvert et financé les 7 680 tunnels actifs	1
Adresses ayant ouvert les 977 tunnels à zéro reçu	81
Adresses ayant activé des tunnels	2

Répétitions comprises, le package a engagé au total 117,4 milliards de reçus hors chaîne.

En nombre de reçus, le run se répartit ainsi : 79,0 % simple_payments, 10,8 % flash (les messages du chat de l'explorateur, a priori), 4,0 % tic_tac_toe, 3,4 % battleship et 2,8 % de tunnels dont le résultat est une paire de piles de jetons, probablement les tables de cartes.

D'où viennent les 40 millions

TPS effectifs ≈ tunnels actifs × mises à jour par tunnel et par seconde = 7 680 × ~5 230 ≈ 40 millions

Chaque tunnel, ce sont deux parties qui s'échangent des mises à jour d'état signées aussi vite que possible. Rien à l'intérieur d'un tunnel ne passe par le consensus : le chiffre affiché dépend donc du nombre de tunnels qui tournent en même temps.

Les activations montrent comment ce nombre a été construit. Les 7 680 tunnels actifs ont été allumés en dix vagues entre 08:41:52 et 08:46:04 UTC : 256, 256, 256, 512, puis quatre vagues de 1 280, puis 1 024 et 256. Chaque vague correspond à une marche du graphique. Toutes les activations ont été envoyées par l'une de deux adresses.

C'est exactement à ça que ressemble un passage à l'échelle horizontal : le débit croît linéairement avec le nombre de canaux simultanés, et la couche de base n'a qu'à suivre le rythme des ouvertures et des fermetures. Cela veut aussi dire que « 40 millions » mesure une capacité, pas une demande.

Ce que le chiffre n'est pas

Le compte rendu de Sui précise bien que le comptage a eu lieu à l'intérieur des tunnels. Mais trois choses ressortent des données, et elles se perdent facilement quand le chiffre circule seul.

Ce ne sont pas des TPS de couche de base. Pendant le run, le commentaire sur scène a comparé le compteur à Visa, puis décrit les quelque 120 validateurs de Sui comme capables de traiter les transactions plus vite que des systèmes centralisés. Les validateurs ont traité les 11 502 transactions qui ont ouvert, financé, activé et réglé les tunnels. Les 15,2 milliards de mises à jour, elles, ont circulé entre les deux parties de chaque tunnel.
Ce ne sont pas 40 millions de paiements. Un reçu est une mise à jour d'état signée, pas un transfert de valeur. Sur les 6 144 tunnels de paiement du run, 3 080 se sont refermés avec les deux soldes exactement à leur niveau de départ, 100 MTPS chacun. L'un d'eux après 3 132 986 transferts (enregistrement de règlement). La compensation est la raison d'être d'un canal ; cela signifie que ce qui est réglé sur Sui, c'est le solde net, pas le compteur.
Ce n'est pas le public. Abiodun a évoqué environ 10 000 personnes connectées au stream et participant, et le public a bien ouvert des tunnels : 977, depuis 81 adresses. Aucun n'a produit de reçu. Toutes les mises à jour du record viennent des 7 680 paires d'agents ouvertes par une seule adresse, ce qui est précisément le scénario que le test voulait démontrer.

Rien de tout cela ne rend le record faux. Cela le rend précis : Sui a ancré 15,2 milliards de mises à jour hors chaîne, produites à un pic d'environ 40 millions par seconde, pour 86 SUI de gas.

Ce qui compte quand on construit des agents

Je construis des wallets d'agents bornés : des plafonds de dépense onchain qui tiennent même quand le raisonnement de l'agent ne tient plus. Vu d'ici, la donnée la plus utile de ce run n'est pas le pic. C'est la façon dont les tunnels se terminent.

Quand les deux parties sont là, la fermeture est instantanée. Les 7 680 tunnels actifs ont été réglés onchain en médiane 0,43 seconde après leur dernière mise à jour hors chaîne (90e centile 0,64 s, pire cas 1,2 s). Aucun n'a fait l'objet d'un litige.

Quand une partie ne se présente jamais, l'argent attend. 593 tunnels ont été ouverts, financés et activés, mais la contrepartie n'a jamais envoyé une seule mise à jour. Le runtime a ouvert un litige sur chacun, en général dans les 18 secondes. Chacun a ensuite été réglé exactement 3 heures (526 tunnels) ou 6 heures (67) après l'ouverture du litige, ce qui ressemble à une fenêtre de contestation fixe. Rien n'a été perdu ; tout a été bloqué. Pour un agent, la panne réaliste est une contrepartie qui se tait : budgets et délais doivent être dimensionnés pour cette fenêtre, pas pour la médiane de 0,4 seconde.

Le même package embarque aussi deux modules que le run n'a jamais utilisés : agent_allowance (un mandant finance un séquestre et désigne un bénéficiaire et un délégué, avec un débit par seconde, un plafond de dépense, une expiration, une pause et une révocation) et streaming_payment. Aucun n'a émis le moindre événement. Des tunnels pour la vitesse et une allocation bornée pour l'autorité : cela ressemble à la prochaine étape.

Les deux autres annonces de Basecamp complètent la pile :

Couche	Brique Sui	État aujourd'hui
Autorité : que peut dépenser l'agent ?	Les autorisations de Sui Agent Payments : services autorisés, budget total, plafond par paiement, expiration, appliqués onchain au règlement. Compatible MPP et x402 ; le rail agent annonce actuellement MPP	Testnet ; appels payants sur invitation ; annuaire et tableau de bord « bientôt ». Les services d'Alibaba Cloud doivent s'y brancher, sans date, tarif ni liste de services pour l'instant (BeInCrypto)
Débit : à quelle vitesse deux agents transigent-ils ?	Les tunnels : environ 5 230 mises à jour par seconde et par paire, engagées par une racine de transcription	Démontré sur le mainnet ; pas de SDK public à ma connaissance
Preuve : un tiers peut-il vérifier ce qui s'est passé ?	Le Verifiable Agent Arbiter avec Google Cloud : journaux privés dans le stockage du client, preuves sur Walrus, coordination sur Sui, litiges rejoués via A2A	Annoncé le 6 octobre ; premiers déploiements en entreprise d'abord, aucun client nommé

Le plus intéressant, c'est la jointure entre les lignes. Une autorisation plafonne chaque paiement, mais dans un tunnel, un paiement n'est qu'une mise à jour signée parmi des millions. Où les limites d'une autorisation s'appliquent-elles sur un tunnel : à l'ouverture, à chaque mise à jour ou à la fermeture ? C'est la question de conception à laquelle j'aimerais le plus une réponse.

Questions pour le rapport CertiK

La chaîne confirme déjà le chiffre principal. Voici ce qu'elle ne peut pas trancher seule.

Qu'est-ce qu'une transaction, exactement ? Sur 38 243 des 40 330 enregistrements, receipt_count est égal au nonce final : un reçu correspond donc à une transition d'état. Est-ce bien ce qui a été compté, et sur quelle fenêtre d'échantillonnage les 40 614 180 ont-ils été mesurés ?
Peut-on vérifier une transcription ? Chaque règlement engage un transcript_root. Les journaux hors chaîne seront-ils publiés, pour qu'un tiers puisse recalculer quelques racines au lieu de faire confiance aux compteurs ?
Pourquoi aucun tunnel du public n'a-t-il tourné ? Les 977 tunnels ouverts par le public se sont tous fermés avec zéro reçu, et 384 portent un horodatage final qui n'est pas une heure réelle. Choix de conception ou limite de capacité ce jour-là ?
La fenêtre de contestation est-elle configurable ? Les tunnels inactifs ont été clôturés après exactement 3 ou 6 heures. Quelle valeur une intégration d'agent pourra-t-elle choisir ?
Le runtime était-il attesté ? Le package contient un registre d'attestation pour enclaves Nitro, mais chaque règlement du run porte evidence_class 0. Si cela signifie « pas d'attestation », mieux vaut le dire : cela change le degré de confiance à accorder au runtime.

Reproduire l'analyse

Tout ce qui précède vient de données publiques du mainnet et tourne avec la bibliothèque standard de Python (le graphique demande matplotlib), sans wallet ni clé d'API. Les scripts sont sur github.com/Makabeez/sui-40m-tps-rebuild.

Package arena tunnel : 0x9498606724aa4c03dd0e50ce508b3f5555c4915d3f8d0d4525c0f98dd1737eb1
Registre 0x11c05904ca67cea5658d5bc2a0a0171eafb5d1649bd4f3cd81392b2d11ea571d ; jeton de test 0xcb913929…3eedcd::mtps::MTPS (0 décimale)
Endpoint : https://graphql.mainnet.sui.io/graphql, données récupérées le 10 octobre 2026

Si les chiffres de CertiK diffèrent des miens, je publierai l'écart.

DEV Community