En examinant les « validator economics » de Babylon, j’ai remarqué une conception d’alignement des incitations particulièrement intéressante.
Sur les chaînes PoS traditionnelles, les revenus des validateurs proviennent principalement des block rewards et des frais de transaction. Mais dans le cadre de Babylon, les validateurs disposent aussi d’une source de revenus supplémentaire : les cross-chain security fees.
Ces frais proviennent des chaînes PoS qui s’appuient sur Babylon. Elles doivent payer des jetons BABY pour louer la sécurité du Bitcoin. Les frais sont ensuite répartis entre les validateurs en fonction de la proportion de leur stake.
Je pense que ce modèle de revenus « multi-stream » peut améliorer de manière significative la résilience économique des validateurs. Même si l’activité d’une chaîne en aval diminue et entraîne une baisse des frais de transaction, les validateurs peuvent toujours être compensés par les revenus provenant d’autres chaînes.
Cependant, cette conception introduit aussi une nouvelle complexité : comment évaluer équitablement les services de sécurité ? Les besoins de sécurité diffèrent selon chaque chaîne PoS : certaines nécessitent des soumissions de checkpoints à haute fréquence, tandis que d’autres n’ont besoin que d’une garantie de finalité à faible fréquence.
À l’heure actuelle, la solution de Babylon consiste à faire en sorte que chaque chaîne obtienne des « security slots » via un mécanisme d’enchères. Une tarification pilotée par le marché devrait, en théorie, permettre une allocation efficiente.
Mais ce qui m’inquiète, c’est qu’au tout début, si le nombre de chaînes participantes est trop faible, les enchères pourraient manquer de concurrence suffisante, entraînant ainsi une distorsion de la tarification.
Un autre point à surveiller est la conception de la validator bonding curve. Babylon exige que les validateurs « bondent » à la fois BABY et BTC. Le ratio entre les deux détermine leur pouvoir de vote. Ce mécanisme de bonding à deux actifs augmente les exigences en capital des validateurs, mais accroît également le coût d’une attaque.
Du point de vue de la sécurité, cette approche est cohérente : l’attaquant doit acquérir simultanément deux types d’actifs pour lancer une attaque, ce qui augmente fortement la complexité de l’attaque.
$BABY #baby @BabylonLabs_io
Sur les chaînes PoS traditionnelles, les revenus des validateurs proviennent principalement des block rewards et des frais de transaction. Mais dans le cadre de Babylon, les validateurs disposent aussi d’une source de revenus supplémentaire : les cross-chain security fees.
Ces frais proviennent des chaînes PoS qui s’appuient sur Babylon. Elles doivent payer des jetons BABY pour louer la sécurité du Bitcoin. Les frais sont ensuite répartis entre les validateurs en fonction de la proportion de leur stake.
Je pense que ce modèle de revenus « multi-stream » peut améliorer de manière significative la résilience économique des validateurs. Même si l’activité d’une chaîne en aval diminue et entraîne une baisse des frais de transaction, les validateurs peuvent toujours être compensés par les revenus provenant d’autres chaînes.
Cependant, cette conception introduit aussi une nouvelle complexité : comment évaluer équitablement les services de sécurité ? Les besoins de sécurité diffèrent selon chaque chaîne PoS : certaines nécessitent des soumissions de checkpoints à haute fréquence, tandis que d’autres n’ont besoin que d’une garantie de finalité à faible fréquence.
À l’heure actuelle, la solution de Babylon consiste à faire en sorte que chaque chaîne obtienne des « security slots » via un mécanisme d’enchères. Une tarification pilotée par le marché devrait, en théorie, permettre une allocation efficiente.
Mais ce qui m’inquiète, c’est qu’au tout début, si le nombre de chaînes participantes est trop faible, les enchères pourraient manquer de concurrence suffisante, entraînant ainsi une distorsion de la tarification.
Un autre point à surveiller est la conception de la validator bonding curve. Babylon exige que les validateurs « bondent » à la fois BABY et BTC. Le ratio entre les deux détermine leur pouvoir de vote. Ce mécanisme de bonding à deux actifs augmente les exigences en capital des validateurs, mais accroît également le coût d’une attaque.
Du point de vue de la sécurité, cette approche est cohérente : l’attaquant doit acquérir simultanément deux types d’actifs pour lancer une attaque, ce qui augmente fortement la complexité de l’attaque.
$BABY #baby @BabylonLabs_io