Warum Babylon-Staking kein Smart Contract ist
Ein Wort hat mich beim Durchgehen des Babylon-Staking-Setups immer wieder aus dem Konzept gebracht.
„Smart contract.“
Sagt man diesen Satz, stellen sich die meisten einen Motor vor, der Entscheidungen live trifft — wer bezahlt wird, wer bestraft wird — so wie „programmierbare“ Logik auf Ethereum abläuft.
Also habe ich nachverfolgt, wie ein Babylon-Stake tatsächlich zustande kommt.
Kein Vertrag sitzt irgendwo deployed. Nichts führt sich aus, während es läuft. Die gesamte Vereinbarung wird von Anfang an in ein Bitcoin-Taproot-Script eingemeißelt — drei Ausgabebedingungen, jede als eigenes Leaf in der Baumstruktur des Scripts, festgelegt, bevor der Stake überhaupt live geht.
Dieser eine Detailpunkt hat, wie ich das ganze Setup lese, komplett verändert.
Ein Zweig benötigt die eigene Signatur der staker. Ein anderer öffnet sich erst, wenn ein Timelock abgelaufen ist. Der dritte gehört einem Covenant-Komitee, gestützt von Einmalsignaturen, die speziell dafür gebaut sind, um Doppelsignierungen abzufangen. Auszahlung, abwarten oder geschlachtet werden — keine dieser Optionen wird in Echtzeit ausgewählt. Jede Konsequenz war bereits festgeschrieben und unterschrieben, bevor der Stake begonnen hat.
Hab die Dokumente-Registerkarte geschlossen, mir Wasser geholt und einfach einen Moment damit gesessen. Ich habe immer noch auf einen Schritt gehofft, in dem das System tatsächlich etwas auswählt, während es passiert — so wie ein Vertrag, wenn er aufgerufen wird. Habe nichts gefunden.
Also ist „smart contract“ hier nicht der richtige Rahmen. Nichts bewertet Bedingungen live, kein Code läuft mitten in der Transaktion. Es geht nur um fest verdrahtete Bitcoin-Script-Ergebnisse, lange bevor irgendwer abhebt.
Strengere Garantie als „programmierbar“ es impliziert — vielleicht sogar robuster, weil während des aktiven Stakings weniger passiert.
Trotzdem ist „fest“ nicht einfach. Jeder Zweig muss bei der Erstellung korrekt sein, denn hier wird nichts nachträglich „gepatched“, wie es bei einem live Vertrag manchmal möglich ist.
Ich bin immer wieder zu diesem Trade-off zurückgekehrt.
Macht das Weglassen eines Smart Contracts das Ganze leichter vertrauenswürdig, oder verlagert es das Risiko nur früher?
@BabylonLabs_io #baby $BABY $DEXE $ESPORTS
Ein Wort hat mich beim Durchgehen des Babylon-Staking-Setups immer wieder aus dem Konzept gebracht.
„Smart contract.“
Sagt man diesen Satz, stellen sich die meisten einen Motor vor, der Entscheidungen live trifft — wer bezahlt wird, wer bestraft wird — so wie „programmierbare“ Logik auf Ethereum abläuft.
Also habe ich nachverfolgt, wie ein Babylon-Stake tatsächlich zustande kommt.
Kein Vertrag sitzt irgendwo deployed. Nichts führt sich aus, während es läuft. Die gesamte Vereinbarung wird von Anfang an in ein Bitcoin-Taproot-Script eingemeißelt — drei Ausgabebedingungen, jede als eigenes Leaf in der Baumstruktur des Scripts, festgelegt, bevor der Stake überhaupt live geht.
Dieser eine Detailpunkt hat, wie ich das ganze Setup lese, komplett verändert.
Ein Zweig benötigt die eigene Signatur der staker. Ein anderer öffnet sich erst, wenn ein Timelock abgelaufen ist. Der dritte gehört einem Covenant-Komitee, gestützt von Einmalsignaturen, die speziell dafür gebaut sind, um Doppelsignierungen abzufangen. Auszahlung, abwarten oder geschlachtet werden — keine dieser Optionen wird in Echtzeit ausgewählt. Jede Konsequenz war bereits festgeschrieben und unterschrieben, bevor der Stake begonnen hat.
Hab die Dokumente-Registerkarte geschlossen, mir Wasser geholt und einfach einen Moment damit gesessen. Ich habe immer noch auf einen Schritt gehofft, in dem das System tatsächlich etwas auswählt, während es passiert — so wie ein Vertrag, wenn er aufgerufen wird. Habe nichts gefunden.
Also ist „smart contract“ hier nicht der richtige Rahmen. Nichts bewertet Bedingungen live, kein Code läuft mitten in der Transaktion. Es geht nur um fest verdrahtete Bitcoin-Script-Ergebnisse, lange bevor irgendwer abhebt.
Strengere Garantie als „programmierbar“ es impliziert — vielleicht sogar robuster, weil während des aktiven Stakings weniger passiert.
Trotzdem ist „fest“ nicht einfach. Jeder Zweig muss bei der Erstellung korrekt sein, denn hier wird nichts nachträglich „gepatched“, wie es bei einem live Vertrag manchmal möglich ist.
Ich bin immer wieder zu diesem Trade-off zurückgekehrt.
Macht das Weglassen eines Smart Contracts das Ganze leichter vertrauenswürdig, oder verlagert es das Risiko nur früher?
@BabylonLabs_io #baby $BABY $DEXE $ESPORTS
Easier to trust
50%
Risk moved earlier
50%
Depends on failure
0%
Not sure yet
0%
8 Stimmen • Abstimmung beendet