Ich habe einmal alle zu einem Gruppenchat hinzugefügt, bevor ich geprüft habe, wer noch verfügbar war, als die eigentliche Arbeit begann.
Dieser kleine Fehler veränderte, wie ich das Herausforderer-Design von @BabylonLabs_io wahrnahm.
Ein vertrauensloses Bitcoin-Vault wartet nicht erst, bis es zu einem Streit kommt, um zu entscheiden, wer teilnehmen darf. Anspruchsteller und Herausforderer sind festgelegt, sobald der Vault erstellt wird, weil das Verfahren zur Streitbeilegung mit Garbled-Circuits zwischen vordefinierten Parteien funktioniert.
Das macht den Transaktionsgraphen vorhersagbar.
Aber es verwandelt Sicherheit auch in eine Auswahl des Personals, die getroffen wird, bevor künftige Bedingungen bekannt sind.
Das verborgene Risiko besteht nicht darin, ob BABY Herausforderer hat.
Es besteht darin, ob die richtigen Herausforderer noch aktiv sind, wenn sie schließlich gebraucht werden.
Ein statisches, versioniertes Set von Universal Challenger kann Unsicherheit reduzieren und verhindern, dass zufällige Akteure kritische Pfade betreten. Aber wenn die Mitgliedschaft nicht permissionless ist: Wie schnell kann BABY einen Operator ersetzen, der langsam wird, unterfinanziert ist oder nicht verfügbar? Und was passiert mit älteren Vaults, wenn stärkere Monitoring-Infrastruktur auf eine neuere Registry-Version umzieht?
Eine feste Mitgliedschaft ist in gewissem Maß vertretbar. Vollständig offene Teilnahme kann Spam erzeugen, unklare Verantwortlichkeiten und Koordinationsausfälle.
Dennoch verschiebt die Vor-Auswahl von Verteidigern einen Teil der Sicherheit von Babylon von der Kryptografie hin zur langfristigen Verfügbarkeit. Das Beweissystem mag weiterhin korrekt bleiben, während die Teilnehmenden, die man erwartete, es langsam zu aktivieren, nach und nach verschwinden.
Ich glaube nicht, dass das BABY zerstört.
Ich beobachte, ob Babylon eine feste Streitstruktur beibehalten kann, ohne dass die Teilnehmerliste von gestern zu einem Liveness-Engpass von morgen wird.
@BabylonLabs_io $BABY #baby
Dieser kleine Fehler veränderte, wie ich das Herausforderer-Design von @BabylonLabs_io wahrnahm.
Ein vertrauensloses Bitcoin-Vault wartet nicht erst, bis es zu einem Streit kommt, um zu entscheiden, wer teilnehmen darf. Anspruchsteller und Herausforderer sind festgelegt, sobald der Vault erstellt wird, weil das Verfahren zur Streitbeilegung mit Garbled-Circuits zwischen vordefinierten Parteien funktioniert.
Das macht den Transaktionsgraphen vorhersagbar.
Aber es verwandelt Sicherheit auch in eine Auswahl des Personals, die getroffen wird, bevor künftige Bedingungen bekannt sind.
Das verborgene Risiko besteht nicht darin, ob BABY Herausforderer hat.
Es besteht darin, ob die richtigen Herausforderer noch aktiv sind, wenn sie schließlich gebraucht werden.
Ein statisches, versioniertes Set von Universal Challenger kann Unsicherheit reduzieren und verhindern, dass zufällige Akteure kritische Pfade betreten. Aber wenn die Mitgliedschaft nicht permissionless ist: Wie schnell kann BABY einen Operator ersetzen, der langsam wird, unterfinanziert ist oder nicht verfügbar? Und was passiert mit älteren Vaults, wenn stärkere Monitoring-Infrastruktur auf eine neuere Registry-Version umzieht?
Eine feste Mitgliedschaft ist in gewissem Maß vertretbar. Vollständig offene Teilnahme kann Spam erzeugen, unklare Verantwortlichkeiten und Koordinationsausfälle.
Dennoch verschiebt die Vor-Auswahl von Verteidigern einen Teil der Sicherheit von Babylon von der Kryptografie hin zur langfristigen Verfügbarkeit. Das Beweissystem mag weiterhin korrekt bleiben, während die Teilnehmenden, die man erwartete, es langsam zu aktivieren, nach und nach verschwinden.
Ich glaube nicht, dass das BABY zerstört.
Ich beobachte, ob Babylon eine feste Streitstruktur beibehalten kann, ohne dass die Teilnehmerliste von gestern zu einem Liveness-Engpass von morgen wird.
@BabylonLabs_io $BABY #baby