Nachdem ich die Staking-Dokumente von @Dusk durchgesehen habe, wurde mir klar, dass der Name Hyperstaking ziemlich in die Irre führen kann. Dabei werden die Erträge aus dem Basis-Staking nicht einfach „aus dem Nichts“ erhöht, sondern es ermöglicht, dass der Smart Contract die Staking-Position direkt hält, Belohnungen entgegennehmen kann und sie anschließend nach den im Vertrag festgelegten Regeln verteilt. Die Veränderung liegt nicht darin, woher die Belohnungen kommen, sondern darin, wer für dich den gesamten Ablauf übernimmt.
Beim normalen Staking musst du mindestens 1000 DUSK selbst bereitstellen und zudem dafür sorgen, dass der Provisioner online synchron bleibt. Stake Abstraction öffnet diese Fähigkeiten für Smart Contracts: Die Mittel sammeln sich zunächst im Pool; durch den Transfer Contract wird stake_from_contract ausgelöst. Beim Entstaken und beim Abholen der Erträge ruft der Stake Contract dann die Empfangslogik des Pools zurück. Auch der Vertrag kommt nicht an der 1000-DUSK-Schwelle und einer Reifezeit von etwa 4320 Blöcken vorbei.
Was diese Sache wirklich eröffnet, sind Möglichkeiten für Kombinationen. Geringe Beträge können sich zusammenschließen, um gemeinsam teilzunehmen; der Pool kann automatisch reinvestieren, Erträge anteilig nach Anteilshöhe ausschütten und sogar „liquid staking“ umsetzen. Früher war Staking eine Aktion einer einzelnen Person, jetzt kann es als eine fortlaufend laufende Finanzstrategie beschrieben werden. Dadurch wird der Staking-Bedarf von $DUSK von reinen Node-Operatoren hin zu Anwendungs-Contracts erweitert.
Das Basisprotokoll hebt die Wartezeit beim Entstaken nicht auf. Das heißt aber nicht, dass Pool-Nutzer jederzeit sofort aussteigen können; der Pool kann sehr wohl selbst Queueing, Gebühren oder Liquiditätsbeschränkungen hinzufügen. Noch wichtiger: Der Nutzer trägt nicht mehr nur das Risiko, dass ein Node offline geht oder dass er wegen etwas penalisiert wird, sondern zusätzlich auch Dinge wie Anteilsberechnung, Callback-Verarbeitung, Belohnungsverteilung und Berechtigungen für Contract-Upgrades. Non-custodial im Unterbau heißt nicht, dass es im oberen Layer keine Kontrollmöglichkeiten gibt.
Hyperstaking verlagert die Einstiegshürde für das Betreiben der Nodes auf die Prüfung des Contracts; für normale Nutzer kann das schwierig(er) sein. Außerdem muss man die vom Pool angezeigte Rendite auseinandernehmen: Was sind Protokoll-Belohnungen, was sind Betreiber-Abzüge, was sind Subventionen—und nicht alles kann man einfach dem Dusk-Konsens zuschreiben.
Als Nächstes akzeptiere ich nur ein paar überprüfbare Kennzahlen: Ob der Pool-Contract Open-Source-Audits hat, ob Assets und Belohnungen on-chain nachvollziehbar gegenbuchbar sind, und ob die Exit-Regeln klar und getrennt von denen des Basisprotokolls definiert sind. Der wirklich wertvolle Teil staker-kontraktbasierter Konstrukte liegt in der Automatisierung der Zusammenarbeit. Wenn es nur darum geht, Node-Hosting durch einen Smart Contract-Blackbox zu ersetzen, dann wird kein Vertrauen beseitigt—es wurde lediglich gegen ein „chain-on“-wirkenderes Gewand getauscht. #dusk
@Dusk $DUSK
Beim normalen Staking musst du mindestens 1000 DUSK selbst bereitstellen und zudem dafür sorgen, dass der Provisioner online synchron bleibt. Stake Abstraction öffnet diese Fähigkeiten für Smart Contracts: Die Mittel sammeln sich zunächst im Pool; durch den Transfer Contract wird stake_from_contract ausgelöst. Beim Entstaken und beim Abholen der Erträge ruft der Stake Contract dann die Empfangslogik des Pools zurück. Auch der Vertrag kommt nicht an der 1000-DUSK-Schwelle und einer Reifezeit von etwa 4320 Blöcken vorbei.
Was diese Sache wirklich eröffnet, sind Möglichkeiten für Kombinationen. Geringe Beträge können sich zusammenschließen, um gemeinsam teilzunehmen; der Pool kann automatisch reinvestieren, Erträge anteilig nach Anteilshöhe ausschütten und sogar „liquid staking“ umsetzen. Früher war Staking eine Aktion einer einzelnen Person, jetzt kann es als eine fortlaufend laufende Finanzstrategie beschrieben werden. Dadurch wird der Staking-Bedarf von $DUSK von reinen Node-Operatoren hin zu Anwendungs-Contracts erweitert.
Das Basisprotokoll hebt die Wartezeit beim Entstaken nicht auf. Das heißt aber nicht, dass Pool-Nutzer jederzeit sofort aussteigen können; der Pool kann sehr wohl selbst Queueing, Gebühren oder Liquiditätsbeschränkungen hinzufügen. Noch wichtiger: Der Nutzer trägt nicht mehr nur das Risiko, dass ein Node offline geht oder dass er wegen etwas penalisiert wird, sondern zusätzlich auch Dinge wie Anteilsberechnung, Callback-Verarbeitung, Belohnungsverteilung und Berechtigungen für Contract-Upgrades. Non-custodial im Unterbau heißt nicht, dass es im oberen Layer keine Kontrollmöglichkeiten gibt.
Hyperstaking verlagert die Einstiegshürde für das Betreiben der Nodes auf die Prüfung des Contracts; für normale Nutzer kann das schwierig(er) sein. Außerdem muss man die vom Pool angezeigte Rendite auseinandernehmen: Was sind Protokoll-Belohnungen, was sind Betreiber-Abzüge, was sind Subventionen—und nicht alles kann man einfach dem Dusk-Konsens zuschreiben.
Als Nächstes akzeptiere ich nur ein paar überprüfbare Kennzahlen: Ob der Pool-Contract Open-Source-Audits hat, ob Assets und Belohnungen on-chain nachvollziehbar gegenbuchbar sind, und ob die Exit-Regeln klar und getrennt von denen des Basisprotokolls definiert sind. Der wirklich wertvolle Teil staker-kontraktbasierter Konstrukte liegt in der Automatisierung der Zusammenarbeit. Wenn es nur darum geht, Node-Hosting durch einen Smart Contract-Blackbox zu ersetzen, dann wird kein Vertrauen beseitigt—es wurde lediglich gegen ein „chain-on“-wirkenderes Gewand getauscht. #dusk
@Dusk $DUSK