Une vibration du téléphone au milieu de la nuit, une alerte d'anomalie sur le registre XRP clignote — ça recommence. Mais cette fois, le scénario est bien plus intéressant que prévu.
Après plusieurs années dans le domaine de la cryptographie, j'ai vu trop de chaînes d'explosions en série causées par de petites bugs dans le code. La scène de "déraillement automatisé" sur le registre XRP d'hier soir est devenue un cas d'école : le système automatisé d'un des principaux fournisseurs de services de garde a, après avoir vidé le solde XRP d'un portefeuille associé, continué à créer frénétiquement de nouveaux comptes en masse. En quelques heures seulement, près de 11 000 requêtes de transactions invalides ont été envoyées au réseau XRP.
Ce n'est pas une intrusion de hacker. En clair, c'est un script automatisé qui a complètement perdu le contrôle.
**Du processus normal à la boucle infinie**
L'affaire est simple. Le script de création de comptes de ce fournisseur de services génère des portefeuilles XRP pour les utilisateurs selon une logique prédéfinie, et ce système fonctionnait plutôt bien. Le problème réside dans une étape : la logique de vérification après que le solde a été vidé.
Le registre XRP possède un mécanisme de conception — chaque nouveau compte doit verrouiller au moins 20 XRP comme réserve, et chaque transaction détruit 0,04% de XRP. Cette mesure vise à empêcher les malfaiteurs de créer en masse des comptes inutiles qui pourraient paralyser le réseau.
Théoriquement, lorsque le solde XRP du fournisseur de services est épuisé, le script devrait s’arrêter. Mais en réalité ? Le système est tombé dans une boucle infinie. Il ne s’est pas arrêté, au contraire, il a continué à envoyer des requêtes de création à haute fréquence.
Cet épisode de déraillement automatisé a transformé la "mécanique de protection" en une source de pression. Il rappelle à tous une vérité simple : aussi intelligent que soit le code, il doit être équipé de dispositifs de coupure et de mécanismes d’intervention humaine. Même un fournisseur de services de garde de premier plan, aussi fiable soit-il, peut voir ses conséquences s’étendre à toute la blockchain si la logique automatisée comporte des failles.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
12 J'aime
Récompense
12
6
Reposter
Partager
Commentaire
0/400
SmartMoneyWallet
· Il y a 16h
1.1万 requêtes invalides ? À quel point la logique de protection de ce gars doit-elle être défaillante... Même les fournisseurs de services de premier plan ont ce genre de problème, alors à quoi peuvent croire les petits investisseurs ?
Pas étonnant que ce soient toujours les grandes institutions qui ont des problèmes, en vérifiant les données sur la chaîne, la vérité éclate, cette excuse de scripts automatisés hors de contrôle est vraiment dépassée.
Pas de dispositif de coupure ? Ce n’est pas jouer avec le feu, faire tomber la chaîne publique n’est qu’une question de temps.
On compte vraiment sur une intervention humaine ? Haha... Réveillez-vous, tout le monde.
Au fait, concernant ces 11 000 transactions spam, personne ne s’est intéressé aux flux de capitaux des baleines avant et après ? Ce n’est pas si simple que ça.
Voir l'originalRépondre0
ChainSpy
· Il y a 16h
C'est pourquoi je ne fais jamais confiance à l'automatisation complète, aussi intelligent que le code soit, il ne peut pas résister à une faille logique.
Voir l'originalRépondre0
gas_fee_therapy
· Il y a 16h
Le code qui devient incontrôlable est plus effrayant que les hackers, c'est vraiment embarrassant
Voir l'originalRépondre0
RugPullProphet
· Il y a 16h
C'est encore la faute de l'automatisation, il aurait dû y avoir un mécanisme de coupure dès le départ.
Voir l'originalRépondre0
SchrodingerAirdrop
· Il y a 16h
Encore ce genre de bug de bas niveau ? Même le fournisseur principal de hosting peut faire faillite, c'est à mourir de rire.
---
Le script automatisé qui dérape est une opération courante, ce qui est vraiment effrayant, c'est qu'il n'y a pas de dispositif de coupure.
---
Donc, peu importe à quel point le code est génial, il faut quelqu'un pour le surveiller, on ne peut pas faire entièrement confiance à la machine.
---
10 000 transactions spam, si c'était un hacker, il aurait été attrapé depuis longtemps, mais les bugs de code sont beaucoup plus difficiles à prévenir.
---
Et ils osent encore se prétendre leader ? Ils n'ont même pas mis en place de mécanismes de protection.
---
Recevoir une alerte en pleine nuit devrait donner un peu d'expérience, mais cette fois c'était vraiment aberrant, le script s'est auto-détruit.
---
Il faut probablement ajouter un mécanisme de stop-loss, sinon une simple erreur de logique peut paralyser toute la chaîne, c'est trop risqué.
Voir l'originalRépondre0
SerumSquirrel
· Il y a 17h
Encore, encore, encore, les codes des principaux fournisseurs de services utilisent aussi cette méthode ? On dirait que personne ne peut échapper au sort de l'automatisation.
Une vibration du téléphone au milieu de la nuit, une alerte d'anomalie sur le registre XRP clignote — ça recommence. Mais cette fois, le scénario est bien plus intéressant que prévu.
Après plusieurs années dans le domaine de la cryptographie, j'ai vu trop de chaînes d'explosions en série causées par de petites bugs dans le code. La scène de "déraillement automatisé" sur le registre XRP d'hier soir est devenue un cas d'école : le système automatisé d'un des principaux fournisseurs de services de garde a, après avoir vidé le solde XRP d'un portefeuille associé, continué à créer frénétiquement de nouveaux comptes en masse. En quelques heures seulement, près de 11 000 requêtes de transactions invalides ont été envoyées au réseau XRP.
Ce n'est pas une intrusion de hacker. En clair, c'est un script automatisé qui a complètement perdu le contrôle.
**Du processus normal à la boucle infinie**
L'affaire est simple. Le script de création de comptes de ce fournisseur de services génère des portefeuilles XRP pour les utilisateurs selon une logique prédéfinie, et ce système fonctionnait plutôt bien. Le problème réside dans une étape : la logique de vérification après que le solde a été vidé.
Le registre XRP possède un mécanisme de conception — chaque nouveau compte doit verrouiller au moins 20 XRP comme réserve, et chaque transaction détruit 0,04% de XRP. Cette mesure vise à empêcher les malfaiteurs de créer en masse des comptes inutiles qui pourraient paralyser le réseau.
Théoriquement, lorsque le solde XRP du fournisseur de services est épuisé, le script devrait s’arrêter. Mais en réalité ? Le système est tombé dans une boucle infinie. Il ne s’est pas arrêté, au contraire, il a continué à envoyer des requêtes de création à haute fréquence.
Cet épisode de déraillement automatisé a transformé la "mécanique de protection" en une source de pression. Il rappelle à tous une vérité simple : aussi intelligent que soit le code, il doit être équipé de dispositifs de coupure et de mécanismes d’intervention humaine. Même un fournisseur de services de garde de premier plan, aussi fiable soit-il, peut voir ses conséquences s’étendre à toute la blockchain si la logique automatisée comporte des failles.