Ich habe gestern das TBV-Dokument von @BabylonLabs_io durchgelesen. In dem Kapitel „Safety & trust assumptions“ gab es einen Satz, der mich sofort innehalten ließ: „the depositor does not have to trust a third party to keep the deposited BTC safe“. Danach hat das offizielle Dokument dann eine ganze Liste von Rollen aufgeführt: Custodian, Bridge operator, Wrapper issuer, Vault Provider. Ich bin da ziemlich pingelig und dachte mir: Das soll ja alle möglichen Mittelsmänner rausstreichen, die man theoretisch „rausnehmen“ könnte.
Wirklich beschäftigt hat mich dann aber erst die Passage: „The BTC held in a vault can only be released along the spending paths committed at vault creation“. Jeder Vault wird erstellt und bindet dabei eine einzelne, unabhängige UTXO fest. Alle zulässigen Ausgabenpfade sind im Voraus per Signatur gesperrt. Ich habe den Verifikationsprozess noch einmal Schritt für Schritt durchgerechnet, bevor es bei mir klick gemacht hat: Bitcoin muss im Grunde nicht verstehen, welche Geschäftslogik hinter externen Protokollen steckt. Es prüft einfach nur, ob diese UTXO die damals signierten Bedingungen erfüllt. Babylon Labs bezeichnet das offiziell als „translation“ – ich finde, es ist eher wie ein Checkpoint zwischen Bitcoin und einer externen Kette, der nur kryptografische Nachweise akzeptiert.
Das Design dieser Babylon-Labs-Technik ist wirklich ausgeklügelt. Aber im Business-Teil komme ich trotzdem nicht ganz dahinter. Der Abschnitt zu den Gebühren im Whitepaper ist ziemlich klar: Für den BTC-staker wird BTC gesperrt und dafür bezahlt man die BTC-Netzwerkgebühren. Für die Sicherheitsleistung, die über die PoS-Kette gekauft wird, bezahlt man ebenfalls BTC oder den jeweiligen nativen Token dieser Kette. Ich habe es mehrmals durchgesehen und nirgendwo einen echten Kern-Use-Case gefunden, für den zwingend $BABY zur Abrechnung genutzt werden müsste. Aktuell bleiben im Wesentlichen nur die Staking-Schwelle für den „Finality Provider“ und Governance-Token-Votings übrig. Wie auch immer: Die technische Erzählung kann eine Weile die Bewertung stützen – am Ende entscheidet aber, ob es auch einen echten Token-Verbrauch gibt, der den Wert überprüfbar macht.
Im Dokument steht außerdem, dass der „Security Council“ „removable“ ist; nach anfänglichen Multisigs wird er später nach und nach zurückgezogen. Das Slashing-/Strafmechanismus-Design von Babylon Labs stapelt mehrere Ebenen mit EOTS, BABE-Schaltkreisen und WOTS-Signaturen. Wenn irgendwo eine Stelle schiefgeht, wird’s schnell kompliziert. Es gibt noch zu wenig belastbare Praxisdaten – deshalb traue ich mich im Moment wirklich nicht, zu viel zu versprechen. Was meint ihr: Lässt sich dieses Setup am Ende stabil zum Laufen bringen? #baby
Wirklich beschäftigt hat mich dann aber erst die Passage: „The BTC held in a vault can only be released along the spending paths committed at vault creation“. Jeder Vault wird erstellt und bindet dabei eine einzelne, unabhängige UTXO fest. Alle zulässigen Ausgabenpfade sind im Voraus per Signatur gesperrt. Ich habe den Verifikationsprozess noch einmal Schritt für Schritt durchgerechnet, bevor es bei mir klick gemacht hat: Bitcoin muss im Grunde nicht verstehen, welche Geschäftslogik hinter externen Protokollen steckt. Es prüft einfach nur, ob diese UTXO die damals signierten Bedingungen erfüllt. Babylon Labs bezeichnet das offiziell als „translation“ – ich finde, es ist eher wie ein Checkpoint zwischen Bitcoin und einer externen Kette, der nur kryptografische Nachweise akzeptiert.
Das Design dieser Babylon-Labs-Technik ist wirklich ausgeklügelt. Aber im Business-Teil komme ich trotzdem nicht ganz dahinter. Der Abschnitt zu den Gebühren im Whitepaper ist ziemlich klar: Für den BTC-staker wird BTC gesperrt und dafür bezahlt man die BTC-Netzwerkgebühren. Für die Sicherheitsleistung, die über die PoS-Kette gekauft wird, bezahlt man ebenfalls BTC oder den jeweiligen nativen Token dieser Kette. Ich habe es mehrmals durchgesehen und nirgendwo einen echten Kern-Use-Case gefunden, für den zwingend $BABY zur Abrechnung genutzt werden müsste. Aktuell bleiben im Wesentlichen nur die Staking-Schwelle für den „Finality Provider“ und Governance-Token-Votings übrig. Wie auch immer: Die technische Erzählung kann eine Weile die Bewertung stützen – am Ende entscheidet aber, ob es auch einen echten Token-Verbrauch gibt, der den Wert überprüfbar macht.
Im Dokument steht außerdem, dass der „Security Council“ „removable“ ist; nach anfänglichen Multisigs wird er später nach und nach zurückgezogen. Das Slashing-/Strafmechanismus-Design von Babylon Labs stapelt mehrere Ebenen mit EOTS, BABE-Schaltkreisen und WOTS-Signaturen. Wenn irgendwo eine Stelle schiefgeht, wird’s schnell kompliziert. Es gibt noch zu wenig belastbare Praxisdaten – deshalb traue ich mich im Moment wirklich nicht, zu viel zu versprechen. Was meint ihr: Lässt sich dieses Setup am Ende stabil zum Laufen bringen? #baby