Une chose m’a fait arrêter de défiler. Ce n’était pas le bogue lui-même. C’était la ligne indiquant que la fenêtre de course n’existe qu’entre une lecture de base de données et une écriture de base de données. Cela ressemblait à un tout petit détail d’implémentation jusqu’à ce que je commence à réfléchir à ce que cela dit sur le modèle d’exécution de Babylon.
J’ai cessé de chercher un attaquant et j’ai commencé à regarder le flux. Je suis revenu comparer le chemin de validation et j’ai passé un moment à tracer où les changements d’état deviennent réellement définitifs. Puis j’ai pris un café et j’ai relu la séquence encore une fois. Plus j’y regardais, moins cela me semblait être uniquement un problème de sécurité. Cela ressemblait davantage à un choix de conception concernant le niveau de risque temporel que le protocole est prêt à tolérer.
Ce qui a fini par devenir évident, c’est que la protection n’est pas conçue pour rendre la course impossible. Elle est conçue pour rendre l’occasion extrêmement faible. Ce sont deux idées différentes. La première supprime la condition. La seconde réduit la probabilité. Cette différence est facile à manquer car, de l’extérieur, les deux peuvent sembler sécurisées.
C’est la partie que personne ne met dans la présentation. Babylon dépend du fait que les validateurs et les services traitent l’état dans un ordre prévisible tout en acceptant qu’un minuscule intervalle d’exécution subsiste. Le protocole dit, en pratique, que le coût opérationnel lié à l’élimination de chaque course possible est supérieur au risque restant de laisser une fenêtre aussi étroite.
Peut-être que c’est le bon compromis pour la performance. Peut-être que l’exposition restante est tellement faible que rajouter davantage de synchronisation créerait ailleurs des problèmes plus importants.
Ce que je n’arrive toujours pas à décider, c’est où Babylon trace la frontière entre une hypothèse temporelle acceptable et une garantie de protocole qui ne devrait jamais dépendre du timing.
@BabylonLabs_io
#baby $BABY
J’ai cessé de chercher un attaquant et j’ai commencé à regarder le flux. Je suis revenu comparer le chemin de validation et j’ai passé un moment à tracer où les changements d’état deviennent réellement définitifs. Puis j’ai pris un café et j’ai relu la séquence encore une fois. Plus j’y regardais, moins cela me semblait être uniquement un problème de sécurité. Cela ressemblait davantage à un choix de conception concernant le niveau de risque temporel que le protocole est prêt à tolérer.
Ce qui a fini par devenir évident, c’est que la protection n’est pas conçue pour rendre la course impossible. Elle est conçue pour rendre l’occasion extrêmement faible. Ce sont deux idées différentes. La première supprime la condition. La seconde réduit la probabilité. Cette différence est facile à manquer car, de l’extérieur, les deux peuvent sembler sécurisées.
C’est la partie que personne ne met dans la présentation. Babylon dépend du fait que les validateurs et les services traitent l’état dans un ordre prévisible tout en acceptant qu’un minuscule intervalle d’exécution subsiste. Le protocole dit, en pratique, que le coût opérationnel lié à l’élimination de chaque course possible est supérieur au risque restant de laisser une fenêtre aussi étroite.
Peut-être que c’est le bon compromis pour la performance. Peut-être que l’exposition restante est tellement faible que rajouter davantage de synchronisation créerait ailleurs des problèmes plus importants.
Ce que je n’arrive toujours pas à décider, c’est où Babylon trace la frontière entre une hypothèse temporelle acceptable et une garantie de protocole qui ne devrait jamais dépendre du timing.
@BabylonLabs_io
#baby $BABY