Je voulais savoir ce qui se passe dans l’intervalle entre le moment où la garantie réelle d’un prestataire de finalité change et le moment où le protocole en reconnaît le changement. J’ai donc étudié comment le module d’« epoching » de Babylon traite une nouvelle délégation.
Les messages de mise en jeu (staking) et de retrait (unstaking) ne s’exécutent pas immédiatement. Ils sont mis en file pour la durée d’un epoch entier, puis traités en un seul lot à la frontière. Tant que cette frontière n’est pas atteinte, la puissance de vote en matière de finalité de la chaîne reflète l’ancien instantané, et non le courant. Un prestataire de finalité pourrait perdre des délégations en temps réel, pourrait se vider économiquement en cours d’epoch, et tout de même voter avec le poids qu’il avait avant que quiconque ne retire.
Ce n’est pas un bug. C’est le compromis lié au regroupement de milliers de délégations adossées à des BTC dans un seul règlement, au lieu de traiter chaque délégation individuellement. Mais cela signifie que la sécurité crypto-économique qui soutient un bloc donné n’est pas celle qui existe actuellement. C’est celle qui existait au dernier point de contrôle, reportée par confiance, en supposant que rien de matériel n’a changé entre-temps.
J’ai continué à comparer cela à la manière dont fonctionne réellement une ligne de crédit. Votre limite ne se met pas à jour instantanément quand vos revenus changent. Elle s’actualise sur un cycle, et pendant ce temps, la banque étend sa confiance sur un chiffre qui est déjà légèrement inexact. Babylon fait la même chose avec le poids de Bitcoin, mais avec une cryptographie plus solide enrobant l’inexactitude.
Je ne pense pas que cela rompe le modèle. Le dénouement rapide, d’environ deux jours, maintient cette fenêtre courte par rapport aux chaînes PoS typiques. Mais court n’est pas zéro, et la partie à surveiller n’est pas le prix du token. C’est la largeur de cette fenêtre d’epoch qui augmente au fur et à mesure que l’ensemble des validateurs grandit.
$BABY @BabylonLabs_io #baby $ON $BTC
Les messages de mise en jeu (staking) et de retrait (unstaking) ne s’exécutent pas immédiatement. Ils sont mis en file pour la durée d’un epoch entier, puis traités en un seul lot à la frontière. Tant que cette frontière n’est pas atteinte, la puissance de vote en matière de finalité de la chaîne reflète l’ancien instantané, et non le courant. Un prestataire de finalité pourrait perdre des délégations en temps réel, pourrait se vider économiquement en cours d’epoch, et tout de même voter avec le poids qu’il avait avant que quiconque ne retire.
Ce n’est pas un bug. C’est le compromis lié au regroupement de milliers de délégations adossées à des BTC dans un seul règlement, au lieu de traiter chaque délégation individuellement. Mais cela signifie que la sécurité crypto-économique qui soutient un bloc donné n’est pas celle qui existe actuellement. C’est celle qui existait au dernier point de contrôle, reportée par confiance, en supposant que rien de matériel n’a changé entre-temps.
J’ai continué à comparer cela à la manière dont fonctionne réellement une ligne de crédit. Votre limite ne se met pas à jour instantanément quand vos revenus changent. Elle s’actualise sur un cycle, et pendant ce temps, la banque étend sa confiance sur un chiffre qui est déjà légèrement inexact. Babylon fait la même chose avec le poids de Bitcoin, mais avec une cryptographie plus solide enrobant l’inexactitude.
Je ne pense pas que cela rompe le modèle. Le dénouement rapide, d’environ deux jours, maintient cette fenêtre courte par rapport aux chaînes PoS typiques. Mais court n’est pas zéro, et la partie à surveiller n’est pas le prix du token. C’est la largeur de cette fenêtre d’epoch qui augmente au fur et à mesure que l’ensemble des validateurs grandit.
$BABY @BabylonLabs_io #baby $ON $BTC
