$GRVT 是真的难刷，磨损之高。
翻完Dusk白皮书那天，我在办公室坐了很久。
不是因为文档难懂，而是用 una forma casi obsesiva de meter a la vez “privacidad” y “velocidad” en un mismo consenso. Succinct Attestation (SA) en ideas es realmente hermosa: oculta la identidad del validador con pujas a ciegas, sustituye la validación de nodos completos por un comité, y usa el protocolo de difusión Kadcast para reducir al mínimo el costo de ancho de banda. En el papel, este conjunto de movimientos empuja “latencia baja a nivel financiero” y “privacidad resistente a la censura” bastante más lejos.
Pero al terminar de revisar las especificaciones del protocolo y los problemas conocidos, mi atención se quedó fija en el tema de los “tres comités en capas”. Cada ronda de consenso da tres pasos: Proposal → Validation → Ratification. Cada paso requiere que comités distintos alcancen el quórum legal. Los mensajes tienen que transmitirse completamente entre los tres comités en una ronda, para que el bloque finalmente se pueda confirmar. Con una capa más de comité: una ronda más de transmisión de mensajes y un paso más donde puede quedarse todo trabado.
El escenario expuesto en el Issue #3543 vuelve este riesgo concreto: en el paso de Validation, en realidad se alcanza el quórum, pero algunos nodos no lo vieron y en Ratification votaron NoQuorum. Como el quórum legal de las tres capas no coincide, toda la ronda de consenso se invalida de inmediato; no es un problema de “ir más lento”. Es volver a empezar toda la ronda.
Kadcast también tiene zonas ciegas. Aunque la auditoría dio 9.8/10, el Issue #108 expone un problema directo: los nodos desconectados nunca serán removidos del cubo. Si este nodo se selecciona para difundir, el mensaje se pierde. Si en los objetivos de la difusión se mezclan nodos desconectados, no se alcanza el quórum legal y el bloque queda atascado.
Aún menos tranquilizador es que SBA pertenece a un “consenso totalmente nuevo desarrollado por la propia iniciativa”. El equipo también detectó una vulnerabilidad de “timeout fork”, que eleva de manera anormal la probabilidad de bifurcación del consenso. Un consenso que ya tuvo una vulnerabilidad de bifurcación, además tiene encima otra capa de complejidad en la sincronización de mensajes de los tres comités.
SA intercambia privacidad y velocidad por tres comités en capas, pero en cada ronda de consenso exige que los mensajes de los tres comités se sincronicen completamente en Kadcast. Un consenso en el que una Validation sí se alcanzó pero la Ratification no lo vio, y por tanto toda la ronda se invalida: ¿estás seguro de que cuando la red se agita (jitter) no se va a atascar el bloque con frecuencia?
¿El diseño de tres comités en Dusk es una arquitectura de ingeniería ingeniosa o una incubadora de riesgos de “vida” (liveness)?
#dusk $DUSK @Dusk
翻完Dusk白皮书那天，我在办公室坐了很久。
不是因为文档难懂，而是用 una forma casi obsesiva de meter a la vez “privacidad” y “velocidad” en un mismo consenso. Succinct Attestation (SA) en ideas es realmente hermosa: oculta la identidad del validador con pujas a ciegas, sustituye la validación de nodos completos por un comité, y usa el protocolo de difusión Kadcast para reducir al mínimo el costo de ancho de banda. En el papel, este conjunto de movimientos empuja “latencia baja a nivel financiero” y “privacidad resistente a la censura” bastante más lejos.
Pero al terminar de revisar las especificaciones del protocolo y los problemas conocidos, mi atención se quedó fija en el tema de los “tres comités en capas”. Cada ronda de consenso da tres pasos: Proposal → Validation → Ratification. Cada paso requiere que comités distintos alcancen el quórum legal. Los mensajes tienen que transmitirse completamente entre los tres comités en una ronda, para que el bloque finalmente se pueda confirmar. Con una capa más de comité: una ronda más de transmisión de mensajes y un paso más donde puede quedarse todo trabado.
El escenario expuesto en el Issue #3543 vuelve este riesgo concreto: en el paso de Validation, en realidad se alcanza el quórum, pero algunos nodos no lo vieron y en Ratification votaron NoQuorum. Como el quórum legal de las tres capas no coincide, toda la ronda de consenso se invalida de inmediato; no es un problema de “ir más lento”. Es volver a empezar toda la ronda.
Kadcast también tiene zonas ciegas. Aunque la auditoría dio 9.8/10, el Issue #108 expone un problema directo: los nodos desconectados nunca serán removidos del cubo. Si este nodo se selecciona para difundir, el mensaje se pierde. Si en los objetivos de la difusión se mezclan nodos desconectados, no se alcanza el quórum legal y el bloque queda atascado.
Aún menos tranquilizador es que SBA pertenece a un “consenso totalmente nuevo desarrollado por la propia iniciativa”. El equipo también detectó una vulnerabilidad de “timeout fork”, que eleva de manera anormal la probabilidad de bifurcación del consenso. Un consenso que ya tuvo una vulnerabilidad de bifurcación, además tiene encima otra capa de complejidad en la sincronización de mensajes de los tres comités.
SA intercambia privacidad y velocidad por tres comités en capas, pero en cada ronda de consenso exige que los mensajes de los tres comités se sincronicen completamente en Kadcast. Un consenso en el que una Validation sí se alcanzó pero la Ratification no lo vio, y por tanto toda la ronda se invalida: ¿estás seguro de que cuando la red se agita (jitter) no se va a atascar el bloque con frecuencia?
¿El diseño de tres comités en Dusk es una arquitectura de ingeniería ingeniosa o una incubadora de riesgos de “vida” (liveness)?
#dusk $DUSK @Dusk
