Hier soir, Lao Zhao et le singe sont venus boire chez moi. En parlant de Babylon Genesis, les deux ont tapé du poing sur la table en même temps, me demandant d’aller consulter les livres blancs. Aujourd’hui à midi, je me suis attardé longtemps sur ce concept de « dual-quorum staking ».
« 100 validateurs CometBFT exécutant le consensus CometBFT, ensemble avec 60 Finality Providers misant du Bitcoin en ajoutant des signatures de finalité Bitcoin. » Utiliser la sécurité économique de Bitcoin comme couche de défense externe pour une chaîne PoS, c’est vraiment une idée brillante. Quiconque a déjà écrit des systèmes distribués doit reconnaître que c’est, pour l’instant, la tentative de sécurité la plus audacieuse.
Mais en décortiquant la structure de pouvoir de la couche de consensus vers le bas, la chair de poule commence à me gagner.
Le droit de vote des Finality Providers est directement lié au volume de BTC délégués. Il n’y a pas de limite de détention pour la mise en BTC : de grosses baleines peuvent regrouper et accumuler une quantité énorme de BTC délégués à un seul Provider. Un acteur qui monopolise le droit de vote peut alors mettre en place la censure des blocs et des retours malveillants.
Ce qui m’inquiète encore plus, ce sont les vulnérabilités lors du changement d’époque (epoch). Babylon fait tourner les validateurs à chaque époque ; une annonce de sécurité GitHub, GHSA-rj53-j6jw-7f7g, révèle qu’en envoyant un message modifiant l’ensemble des validateurs à la frontière des époques, toute la chaîne se met en halt. Les développeurs ont découvert que, lorsque des valeurs sont manquantes dans le hash de bloc, le protocole déréférence un pointeur nul et déclenche un panic. Des validateurs malveillants peuvent intentionnellement omettre le champ de hash dans l’extension des votes BLS ; plusieurs validateurs exploitant simultanément cela entraînent un crash et ralentissent la cadence de production des blocs. La faille a été classée « High severity » et, au moment de la divulgation, l’official n’avait pas encore répondu publiquement.
CometBFT dit : « Je suis d’accord », les Finality Providers disent : « Je l’ai signé », mais, à l’instant du changement d’époque, toute la chaîne s’arrête. Tu paries que cette faille ne sera pas exploitée ?
Ce qui précède ne reflète que mon avis personnel et ne constitue pas un conseil en investissement. Vous avez un avis différent ? N’hésitez pas à en discuter dans la section commentaires.
#baby $BABY @BabylonLabs_io
« 100 validateurs CometBFT exécutant le consensus CometBFT, ensemble avec 60 Finality Providers misant du Bitcoin en ajoutant des signatures de finalité Bitcoin. » Utiliser la sécurité économique de Bitcoin comme couche de défense externe pour une chaîne PoS, c’est vraiment une idée brillante. Quiconque a déjà écrit des systèmes distribués doit reconnaître que c’est, pour l’instant, la tentative de sécurité la plus audacieuse.
Mais en décortiquant la structure de pouvoir de la couche de consensus vers le bas, la chair de poule commence à me gagner.
Le droit de vote des Finality Providers est directement lié au volume de BTC délégués. Il n’y a pas de limite de détention pour la mise en BTC : de grosses baleines peuvent regrouper et accumuler une quantité énorme de BTC délégués à un seul Provider. Un acteur qui monopolise le droit de vote peut alors mettre en place la censure des blocs et des retours malveillants.
Ce qui m’inquiète encore plus, ce sont les vulnérabilités lors du changement d’époque (epoch). Babylon fait tourner les validateurs à chaque époque ; une annonce de sécurité GitHub, GHSA-rj53-j6jw-7f7g, révèle qu’en envoyant un message modifiant l’ensemble des validateurs à la frontière des époques, toute la chaîne se met en halt. Les développeurs ont découvert que, lorsque des valeurs sont manquantes dans le hash de bloc, le protocole déréférence un pointeur nul et déclenche un panic. Des validateurs malveillants peuvent intentionnellement omettre le champ de hash dans l’extension des votes BLS ; plusieurs validateurs exploitant simultanément cela entraînent un crash et ralentissent la cadence de production des blocs. La faille a été classée « High severity » et, au moment de la divulgation, l’official n’avait pas encore répondu publiquement.
CometBFT dit : « Je suis d’accord », les Finality Providers disent : « Je l’ai signé », mais, à l’instant du changement d’époque, toute la chaîne s’arrête. Tu paries que cette faille ne sera pas exploitée ?
Ce qui précède ne reflète que mon avis personnel et ne constitue pas un conseil en investissement. Vous avez un avis différent ? N’hésitez pas à en discuter dans la section commentaires.
#baby $BABY @BabylonLabs_io