Es gibt eine Version von Staking, bei der du nicht derjenige bist, der stakt.
Oft habe ich angenommen, dass Staking etwas ist, das nur eine Wallet machen kann. verbinden, delegieren, warten. das war das Modell überall, wo ich es zuvor genutzt habe.
Aber als ich den Abschnitt zur Stake-Abstraktion @Dusk stake gelesen habe, dachte ich, das wäre einfach nur Delegation mit einem neuen Namen. Ich brauchte ein paar Durchläufe durch die Dokus, bis ich merkte, dass dem nicht so ist.
Es stellt sich heraus: Es hängt davon ab, wie Dusk Verträge behandelt. Sie können Zustände wie eine Wallet halten und verwalten—nicht nur Logik ausführen. Also kann ein Vertrag staken, nicht nur eine Wallet.
So läuft die Abfolge ab. Der Vertrag ruft die Staking-Funktion nicht direkt auf. Die Gelder gehen zuerst in den Vertrag, und dann macht er eine Übertragung von Vertrag zu Vertrag in den Stake-Contract. Unstaking und Rewards laufen über Callbacks zurück. Das Minimum bleibt 1.000 DUSK, und die Aktivierungsregeln sind die gleichen wie bei normalem Staking.
Was mich hier „Abstraktion“ glauben lässt, bedeutet nicht weniger Komplexität—es verlagert nur, wer sie handhabt. Wallet-Staking ist einfach, weil eine Person entscheidet. Contract-Staking bedeutet, dass der Code jede Entscheidung selbst richtig treffen muss. Ein falscher Callback und die Rewards bleiben stecken.
Ich bin mir trotzdem nicht sicher, wo die Grenze verläuft, wenn etwas kaputtgeht. Der Vertrag besitzt den Ablauf, aber das Protokoll besitzt weiterhin die Eignung für den Konsens. Wenn also ein gepoolter Staking-Contract durcheinanderkommt: ist das ein Vertragsfehler oder ein Protokollrisiko? Das habe ich noch nicht beantwortet gefunden.
@Dusk_Foundation $DUSK #dusk
Oft habe ich angenommen, dass Staking etwas ist, das nur eine Wallet machen kann. verbinden, delegieren, warten. das war das Modell überall, wo ich es zuvor genutzt habe.
Aber als ich den Abschnitt zur Stake-Abstraktion @Dusk stake gelesen habe, dachte ich, das wäre einfach nur Delegation mit einem neuen Namen. Ich brauchte ein paar Durchläufe durch die Dokus, bis ich merkte, dass dem nicht so ist.
Es stellt sich heraus: Es hängt davon ab, wie Dusk Verträge behandelt. Sie können Zustände wie eine Wallet halten und verwalten—nicht nur Logik ausführen. Also kann ein Vertrag staken, nicht nur eine Wallet.
So läuft die Abfolge ab. Der Vertrag ruft die Staking-Funktion nicht direkt auf. Die Gelder gehen zuerst in den Vertrag, und dann macht er eine Übertragung von Vertrag zu Vertrag in den Stake-Contract. Unstaking und Rewards laufen über Callbacks zurück. Das Minimum bleibt 1.000 DUSK, und die Aktivierungsregeln sind die gleichen wie bei normalem Staking.
Was mich hier „Abstraktion“ glauben lässt, bedeutet nicht weniger Komplexität—es verlagert nur, wer sie handhabt. Wallet-Staking ist einfach, weil eine Person entscheidet. Contract-Staking bedeutet, dass der Code jede Entscheidung selbst richtig treffen muss. Ein falscher Callback und die Rewards bleiben stecken.
Ich bin mir trotzdem nicht sicher, wo die Grenze verläuft, wenn etwas kaputtgeht. Der Vertrag besitzt den Ablauf, aber das Protokoll besitzt weiterhin die Eignung für den Konsens. Wenn also ein gepoolter Staking-Contract durcheinanderkommt: ist das ein Vertragsfehler oder ein Protokollrisiko? Das habe ich noch nicht beantwortet gefunden.
@Dusk_Foundation $DUSK #dusk