ich bin heute im Babylon-Flow an einer winzigen Stelle hängen geblieben, und ehrlich gesagt hat mich das mehr gestört als der Bug selbst… das Rennen existiert nur zwischen dem Lesen des alten Zustands und dem Schreiben des neuen. klingt fast harmlos, wenn ich es so sage – nur ein paar Momente im Backend – aber dann dachte ich ständig: Moment mal, die ganze Sicherheit hängt davon ab, was in genau diesen Momenten passieren kann.
ich habe aufgehört, darüber nachzudenken wie „Kann jemand das angreifen?“ und stattdessen auf die Reihenfolge geschaut. Der Service liest den Zustand, macht die Prüfung, während zur fast gleichen Zeit etwas anderes passiert, und dann wird das Update geschrieben. In den meisten Fällen ist die Lücke so klein, dass nichts schiefgeht, und von außen wirkt es komplett sicher.
aber „sehr unwahrscheinlich“ und „unmöglich“ sind nicht dasselbe.
das blieb mir im Kopf.
ich glaube, Babylon trifft hier einen ziemlich normalen Engineering-Trade-off… bremst das ganze System nicht mit schweren Lockings oder zusätzlicher Koordination aus, nur um eine einzige winzige Timing-Lücke zu beseitigen; macht die Lücke so klein, dass es extrem schwer wird, sie auszunutzen. vielleicht ist das die richtige Entscheidung. vielleicht würde das vollständige Entfernen mehr Verzögerung verursachen und irgendwo anders neue Probleme schaffen.
trotzdem gefällt mir nicht, wenn Wahrscheinlichkeit so erklärt wird, als wäre es eine Garantie. Wenn die Sicherheit davon abhängt, dass Validatoren und Services denselben Zustand in der erwarteten Reihenfolge erreichen, dann ist Timing Teil des Sicherheitsmodells – ob Menschen es aussprechen oder nicht.
und ich frage mich immer wieder, wo genau die Linie sein sollte… wie klein muss eine Race-Window werden, bevor wir sie als akzeptabel bezeichnen, und welche Teile eines Protokolls sollten niemals vom Timing abhängen?
vielleicht entfernt das System die Race gar nicht.
vielleicht macht es nur die Ziellinie fast unerreichbar.
@BabylonLabs_io #baby $BABY
ich habe aufgehört, darüber nachzudenken wie „Kann jemand das angreifen?“ und stattdessen auf die Reihenfolge geschaut. Der Service liest den Zustand, macht die Prüfung, während zur fast gleichen Zeit etwas anderes passiert, und dann wird das Update geschrieben. In den meisten Fällen ist die Lücke so klein, dass nichts schiefgeht, und von außen wirkt es komplett sicher.
aber „sehr unwahrscheinlich“ und „unmöglich“ sind nicht dasselbe.
das blieb mir im Kopf.
ich glaube, Babylon trifft hier einen ziemlich normalen Engineering-Trade-off… bremst das ganze System nicht mit schweren Lockings oder zusätzlicher Koordination aus, nur um eine einzige winzige Timing-Lücke zu beseitigen; macht die Lücke so klein, dass es extrem schwer wird, sie auszunutzen. vielleicht ist das die richtige Entscheidung. vielleicht würde das vollständige Entfernen mehr Verzögerung verursachen und irgendwo anders neue Probleme schaffen.
trotzdem gefällt mir nicht, wenn Wahrscheinlichkeit so erklärt wird, als wäre es eine Garantie. Wenn die Sicherheit davon abhängt, dass Validatoren und Services denselben Zustand in der erwarteten Reihenfolge erreichen, dann ist Timing Teil des Sicherheitsmodells – ob Menschen es aussprechen oder nicht.
und ich frage mich immer wieder, wo genau die Linie sein sollte… wie klein muss eine Race-Window werden, bevor wir sie als akzeptabel bezeichnen, und welche Teile eines Protokolls sollten niemals vom Timing abhängen?
vielleicht entfernt das System die Race gar nicht.
vielleicht macht es nur die Ziellinie fast unerreichbar.
@BabylonLabs_io #baby $BABY