Das Durchgehen der Dokumentation von Dusk zeigt einen eleganten Ansatz für den Blockvorschlag, der jedoch stark auf fein abgestimmte Systemparameter angewiesen ist.
Die Anforderungen für Bereitsteller (Provisioner) sind strikt begrenzt: eine minimale Staking-Höhe von 1000 DUSK und ein Altersprofil innerhalb von 0 bis M Blöcken. Wenn es an der Zeit ist, einen Proposer zu wählen, setzt die DS-Engine den öffentlichen Schlüssel des Knotens, den Hash des vorherigen Blocks und den Staking-Betrag zu einer deterministischen Bewertung zusammen. Die höchste Bewertung erhält das Recht, den Block vorzuschlagen.
Die Validierung erfolgt in klar getrennten Phasen:
Kandidatenblöcke benötigen eine einfache Mehrheitsabstimmung, um die anfängliche Validierungsphase zu passieren.
Für die finale Finalität ist während der Ratifizierung eine Supermehrheitsabstimmung erforderlich, die den nächsten Satz von Provisionern festlegt.
Das Haupt risiko liegt in der Verwundbarkeit der Parameter. Das Ändern der Schwelle \bm{M} oder der Staking-Untergrenze könnte still und heimlich die Provisioner-Pool zentralisieren, ohne klare externe Warnungen. Außerdem bleibt es eine komplexe Herausforderung, das Ledger zu korrigieren, nachdem ein Block die Attestation erreicht hat, falls ein Exploit es jemandem ermöglicht, die DS-Bewertung zu manipulieren.
Wie stehen Sie zur Robustheit dieser Konsens-Schwellenanforderungen?
#dusk $DUSK @Dusk
#dusk $DUSK @Dusk
Die Anforderungen für Bereitsteller (Provisioner) sind strikt begrenzt: eine minimale Staking-Höhe von 1000 DUSK und ein Altersprofil innerhalb von 0 bis M Blöcken. Wenn es an der Zeit ist, einen Proposer zu wählen, setzt die DS-Engine den öffentlichen Schlüssel des Knotens, den Hash des vorherigen Blocks und den Staking-Betrag zu einer deterministischen Bewertung zusammen. Die höchste Bewertung erhält das Recht, den Block vorzuschlagen.
Die Validierung erfolgt in klar getrennten Phasen:
Kandidatenblöcke benötigen eine einfache Mehrheitsabstimmung, um die anfängliche Validierungsphase zu passieren.
Für die finale Finalität ist während der Ratifizierung eine Supermehrheitsabstimmung erforderlich, die den nächsten Satz von Provisionern festlegt.
Das Haupt risiko liegt in der Verwundbarkeit der Parameter. Das Ändern der Schwelle \bm{M} oder der Staking-Untergrenze könnte still und heimlich die Provisioner-Pool zentralisieren, ohne klare externe Warnungen. Außerdem bleibt es eine komplexe Herausforderung, das Ledger zu korrigieren, nachdem ein Block die Attestation erreicht hat, falls ein Exploit es jemandem ermöglicht, die DS-Bewertung zu manipulieren.
Wie stehen Sie zur Robustheit dieser Konsens-Schwellenanforderungen?
#dusk $DUSK @Dusk
#dusk $DUSK @Dusk