Ich dachte ursprünglich, Babylons größte Sicherheitsfrage sei ganz einfach: Wie sicher lässt sich BTC staken, ohne die Verwahrung aufzugeben?
Nachdem ich stundenlang seine Dokumentation gelesen hatte, merkte ich, dass ich auf die falsche Ebene blickte.
Was meine Aufmerksamkeit wirklich auf sich zog, war, wie Babylon die Schlüssel für Finality Provider handhabt. Ich stellte fest, dass der EOTS-Schlüssel und der Babylon-Genesis-Schlüssel festgelegt sind, sobald der Provider erstellt wird, und nicht einfach später rotiert werden können.
Zunächst sah ich das als Einschränkung. Dann verstand ich den Grund. Wenn die Identität fest bleibt, wird die Beziehung zwischen einem Provider, seiner Signierautorität und delegiertem BTC vorhersehbarer. Aber das macht auch die operative Disziplin viel wichtiger.
Wenn ein Schlüssel kompromittiert, verloren oder schlecht verwaltet wird, ist das Problem nicht damit gelöst, dass man ihn einfach aus dem Stand ersetzt. Backups, Isolation, Monitoring und die Schlüsselsicherheit werden zu einem Teil der praktischen Sicherheitsgrenze des Protokolls.
Das hat meine Sicht auf Babylon verändert: Selbstverwahrung verringert das Verwahrungsrisiko, beseitigt aber nicht das Betriebsrisiko.
Ich finde, dass dieser Kompromiss mehr Aufmerksamkeit verdient.
Würden Sie unveränderliche Validator-Keys eher als Sicherheitsstärke oder als operatives Risiko ansehen?
@BabylonLabs_io #baby $BABY
Nachdem ich stundenlang seine Dokumentation gelesen hatte, merkte ich, dass ich auf die falsche Ebene blickte.
Was meine Aufmerksamkeit wirklich auf sich zog, war, wie Babylon die Schlüssel für Finality Provider handhabt. Ich stellte fest, dass der EOTS-Schlüssel und der Babylon-Genesis-Schlüssel festgelegt sind, sobald der Provider erstellt wird, und nicht einfach später rotiert werden können.
Zunächst sah ich das als Einschränkung. Dann verstand ich den Grund. Wenn die Identität fest bleibt, wird die Beziehung zwischen einem Provider, seiner Signierautorität und delegiertem BTC vorhersehbarer. Aber das macht auch die operative Disziplin viel wichtiger.
Wenn ein Schlüssel kompromittiert, verloren oder schlecht verwaltet wird, ist das Problem nicht damit gelöst, dass man ihn einfach aus dem Stand ersetzt. Backups, Isolation, Monitoring und die Schlüsselsicherheit werden zu einem Teil der praktischen Sicherheitsgrenze des Protokolls.
Das hat meine Sicht auf Babylon verändert: Selbstverwahrung verringert das Verwahrungsrisiko, beseitigt aber nicht das Betriebsrisiko.
Ich finde, dass dieser Kompromiss mehr Aufmerksamkeit verdient.
Würden Sie unveränderliche Validator-Keys eher als Sicherheitsstärke oder als operatives Risiko ansehen?
@BabylonLabs_io #baby $BABY