He estado investigando cómo Succinct Attestation realmente resuelve una iteración, y algo sobre la ruta de fallo no dejaba de rondarme.
La historia obvia: un comité valida un bloque, lo ratifica y listo. Pero el protocolo de Dusk no solo hace un seguimiento de “válido”; hace un seguimiento de las Attestations, y una Failed Attestation (un quórum que acuerda que un bloque no es *válido*) es un resultado de primera clase, no un mero detalle.
Esto es lo que no había considerado: rechazar es estructuralmente más fácil que aceptar. Para ratificar un bloque válido, el comité tiene que verificar realmente las transiciones de estado, las firmas, todo el candidato. Para llegar a una Failed Attestation, los miembros del comité solo necesitan un acuerdo de supermayoría de que *algo* está mal: datos mal formados, un proponente incorrecto, un tiempo de espera. Esa verificación es mucho más superficial.
Así que, mecánicamente, un bloque defectuoso puede superar antes su umbral de quórum que uno bueno superar la validación, no porque la red favorezca los bloques inválidos, sino porque el rechazo no requiere reconstruir la corrección, solo detectar su ausencia. Eso no es un fallo. De hecho, es por eso que existen las iteraciones: fallar rápido, pasar el turno al siguiente proveedor y mantener el tiempo de bloque predecible.
Aun así, sigo trabajando en qué significa esta asimetría cuando los tamaños de los comités cambian con la distribución de la participación. ¿El rechazo más rápido se convierte en una superficie de ataque, o es solo resiliencia diseñada?
@Dusk_Foundation #dusk $DUSK
La historia obvia: un comité valida un bloque, lo ratifica y listo. Pero el protocolo de Dusk no solo hace un seguimiento de “válido”; hace un seguimiento de las Attestations, y una Failed Attestation (un quórum que acuerda que un bloque no es *válido*) es un resultado de primera clase, no un mero detalle.
Esto es lo que no había considerado: rechazar es estructuralmente más fácil que aceptar. Para ratificar un bloque válido, el comité tiene que verificar realmente las transiciones de estado, las firmas, todo el candidato. Para llegar a una Failed Attestation, los miembros del comité solo necesitan un acuerdo de supermayoría de que *algo* está mal: datos mal formados, un proponente incorrecto, un tiempo de espera. Esa verificación es mucho más superficial.
Así que, mecánicamente, un bloque defectuoso puede superar antes su umbral de quórum que uno bueno superar la validación, no porque la red favorezca los bloques inválidos, sino porque el rechazo no requiere reconstruir la corrección, solo detectar su ausencia. Eso no es un fallo. De hecho, es por eso que existen las iteraciones: fallar rápido, pasar el turno al siguiente proveedor y mantener el tiempo de bloque predecible.
Aun así, sigo trabajando en qué significa esta asimetría cuando los tamaños de los comités cambian con la distribución de la participación. ¿El rechazo más rápido se convierte en una superficie de ataque, o es solo resiliencia diseñada?
@Dusk_Foundation #dusk $DUSK