Zehn Minuten Offline im Rechenzentrum, und mit demselben Schlüssel zwei widersprüchliche Ergebnisse signiert: Kann man dann gleich hart bestrafen? Wenn die Antwort „beide verbrennen Coins“ ist, traue ich mich eher nicht, Knoten zu betreiben.
Ich habe die aktuellen Pledge-Regeln für @Dusk erneut überprüft. Dusk teilt die Consensus-Strafen in soft und hard ein, aber die eigentliche Grenze ist nicht, ob der Node-Owner mit Worten böswillig ist, sondern welche Beweise die On-Chain hinterlässt.
Die Soft-Strafe gilt für gescheitertes Mitwirken, z. B. wenn kein gültiger Kandidatenblock erzeugt werden konnte. Das Protokoll kann die Berechtigung des Knotens aussetzen und einen Teil des aktiven Stakes in einen gesperrten Stake überführen. Die Mittel bleiben Eigentum des Validators, aber sie verlieren vorübergehend die Fähigkeit, am Konsens teilzunehmen und Belohnungen zu verdienen.
Die Hard-Strafe richtet sich gegen nachweislich ungültiges Verhalten, darunter ungültige Votes sowie doppelt signierte Abstimmungs- oder konfliktierende Vorschläge. Zusätzlich zur Aussetzung der Berechtigung kann das Protokoll einen Teil des Stakes direkt vernichten, weil die Signatur bereits ein Beweis für die Zerstörung des Konsenses ist.
Das Protokoll entscheidet nicht für den Knoten, ob es ein Angriff oder ein Bedienfehler war. Die offizielle Stelle weist ausdrücklich darauf hin, dass man denselben <c-1/> consensus key nicht gleichzeitig auf zwei aktiven Knoten laufen lassen darf. Bei der Migration ist der alte Knoten eventuell noch nicht gestoppt, während der neue bereits signiert; Bedienfehler können ebenfalls zu Konfliktmeldungen führen und dann hart bestraft werden.
Daher darf das Pledge-Risiko nicht nur am APY festgemacht werden. Soft-Penalties beeinflussen den effektiven gestakten Betrag und den Ertragsausfall bei Stillstand, Hard-Penalties können das Kapital selbst treffen. Ich werde auf fault count, locked stake, die Aussetzungsdauer und Konflikt-Signaturen achten. $DUSK -Staking ist keine Einzahlung, sondern die Absicherung eines Produktionssystems mit dauerhaftem Online-Betrieb und einem einzigartigen Schlüssel.
#dusk $DUSK
Ich habe die aktuellen Pledge-Regeln für @Dusk erneut überprüft. Dusk teilt die Consensus-Strafen in soft und hard ein, aber die eigentliche Grenze ist nicht, ob der Node-Owner mit Worten böswillig ist, sondern welche Beweise die On-Chain hinterlässt.
Die Soft-Strafe gilt für gescheitertes Mitwirken, z. B. wenn kein gültiger Kandidatenblock erzeugt werden konnte. Das Protokoll kann die Berechtigung des Knotens aussetzen und einen Teil des aktiven Stakes in einen gesperrten Stake überführen. Die Mittel bleiben Eigentum des Validators, aber sie verlieren vorübergehend die Fähigkeit, am Konsens teilzunehmen und Belohnungen zu verdienen.
Die Hard-Strafe richtet sich gegen nachweislich ungültiges Verhalten, darunter ungültige Votes sowie doppelt signierte Abstimmungs- oder konfliktierende Vorschläge. Zusätzlich zur Aussetzung der Berechtigung kann das Protokoll einen Teil des Stakes direkt vernichten, weil die Signatur bereits ein Beweis für die Zerstörung des Konsenses ist.
Das Protokoll entscheidet nicht für den Knoten, ob es ein Angriff oder ein Bedienfehler war. Die offizielle Stelle weist ausdrücklich darauf hin, dass man denselben <c-1/> consensus key nicht gleichzeitig auf zwei aktiven Knoten laufen lassen darf. Bei der Migration ist der alte Knoten eventuell noch nicht gestoppt, während der neue bereits signiert; Bedienfehler können ebenfalls zu Konfliktmeldungen führen und dann hart bestraft werden.
Daher darf das Pledge-Risiko nicht nur am APY festgemacht werden. Soft-Penalties beeinflussen den effektiven gestakten Betrag und den Ertragsausfall bei Stillstand, Hard-Penalties können das Kapital selbst treffen. Ich werde auf fault count, locked stake, die Aussetzungsdauer und Konflikt-Signaturen achten. $DUSK -Staking ist keine Einzahlung, sondern die Absicherung eines Produktionssystems mit dauerhaftem Online-Betrieb und einem einzigartigen Schlüssel.
#dusk $DUSK
