Ich habe einen Teil des heutigen Tages damit verbracht, Dusk’ Fork-Handling und das Privacy-Design zu lesen, und am Ende habe ich zwei Bereiche miteinander verbunden, die ich anfangs für unabhängig hielt: Konsens-Anreize und private Transaktionen.
Die Fork-Regel hat zuerst meine Aufmerksamkeit erregt. Dusk verwendet die Iterationsnummer, wenn konkurrierende Blöcke aufgelöst werden, und bevorzugt dabei die niedrigere Iteration. Ich verstehe die grundlegende Logik, aber warum ist die Iteration das stärkste Signal dafür, welcher Block überleben sollte? Welche Annahmen werden dabei über Netzwerk-Timing und ehrliche Teilnahme gemacht?
Dann habe ich mir das Problem des Future-Generators angesehen. Wenn ein Provisioner weiß, dass er in einer späteren Iteration möglicherweise zum Generator werden könnte, könnte es dann von Vorteil sein, frühere Versuche scheitern zu lassen? Das erzeugt ein seltsames Anreizproblem, insbesondere wenn Blockprämien im Spiel sind.
Auch das Fehler-Modell ergibt in diesem Kontext mehr Sinn. Warum sollte doppeltes Wählen/Abstimmen strenger bestraft werden als das Scheitern, einen Kandidaten zu broadcasten? Meine Interpretation ist, dass bewusstes widersprüchliches Verhalten den Konsens direkt gefährdet, während Untätigkeit vor allem die Liveness betrifft, aber die Unterscheidung ist für die Validator-Ökonomie entscheidend.
Phoenix hat die Diskussion zurück zur Finanzierung gebracht. Ich kann nachvollziehen, warum private Transaktionen für Wertpapiere, institutionelle Überweisungen oder sensible Finanzaktivitäten relevant sein könnten. Seine ZK-Beweise können zeigen, dass Salden, Eigentumsverhältnisse und Ausgabenregeln gültig sind, ohne die zugrunde liegenden Details offenzulegen.
Aber Delegation bringt noch eine weitere Ebene des Vertrauens mit sich. Wenn Nutzer darauf vertrauen, dass Dritte ihre Transaktionen anhand von View-Keys scannen, was für Informationen können diese Parteien tatsächlich lernen?
Ich frage mich, wo Dusk die praktische Grenze zieht zwischen Privacy, Sicherheit, Anreizen und betrieblicher Bequemlichkeit.
#dusk $DUSK @Dusk
Die Fork-Regel hat zuerst meine Aufmerksamkeit erregt. Dusk verwendet die Iterationsnummer, wenn konkurrierende Blöcke aufgelöst werden, und bevorzugt dabei die niedrigere Iteration. Ich verstehe die grundlegende Logik, aber warum ist die Iteration das stärkste Signal dafür, welcher Block überleben sollte? Welche Annahmen werden dabei über Netzwerk-Timing und ehrliche Teilnahme gemacht?
Dann habe ich mir das Problem des Future-Generators angesehen. Wenn ein Provisioner weiß, dass er in einer späteren Iteration möglicherweise zum Generator werden könnte, könnte es dann von Vorteil sein, frühere Versuche scheitern zu lassen? Das erzeugt ein seltsames Anreizproblem, insbesondere wenn Blockprämien im Spiel sind.
Auch das Fehler-Modell ergibt in diesem Kontext mehr Sinn. Warum sollte doppeltes Wählen/Abstimmen strenger bestraft werden als das Scheitern, einen Kandidaten zu broadcasten? Meine Interpretation ist, dass bewusstes widersprüchliches Verhalten den Konsens direkt gefährdet, während Untätigkeit vor allem die Liveness betrifft, aber die Unterscheidung ist für die Validator-Ökonomie entscheidend.
Phoenix hat die Diskussion zurück zur Finanzierung gebracht. Ich kann nachvollziehen, warum private Transaktionen für Wertpapiere, institutionelle Überweisungen oder sensible Finanzaktivitäten relevant sein könnten. Seine ZK-Beweise können zeigen, dass Salden, Eigentumsverhältnisse und Ausgabenregeln gültig sind, ohne die zugrunde liegenden Details offenzulegen.
Aber Delegation bringt noch eine weitere Ebene des Vertrauens mit sich. Wenn Nutzer darauf vertrauen, dass Dritte ihre Transaktionen anhand von View-Keys scannen, was für Informationen können diese Parteien tatsächlich lernen?
Ich frage mich, wo Dusk die praktische Grenze zieht zwischen Privacy, Sicherheit, Anreizen und betrieblicher Bequemlichkeit.
#dusk $DUSK @Dusk