Ich habe bei der Betrachtung von Verbundprodukten eine schlechte Angewohnheit: Wenn auf der Seite gleichzeitig zwei Marken auftauchen, vermischt man schnell auch die Verantwortung. Wenn etwas schiefgeht, fühlt es sich intuitiv so an, als würden beide Seiten gemeinsam die Assets verwalten und gemeinsam die Konten betreuen—also könne jeder an die Kernberechtigungen herankommen. Wenn man diese Logik dann befolgt und @BabylonLabs_io s „Trustless Bitcoin Vaults (TBV)“ liest, ist die Wahrscheinlichkeit höher, es falsch zu verstehen.
In den TBV übernimmt Babylon und Aave nicht dieselbe Aufgabe. Babylon stellt Regeln für die Bitcoin-Tresore bereit und sorgt dafür, dass der belegungsstatus von nativen BTCs als anwendbar erkennbar wird. Aave v4 verwaltet hingegen Kreditkonten, gemeinschaftliche Liquidität, Asset-Auslastung und Zinssätze. Native BTCs werden dadurch nicht an Aave zur Verwahrung übergeben; Aave ist auch nicht die Instanz, die für Nutzer die Bitcoin-Private-Keys verwaltet. Genau diese Arbeitsteilung wird in #baby leicht durch den gemeinsam verwendeten Namen überdeckt.
Ich würde diese Struktur lieber so verstehen wie verschiedene Fachabteilungen in einem Krankenhaus: Die Radiologie liefert überprüfbare Untersuchungsergebnisse; die klinische Abteilung entscheidet anhand der Ergebnisse über den Behandlungsplan. Beide Seiten müssen zusammenarbeiten, aber die Radiologie verschreibt nicht stellvertretend für die klinische Abteilung Medikamente—und die klinische Abteilung kann auch nicht später die ursprünglichen Bilddaten nachträglich ändern. Sobald die Zuständigkeiten klar sind, weiß man bei Auftreten von Anomalien erst, welche Ebene zu prüfen ist. Wenn der Tresor-Pfad falsch ist, muss man Bitcoin-Skripte, Pre-Signing und Babylon-relevante Komponenten prüfen. Wenn Kreditkonten, Zinssätze oder Liquidität auffällig sind, sollte man Aave Hub, Spoke, Verträge und Oracles überprüfen. Der Sinn der geschichteten Systemarchitektur ist, die Verantwortung besser nachverfolgbar zu machen—nicht, um irgendeiner Ebene einen Freipass zu geben, indem man ihr einfach irgendeinen Prüfvermerk ausstellt, und jede Ebene muss Belege hinterlassen, die überprüfbar sind.
Wenn ich es auf die Wertbeurteilung in $BABY herunterbreche, geht es mir nicht darum, wie laut der Kooperationsname klingt, sondern ob diese Grenze langfristig klar bestehen bleiben kann. Je komplexer ein System ist, desto weniger darf sich die Verantwortung mit dem einen Satz „gemeinsam entwickelt“ einfach überdecken lassen. Aktuell handelt es sich noch um ein öffentliches Testnetz, und Aave v4 ist zudem das erste und bislang einzige registrierte Application. TBV verbindet zwei Verantwortungsbereiche miteinander—aber der wirklich ausgereifte Standard ist: Wenn etwas schiefgeht, können alle Ebenen eindeutig verortet und erklärt werden, und außerdem muss es eine Person oder Stelle geben, die die entsprechenden Konsequenzen trägt.
In den TBV übernimmt Babylon und Aave nicht dieselbe Aufgabe. Babylon stellt Regeln für die Bitcoin-Tresore bereit und sorgt dafür, dass der belegungsstatus von nativen BTCs als anwendbar erkennbar wird. Aave v4 verwaltet hingegen Kreditkonten, gemeinschaftliche Liquidität, Asset-Auslastung und Zinssätze. Native BTCs werden dadurch nicht an Aave zur Verwahrung übergeben; Aave ist auch nicht die Instanz, die für Nutzer die Bitcoin-Private-Keys verwaltet. Genau diese Arbeitsteilung wird in #baby leicht durch den gemeinsam verwendeten Namen überdeckt.
Ich würde diese Struktur lieber so verstehen wie verschiedene Fachabteilungen in einem Krankenhaus: Die Radiologie liefert überprüfbare Untersuchungsergebnisse; die klinische Abteilung entscheidet anhand der Ergebnisse über den Behandlungsplan. Beide Seiten müssen zusammenarbeiten, aber die Radiologie verschreibt nicht stellvertretend für die klinische Abteilung Medikamente—und die klinische Abteilung kann auch nicht später die ursprünglichen Bilddaten nachträglich ändern. Sobald die Zuständigkeiten klar sind, weiß man bei Auftreten von Anomalien erst, welche Ebene zu prüfen ist. Wenn der Tresor-Pfad falsch ist, muss man Bitcoin-Skripte, Pre-Signing und Babylon-relevante Komponenten prüfen. Wenn Kreditkonten, Zinssätze oder Liquidität auffällig sind, sollte man Aave Hub, Spoke, Verträge und Oracles überprüfen. Der Sinn der geschichteten Systemarchitektur ist, die Verantwortung besser nachverfolgbar zu machen—nicht, um irgendeiner Ebene einen Freipass zu geben, indem man ihr einfach irgendeinen Prüfvermerk ausstellt, und jede Ebene muss Belege hinterlassen, die überprüfbar sind.
Wenn ich es auf die Wertbeurteilung in $BABY herunterbreche, geht es mir nicht darum, wie laut der Kooperationsname klingt, sondern ob diese Grenze langfristig klar bestehen bleiben kann. Je komplexer ein System ist, desto weniger darf sich die Verantwortung mit dem einen Satz „gemeinsam entwickelt“ einfach überdecken lassen. Aktuell handelt es sich noch um ein öffentliches Testnetz, und Aave v4 ist zudem das erste und bislang einzige registrierte Application. TBV verbindet zwei Verantwortungsbereiche miteinander—aber der wirklich ausgereifte Standard ist: Wenn etwas schiefgeht, können alle Ebenen eindeutig verortet und erklärt werden, und außerdem muss es eine Person oder Stelle geben, die die entsprechenden Konsequenzen trägt.
