$GRVT =ist wirklich schwer zu „刷en“, und der Verschleiß ist extrem hoch.
An dem Tag, an dem ich das Dusk-Whitepaper komplett durchgearbeitet hatte, saß ich sehr lange im Büro.
Nicht weil das Dokument schwer verständlich wäre, sondern weil es „Privatsphäre“ und „Geschwindigkeit“ auf eine fast zwanghafte Art gleichzeitig in dasselbe Konsens-Set hineinstopft. Succinct Attestation (SA) ist vom Ansatz her tatsächlich hübsch—mit Blindgeboten die Identität der Validatoren verstecken, mit einem Komitee statt mit der Validierung durch alle Full Nodes, und dann mit dem Kadcast-Broadcast-Protokoll die Bandbreitenkosten auf ein Minimum drücken. In Summe schiebt dieses Zusammenspiel auf dem Papier „finanzreife Niedriglatenz“ und „anti-zensur Datenschutz“ gleichzeitig ein großes Stück nach vorn.
Aber nachdem ich die Protokollspezifikation und die bekannten Probleme durchgegangen war, konnte ich meinen Blick nicht mehr von den „Dreistufen-Komitees“ abwenden. Jede Runde des Konsenses geht drei Schritte: Proposal → Validation → Ratification. In jedem Schritt müssen unterschiedliche Komitees die Beschlussfähigkeit (Quorum) erreichen. Die Nachricht muss in voller Runde zwischen den drei Komitees durchgereicht werden, damit ein Block am Ende final bestätigt werden kann. Mehr eine Komiteestufe bedeutet mehr eine Nachrichtenweiterleitungsrunde—und damit mehr eine Stelle, an der es hängen bleiben kann.
Das durch Issue #3543 offengelegte Szenario macht dieses Risiko konkret: Der Validation-Schritt hat faktisch das Quorum erreicht, aber einige Knoten haben es nicht gesehen und haben in der Ratification Phase „NoQuorum“ gestimmt. Wenn die Quoren der drei Stufen nicht übereinstimmen, wird die gesamte Runde des Konsenses direkt verworfen—es ist nicht nur „langsamer“, sondern: Die ganze Runde beginnt von vorn.
Kadcast hat ebenfalls blinde Flecken. Zwar gab das Audit 9.8/10, aber Issue #108 legt ein sehr direktes Problem offen: Offline-Knoten werden niemals aus dem Bucket entfernt. Wenn so ein Knoten ausgewählt wird, geht die Nachricht direkt verloren. In den Broadcast-Zielen sind Offline-Knoten mit eingemischt—dann kommt das Quorum nicht zustande, und der Block bleibt stecken.
Noch weniger beruhigend ist, dass SBA zu einem „vollständig neuen, selbst entwickelten Konsens“ gehört. Das Team hat selbst schon einen „timeout fork“-Bug gefunden—die Wahrscheinlichkeit für Konsens-Forks steigt dabei ungewöhnlich stark. Ein Konsens, der bereits einen Fork-Bug hatte, hat durch die zusätzliche Synchronisationskomplexität der drei Stufen noch eine weitere Schicht drauf.
SA tauscht zwar mit drei Komiteestufen Privatsphäre und Geschwindigkeit ein, aber jede Konsensrunde verlangt, dass die Nachrichten der drei Komitees auf Kadcast vollständig synchronisiert werden. Ein Konsens, bei dem ein bereits erreichtes Validation zwar vorliegt, aber in der Ratification nicht gesehen wird und daher die ganze Runde verworfen wird—bist du sicher, dass er bei Netzwerk-„Jitter“ nicht häufig Blocks hängen lässt?
Ist Dusk mit diesem Drei-Komitee-Design eine präzise Ingenieursarchitektur oder eher ein Nährboden für Risiken in der gelebten Realität?
#dusk $DUSK @Dusk
An dem Tag, an dem ich das Dusk-Whitepaper komplett durchgearbeitet hatte, saß ich sehr lange im Büro.
Nicht weil das Dokument schwer verständlich wäre, sondern weil es „Privatsphäre“ und „Geschwindigkeit“ auf eine fast zwanghafte Art gleichzeitig in dasselbe Konsens-Set hineinstopft. Succinct Attestation (SA) ist vom Ansatz her tatsächlich hübsch—mit Blindgeboten die Identität der Validatoren verstecken, mit einem Komitee statt mit der Validierung durch alle Full Nodes, und dann mit dem Kadcast-Broadcast-Protokoll die Bandbreitenkosten auf ein Minimum drücken. In Summe schiebt dieses Zusammenspiel auf dem Papier „finanzreife Niedriglatenz“ und „anti-zensur Datenschutz“ gleichzeitig ein großes Stück nach vorn.
Aber nachdem ich die Protokollspezifikation und die bekannten Probleme durchgegangen war, konnte ich meinen Blick nicht mehr von den „Dreistufen-Komitees“ abwenden. Jede Runde des Konsenses geht drei Schritte: Proposal → Validation → Ratification. In jedem Schritt müssen unterschiedliche Komitees die Beschlussfähigkeit (Quorum) erreichen. Die Nachricht muss in voller Runde zwischen den drei Komitees durchgereicht werden, damit ein Block am Ende final bestätigt werden kann. Mehr eine Komiteestufe bedeutet mehr eine Nachrichtenweiterleitungsrunde—und damit mehr eine Stelle, an der es hängen bleiben kann.
Das durch Issue #3543 offengelegte Szenario macht dieses Risiko konkret: Der Validation-Schritt hat faktisch das Quorum erreicht, aber einige Knoten haben es nicht gesehen und haben in der Ratification Phase „NoQuorum“ gestimmt. Wenn die Quoren der drei Stufen nicht übereinstimmen, wird die gesamte Runde des Konsenses direkt verworfen—es ist nicht nur „langsamer“, sondern: Die ganze Runde beginnt von vorn.
Kadcast hat ebenfalls blinde Flecken. Zwar gab das Audit 9.8/10, aber Issue #108 legt ein sehr direktes Problem offen: Offline-Knoten werden niemals aus dem Bucket entfernt. Wenn so ein Knoten ausgewählt wird, geht die Nachricht direkt verloren. In den Broadcast-Zielen sind Offline-Knoten mit eingemischt—dann kommt das Quorum nicht zustande, und der Block bleibt stecken.
Noch weniger beruhigend ist, dass SBA zu einem „vollständig neuen, selbst entwickelten Konsens“ gehört. Das Team hat selbst schon einen „timeout fork“-Bug gefunden—die Wahrscheinlichkeit für Konsens-Forks steigt dabei ungewöhnlich stark. Ein Konsens, der bereits einen Fork-Bug hatte, hat durch die zusätzliche Synchronisationskomplexität der drei Stufen noch eine weitere Schicht drauf.
SA tauscht zwar mit drei Komiteestufen Privatsphäre und Geschwindigkeit ein, aber jede Konsensrunde verlangt, dass die Nachrichten der drei Komitees auf Kadcast vollständig synchronisiert werden. Ein Konsens, bei dem ein bereits erreichtes Validation zwar vorliegt, aber in der Ratification nicht gesehen wird und daher die ganze Runde verworfen wird—bist du sicher, dass er bei Netzwerk-„Jitter“ nicht häufig Blocks hängen lässt?
Ist Dusk mit diesem Drei-Komitee-Design eine präzise Ingenieursarchitektur oder eher ein Nährboden für Risiken in der gelebten Realität?
#dusk $DUSK @Dusk
