Ich hatte erwartet, dass sich das Protokolldesign abhebt, aber eine einzige kleine Beobachtung zum Testen zog mich immer wieder zurück. Es war keine komplexe kryptografische Grundfunktion oder ein Validator-Parameter. Es war die stille Erinnerung daran, dass sich Fehler in Logik und Prozess genau dort zeigen, wo getestet wird. Das klang zunächst gewöhnlich, bis ich anfing, Babylon aus der Perspektive der Koordination zu betrachten – nicht aus der Sicht von Code.
Ich habe mich durch den Protokollablauf gearbeitet und gehofft, ein weiteres interessantes Sicherheitsmechanismus zu finden. Stattdessen achtete ich immer stärker auf jede Stelle, an der verschiedene Komponenten sich auf dieselbe Abfolge von Ereignissen einigen müssen. Dann holte ich mir einen Kaffee und ging zurück, um die Dokumente erneut zu vergleichen, denn je mehr ich hinschaute, desto weniger fühlte sich Testen wie eine reine Entwicklungsaufgabe an – und desto mehr sah es nach einem Teil des Sicherheitsmodells des Protokolls aus.
Das Interessante ist nicht, ob eine Funktion einen Unit-Test besteht. Entscheidend ist, ob die Annahmen, die unabhängige Bausteine miteinander verknüpfen, weiterhin gelten, wenn Timing, Zustandsübergänge und das Verhalten der Validatoren unvorhersehbar werden. Mechanisch ergibt das Sinn, strukturell erzählt es jedoch eine andere Geschichte. Ein Protokoll kann für sich einzeln korrekte Komponenten haben, während die Interaktionen zwischen ihnen stillschweigend unerwartetes Verhalten einführen. Das ist der Teil, den niemand in die Präsentationsfolien packt.
Vielleicht ist das Absicht, weil verteilte Systeme eher durch Interaktionen definiert sind als durch isolierte Funktionen. Oder vielleicht ist es einfach der unvermeidliche Trade-off, wenn mehrere Akteure aus unterschiedlichen Perspektiven zu derselben Schlussfolgerung gelangen müssen. Ich bin mir immer noch nicht sicher, ob Testen in Babylon wirklich darum geht, Bugs zu finden – oder darum, Annahmen offenzulegen, die erst existieren, wenn das Gesamtsystem anfängt, sich gemeinsam zu bewegen.
Das hat mich nachdenken lassen, welche Kategorie historisch gesehen mehr Probleme für Babylon verursacht hat: falscher Code oder korrekter Code, der unter falschen Annahmen läuft?
#baby @BabylonLabs_io $BABY
Ich habe mich durch den Protokollablauf gearbeitet und gehofft, ein weiteres interessantes Sicherheitsmechanismus zu finden. Stattdessen achtete ich immer stärker auf jede Stelle, an der verschiedene Komponenten sich auf dieselbe Abfolge von Ereignissen einigen müssen. Dann holte ich mir einen Kaffee und ging zurück, um die Dokumente erneut zu vergleichen, denn je mehr ich hinschaute, desto weniger fühlte sich Testen wie eine reine Entwicklungsaufgabe an – und desto mehr sah es nach einem Teil des Sicherheitsmodells des Protokolls aus.
Das Interessante ist nicht, ob eine Funktion einen Unit-Test besteht. Entscheidend ist, ob die Annahmen, die unabhängige Bausteine miteinander verknüpfen, weiterhin gelten, wenn Timing, Zustandsübergänge und das Verhalten der Validatoren unvorhersehbar werden. Mechanisch ergibt das Sinn, strukturell erzählt es jedoch eine andere Geschichte. Ein Protokoll kann für sich einzeln korrekte Komponenten haben, während die Interaktionen zwischen ihnen stillschweigend unerwartetes Verhalten einführen. Das ist der Teil, den niemand in die Präsentationsfolien packt.
Vielleicht ist das Absicht, weil verteilte Systeme eher durch Interaktionen definiert sind als durch isolierte Funktionen. Oder vielleicht ist es einfach der unvermeidliche Trade-off, wenn mehrere Akteure aus unterschiedlichen Perspektiven zu derselben Schlussfolgerung gelangen müssen. Ich bin mir immer noch nicht sicher, ob Testen in Babylon wirklich darum geht, Bugs zu finden – oder darum, Annahmen offenzulegen, die erst existieren, wenn das Gesamtsystem anfängt, sich gemeinsam zu bewegen.
Das hat mich nachdenken lassen, welche Kategorie historisch gesehen mehr Probleme für Babylon verursacht hat: falscher Code oder korrekter Code, der unter falschen Annahmen läuft?
#baby @BabylonLabs_io $BABY