Eine Sache hat mich vom Scrollen abgehalten. Nicht der Bug selbst. Es war die Zeile, dass das Race Window nur zwischen einem Datenbank-Read und einem Datenbank-Write existiert. Das sah nach einer winzigen Implementierungs-Detailfrage aus, bis ich anfing, darüber nachzudenken, was das über Babylons Ausführungsmodell aussagt.
Ich hörte auf, nach einem Angreifer zu suchen, und begann stattdessen, nach dem Ablauf zu schauen. Ich ging zurück, um den Validierungspfad zu vergleichen, und verbrachte eine Weile damit nachzuverfolgen, an welcher Stelle Statusänderungen tatsächlich endgültig werden. Dann holte ich mir einen Kaffee und las die Abfolge noch einmal durch. Je mehr ich hinsah, desto weniger fühlte es sich nach einem reinen Sicherheitsproblem an. Es fühlte sich an wie eine Designentscheidung darüber, wie viel Timing-Risiko das Protokoll zu tolerieren bereit ist.
Langsam wurde klar, dass der Schutz nicht darum gebaut ist, das Race unmöglich zu machen. Er ist darauf ausgelegt, die Gelegenheit extrem klein zu halten. Das sind zwei unterschiedliche Ideen. Die erste entfernt die Bedingung. Die zweite reduziert die Wahrscheinlichkeit. Der Unterschied ist leicht zu übersehen, weil beides von außen wie „sicher“ wirken kann.
Das ist der Teil, den niemand in die Präsentationsfolie packt. Babylon ist darauf angewiesen, dass Validatoren und Services den Zustand in einer vorhersehbaren Reihenfolge verarbeiten, während man akzeptiert, dass trotzdem noch ein winziger Ausführungsspalt existiert. Das Protokoll sagt im Grunde, dass die operativen Kosten, jedes mögliche Race zu entfernen, höher sind als das verbleibende Risiko, ein einziges schmales Fenster offen zu lassen.
Vielleicht ist das der richtige Trade-off für die Performance. Vielleicht ist die verbleibende Exponierung so gering, dass zusätzliche Synchronisierung anderswo größere Probleme erzeugen würde.
Was ich immer noch nicht entscheiden kann, ist, wo Babylon die Grenze zieht zwischen einer akzeptablen Timing-Annahme und einer Protokollgarantie, die niemals von Timing abhängen sollte.
@BabylonLabs_io
#baby $BABY
Ich hörte auf, nach einem Angreifer zu suchen, und begann stattdessen, nach dem Ablauf zu schauen. Ich ging zurück, um den Validierungspfad zu vergleichen, und verbrachte eine Weile damit nachzuverfolgen, an welcher Stelle Statusänderungen tatsächlich endgültig werden. Dann holte ich mir einen Kaffee und las die Abfolge noch einmal durch. Je mehr ich hinsah, desto weniger fühlte es sich nach einem reinen Sicherheitsproblem an. Es fühlte sich an wie eine Designentscheidung darüber, wie viel Timing-Risiko das Protokoll zu tolerieren bereit ist.
Langsam wurde klar, dass der Schutz nicht darum gebaut ist, das Race unmöglich zu machen. Er ist darauf ausgelegt, die Gelegenheit extrem klein zu halten. Das sind zwei unterschiedliche Ideen. Die erste entfernt die Bedingung. Die zweite reduziert die Wahrscheinlichkeit. Der Unterschied ist leicht zu übersehen, weil beides von außen wie „sicher“ wirken kann.
Das ist der Teil, den niemand in die Präsentationsfolie packt. Babylon ist darauf angewiesen, dass Validatoren und Services den Zustand in einer vorhersehbaren Reihenfolge verarbeiten, während man akzeptiert, dass trotzdem noch ein winziger Ausführungsspalt existiert. Das Protokoll sagt im Grunde, dass die operativen Kosten, jedes mögliche Race zu entfernen, höher sind als das verbleibende Risiko, ein einziges schmales Fenster offen zu lassen.
Vielleicht ist das der richtige Trade-off für die Performance. Vielleicht ist die verbleibende Exponierung so gering, dass zusätzliche Synchronisierung anderswo größere Probleme erzeugen würde.
Was ich immer noch nicht entscheiden kann, ist, wo Babylon die Grenze zieht zwischen einer akzeptablen Timing-Annahme und einer Protokollgarantie, die niemals von Timing abhängen sollte.
@BabylonLabs_io
#baby $BABY