Quand j’ai vu pour la première fois les localChallengers et universalChallengers dans la boîte à outils Babylon’s Trustless Bitcoin Vaults (TBV), ils ressemblaient à des tableaux. Ajoutez une clé publique, ajoutez un autre watcher. Presque gratuit.
Puis j’ai suivi ce que le code construit pour chaque challenger.
Un challenger est lié à trois transactions ChallengeAssert et à un script NoPayout distinct. Ajouter un challenger ne fait pas qu’agrandir une liste hors chaîne. Cela crée davantage de chemins d’exécution Bitcoin avant même qu’un litige ne commence.
Alors j’ai laissé l’ensemble local inchangé et j’ai varié uniquement les Universal Challengers : 1, 3 et 5. Ensuite, j’ai associé chaque configuration à des taux de frais de 5, 20 et 100 sat/vB.
9 scénarios.
Sans inventer de valeurs de réserve. Les entrées montrent déjà où le coût intervient.
computeMinClaimValue prend le nombre de challengers locaux et universels, plus la taille du conseil, le quorum et le taux de frais. Sa sortie doit réserver une valeur pour le graphe en aval Claim, Assert et Payout. À 100 sat/vB, chaque octet virtuel futur coûte vingt fois plus cher qu’à 5 sat/vB. Ajoutez des challengers, et davantage de chemins de dispute doivent être préparés dans cet environnement de frais.
Avant que quiconque ne mente. Avant que quiconque ne conteste.
La plupart de ces transactions n’atteindront peut-être jamais Bitcoin. Elles doivent quand même être dérivées correctement, stockées et financées pour rester utilisables si une fausse revendication apparaît. Babylon valorise la possibilité de conflit avant même que le conflit existe.
Le dimensionnement PegIn montre la même logique sous un autre angle. Sa forme prédite du witness dépend du nombre de signataires Vault Keeper et Universal Challenger. Augmentez l’ensemble universel, et le choix de sécurité laisse du poids dans le plan de transaction avant que le vault ne soit actif.
C’est la partie que les tableaux de bord cachent.
Cinq challengers peuvent sembler être cinq noms. Dans Babylon TBV, ils deviennent des scripts, des signatures, des transactions futures et du capital réservé pour un litige qui ne se produira peut-être jamais.
Plus de challengers peuvent réduire la probabilité qu’une fraude passe inaperçue. Ils peuvent aussi rendre chaque vault plus lourd avant même qu’une fraude n’ait lieu.
De combien de “machinerie” de litige chaque déposant TBV doit-il financer juste pour la garder prête ? $BANK $BABY #baby @BabylonLabs_io
Puis j’ai suivi ce que le code construit pour chaque challenger.
Un challenger est lié à trois transactions ChallengeAssert et à un script NoPayout distinct. Ajouter un challenger ne fait pas qu’agrandir une liste hors chaîne. Cela crée davantage de chemins d’exécution Bitcoin avant même qu’un litige ne commence.
Alors j’ai laissé l’ensemble local inchangé et j’ai varié uniquement les Universal Challengers : 1, 3 et 5. Ensuite, j’ai associé chaque configuration à des taux de frais de 5, 20 et 100 sat/vB.
9 scénarios.
Sans inventer de valeurs de réserve. Les entrées montrent déjà où le coût intervient.
computeMinClaimValue prend le nombre de challengers locaux et universels, plus la taille du conseil, le quorum et le taux de frais. Sa sortie doit réserver une valeur pour le graphe en aval Claim, Assert et Payout. À 100 sat/vB, chaque octet virtuel futur coûte vingt fois plus cher qu’à 5 sat/vB. Ajoutez des challengers, et davantage de chemins de dispute doivent être préparés dans cet environnement de frais.
Avant que quiconque ne mente. Avant que quiconque ne conteste.
La plupart de ces transactions n’atteindront peut-être jamais Bitcoin. Elles doivent quand même être dérivées correctement, stockées et financées pour rester utilisables si une fausse revendication apparaît. Babylon valorise la possibilité de conflit avant même que le conflit existe.
Le dimensionnement PegIn montre la même logique sous un autre angle. Sa forme prédite du witness dépend du nombre de signataires Vault Keeper et Universal Challenger. Augmentez l’ensemble universel, et le choix de sécurité laisse du poids dans le plan de transaction avant que le vault ne soit actif.
C’est la partie que les tableaux de bord cachent.
Cinq challengers peuvent sembler être cinq noms. Dans Babylon TBV, ils deviennent des scripts, des signatures, des transactions futures et du capital réservé pour un litige qui ne se produira peut-être jamais.
Plus de challengers peuvent réduire la probabilité qu’une fraude passe inaperçue. Ils peuvent aussi rendre chaque vault plus lourd avant même qu’une fraude n’ait lieu.
De combien de “machinerie” de litige chaque déposant TBV doit-il financer juste pour la garder prête ? $BANK $BABY #baby @BabylonLabs_io