El detalle de Dusk al que seguía volviendo es que un bloque puede tener una atestación de éxito y aun así no ser final.
Mi primera lectura de Succinct Attestation era más sencilla.
la propuesta llega.
la validación alcanza una supermayoría de votos válidos.
la ratificación lo confirma.
las firmas BLS agregadas prueban el quórum.
¿Listo, cierto?
No del todo.
La sección de finalización progresiva (rolling finality) de Dusk divide un bloque en aceptado, atestado, confirmado y final.
si se produce un bloque en la iteración I > 0 mientras una iteración anterior aún no tiene atestación de fallo, puede llevar una atestación de éxito y solo marcarse como aceptado.
porque “el comité alcanzó el quórum” suena muy parecido a “este bloque no puede desaparecer”.
en Dusk esas son afirmaciones diferentes.
la iteración anterior no resuelta todavía importa. si un bloque de iteración inferior más tarde llega a consenso, el mecanismo de respaldo (fallback) puede reemplazar el bloque aceptado y descartar a sus sucesores.
así que la atestación de éxito prueba que ocurrió el acuerdo.
pero no siempre prueba que la cadena haya terminado de elegir.
un bloque atestado o bien aterrizó en la iteración 0, o bien tiene atestaciones de fallo que cubren cada iteración anterior, de modo que ningún bloque de iteración inferior puede reemplazarlo directamente. confirmado depende de bloques posteriores. final llega solo cuando el bloque está confirmado y su padre ya es final.
eso hizo que “finalidad en segundos” se sintiera menos como un solo evento y más como un límite que una aplicación tiene que leer correctamente.
una aplicación en Dusk no solo pregunta si el consenso firmó algo.
¿liberar colateral?
¿reconocer una transferencia de seguridad?
¿dejar que otro contrato trate el estado como irreversible?
esos casos quizá no merezcan el mismo umbral.
la mayor parte del tiempo esto probablemente avanza rápido. bien
el caso límite es lo que me interesa: un bloque parece exitoso, una aplicación reacciona a él y una iteración inferior todavía está viva.
Dusk no oculta ese hueco. lo nombra.
aceptado no es final.
y una vez que noté eso, mi pregunta de integración cambió.
no “¿el consenso tuvo éxito?”
¿qué tan irreversible necesita esta aplicación que sea Dusk antes de que actúe?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
Mi primera lectura de Succinct Attestation era más sencilla.
la propuesta llega.
la validación alcanza una supermayoría de votos válidos.
la ratificación lo confirma.
las firmas BLS agregadas prueban el quórum.
¿Listo, cierto?
No del todo.
La sección de finalización progresiva (rolling finality) de Dusk divide un bloque en aceptado, atestado, confirmado y final.
si se produce un bloque en la iteración I > 0 mientras una iteración anterior aún no tiene atestación de fallo, puede llevar una atestación de éxito y solo marcarse como aceptado.
porque “el comité alcanzó el quórum” suena muy parecido a “este bloque no puede desaparecer”.
en Dusk esas son afirmaciones diferentes.
la iteración anterior no resuelta todavía importa. si un bloque de iteración inferior más tarde llega a consenso, el mecanismo de respaldo (fallback) puede reemplazar el bloque aceptado y descartar a sus sucesores.
así que la atestación de éxito prueba que ocurrió el acuerdo.
pero no siempre prueba que la cadena haya terminado de elegir.
un bloque atestado o bien aterrizó en la iteración 0, o bien tiene atestaciones de fallo que cubren cada iteración anterior, de modo que ningún bloque de iteración inferior puede reemplazarlo directamente. confirmado depende de bloques posteriores. final llega solo cuando el bloque está confirmado y su padre ya es final.
eso hizo que “finalidad en segundos” se sintiera menos como un solo evento y más como un límite que una aplicación tiene que leer correctamente.
una aplicación en Dusk no solo pregunta si el consenso firmó algo.
¿liberar colateral?
¿reconocer una transferencia de seguridad?
¿dejar que otro contrato trate el estado como irreversible?
esos casos quizá no merezcan el mismo umbral.
la mayor parte del tiempo esto probablemente avanza rápido. bien
el caso límite es lo que me interesa: un bloque parece exitoso, una aplicación reacciona a él y una iteración inferior todavía está viva.
Dusk no oculta ese hueco. lo nombra.
aceptado no es final.
y una vez que noté eso, mi pregunta de integración cambió.
no “¿el consenso tuvo éxito?”
¿qué tan irreversible necesita esta aplicación que sea Dusk antes de que actúe?
@Dusk_Foundation $DUSK #Dusk $ACE $APR
SELECTIVE DISCLOSURE
0%
DUSKVM
0%
DUSK'S MOONLIGHT
100%
DUSK'S PHOENIX
0%
1 Votos • Votación cerrada