Ayer volví a revisar la documentación de Dusk ( @Dusk ) por la noche, y cuanto más profundicé en el consenso, más interesantes se volvieron los casos de fallo.
Al principio, el modo de emergencia sonaba como una copia de seguridad sencilla. Pero, ¿por qué Dusk lo necesita si el protocolo normal ya puede reintentar iteraciones fallidas? La documentación explica que, después de fallos repetidos, el protocolo puede mantener abiertas iteraciones hasta que el consenso tenga éxito. Eso me hace preguntarme cuánta vivacidad se está priorizando sobre la eficiencia durante condiciones extremas de red.
Luego está la cuestión del fork. ¿Cómo pueden dos bloques candidato llegar a un consenso en la misma ronda? Dusk usa números de iteración y un mecanismo de retroceso para resolverlo, pero un bloque con una iteración mayor aún puede revertirse. Para la liquidación financiera, esa distinción parece importante.
También noté la estructura de recompensas. Los generadores reciben la mayor parte de la recompensa del bloque, mientras que los votantes reciben una parte separada. Eso tuvo más sentido cuando consideré el problema de incentivos: ¿qué impide que un generador futuro se beneficie cuando fallan iteraciones anteriores?
El sistema de fallos añade otra capa. ¿Por qué separar fallos menores de los mayores? La suspensión y el slashing suave parecen estar diseñados de manera distinta al slashing duro para comportamientos serios como el doble voto o los bloques inválidos.
Por último, Moonlight y Phoenix me hicieron replantearme la capa de transacciones. ¿Por qué mantener tanto un modelo transparente basado en cuentas como un modelo de privacidad basado en UTXO?
¿Este diseño dual crea flexibilidad útil o añade complejidad? Y a medida que Dusk crece, ¿en qué partes podría hacerse más difícil preservar la descentralización y la seguridad?
@Dusk_Foundation #dusk $DUSK
Al principio, el modo de emergencia sonaba como una copia de seguridad sencilla. Pero, ¿por qué Dusk lo necesita si el protocolo normal ya puede reintentar iteraciones fallidas? La documentación explica que, después de fallos repetidos, el protocolo puede mantener abiertas iteraciones hasta que el consenso tenga éxito. Eso me hace preguntarme cuánta vivacidad se está priorizando sobre la eficiencia durante condiciones extremas de red.
Luego está la cuestión del fork. ¿Cómo pueden dos bloques candidato llegar a un consenso en la misma ronda? Dusk usa números de iteración y un mecanismo de retroceso para resolverlo, pero un bloque con una iteración mayor aún puede revertirse. Para la liquidación financiera, esa distinción parece importante.
También noté la estructura de recompensas. Los generadores reciben la mayor parte de la recompensa del bloque, mientras que los votantes reciben una parte separada. Eso tuvo más sentido cuando consideré el problema de incentivos: ¿qué impide que un generador futuro se beneficie cuando fallan iteraciones anteriores?
El sistema de fallos añade otra capa. ¿Por qué separar fallos menores de los mayores? La suspensión y el slashing suave parecen estar diseñados de manera distinta al slashing duro para comportamientos serios como el doble voto o los bloques inválidos.
Por último, Moonlight y Phoenix me hicieron replantearme la capa de transacciones. ¿Por qué mantener tanto un modelo transparente basado en cuentas como un modelo de privacidad basado en UTXO?
¿Este diseño dual crea flexibilidad útil o añade complejidad? Y a medida que Dusk crece, ¿en qué partes podría hacerse más difícil preservar la descentralización y la seguridad?
@Dusk_Foundation #dusk $DUSK