Zu spät dran gewesen, um mich richtig in die Slash-Mechaniken von Dusk einzuarbeiten. Irgendetwas passt nicht.
Sie verstecken die Einsatzbeträge, um die VRF-Auswahl zufällig zu halten. Klingt auf dem Papier plausibel. Aber beim Slashing müssen diese Beträge offengelegt werden, um zu beweisen, dass die Strafe gültig ist.
Hier tut mir der Kopf weh: Wenn der Einsatz verborgen bleibt, bis nach Fehlverhalten, was hindert dann einen Validator daran, den Einsatz über eine geschützte Übertragung kurz bevor er erwischt wird zu verschieben? In den Docs heißt es zwar, dass der Zustand gesperrt ist, aber diese Verifikationsverzögerung—selbst wenn es nur zwei oder drei Blöcke Unterschied sind—schafft ein Zeitfenster.
Man könnte einen Müll-Block vorschlagen, die Belohnung einstecken und drei Blöcke später geslashed werden, aber die Tokens sind dann schon weg. Der Slash verbrennt im Grunde nur ein leeres Konto. Die Chain macht den Block nicht rückgängig; sie verhängt einfach rückwirkend eine Strafe gegen ein Gespenst.
Alle verkaufen „regulierte Finanzen“ als Marketing-Argument für Privatsphäre. Aber ehrlich? Ich glaube inzwischen, dass die Identitätsschicht nicht nur ein Compliance-Kreuzchen ist—sondern eine technische Lösung genau für diese Lücke. Ohne off-chain-ID kannst du die Entität nicht verbannen, also wird der Exploit rein ökonomisch, und es könnte tatsächlich funktionieren.
Also ist Dusk’s KYC/AML wirklich ein Produkt-Unterscheidungsmerkmal, oder ist es die eigentliche Korrektur für eine zeitliche Lücke in deren eigenem PoS-Spieltheorie?
Vielleicht denke ich das Fenster nur zu groß. Aber die Dokumentation winkt bei dem Punkt ziemlich hart ab. Fängt ein State-Restoration das ab, oder ist es einfach „burn-and-forget“? Ich bin wirklich neugierig, ob das schon jemand tiefer analysiert hat.
@Dusk_Foundation #dusk $DUSK #DUSK
Sie verstecken die Einsatzbeträge, um die VRF-Auswahl zufällig zu halten. Klingt auf dem Papier plausibel. Aber beim Slashing müssen diese Beträge offengelegt werden, um zu beweisen, dass die Strafe gültig ist.
Hier tut mir der Kopf weh: Wenn der Einsatz verborgen bleibt, bis nach Fehlverhalten, was hindert dann einen Validator daran, den Einsatz über eine geschützte Übertragung kurz bevor er erwischt wird zu verschieben? In den Docs heißt es zwar, dass der Zustand gesperrt ist, aber diese Verifikationsverzögerung—selbst wenn es nur zwei oder drei Blöcke Unterschied sind—schafft ein Zeitfenster.
Man könnte einen Müll-Block vorschlagen, die Belohnung einstecken und drei Blöcke später geslashed werden, aber die Tokens sind dann schon weg. Der Slash verbrennt im Grunde nur ein leeres Konto. Die Chain macht den Block nicht rückgängig; sie verhängt einfach rückwirkend eine Strafe gegen ein Gespenst.
Alle verkaufen „regulierte Finanzen“ als Marketing-Argument für Privatsphäre. Aber ehrlich? Ich glaube inzwischen, dass die Identitätsschicht nicht nur ein Compliance-Kreuzchen ist—sondern eine technische Lösung genau für diese Lücke. Ohne off-chain-ID kannst du die Entität nicht verbannen, also wird der Exploit rein ökonomisch, und es könnte tatsächlich funktionieren.
Also ist Dusk’s KYC/AML wirklich ein Produkt-Unterscheidungsmerkmal, oder ist es die eigentliche Korrektur für eine zeitliche Lücke in deren eigenem PoS-Spieltheorie?
Vielleicht denke ich das Fenster nur zu groß. Aber die Dokumentation winkt bei dem Punkt ziemlich hart ab. Fängt ein State-Restoration das ab, oder ist es einfach „burn-and-forget“? Ich bin wirklich neugierig, ob das schon jemand tiefer analysiert hat.
@Dusk_Foundation #dusk $DUSK #DUSK