Dos vendedores en el mercado Saddar de Karachi, una vez ambos afirmaron que me habían vendido el mismo estuche de teléfono primero, y el encargado de la tienda simplemente siguió a quien agarró primero el cuaderno de recibos. Me pareció que Dusk maneja los bloques en competencia de la misma forma ruda: gana el que la red ve primero.
Eso va al revés de cómo funciona realmente el fallback. Cuando dos bloques candidatos llegan ambos a consenso en la misma ronda, lo cual puede ocurrir por mensajes retrasados o perdidos durante la congestión de la red, Dusk no favorece el que llegó primero. Favorece el que alcanzó el consenso con el menor número de iteración. Un bloque en la iteración 5 puede ser reemplazado por uno en la iteración 2 si el bloque de iteración más baja también logra quórum. El procedimiento de fallback revierte la cadena local a justo antes del bloque de mayor iteración, acepta en su lugar el de menor iteración y descarta todos los sucesores que se construyeron encima del bloque descartado.
Lo que realmente cambió mi forma de pensar es la excepción de la iteración 0. Un bloque que llega a consenso en la iteración 0 nunca puede ser reemplazado por un bloque de iteración inferior, ya que no existe una iteración más baja. Aun así, puede revertirse más adelante, pero solo si algo que está aguas arriba de él—uno de sus ancestros—se revierte primero. Así que la finalidad en Dusk no se trata tanto del estado de un bloque individual: se hereda de todo lo que está debajo.
Lo que el whitepaper no cuantifica es con qué frecuencia ocurren realmente bifurcaciones como esta cuando la red está bajo una congestión real a escala, no solo en teoría.
¿Alguien ha visto ya un evento real de fallback que ocurra en un bloque de Dusk?
#dusk $DUSK @Dusk
Eso va al revés de cómo funciona realmente el fallback. Cuando dos bloques candidatos llegan ambos a consenso en la misma ronda, lo cual puede ocurrir por mensajes retrasados o perdidos durante la congestión de la red, Dusk no favorece el que llegó primero. Favorece el que alcanzó el consenso con el menor número de iteración. Un bloque en la iteración 5 puede ser reemplazado por uno en la iteración 2 si el bloque de iteración más baja también logra quórum. El procedimiento de fallback revierte la cadena local a justo antes del bloque de mayor iteración, acepta en su lugar el de menor iteración y descarta todos los sucesores que se construyeron encima del bloque descartado.
Lo que realmente cambió mi forma de pensar es la excepción de la iteración 0. Un bloque que llega a consenso en la iteración 0 nunca puede ser reemplazado por un bloque de iteración inferior, ya que no existe una iteración más baja. Aun así, puede revertirse más adelante, pero solo si algo que está aguas arriba de él—uno de sus ancestros—se revierte primero. Así que la finalidad en Dusk no se trata tanto del estado de un bloque individual: se hereda de todo lo que está debajo.
Lo que el whitepaper no cuantifica es con qué frecuencia ocurren realmente bifurcaciones como esta cuando la red está bajo una congestión real a escala, no solo en teoría.
¿Alguien ha visto ya un evento real de fallback que ocurra en un bloque de Dusk?
#dusk $DUSK @Dusk
