Hermanos, hablemos de un tema que puede salvar vidas, no lo vean como algo complicado.
La gran pizza ya subió a más de 80.000, ¡y el BTC está realmente fuerte!
En el sector hay una mala costumbre: en cuanto aparece el hash de una transacción, uno no puede esperar para brindar con champán. Pero dicho de forma cruda, en una cadena como Dusk —que busca finanzas reguladas—, entre Confirmed (confirmado) y Finalized (finalidad) en realidad hay una “brecha de tiempo” que necesitas mirar con lupa.
Volví a ordenar la base de Succinct Attestation y descubrí que este diseño es bastante contraintuitivo. No sigue esa lógica brusca de “en cuanto sale el bloque, ya queda todo sellado”, sino que sube por tres escalones muy firmes: primero, el Provisioner presenta los bloques candidatos; luego, el comité elegido al azar se pone manos a la obra y Validation los revisa; pero todavía no termina: hay que esperar a que otro grupo de jueces firme la Ratification. Solo cuando cae el “martillo” del tercer paso, el libro mayor se considera “quedó asentado para siempre”. Los dos pasos anteriores, por mucho que digas, todavía son “borradores”.
Esta diferencia normalmente no se siente en las transferencias, pero si lo piensas con calma… ¿y si esto fuera una entrega de valores en Trade de Dusk, o un abono grande en alguna institución? Solo con escuchar Contract Executed ya te pones a contabilizar; pero si después ocurre un Block Reverted (recuerda: esto no es un error del contrato, es un “rebobinado del tiempo” a nivel de consenso), ¿cómo vas a cuadrar los libros con el equipo de finanzas? El rastro ni siquiera vuelve. En la documentación separan a propósito el contract revert y el block revert: el primero es un choque de lógica del código; el segundo es que todo el bloque es “ejecutado” por el consenso. Dos fallos, dos formas de salvarse; mezclarlos es cavarte una mina.
Así que miren, aunque el escrito esté tan claro como papel y tinta, no sirve si el que integra se pone flojo. Lo que me preocupa no es “cuántos segundos tarda en salir un bloque en promedio $DUSK ”. Lo que observo es si esos amigos que hacen aplicaciones realmente toman finalized como un candado definitivo, y si hacen operaciones sin cruzar la línea. Si algo sale mal, ¿hay una herramienta de reejecución auditables que permita que la contabilidad del negocio “se tome la medicina del arrepentimiento” junto con la cadena?
La verdadera finalidad del cierre nunca es solo el momento en que los nodos, cerrando puertas, dan el visto bueno. Tiene que partir del evento finalized, atravesar el recorrido pasando por los nodos de archivo y el obstáculo de la reconexión y el barrido de reposición, y al final caer de manera estable en la base de datos del negocio. Entre medias, si cualquier etapa corre antes de tiempo, el asunto se rompe. @Dusk $DUSK #dusk
La gran pizza ya subió a más de 80.000, ¡y el BTC está realmente fuerte!
En el sector hay una mala costumbre: en cuanto aparece el hash de una transacción, uno no puede esperar para brindar con champán. Pero dicho de forma cruda, en una cadena como Dusk —que busca finanzas reguladas—, entre Confirmed (confirmado) y Finalized (finalidad) en realidad hay una “brecha de tiempo” que necesitas mirar con lupa.
Volví a ordenar la base de Succinct Attestation y descubrí que este diseño es bastante contraintuitivo. No sigue esa lógica brusca de “en cuanto sale el bloque, ya queda todo sellado”, sino que sube por tres escalones muy firmes: primero, el Provisioner presenta los bloques candidatos; luego, el comité elegido al azar se pone manos a la obra y Validation los revisa; pero todavía no termina: hay que esperar a que otro grupo de jueces firme la Ratification. Solo cuando cae el “martillo” del tercer paso, el libro mayor se considera “quedó asentado para siempre”. Los dos pasos anteriores, por mucho que digas, todavía son “borradores”.
Esta diferencia normalmente no se siente en las transferencias, pero si lo piensas con calma… ¿y si esto fuera una entrega de valores en Trade de Dusk, o un abono grande en alguna institución? Solo con escuchar Contract Executed ya te pones a contabilizar; pero si después ocurre un Block Reverted (recuerda: esto no es un error del contrato, es un “rebobinado del tiempo” a nivel de consenso), ¿cómo vas a cuadrar los libros con el equipo de finanzas? El rastro ni siquiera vuelve. En la documentación separan a propósito el contract revert y el block revert: el primero es un choque de lógica del código; el segundo es que todo el bloque es “ejecutado” por el consenso. Dos fallos, dos formas de salvarse; mezclarlos es cavarte una mina.
Así que miren, aunque el escrito esté tan claro como papel y tinta, no sirve si el que integra se pone flojo. Lo que me preocupa no es “cuántos segundos tarda en salir un bloque en promedio $DUSK ”. Lo que observo es si esos amigos que hacen aplicaciones realmente toman finalized como un candado definitivo, y si hacen operaciones sin cruzar la línea. Si algo sale mal, ¿hay una herramienta de reejecución auditables que permita que la contabilidad del negocio “se tome la medicina del arrepentimiento” junto con la cadena?
La verdadera finalidad del cierre nunca es solo el momento en que los nodos, cerrando puertas, dan el visto bueno. Tiene que partir del evento finalized, atravesar el recorrido pasando por los nodos de archivo y el obstáculo de la reconexión y el barrido de reposición, y al final caer de manera estable en la base de datos del negocio. Entre medias, si cualquier etapa corre antes de tiempo, el asunto se rompe. @Dusk $DUSK #dusk