Ein Block-Explorer zeigt die Rückgabe (Redemption) – warum kann $BTC denn trotzdem noch nicht freigeben?
Die Ethereum-Transaktion wurde bereits ausgestrahlt, in einem Block verpackt und hat einen Receipt erzeugt. Sogar ein „redemption event“ lässt sich nachverfolgen. Das beweist nur, dass ein bestimmter Execution-Block diese Aufzeichnung enthält. Für den aktuellen öffentlichen Testnet-Testfall TBV reicht das jedoch nicht aus, um BTC freizugeben, denn man muss zusätzlich nachweisen, dass der Block Teil der von Ethereum letztlich akzeptierten Historie ist.
Wenn Nutzer ihre Schulden vollständig beglichen und den Vault withdrawen, oder wenn der Bereinigungs-/Liquidationsprozess den Vault an die nachfolgende Redemption-Rolle übergibt, wird jeweils ein redemption event ausgelöst. Der Off-Chain-SP1-Prover konstruiert die Beweise in fester Reihenfolge: Zuerst bestätigt Beacon-Finality, dass der Beacon-Block bereits vom Konsenslayer finalisiert wurde; anschließend verknüpft Execution-Finality diesen finalisierten Beacon-Block mit dem Execution-Block, der die Redemption-Transaktion enthält; zum Schluss bestätigt Receipt-Inclusion, dass das Ziel-„redemption log“ in der Transaction Receipt dieses Blocks vorhanden ist. Groth16 komprimiert und bündelt nur die ersten drei Ebenen zu einem kompakten proof, verleiht aber keine Block-Endgültigkeit.
Diese geschichtete Struktur verändert meine Einschätzung: Ich betrachte „der Browser hat die Transaktion bereits gesehen“ nicht mehr als hinreichenden Beweis, dass die grenzüberschreitende Redemption bereits als Tatsache steht. Stattdessen prüfe ich, ob beide Dinge gleichzeitig bewiesen werden können – dass das Ereignis tatsächlich enthalten ist und dass der Execution-Block, der es trägt, von der finalisierten Beacon-Chain als endgültig anerkannt wurde. Das eine beantwortet „was passiert ist“, das andere „ob es zum endgültigen Ethereum-Zustand wurde“. Fehlt die zweite Ebene, könnte ein Bitcoin Payout auf einer noch nicht stabilen externen Historie basieren.
Erst nachdem Finality- und Inclusion-Beweise abgeschlossen sind, übergibt der Claimer die komprimierte proof an den Bitcoin-Teil für Claim, Assert und das challenge window. Ethereum-Finality bestätigt, zu welchem Abschnitt der finalen externen Historie das Ereignis gehört; das Bitcoin-Challenge-Window prüft, ob die auf die Bitcoin-Seite eingereichte proof überhaupt gültig ist. Beides sind nicht dieselben „wartenden“ Abschnitte und sie können sich nicht gegenseitig ersetzen. Nur wenn die proof nicht wirksam widerlegt wird, kommt es zur Ausführung des Payouts.
Auch die Grenzen sollte man klar lassen: Eine finalisierte redemption-event-Beweisführung bedeutet, dass dieses Log in den endgültigen Ethereum-Zustand eingegangen ist – nicht, dass der Upstream-Vertrag, das Oracle oder die Liquidationsentscheidung notwendigerweise auch wirtschaftlich korrekt ist. Wenn im Ethereum-Konsens tiefergehende Fehler auftreten, kann die Verifikation zudem stecken bleiben oder fehlschlagen. @BabylonLabs_io setzt die Schwelle bei „Ereignis in der finalen Historie“, nicht bei „Ereignis, das im Browser sichtbar ist“ – genau deshalb wird eine nach der Bitcoin-Freigabe eintretende Veränderung in der externen Kette nicht automatisch die Redemption zurücknehmen. $ETH
$BABY
#baby
Die Ethereum-Transaktion wurde bereits ausgestrahlt, in einem Block verpackt und hat einen Receipt erzeugt. Sogar ein „redemption event“ lässt sich nachverfolgen. Das beweist nur, dass ein bestimmter Execution-Block diese Aufzeichnung enthält. Für den aktuellen öffentlichen Testnet-Testfall TBV reicht das jedoch nicht aus, um BTC freizugeben, denn man muss zusätzlich nachweisen, dass der Block Teil der von Ethereum letztlich akzeptierten Historie ist.
Wenn Nutzer ihre Schulden vollständig beglichen und den Vault withdrawen, oder wenn der Bereinigungs-/Liquidationsprozess den Vault an die nachfolgende Redemption-Rolle übergibt, wird jeweils ein redemption event ausgelöst. Der Off-Chain-SP1-Prover konstruiert die Beweise in fester Reihenfolge: Zuerst bestätigt Beacon-Finality, dass der Beacon-Block bereits vom Konsenslayer finalisiert wurde; anschließend verknüpft Execution-Finality diesen finalisierten Beacon-Block mit dem Execution-Block, der die Redemption-Transaktion enthält; zum Schluss bestätigt Receipt-Inclusion, dass das Ziel-„redemption log“ in der Transaction Receipt dieses Blocks vorhanden ist. Groth16 komprimiert und bündelt nur die ersten drei Ebenen zu einem kompakten proof, verleiht aber keine Block-Endgültigkeit.
Diese geschichtete Struktur verändert meine Einschätzung: Ich betrachte „der Browser hat die Transaktion bereits gesehen“ nicht mehr als hinreichenden Beweis, dass die grenzüberschreitende Redemption bereits als Tatsache steht. Stattdessen prüfe ich, ob beide Dinge gleichzeitig bewiesen werden können – dass das Ereignis tatsächlich enthalten ist und dass der Execution-Block, der es trägt, von der finalisierten Beacon-Chain als endgültig anerkannt wurde. Das eine beantwortet „was passiert ist“, das andere „ob es zum endgültigen Ethereum-Zustand wurde“. Fehlt die zweite Ebene, könnte ein Bitcoin Payout auf einer noch nicht stabilen externen Historie basieren.
Erst nachdem Finality- und Inclusion-Beweise abgeschlossen sind, übergibt der Claimer die komprimierte proof an den Bitcoin-Teil für Claim, Assert und das challenge window. Ethereum-Finality bestätigt, zu welchem Abschnitt der finalen externen Historie das Ereignis gehört; das Bitcoin-Challenge-Window prüft, ob die auf die Bitcoin-Seite eingereichte proof überhaupt gültig ist. Beides sind nicht dieselben „wartenden“ Abschnitte und sie können sich nicht gegenseitig ersetzen. Nur wenn die proof nicht wirksam widerlegt wird, kommt es zur Ausführung des Payouts.
Auch die Grenzen sollte man klar lassen: Eine finalisierte redemption-event-Beweisführung bedeutet, dass dieses Log in den endgültigen Ethereum-Zustand eingegangen ist – nicht, dass der Upstream-Vertrag, das Oracle oder die Liquidationsentscheidung notwendigerweise auch wirtschaftlich korrekt ist. Wenn im Ethereum-Konsens tiefergehende Fehler auftreten, kann die Verifikation zudem stecken bleiben oder fehlschlagen. @BabylonLabs_io setzt die Schwelle bei „Ereignis in der finalen Historie“, nicht bei „Ereignis, das im Browser sichtbar ist“ – genau deshalb wird eine nach der Bitcoin-Freigabe eintretende Veränderung in der externen Kette nicht automatisch die Redemption zurücknehmen. $ETH
$BABY
#baby