@BabylonLabs_io Jedes Mal, wenn ich mir ein neues Staking-Design ansehe, ist das Erste, was ich prüfe, wie viele Möglichkeiten sich für die beweglichen, gesperrten Mittel ergeben. Bei Babylon stellte sich heraus, dass die Antwort kleiner ausfiel als erwartet – und deutlich durchdachter.
Der Staking-Output ist ein Taproot-Output, und Babylon deaktiviert den normalen Key-Spend-Pfad vollständig. Das geschieht, indem der interne Key auf einen NUMS-Point gesetzt wird – den „nothing up my sleeve“-Wert, der in BIP-341 definiert ist und aus dem Hashing von Bitcoins eigenem Basispunkt G abgeleitet wird. Für diesen Punkt existiert kein privater Schlüssel. Dieser Pfad ist nicht schwach – er ist absichtlich geschlossen.
Übrig bleiben genau drei Script-Pfade.
Der Timelock-Pfad ermöglicht es dem Staker, allein auszugeben, sobald die festgelegte Anzahl an Bitcoin-Blöcken abgelaufen ist. Der Unbonding-Pfad erlaubt dem Staker ein frühes Aussteigen – zusammen mit einer Schwelle an Covenant-Committee-Signaturen, ohne eingebundenen Finality-Provider.
Der Slashing-Pfad benötigt den Staker, dieselbe Covenant-Schwelle und den Key des Finality-Providers gemeinsam – und ist nur ausführbar, wenn dieser Provider doppelt signiert hat.
Drei Türen, und der Unterschied zwischen ihnen liegt nicht darin, wer zugelassen ist, sondern darin, welcher Signer aufkreuzen muss. Unbonding und Slashing sehen fast identisch aus: dieselbe Staker-Signatur, dieselbe Covenant-Schwelle – nur dass beim einen der Key des Finality-Providers enthalten ist und beim anderen nicht. Diese eine Aufnahme verwandelt einen freiwilligen Exit in einen strafenden.
Das Entfernen des Key-Spend-Pfads beseitigt jede informelle Möglichkeit, die Mittel zu bewegen – nur diese drei formalen Optionen existieren. Aber das bedeutet auch, dass das gesamte Sicherheitsmodell nun davon abhängt, dass diese drei Scripts exakt richtig sind, ohne dass darunter ein einfacherer Fallback bereitliegt.
Macht das Schließen jeder Abkürzung ein Script sicherer – oder nur weniger verzeihend für einen Fehler im Script selbst?
$BABY #baby @BabylonLabs_io
Der Staking-Output ist ein Taproot-Output, und Babylon deaktiviert den normalen Key-Spend-Pfad vollständig. Das geschieht, indem der interne Key auf einen NUMS-Point gesetzt wird – den „nothing up my sleeve“-Wert, der in BIP-341 definiert ist und aus dem Hashing von Bitcoins eigenem Basispunkt G abgeleitet wird. Für diesen Punkt existiert kein privater Schlüssel. Dieser Pfad ist nicht schwach – er ist absichtlich geschlossen.
Übrig bleiben genau drei Script-Pfade.
Der Timelock-Pfad ermöglicht es dem Staker, allein auszugeben, sobald die festgelegte Anzahl an Bitcoin-Blöcken abgelaufen ist. Der Unbonding-Pfad erlaubt dem Staker ein frühes Aussteigen – zusammen mit einer Schwelle an Covenant-Committee-Signaturen, ohne eingebundenen Finality-Provider.
Der Slashing-Pfad benötigt den Staker, dieselbe Covenant-Schwelle und den Key des Finality-Providers gemeinsam – und ist nur ausführbar, wenn dieser Provider doppelt signiert hat.
Drei Türen, und der Unterschied zwischen ihnen liegt nicht darin, wer zugelassen ist, sondern darin, welcher Signer aufkreuzen muss. Unbonding und Slashing sehen fast identisch aus: dieselbe Staker-Signatur, dieselbe Covenant-Schwelle – nur dass beim einen der Key des Finality-Providers enthalten ist und beim anderen nicht. Diese eine Aufnahme verwandelt einen freiwilligen Exit in einen strafenden.
Das Entfernen des Key-Spend-Pfads beseitigt jede informelle Möglichkeit, die Mittel zu bewegen – nur diese drei formalen Optionen existieren. Aber das bedeutet auch, dass das gesamte Sicherheitsmodell nun davon abhängt, dass diese drei Scripts exakt richtig sind, ohne dass darunter ein einfacherer Fallback bereitliegt.
Macht das Schließen jeder Abkürzung ein Script sicherer – oder nur weniger verzeihend für einen Fehler im Script selbst?
$BABY #baby @BabylonLabs_io
More secure
0%
Less forgiving
0%
Both, really
0%
Not sure
0%
0 Stimmen • Abstimmung beendet