Die Garderobe bei einer Hochzeit, bei der ich mitgearbeitet habe, nutzte nummerierte Papiertickets — man riss eine Hälfte ab, behielt die andere, ein Mantel pro Nummer. Ganz einfach, solange die Maschine jede Nummer nur einmal ausdruckte.
Irgendwann gegen Ende der Nacht hakte es und fing an, bereits ausgegebene Nummern erneut zu drucken. Zwei Leute kamen mit Ticket #114 in der Hand. Unter dieser Nummer hing aber nur jemals ein einziger Mantel.
Das Wort, das dafür passt, soweit ich es beurteilen kann: das Zusatzticket — ein Anspruch, der mehr als einmal ausgegeben wurde, weil das System, das die Ansprüche ausdruckt, nie prüft, was tatsächlich im Hintergrund hängt. Liquid-Staking-Tokens tragen dasselbe Risiko: Ein Beleg wird gegen eine Einzahlung geprägt — nur so ehrlich wie der Code, der ihn prägt.
Im März ließ das BRO-Vault von Solv Protocol eine BTC-Einzahlung mehr SolvBTC prägen, als es hätte tun dürfen. Ein Reentrancy-Bug ermöglichte, dass eine einzige NFT-Einzahlung einen Callback auslöste, der eine zweite Token-Charge ausgab, bevor das erste Minting abgeschlossen war — das Security-Unternehmen Halborn führte das auf diesen doppelten-Minting-Pfad zurück, etwa im Wert von 2,7 Mio. US-Dollar. Nutzer wurden erstattet, aber eine Zeit lang war das Receipt-Token schneller als das Bitcoin dahinter.
Der Staking-Integrationsansatz von Babylon überspringt genau aus diesem Grund den Receipt-Token-Schritt. Ein gestaktes BTC-Vault trägt drei vorab bei der Erstellung signierte Ausgabebedingungen — unstake, liquidate, slashing — die direkt durch das Bitcoin-Skript selbst erzwungen werden, nicht durch einen Smart Contract, der obenauf einen Anspruch mintet. Es gibt kein zweites Token, das jemals doppelt ausgegeben werden könnte, weil es kein Token gibt.
Was mir dabei im Kopf bleibt: Solv könnte nach dem Exploit seinen Vertrag patchen und Nutzer erstatten. Ein vorab signiertes Vault lässt sich nicht patchen — welche Bedingungen bei der Erstellung signiert wurden, das sind die Bedingungen für die gesamte Laufzeit dieses Vaults. Ein Bug, den man beheben kann, gegen einen Fehler einzutauschen, den man nicht beheben kann, ist eine eigene Art von Risiko.
Ticket #114 ist die Nummer, an die ich mich noch erinnere — mehr als an den Mantel selbst.
Mein eigener Withdraw-Request vom Testnet steckt noch in der Challenge-Periode — ich melde mich zurück, sobald er tatsächlich im Wallet landet, nicht nur im Dashboard.
@BabylonLabs_io $BABY #baby
Irgendwann gegen Ende der Nacht hakte es und fing an, bereits ausgegebene Nummern erneut zu drucken. Zwei Leute kamen mit Ticket #114 in der Hand. Unter dieser Nummer hing aber nur jemals ein einziger Mantel.
Das Wort, das dafür passt, soweit ich es beurteilen kann: das Zusatzticket — ein Anspruch, der mehr als einmal ausgegeben wurde, weil das System, das die Ansprüche ausdruckt, nie prüft, was tatsächlich im Hintergrund hängt. Liquid-Staking-Tokens tragen dasselbe Risiko: Ein Beleg wird gegen eine Einzahlung geprägt — nur so ehrlich wie der Code, der ihn prägt.
Im März ließ das BRO-Vault von Solv Protocol eine BTC-Einzahlung mehr SolvBTC prägen, als es hätte tun dürfen. Ein Reentrancy-Bug ermöglichte, dass eine einzige NFT-Einzahlung einen Callback auslöste, der eine zweite Token-Charge ausgab, bevor das erste Minting abgeschlossen war — das Security-Unternehmen Halborn führte das auf diesen doppelten-Minting-Pfad zurück, etwa im Wert von 2,7 Mio. US-Dollar. Nutzer wurden erstattet, aber eine Zeit lang war das Receipt-Token schneller als das Bitcoin dahinter.
Der Staking-Integrationsansatz von Babylon überspringt genau aus diesem Grund den Receipt-Token-Schritt. Ein gestaktes BTC-Vault trägt drei vorab bei der Erstellung signierte Ausgabebedingungen — unstake, liquidate, slashing — die direkt durch das Bitcoin-Skript selbst erzwungen werden, nicht durch einen Smart Contract, der obenauf einen Anspruch mintet. Es gibt kein zweites Token, das jemals doppelt ausgegeben werden könnte, weil es kein Token gibt.
Was mir dabei im Kopf bleibt: Solv könnte nach dem Exploit seinen Vertrag patchen und Nutzer erstatten. Ein vorab signiertes Vault lässt sich nicht patchen — welche Bedingungen bei der Erstellung signiert wurden, das sind die Bedingungen für die gesamte Laufzeit dieses Vaults. Ein Bug, den man beheben kann, gegen einen Fehler einzutauschen, den man nicht beheben kann, ist eine eigene Art von Risiko.
Ticket #114 ist die Nummer, an die ich mich noch erinnere — mehr als an den Mantel selbst.
Mein eigener Withdraw-Request vom Testnet steckt noch in der Challenge-Periode — ich melde mich zurück, sobald er tatsächlich im Wallet landet, nicht nur im Dashboard.
@BabylonLabs_io $BABY #baby