Ethereum hat Smart Contracts, daher ist das Slashing eines Validators dort größtenteils ein Programmierproblem: Man schreibt eine Logik, die eine Bedingung prüft und die Gelder entsprechend verschiebt. Bitcoin hat weder Smart Contracts noch eine Möglichkeit, beliebigen Code auszuführen. Deshalb konnte das Babylon-Team dieses Vorgehen nicht übernehmen – selbst wenn es das gewollt hätte. Sie mussten ein Slashing-System in einer Skriptsprache aufbauen, die aus Sicherheitsgründen bewusst schlicht gehalten wurde, seit Bitcoins frühesten Tagen.
Ihre Antwort war EOTS, extractable one-time signatures. Ein Finality-Provider signiert jeden Block mit einem frischen Einmal-Schlüssel; signiert zwei verschiedene Blöcke in derselben Höhe mit genau diesem Schlüssel – ein echtes Double-Signing-Ereignis – dann leakt die Mathematik selbst genug von dem privaten Schlüssel des Providers, um eine vorgefertigte Slashing-Transaktion gültig zu machen. Nichts davon erfordert einen Smart Contract, ein Oracle oder eine Ausschuss-Abstimmung, um zu beurteilen, ob Fehlverhalten passiert ist; die Kryptografie beweist es direkt. Da Bitcoin nachträglich ebenfalls keine Logik ausführen kann, muss jeder Bestandteil davon – die Staking-Transaktion, die Unbonding-Transaktion und die Slashing-Transaktion – im Voraus konstruiert und signiert werden, bevor das Stake live geht. Möglich wird das durch Taproot und Schnorr-Signaturen, die auf Bitcoin erst nach dem Taproot-Upgrade möglich wurden.
Der Preis für diese Einschränkung ist Flexibilität. Ein Slashing-Prozentsatz oder eine Bedingung, die zum Zeitpunkt des Stakings festgelegt wird, kann später nicht mehr durch eine Governance-Abstimmung oder ein Contract-Upgrade angepasst werden, so wie es auf einer Smart-Contract-Kette möglich wäre. Deshalb müssen alle Parameter bereits stimmen, bevor ein einzelner Satoshi sich fest einlockt.
Babylon konnte nicht einfach Ethereums Slashing-Playbook kopieren. Ein Slashing-System, das vollständig auf EOTS basiert und komplett in Bitcoin Script umgesetzt ist, hielt das System wirklich „Bitcoin-nativ“, ohne Smart Contract oder eine Föderation. Gleichzeitig wurden dadurch jedoch sämtliche Slashing-Parameter zum Zeitpunkt des Stakings festgeschrieben, ohne Raum für eine spätere Governance-Anpassung.
@BabylonLabs_io $BABY #baby
$BLESS
Ihre Antwort war EOTS, extractable one-time signatures. Ein Finality-Provider signiert jeden Block mit einem frischen Einmal-Schlüssel; signiert zwei verschiedene Blöcke in derselben Höhe mit genau diesem Schlüssel – ein echtes Double-Signing-Ereignis – dann leakt die Mathematik selbst genug von dem privaten Schlüssel des Providers, um eine vorgefertigte Slashing-Transaktion gültig zu machen. Nichts davon erfordert einen Smart Contract, ein Oracle oder eine Ausschuss-Abstimmung, um zu beurteilen, ob Fehlverhalten passiert ist; die Kryptografie beweist es direkt. Da Bitcoin nachträglich ebenfalls keine Logik ausführen kann, muss jeder Bestandteil davon – die Staking-Transaktion, die Unbonding-Transaktion und die Slashing-Transaktion – im Voraus konstruiert und signiert werden, bevor das Stake live geht. Möglich wird das durch Taproot und Schnorr-Signaturen, die auf Bitcoin erst nach dem Taproot-Upgrade möglich wurden.
Der Preis für diese Einschränkung ist Flexibilität. Ein Slashing-Prozentsatz oder eine Bedingung, die zum Zeitpunkt des Stakings festgelegt wird, kann später nicht mehr durch eine Governance-Abstimmung oder ein Contract-Upgrade angepasst werden, so wie es auf einer Smart-Contract-Kette möglich wäre. Deshalb müssen alle Parameter bereits stimmen, bevor ein einzelner Satoshi sich fest einlockt.
Babylon konnte nicht einfach Ethereums Slashing-Playbook kopieren. Ein Slashing-System, das vollständig auf EOTS basiert und komplett in Bitcoin Script umgesetzt ist, hielt das System wirklich „Bitcoin-nativ“, ohne Smart Contract oder eine Föderation. Gleichzeitig wurden dadurch jedoch sämtliche Slashing-Parameter zum Zeitpunkt des Stakings festgeschrieben, ohne Raum für eine spätere Governance-Anpassung.
@BabylonLabs_io $BABY #baby
$BLESS