Ich bin immer wieder auf einen Detailpunkt im Upgrade-Design von @BabylonLabs_io gestoßen: Ein Live-Tresor bewahrt die Parameter-Version, die existierte, als er erstellt wurde. Anfangs sah das wie ein starker Schutz aus. Governance kann das Protokoll verbessern, ohne die Regeln, die bereits in älteren Tresoren auf Bitcoin angewendet sind, stillschweigend umzuschreiben. Doch die Unveränderlichkeit schafft ein zweites Problem. Während Babylon sich weiterentwickelt, können zwei Nutzer dieselbe Oberfläche öffnen, dieselbe Anwendung verwenden und trotzdem unter unterschiedlichen Sicherheitsannahmen arbeiten. Ein Tresor kann neuere Zeitbegrenzungen (Timelocks), Operator-Konfigurationen oder Wiederherstellungs-Einstellungen widerspiegeln. Ein anderer bleibt für seine gesamte Lebensdauer an eine frühere Version gebunden. Das System wird aktualisiert. Die Sicherheiten (Collateral) werden nicht automatisch mit aktualisiert. Das ist entscheidend für $BABY , denn das Protokollrisiko kann aufhören, eine einzige gemeinsame Bedingung zu sein, und stattdessen zu einer Sammlung historischer Regelbücher werden. Eine Schwäche kann für künftige Einlagen behoben werden, während sie für bereits gesichertes Kapital unter einem früheren Design weiterhin relevant bleibt. Die meisten Menschen vergleichen Änderbarkeit (Upgradeability) mit Unveränderlichkeit (Immutability). Ich denke, der schwierigere Zielkonflikt liegt zwischen Schutz durch Governance und der Fragmentierung der Sicherheit. @BabylonLabs_io gelingt, wenn Nutzer klar erkennen können, welche Version jeden Tresor absichert, was sich danach geändert hat und ob eine Migration möglich ist, ohne die Verwahrung (Custody) zu schwächen. Es scheitert, wenn „das Protokoll wurde aktualisiert“ bei Nutzern das Vertrauen erzeugt, dass auch ihr eigener Tresor aktualisiert wurde. Versionierung schützt alte Zusagen. Aber in großem Maßstab kann sie auch alte Risiken bewahren.
#baby $BABY