Après avoir écrit un script pour Celestia : beaucoup de travaux dans Cosmos n'ont pas été bien faits
TechFlow SélectionTechFlow Sélection
Après avoir écrit un script pour Celestia : beaucoup de travaux dans Cosmos n'ont pas été bien faits
À l'époque, Celestia n'avait certainement pas pris les mesures nécessaires pour faire face à un trafic massif, et la configuration de ses nœuds RPC était aussi très sommaire.
Dédié à des analyses Web3 approfondiesRédaction : Wuyue, Geek Web3
Le 17 décembre, j'ai appris qu'il y aurait des inscriptions CIAS sur Celestia, alors j'ai décidé de bricoler rapidement un script pour spamer des inscriptions. Aujourd'hui, j'ai beaucoup de choses à dire sur Celestia, son écosystème Cosmos, ainsi que sur l'événement CIAS lui-même.
En réalité, écrire un script pour spammer des inscriptions n'est pas difficile. Il se compose principalement de trois modules : création du portefeuille, connexion au nœud et envoi massif de transactions. Pour les deux premières étapes, il suffit de consulter la documentation officielle de la blockchain cible pour trouver rapidement comment les implémenter.
Je me suis donc rendu sur le site officiel de Celestia et son dépôt GitHub, mais je n'ai trouvé aucun exemple destiné aux développeurs souhaitant construire des scénarios utilisateur. La documentation disponible concerne surtout l'exécution de nœuds. Ce n'est pas choquant, car Celestia n'est pas une blockchain orientée grand public (ToC). Cependant, dans un coin discret, Celestia mentionne être basé sur Cosmos et indique qu'on peut interagir avec son réseau principal via CosmJS.
J'ai donc directement consulté CosmJS. Mais bon sang, Cosmos ne sait même pas organiser sa documentation. Je suis allé sur GitHub, ce qui est logique puisque les bibliothèques JS ont généralement des exemples d'utilisation là-bas. Mais le tutoriel était caché dans une page secondaire, et quand j'ai suivi les instructions, j'ai obtenu une erreur.
Cette erreur n'était pas due à mon environnement, mais parce que le tutoriel n'avait pas été mis à jour avec la version correspondante. Par exemple, certains noms de classes avaient changé, rendant certaines fonctions inaccessibles. J'ai essayé de changer la version de la bibliothèque npm selon une ancienne version du tutoriel, mais certains exemples ne fonctionnaient toujours pas. Après plusieurs tentatives infructueuses, j'ai abandonné.
J'ai ensuite fait une recherche Google et découvert que la documentation correcte se trouvait sur le site officiel, et non sur GitHub — ce qui est assez inhabituel. Encore une fois, pourquoi ne pas mettre à jour simplement le fichier README sur GitHub pour rediriger vers le site officiel ?
Une fois en possession du bon tutoriel, j'ai rapidement accompli les deux premières étapes : création du portefeuille et connexion au nœud. Je suis ensuite passé à la construction du module d'envoi massif de transactions. En théorie, ce module n'est rien d'autre qu'une boucle « for » gérant la signature des transactions et les requêtes réseau. Mais là encore, j'ai rencontré quelques problèmes :
Dans la bibliothèque CosmJS, tous les méthodes de transaction exposent uniquement les paramètres de la transaction elle-même, mais pas le champ « sequence », qui n'est pas exposé. (Le « sequence » est analogue au nonce d'Ethereum, un compteur destiné à prévenir les attaques par rejeu. Après chaque transaction envoyée, le nonce et le sequence s'incrémente automatiquement de 1.)
Le « sequence » est récupéré par le système lors de l'étape de signature (sign), via une requête réseau (de même pour le chainId), en passant par sendTokens() → signAndBroadcast → sign(). Chaque transaction nécessite une requête réseau et attend la réponse, ce qui ralentit le spam, augmente inutilement la charge réseau, ce qui est très désavantageux pour un envoi massif, et empêche aussi d'accélérer ou d'annuler facilement une transaction.
Reprenons la méthode d'envoi de transaction dans Web3JS d'Ethereum : vous pouvez spécifier manuellement le nonce. Ce n'est pas possible dans CosmJS. Je pense que le modèle d'Ethereum est bien plus rationnel : pouvoir définir soi-même le nonce permet d'accélérer ou d'annuler une transaction bloquée. Si une transaction est coincée, vous pouvez envoyer une nouvelle transaction avec le même nonce pour la remplacer. Bien sûr, cela peut aussi servir à notre attaque par envoi massif.
Étant donné le manque de temps et plusieurs autres fonctions à modifier dans différentes bibliothèques, j'ai décidé de ne pas utiliser un Proxy pour les surcharger, mais de modifier directement la bibliothèque CosmJS.
L'idée derrière le script d'envoi massif est la suivante : une boucle « for » lance continuellement des transactions, génère des signatures et les envoie au nœud RPC. Après chaque transaction, le sequence/nonce est incrémenté de 1. Après 20 transactions, on recommence un nouveau cycle.
Le « sequence » n'est récupéré qu'une seule fois en local, au début de chaque cycle d'envoi massif, plutôt que d'être demandé à chaque transaction comme par défaut dans la bibliothèque CosmJS. Quant au chainId, il est fixé en dur, évitant ainsi des requêtes répétées au nœud. (Note du rédacteur : le nombre de cycles a été réglé relativement bas ici ; visiblement, l'auteur n'était pas encore si agressif. Quelqu'un qui attaquait les inscriptions Conflux avait déjà réglé ce nombre à 1000 par cycle, envoyant environ 200 transactions différentes par minute.)
Au final, j'ai obtenu un script rudimentaire pour Celestia. Le soir du 17 décembre, après que CIAS ait coupé la connexion, j'ai fait un test rapide et envoyé plusieurs centaines de transactions. Dans la nuit du 19 décembre, lorsque CIAS a relancé l'opération, j'ai effectivement réussi à obtenir quelques CIAS (environ 1800). Mais il y a encore plusieurs points à critiquer :
-
Le 17 décembre, les nœuds RPC de Celestia ont souffert d'un grave problème de désynchronisation des données : les hauteurs de blocs variaient énormément entre différents nœuds RPC. Lorsque vous demandiez le « sequence » de votre compte, les réponses étaient presque toutes différentes. Une situation très frustrante. L'explorateur de blocs de Celestia était également indisponible, nous laissant pratiquement aveugles. On peut dire que bien que le réseau Celestia n'ait pas planté et continue de produire des blocs, il était clairement au bord de ses limites.
-
Face à la saturation imminente de Celestia, l'équipe CIAS a annoncé en urgence que toutes les transactions d'inscription validées après le bloc 48460 seraient invalides, une décision qui sent fort le « retrait de câble par une bourse ». De plus, le site web de CIAS lui-même est tombé en panne.
-
Certains pensent que le protocole de consensus natif des chaînes Cosmos est médiocre en matière de consensus de blocs. Je ne commenterai pas cela, mais l'objectif derrière le retrait de câble de CIAS cette nuit-là semble assez éloquent.
-
Le 17 décembre, il était presque impossible de choisir un nœud RPC synchronisé rapidement, car presque tous les RPC étaient saturés et souvent sans réponse. J'ai fini par écrire un code permettant de changer automatiquement de nœud.
-
Le format d'inscription CIAS est différent des autres. Par exemple, dans les JSON brc-20, tous les nombres sont encodés en chaînes de caractères, tandis que dans cia-20, ils sont en type numérique.
-
Le coût d'une inscription CIAS a atteint un pic la nuit dernière, montant jusqu'à 1,5~2 U par unité, voire jusqu'à 80 U pour une seule inscription. Ces frais exorbitants reflètent simplement un TPS limité. Le fondateur de Celestia prétend que le réseau peut traiter 10 000 transactions par seconde, ce qui est manifestement faux.
Dans l'ensemble, l'expérience de la nuit du 17 décembre peut se résumer en une phrase : Celestia n'était clairement pas prêt à gérer un trafic massif, et la configuration de ses nœuds RPC était lamentable (on peine à croire que quelques dizaines de nœuds RPC puissent être mis hors service en seulement une heure).
La nuit du 19, la situation s'est nettement améliorée. Hormis la flambée des frais de gaz, rien d'autre n'a posé de gros problème. On peut dire que Celestia, en tant que réseau de disponibilité des données (DA) spécialisé dans la distribution de données aux nœuds légers, a temporairement résisté au test. Mais on ignore encore combien d'autres pièges l'attendent à l'avenir.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
