Als ich die Babylon-Unterlagen durchgearbeitet habe und über Nacht wach blieb, wollte ich eigentlich nur die Grenzen der Berechtigungen der Liquidatoren prüfen. Doch ich wurde immer müder und gleichzeitig durch eine Sache plötzlich klarer: Einzahlungen und Auszahlungen folgen einer völlig anderen Logik als das Vertrauen.
Am Anfang dachte ich, dass das Vertrauensmodell des gesamten Tresorsystems einheitlich ist. Später habe ich gesehen: Für die Einzahlung müssen viele Leute zustimmen, und die Vertrauenslogik für Auszahlung und Liquidation ist komplett anders.
Bei der Einzahlung: Du musst jemanden „bitten“. Beim Anlegen des Tresors musst du bei Ethereum eine Peg-In-Anfrage einreichen und dabei einen Hashlock-Geheimwert anhängen, den nur du kennst. Danach sendest du im Bitcoin-Netzwerk die Pre-PegIn-Transaktion aus und sperrst BTC in eine mit dem Hashlock verknüpfte Taproot-Adresse. Dann fängt erst der eigentliche Ärger an – du musst mit einem Vault Provider und AVK off-chain gemeinsam die Transaktions-Vorzeichen- bzw. Vorab-Signatur-Grafik aufbauen, und jeder Teilnehmer muss unterschreiben. Erst wenn der Einzahler das Hashlock-Geheimnis offenlegt, gilt der Tresor offiziell als aktiviert.
Auszahlung und Liquidation funktionieren dagegen völlig anders. Für die Auszahlung läuft alles über den vorberechneten Pre-Sign-Pfad: Beim Erstellen des Tresors sind alle zulässigen Ausgabenpfade bereits vollständig vor-signiert. Sobald der Tresor generiert ist, kann niemand neue Ausgaben fälschen. Bei der Auszahlung nutzt der Einzahler direkt die bei der Erstellung verwendeten Schlüssel, um die Transaktion selbst zu broadcasten – ohne dass irgendwelche anderen Personen mitarbeiten müssen.
Bei der Liquidation ist die Auslöserbedingung, dass der Health Factor des Kreditnehmers unter 1.0 fällt. Es gibt zwei Pfade – permissioned und permissionless. Doch egal welcher Weg: Die Regeln sind beim Erstellen des Tresors bereits fest in den Code geschrieben, und der Liquidator muss niemanden um Zustimmung bitten.
Ein Satz im Dokument hat mich innehalten lassen: „Trust is optional and removable“. Dass bei der Einzahlung mehrere Parteien beteiligt sind, liegt daran, dass der Tresor noch nicht existiert – das Vertrauensverhältnis muss noch aufgebaut werden: Vault Provider treibt die Einrichtung an, AVK co-signiert, und Universal Challengers bezeugen. Aber sobald der Tresor einmal aufgebaut ist und die Vorab-Signatur-Transaktionsgrafik eingefroren ist, brauchst du dich nicht mehr auf Dritte zu verlassen.
Ich habe eine ganze Nacht recherchiert: Die Berechtigungen des Liquidators habe ich nicht einmal fertig gelesen – stattdessen bin ich über den Kontrast bei Einzahlung und Auszahlung gestolpert. Aber nachdem ich es durchdacht hatte, fand ich es plötzlich auch nachvollziehbar: Beim Einzahlen muss man andere um Hilfe bitten, weil das Vertrauen noch nicht aufgebaut ist. Beim Auszahlen und bei der Liquidation bittet man nicht, weil das Vertrauen bereits im Code verankert ist. Findest du dieses Design – zuerst Abhängigkeit von Personen im Aufbau, später nur noch Vertrauen in den Code – wirklich genial oder eher überflüssig? Schreib im Kommentarbereich.
#BABY $BABY @BabylonLabs_io
Am Anfang dachte ich, dass das Vertrauensmodell des gesamten Tresorsystems einheitlich ist. Später habe ich gesehen: Für die Einzahlung müssen viele Leute zustimmen, und die Vertrauenslogik für Auszahlung und Liquidation ist komplett anders.
Bei der Einzahlung: Du musst jemanden „bitten“. Beim Anlegen des Tresors musst du bei Ethereum eine Peg-In-Anfrage einreichen und dabei einen Hashlock-Geheimwert anhängen, den nur du kennst. Danach sendest du im Bitcoin-Netzwerk die Pre-PegIn-Transaktion aus und sperrst BTC in eine mit dem Hashlock verknüpfte Taproot-Adresse. Dann fängt erst der eigentliche Ärger an – du musst mit einem Vault Provider und AVK off-chain gemeinsam die Transaktions-Vorzeichen- bzw. Vorab-Signatur-Grafik aufbauen, und jeder Teilnehmer muss unterschreiben. Erst wenn der Einzahler das Hashlock-Geheimnis offenlegt, gilt der Tresor offiziell als aktiviert.
Auszahlung und Liquidation funktionieren dagegen völlig anders. Für die Auszahlung läuft alles über den vorberechneten Pre-Sign-Pfad: Beim Erstellen des Tresors sind alle zulässigen Ausgabenpfade bereits vollständig vor-signiert. Sobald der Tresor generiert ist, kann niemand neue Ausgaben fälschen. Bei der Auszahlung nutzt der Einzahler direkt die bei der Erstellung verwendeten Schlüssel, um die Transaktion selbst zu broadcasten – ohne dass irgendwelche anderen Personen mitarbeiten müssen.
Bei der Liquidation ist die Auslöserbedingung, dass der Health Factor des Kreditnehmers unter 1.0 fällt. Es gibt zwei Pfade – permissioned und permissionless. Doch egal welcher Weg: Die Regeln sind beim Erstellen des Tresors bereits fest in den Code geschrieben, und der Liquidator muss niemanden um Zustimmung bitten.
Ein Satz im Dokument hat mich innehalten lassen: „Trust is optional and removable“. Dass bei der Einzahlung mehrere Parteien beteiligt sind, liegt daran, dass der Tresor noch nicht existiert – das Vertrauensverhältnis muss noch aufgebaut werden: Vault Provider treibt die Einrichtung an, AVK co-signiert, und Universal Challengers bezeugen. Aber sobald der Tresor einmal aufgebaut ist und die Vorab-Signatur-Transaktionsgrafik eingefroren ist, brauchst du dich nicht mehr auf Dritte zu verlassen.
Ich habe eine ganze Nacht recherchiert: Die Berechtigungen des Liquidators habe ich nicht einmal fertig gelesen – stattdessen bin ich über den Kontrast bei Einzahlung und Auszahlung gestolpert. Aber nachdem ich es durchdacht hatte, fand ich es plötzlich auch nachvollziehbar: Beim Einzahlen muss man andere um Hilfe bitten, weil das Vertrauen noch nicht aufgebaut ist. Beim Auszahlen und bei der Liquidation bittet man nicht, weil das Vertrauen bereits im Code verankert ist. Findest du dieses Design – zuerst Abhängigkeit von Personen im Aufbau, später nur noch Vertrauen in den Code – wirklich genial oder eher überflüssig? Schreib im Kommentarbereich.
#BABY $BABY @BabylonLabs_io