Une fois, j’ai ajouté tout le monde à un groupe avant de vérifier qui serait encore disponible une fois le travail réel commencé.
Cette petite erreur a modifié ma façon de lire le design de challenger de @BabylonLabs_io.
Un coffre-fort Bitcoin sans confiance ne se contente pas d’attendre un différend pour décider qui peut participer. Les demandeurs et les challengers sont fixés au moment où le coffre est créé, car le processus de dispute à circuits brouillés fonctionne entre des parties prédéterminées.
Cela rend le graphe des transactions prévisible.
Mais cela transforme aussi la sécurité en une liste de personnes choisies avant même que les conditions futures soient connues.
Le risque caché n’est pas de savoir si BABY a des challengers.
Il s’agit de savoir si les bons challengers sont toujours actifs quand on en aura finalement besoin.
Un ensemble de challengers universels statique et versionné peut réduire l’incertitude et empêcher des acteurs aléatoires d’entrer dans des parcours critiques. Mais si l’adhésion n’est pas permissionless, à quelle vitesse BABY peut-il remplacer un opérateur qui devient lent, sous-financé ou indisponible ? Et que se passe-t-il pour les coffres plus anciens lorsque des infrastructures de surveillance plus solides évoluent vers une version plus récente du registre ?
Une certaine adhésion fixe est raisonnable. Une participation totalement ouverte peut engendrer du spam, une responsabilité peu claire et des échecs de coordination.
Cela dit, la sélection préalable des défenseurs déplace une partie de la sécurité de Babylon de la cryptographie vers la disponibilité à long terme. Le système de preuve peut rester correct pendant que les participants censés l’activer disparaissent progressivement.
Je ne pense pas que cela rompe BABY.
Je surveille si Babylon peut conserver une structure de dispute fixe sans laisser la liste des participants d’hier devenir le goulot d’étranglement de la disponibilité de demain.
@BabylonLabs_io $BABY #baby
Cette petite erreur a modifié ma façon de lire le design de challenger de @BabylonLabs_io.
Un coffre-fort Bitcoin sans confiance ne se contente pas d’attendre un différend pour décider qui peut participer. Les demandeurs et les challengers sont fixés au moment où le coffre est créé, car le processus de dispute à circuits brouillés fonctionne entre des parties prédéterminées.
Cela rend le graphe des transactions prévisible.
Mais cela transforme aussi la sécurité en une liste de personnes choisies avant même que les conditions futures soient connues.
Le risque caché n’est pas de savoir si BABY a des challengers.
Il s’agit de savoir si les bons challengers sont toujours actifs quand on en aura finalement besoin.
Un ensemble de challengers universels statique et versionné peut réduire l’incertitude et empêcher des acteurs aléatoires d’entrer dans des parcours critiques. Mais si l’adhésion n’est pas permissionless, à quelle vitesse BABY peut-il remplacer un opérateur qui devient lent, sous-financé ou indisponible ? Et que se passe-t-il pour les coffres plus anciens lorsque des infrastructures de surveillance plus solides évoluent vers une version plus récente du registre ?
Une certaine adhésion fixe est raisonnable. Une participation totalement ouverte peut engendrer du spam, une responsabilité peu claire et des échecs de coordination.
Cela dit, la sélection préalable des défenseurs déplace une partie de la sécurité de Babylon de la cryptographie vers la disponibilité à long terme. Le système de preuve peut rester correct pendant que les participants censés l’activer disparaissent progressivement.
Je ne pense pas que cela rompe BABY.
Je surveille si Babylon peut conserver une structure de dispute fixe sans laisser la liste des participants d’hier devenir le goulot d’étranglement de la disponibilité de demain.
@BabylonLabs_io $BABY #baby