Selon les informations publiques, ce problème a été découvert et signalé le 9 décembre de l'année dernière. Quel est le cœur du problème ? L'attaquant peut jouer avec l'envoi de blocs : supprimer intentionnellement le champ de hachage du bloc. Les conséquences sont assez graves — d'autres validateurs planteront lors de la synchronisation du réseau, ce qui entraînera une baisse significative de la vitesse de production de blocs dans le réseau entier.
Du point de vue de la sécurité, cela a été marqué comme à haut risque. La portée de l'impact concerne toutes les versions antérieures à la 4.2.0. Jusqu'à présent, personne n'a vraiment exploité cette vulnérabilité, mais cela ne signifie pas que personne ne l'a découverte — c'est principalement parce que ce type d'attaque nécessite des conditions préalables liées à l'identité du validateur.
L'essentiel est que cela concerne la stabilité de la couche de consensus du réseau. Si un validateur peut provoquer la panne d'un nœud du réseau à volonté, cela pose un risque pour le fonctionnement décentralisé de la blockchain. Heureusement, l'équipe officielle a déjà pris conscience de ce problème, et une mise à jour devrait avoir corrigé cela. Pour les utilisateurs, il est principalement conseillé de mettre à jour vers la dernière version et de ne pas rester sur une version ancienne.
Voir l'original
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.
16 J'aime
Récompense
16
10
Reposter
Partager
Commentaire
0/400
BasementAlchemist
· 01-12 01:37
Oh là là, Babylon a encore eu des problèmes, il faut prendre au sérieux le fait que les validateurs puissent faire tomber le réseau.
Voir l'originalRépondre0
DefiSecurityGuard
· 01-11 12:10
ngl l'exploit de vote BLS de Babylon sur ngl est exactement le genre de cauchemar au niveau du consensus qui me fait rester éveillé la nuit. le validateur peut simplement supprimer le champ du hash du bloc et boom—l'effondrement de la synchronisation du réseau. honnêtement, c'est un vecteur classique d'abus de privilège du validateur. ce n'est pas un conseil financier mais si vous utilisez encore une version antérieure à 4.2.0, vous demandez littéralement ce qui vous arrive. faites vos recherches (DYOR) et mettez à jour immédiatement ou ne dites pas que je ne vous ai pas prévenu.
Voir l'originalRépondre0
unrekt.eth
· 01-11 09:45
babylon, c'est comme ça qu'on joue, supprimer le hash du bloc et écraser directement le validateurs, cette opération est un peu brutale
Il suffit de mettre à jour la version, pas besoin de tergiverser
Ça aurait dû être corrigé depuis longtemps, une telle opération au niveau du consensus doit être faite avec prudence
Voir l'originalRépondre0
YieldHunter
· 01-09 20:53
ngl c'est exactement le genre de vulnérabilité de la couche de consensus qui me fait rester éveillé la nuit. techniquement, si vous regardez les données... les attaques par validation contrôlée sont bien plus dangereuses que ce que les degens réalisent. babylon a vraiment évité une balle ici mais, genre, combien d'autres protocoles ont des points faibles similaires ? 🤔
Voir l'originalRépondre0
fork_in_the_road
· 01-09 12:03
babylon a encore fait des siennes, supprimer un champ de hachage peut faire planter le validateur... à quel point c'est absurde, la barrière d'identification du validateur a sauvé la mise, non ?
Voir l'originalRépondre0
DaoDeveloper
· 01-09 12:01
Ngl, la validation ici fait un gros travail—sans elle, cela aurait été catastrophique bien plus tôt. mais c'est quand même fou que l'absence d'un champ hash puisse simplement anéantir la finalité du réseau comme ça lol
Voir l'originalRépondre0
UnruggableChad
· 01-09 11:59
babylon, cette vulnérabilité ne tient plus, un validateur peut faire planter le réseau en supprimant un hash, c'est vraiment abusé
Voir l'originalRépondre0
TokenSleuth
· 01-09 11:54
Encore un coup de la part du validateur, supprimer le champ de hachage est vraiment brutal, ça fait carrément frotter tout le réseau par terre
Voir l'originalRépondre0
ApeWithAPlan
· 01-09 11:48
babylon, cette vulnérabilité est vraiment sérieuse, le validateur peut directement faire planter le réseau ? Ne pas mettre à jour semble être un gros problème.
Voir l'originalRépondre0
BankruptWorker
· 01-09 11:44
babylon fait encore ce genre de manœuvre ? Supprimer un champ de hachage peut faire échouer collectivement les validateurs, c'est vraiment pas sérieux.
最近有个有趣的技术发现值得关注。Babylon这个项目在GitHub上披露了一个比较严重的漏洞——具体是在BLS投票扩展的处理逻辑里。
Selon les informations publiques, ce problème a été découvert et signalé le 9 décembre de l'année dernière. Quel est le cœur du problème ? L'attaquant peut jouer avec l'envoi de blocs : supprimer intentionnellement le champ de hachage du bloc. Les conséquences sont assez graves — d'autres validateurs planteront lors de la synchronisation du réseau, ce qui entraînera une baisse significative de la vitesse de production de blocs dans le réseau entier.
Du point de vue de la sécurité, cela a été marqué comme à haut risque. La portée de l'impact concerne toutes les versions antérieures à la 4.2.0. Jusqu'à présent, personne n'a vraiment exploité cette vulnérabilité, mais cela ne signifie pas que personne ne l'a découverte — c'est principalement parce que ce type d'attaque nécessite des conditions préalables liées à l'identité du validateur.
L'essentiel est que cela concerne la stabilité de la couche de consensus du réseau. Si un validateur peut provoquer la panne d'un nœud du réseau à volonté, cela pose un risque pour le fonctionnement décentralisé de la blockchain. Heureusement, l'équipe officielle a déjà pris conscience de ce problème, et une mise à jour devrait avoir corrigé cela. Pour les utilisateurs, il est principalement conseillé de mettre à jour vers la dernière version et de ne pas rester sur une version ancienne.