#baby
Im Whitepaper wird ein Beispiel genannt: Bob und Larry haben vorab eine Reihe von Bitcoin-Transaktionen unterschrieben; die Bedingungen sind festgeschrieben, nämlich dass Larry eine Position zwangsliquidieren kann, wenn der BTC-Preis unter 50.000 US-Dollar fällt. Ich habe diese Stelle gelesen und kann mir eine Frage nicht verkneifen: Dieser Preis von 50.000 US-Dollar – wer belegt ihn eigentlich, und auf welche Weise wird er der Bitcoin-Chain nachgewiesen?
Das Kern-Design von TBV ist, dass der Vault nur ZK-Beweise für Zustände eines externen Smart Contracts akzeptiert – keine Werte, die irgendeine Partei einseitig behauptet. Theoretisch löst das das Vertrauensproblem „Wer hat das Sagen?“, denn vor einer Auszahlung muss erst verifiziert werden, ob der entsprechende ZK-Beweis wirklich dem aktuellen Zustand des externen Contracts auf der externen Chain entspricht. Aber hier gibt es eine technische Lücke, die leicht übersehen wird: Ein ZK-Beweis kann garantieren, dass „der externe Contract tatsächlich in einem bestimmten Zustand ist“, aber nicht, dass „die Eingabedaten für diesen Zustand korrekt sind“. Wenn also die Preis- bzw. Kursdaten auf der externen Chain selbst bereits manipulierte Oracle-Ergebnisse sind, würde die ZK-Verifikation von TBV die Auszahlung trotzdem durchwinken, weil sie die logische Korrektheit prüft – nicht die Echtheit der Daten.
Mit anderen Worten: TBV schließt zwar die Vertrauenslücke „dem Brücken-Partner vertrauen“, löst aber weder die Oracle-Risiken der externen Contracts selbst noch ist das überhaupt beabsichtigt. Das sind tatsächlich zwei unterschiedliche Problemebenen.
Ich denke, genau das muss man bei der Bewertung der Sicherheit von TBV klar auseinanderhalten: @BabylonLabs_io löst das Problem von Self-Custody und Verifikation auf der Bitcoin-Seite, aber $BABY – also das DeFi-Protokoll in der Ecosystem-Seite, das angebunden werden soll – muss die Oracle-Sicherheit auf seiner eigenen Seite weiterhin selbst im Blick behalten. Beide Dinge dürfen nicht miteinander vermischt werden.
Im Whitepaper wird ein Beispiel genannt: Bob und Larry haben vorab eine Reihe von Bitcoin-Transaktionen unterschrieben; die Bedingungen sind festgeschrieben, nämlich dass Larry eine Position zwangsliquidieren kann, wenn der BTC-Preis unter 50.000 US-Dollar fällt. Ich habe diese Stelle gelesen und kann mir eine Frage nicht verkneifen: Dieser Preis von 50.000 US-Dollar – wer belegt ihn eigentlich, und auf welche Weise wird er der Bitcoin-Chain nachgewiesen?
Das Kern-Design von TBV ist, dass der Vault nur ZK-Beweise für Zustände eines externen Smart Contracts akzeptiert – keine Werte, die irgendeine Partei einseitig behauptet. Theoretisch löst das das Vertrauensproblem „Wer hat das Sagen?“, denn vor einer Auszahlung muss erst verifiziert werden, ob der entsprechende ZK-Beweis wirklich dem aktuellen Zustand des externen Contracts auf der externen Chain entspricht. Aber hier gibt es eine technische Lücke, die leicht übersehen wird: Ein ZK-Beweis kann garantieren, dass „der externe Contract tatsächlich in einem bestimmten Zustand ist“, aber nicht, dass „die Eingabedaten für diesen Zustand korrekt sind“. Wenn also die Preis- bzw. Kursdaten auf der externen Chain selbst bereits manipulierte Oracle-Ergebnisse sind, würde die ZK-Verifikation von TBV die Auszahlung trotzdem durchwinken, weil sie die logische Korrektheit prüft – nicht die Echtheit der Daten.
Mit anderen Worten: TBV schließt zwar die Vertrauenslücke „dem Brücken-Partner vertrauen“, löst aber weder die Oracle-Risiken der externen Contracts selbst noch ist das überhaupt beabsichtigt. Das sind tatsächlich zwei unterschiedliche Problemebenen.
Ich denke, genau das muss man bei der Bewertung der Sicherheit von TBV klar auseinanderhalten: @BabylonLabs_io löst das Problem von Self-Custody und Verifikation auf der Bitcoin-Seite, aber $BABY – also das DeFi-Protokoll in der Ecosystem-Seite, das angebunden werden soll – muss die Oracle-Sicherheit auf seiner eigenen Seite weiterhin selbst im Blick behalten. Beide Dinge dürfen nicht miteinander vermischt werden.