Volví a revisar la documentación y dediqué más tiempo del esperado a dos áreas: la tolerancia a fallos de Kadcast y las reglas de finalidad del protocolo.
Al principio, el uso de la DHT de Kademlia por parte de Kadcast parecía bastante sencillo. Los nodos pueden actualizar sus tablas de enrutamiento cuando desaparecen pares, mientras que varios pares en cada bucket proporcionan rutas alternativas cuando falla un nodo. Pero me hizo preguntarme: ¿qué tan rápido puede adaptarse la red cuando los nodos se están incorporando y desconectando constantemente o se vuelven poco fiables? ¿Y podría una participación muy desigual crear partes más débiles en la estructura de enrutamiento?
El modelo de estado del consenso fue incluso más interesante.
Un bloque de @Dusk puede avanzar a través de aceptado, atestiguado, confirmado y, finalmente, final. Lo que me ayudó a entenderlo fue la distinción entre un bloque atestiguado y uno aceptado. Si iteraciones anteriores han fallado, un bloque exitoso puede ser aceptado pero aún seguir siendo reemplazable. Cuantas más iteraciones hayan fallado, más puede tardar la confirmación.
Por ejemplo, con dos iteraciones fallidas previas, las reglas exigen cuatro bloques consecutivos atestiguados o confirmados antes de que un bloque aceptado se convierta en confirmado.
Eso me lleva a plantear dudas sobre seguridad y descentralización. ¿Este mecanismo ofrece suficiente protección contra la inestabilidad temporal de la red sin volver la finalidad innecesariamente lenta? ¿Cómo se comporta el protocolo cuando los fallos están correlacionados entre muchos nodos en lugar de estar aislados?
También me pregunto cómo interactúan la dinámica de las tablas de enrutamiento y la finalidad del consenso durante periodos de disrupción seria de la red.
Mi comprensión todavía está en evolución, así que me interesaría escuchar cómo interpretan estas compensaciones otras personas.
¿Qué escenarios de fallo crees que Kadcast maneja especialmente bien? ¿Y dónde podrían ponerse a prueba sus supuestos?
$DUSK #dusk
#dusk $DUSK @Dusk
Al principio, el uso de la DHT de Kademlia por parte de Kadcast parecía bastante sencillo. Los nodos pueden actualizar sus tablas de enrutamiento cuando desaparecen pares, mientras que varios pares en cada bucket proporcionan rutas alternativas cuando falla un nodo. Pero me hizo preguntarme: ¿qué tan rápido puede adaptarse la red cuando los nodos se están incorporando y desconectando constantemente o se vuelven poco fiables? ¿Y podría una participación muy desigual crear partes más débiles en la estructura de enrutamiento?
El modelo de estado del consenso fue incluso más interesante.
Un bloque de @Dusk puede avanzar a través de aceptado, atestiguado, confirmado y, finalmente, final. Lo que me ayudó a entenderlo fue la distinción entre un bloque atestiguado y uno aceptado. Si iteraciones anteriores han fallado, un bloque exitoso puede ser aceptado pero aún seguir siendo reemplazable. Cuantas más iteraciones hayan fallado, más puede tardar la confirmación.
Por ejemplo, con dos iteraciones fallidas previas, las reglas exigen cuatro bloques consecutivos atestiguados o confirmados antes de que un bloque aceptado se convierta en confirmado.
Eso me lleva a plantear dudas sobre seguridad y descentralización. ¿Este mecanismo ofrece suficiente protección contra la inestabilidad temporal de la red sin volver la finalidad innecesariamente lenta? ¿Cómo se comporta el protocolo cuando los fallos están correlacionados entre muchos nodos en lugar de estar aislados?
También me pregunto cómo interactúan la dinámica de las tablas de enrutamiento y la finalidad del consenso durante periodos de disrupción seria de la red.
Mi comprensión todavía está en evolución, así que me interesaría escuchar cómo interpretan estas compensaciones otras personas.
¿Qué escenarios de fallo crees que Kadcast maneja especialmente bien? ¿Y dónde podrían ponerse a prueba sus supuestos?
$DUSK #dusk
#dusk $DUSK @Dusk
