La mayoría de las cadenas de prueba de participación (proof-of-stake) hacen una cosa después de que se propone un bloque: un comité vota y, si caen suficientes votos, el bloque cuenta.
@Dusk lo hace dos veces, y la segunda ronda es la que nadie explica.
Las Attestations (pruebas concisas) se ejecutan en cada ronda en tres pasos. Un proponente propone un bloque candidato. Un comité seleccionado aleatoriamente lo valida. Luego, un segundo comité ratifica —y lo que confirma no es el bloque. Confirma el resultado de la validación.
Esa distinción me llevó un tiempo en verla bien.
La validación responde "¿este bloque es válido?". La ratificación responde "¿en realidad la red acordó que se validara?". Esas son preguntas distintas, y la segunda es donde proviene la finalización determinista. Sin ella tienes la opinión de un comité, propagada por toda una red, llegando a nodos diferentes en distintos momentos. Con ella tienes un registro atestiguado de que el propio acuerdo ocurrió.
Esa es la diferencia entre "este bloque probablemente es definitivo" y "este bloque es definitivo". Para una cadena orientada a la liquidación de valores, esa brecha no es filosófica. Es la diferencia entre una garantía de liquidación y una estimación de liquidación.
El costo también es real. Dos comités significan dos rondas de firmas, dos oportunidades para que la participación quede corta, y repartos de recompensas que lo reflejan —la validación y la ratificación toman cada una una porción de la recompensa del bloque, separada de la que recibe el generador de bloques.
Si esa ronda extra vale o no la latencia y la sobrecarga de coordinación es exactamente el tipo de cosa que una auditoría no puede decirte. La revisión de Oak Security calificó el protocolo como bien diseñado. Que esté bien diseñado y que esté bien adaptado a una carga real son afirmaciones diferentes.
Pregunta genuina para los operadores de nodos aquí: ¿alguien ha medido con qué frecuencia la etapa que se atasca es la ratificación, en vez de la validación?
#dusk $DUSK #block
@Dusk lo hace dos veces, y la segunda ronda es la que nadie explica.
Las Attestations (pruebas concisas) se ejecutan en cada ronda en tres pasos. Un proponente propone un bloque candidato. Un comité seleccionado aleatoriamente lo valida. Luego, un segundo comité ratifica —y lo que confirma no es el bloque. Confirma el resultado de la validación.
Esa distinción me llevó un tiempo en verla bien.
La validación responde "¿este bloque es válido?". La ratificación responde "¿en realidad la red acordó que se validara?". Esas son preguntas distintas, y la segunda es donde proviene la finalización determinista. Sin ella tienes la opinión de un comité, propagada por toda una red, llegando a nodos diferentes en distintos momentos. Con ella tienes un registro atestiguado de que el propio acuerdo ocurrió.
Esa es la diferencia entre "este bloque probablemente es definitivo" y "este bloque es definitivo". Para una cadena orientada a la liquidación de valores, esa brecha no es filosófica. Es la diferencia entre una garantía de liquidación y una estimación de liquidación.
El costo también es real. Dos comités significan dos rondas de firmas, dos oportunidades para que la participación quede corta, y repartos de recompensas que lo reflejan —la validación y la ratificación toman cada una una porción de la recompensa del bloque, separada de la que recibe el generador de bloques.
Si esa ronda extra vale o no la latencia y la sobrecarga de coordinación es exactamente el tipo de cosa que una auditoría no puede decirte. La revisión de Oak Security calificó el protocolo como bien diseñado. Que esté bien diseñado y que esté bien adaptado a una carga real son afirmaciones diferentes.
Pregunta genuina para los operadores de nodos aquí: ¿alguien ha medido con qué frecuencia la etapa que se atasca es la ratificación, en vez de la validación?
#dusk $DUSK #block
