L’hiver dernier, j’ai été percuté par l’arrière sur une bretelle d’accès et j’ai donné à mon assureur un bref récit cet après-midi-là. Deux semaines plus tard, un expert en sinistres m’a appelé pour me demander la déclaration enregistrée et me l’a fait redire plus lentement, en revenant sur des détails comme l’endroit où se trouvaient mes mains. Mon version a tenu parce qu’elle était vraie.
Un collègue, lui, qui a « gonflé » sa réclamation sur la même route n’a pas eu autant de chance. Son calendrier a suffisamment changé lors de la deuxième fois que l’expert l’a remarqué.
La responsabilité optimiste dans la crypto a le même problème : elle dépend du fait que quelqu’un saisisse l’essence du problème avant que la fenêtre de contestation ne se referme.
Babylon contourne le surveillant : ses fournisseurs de finalité s’incriminent eux-mêmes via la mathématique. Chacun s’engage dans une randomisation publique à travers le gestionnaire EOTS pour chaque hauteur de bloc future sur laquelle il a l’intention de voter.
Voter sur deux blocs à la même hauteur et réutiliser cette randomisation est inévitable. Les deux signatures se combinent pour extraire la clé privée du fournisseur, propriété du schéma de signatures. N’importe qui peut soumettre la transaction de slashing ; la puissance de vote tombe à zéro, et le « tombstoning » est définitif.
Auto-critique : cette permanence est ce qui devient inconfortable. Le protocole est clément envers les périodes d’indisponibilité honnêtes ; un fournisseur hors ligne n’est pas puni parce qu’il se tait, mais pas envers une equivocation accidentelle.
EOTS ne peut pas distinguer une double signature délibérée d’une double signature honnête causée par un basculement (failover) mal géré ou par un bug logiciel. Dans les deux cas, cela produit les mêmes deux signatures contradictoires, et les deux mènent à un tombstoning permanent, sans recours.
Mon expert en sinistres aurait pu poser des questions de suivi et évaluer l’intention ; cette mathématique ne voit que la collision. Les fournisseurs qui « staking » vendent déjà des outils anti-slashing pour combler ce manque, plutôt que de faire confiance au protocole pour qu’il pardonne.
Babylon retire la confiance à un seul mode d’échec : l’equivocation délibérée, et non à toutes les façons dont un fournisseur peut échouer. $BABY devrait être évalué selon le mode d’échec précis que le mécanisme retire effectivement la confiance, et pas seulement sur l’affirmation que le slashing rend le système « sans confiance ».
#baby #BTCStaking #bitcoin @BabylonLabs_io $IDOL $BTW
Un collègue, lui, qui a « gonflé » sa réclamation sur la même route n’a pas eu autant de chance. Son calendrier a suffisamment changé lors de la deuxième fois que l’expert l’a remarqué.
La responsabilité optimiste dans la crypto a le même problème : elle dépend du fait que quelqu’un saisisse l’essence du problème avant que la fenêtre de contestation ne se referme.
Babylon contourne le surveillant : ses fournisseurs de finalité s’incriminent eux-mêmes via la mathématique. Chacun s’engage dans une randomisation publique à travers le gestionnaire EOTS pour chaque hauteur de bloc future sur laquelle il a l’intention de voter.
Voter sur deux blocs à la même hauteur et réutiliser cette randomisation est inévitable. Les deux signatures se combinent pour extraire la clé privée du fournisseur, propriété du schéma de signatures. N’importe qui peut soumettre la transaction de slashing ; la puissance de vote tombe à zéro, et le « tombstoning » est définitif.
Auto-critique : cette permanence est ce qui devient inconfortable. Le protocole est clément envers les périodes d’indisponibilité honnêtes ; un fournisseur hors ligne n’est pas puni parce qu’il se tait, mais pas envers une equivocation accidentelle.
EOTS ne peut pas distinguer une double signature délibérée d’une double signature honnête causée par un basculement (failover) mal géré ou par un bug logiciel. Dans les deux cas, cela produit les mêmes deux signatures contradictoires, et les deux mènent à un tombstoning permanent, sans recours.
Mon expert en sinistres aurait pu poser des questions de suivi et évaluer l’intention ; cette mathématique ne voit que la collision. Les fournisseurs qui « staking » vendent déjà des outils anti-slashing pour combler ce manque, plutôt que de faire confiance au protocole pour qu’il pardonne.
Babylon retire la confiance à un seul mode d’échec : l’equivocation délibérée, et non à toutes les façons dont un fournisseur peut échouer. $BABY devrait être évalué selon le mode d’échec précis que le mécanisme retire effectivement la confiance, et pas seulement sur l’affirmation que le slashing rend le système « sans confiance ».
#baby #BTCStaking #bitcoin @BabylonLabs_io $IDOL $BTW