Jedes Protokoll erzählt eine Geschichte. Viele sind um eine entscheidende Rolle herum geschrieben. Wenn diese Rolle verschwindet, endet die Geschichte oder sie wartet auf ein Governance-Verfahren, um das Ende neu zu schreiben. Bei Babylons Trustless Bitcoin Vaults (TBV) habe ich etwas anderes bemerkt. Jede entscheidende Rolle kommt bereits mit ihrer eigenen Backup-Story, und jeder dieser Rollen ist eine Zahl zugeordnet.
Die erste gehört dem Vault Provider: Er koordiniert die Erstellung der Tresore und verwaltet die Bitcoin-Einlösung. Es fühlt sich an, als wäre das die Rolle, von der alles abhängt, bis das Protokoll ein anderes Ende offenbart. Die PegIn-Ausgabe trägt ihre eigene CSV-Timelock, timelockPegin, dokumentiert mit 50 Blöcken in einer Standardkonfiguration. Sogar der normale Pfad läuft bereits nach der eigenen Uhr von Bitcoin: Babylon hat Berichten zufolge die Einzahlungszeiten auf nahe drei Stunden gekürzt, überwiegend begrenzt durch die Bestätigungsgeschwindigkeit und nicht durch die Verfügbarkeit des Vault Providers. Sobald der Timelock abläuft, beansprucht der Einzahler Bitcoin mithilfe von Wiederherstellungsartefakten aus der Tresorerstellung – ohne Einbindung des Vault Providers.
Eine weitere Backup-Story betrifft den Universal Challenger, der dafür zuständig ist, Betrug zu stoppen, bevor BTC freigegeben wird. Die Vault-Parameter tragen separate Arrays für lokale und universelle Challenger, und die Assert-Ausgabe liegt hinter ihrem eigenen Timelock, timelockAssert, dokumentiert mit 144 Blöcken, also nahe an einem vollen Tag. Wenn innerhalb dieses Zeitfensters kein Challenger reagiert, kann der Einzahler die gespeicherten WOTS-Schlüssel des Tresors verwenden, um die Behauptung allein anzufechten. Betrugsschutz war nie eine Aufgabe für nur eine Rolle.
Selbst der Security Council folgt dem Muster. Er existiert als Notfall-Sicherheitsnetz und ist durch ein N-von-N-Quorum abgesichert, statt an einen einzelnen Unterzeichner gebunden zu sein. Er wird als Übergangslösung beschrieben, nicht als dauerhaft. Die Bitcoin-seitige Wiederherstellung bleibt verfügbar, selbst wenn der Rat nie aktiv wird.
Das hat meine Sicht auf TBV verändert. Die Backup-Stories existieren, weil Babylon es ablehnt, operatives Risiko auf nur eine Rolle zu häufen – und diese Ablehnung in Blockzähler und Schwellenwerte schreibt, statt in Versprechen. Sie verlagern still und leise Risiko in das Protokoll, bevor ein Ausfall überhaupt eintritt. Backup-Stories sind, wie Babylon es verteilt – Block für Block. $DEXE $BABY $BANK #baby @BabylonLabs_io
Die erste gehört dem Vault Provider: Er koordiniert die Erstellung der Tresore und verwaltet die Bitcoin-Einlösung. Es fühlt sich an, als wäre das die Rolle, von der alles abhängt, bis das Protokoll ein anderes Ende offenbart. Die PegIn-Ausgabe trägt ihre eigene CSV-Timelock, timelockPegin, dokumentiert mit 50 Blöcken in einer Standardkonfiguration. Sogar der normale Pfad läuft bereits nach der eigenen Uhr von Bitcoin: Babylon hat Berichten zufolge die Einzahlungszeiten auf nahe drei Stunden gekürzt, überwiegend begrenzt durch die Bestätigungsgeschwindigkeit und nicht durch die Verfügbarkeit des Vault Providers. Sobald der Timelock abläuft, beansprucht der Einzahler Bitcoin mithilfe von Wiederherstellungsartefakten aus der Tresorerstellung – ohne Einbindung des Vault Providers.
Eine weitere Backup-Story betrifft den Universal Challenger, der dafür zuständig ist, Betrug zu stoppen, bevor BTC freigegeben wird. Die Vault-Parameter tragen separate Arrays für lokale und universelle Challenger, und die Assert-Ausgabe liegt hinter ihrem eigenen Timelock, timelockAssert, dokumentiert mit 144 Blöcken, also nahe an einem vollen Tag. Wenn innerhalb dieses Zeitfensters kein Challenger reagiert, kann der Einzahler die gespeicherten WOTS-Schlüssel des Tresors verwenden, um die Behauptung allein anzufechten. Betrugsschutz war nie eine Aufgabe für nur eine Rolle.
Selbst der Security Council folgt dem Muster. Er existiert als Notfall-Sicherheitsnetz und ist durch ein N-von-N-Quorum abgesichert, statt an einen einzelnen Unterzeichner gebunden zu sein. Er wird als Übergangslösung beschrieben, nicht als dauerhaft. Die Bitcoin-seitige Wiederherstellung bleibt verfügbar, selbst wenn der Rat nie aktiv wird.
Das hat meine Sicht auf TBV verändert. Die Backup-Stories existieren, weil Babylon es ablehnt, operatives Risiko auf nur eine Rolle zu häufen – und diese Ablehnung in Blockzähler und Schwellenwerte schreibt, statt in Versprechen. Sie verlagern still und leise Risiko in das Protokoll, bevor ein Ausfall überhaupt eintritt. Backup-Stories sind, wie Babylon es verteilt – Block für Block. $DEXE $BABY $BANK #baby @BabylonLabs_io