Nodo devuelve “202 Accepted”, ¿cuántos pasos faltan para que realmente se complete el pago?
En los sistemas de pago tradicionales, “el banco ha recibido” y “los fondos ya se han acreditado” son dos estados diferentes. Tras estudiar el ciclo de vida de la transacción de @Dusk , descubrí que en la cadena también no basta con ver un único aviso de éxito.
Una transacción de Dusk L1 en general pasa por:
envío, prevalidación del nodo, entrada al mempool local, propagación a otros nodos, selección por el productor de bloques, ejecución y confirmación final.
Lo más fácil de malinterpretar es que el endpoint de envío de transacciones devuelva 202 Accepted: eso solo indica que el nodo recibió los datos y los prepara para propagarlos, pero no significa que ya haya entrado en un bloque.
Aunque la transacción entre en el mempool del nodo, solo significa que pasó las comprobaciones iniciales de ese nodo. Cuando entra en un bloque, aún hay que revisar si el campo err en el resultado de la ejecución está vacío. Si el contrato revierte por parámetros, estado o problemas de Gas, el Nonce y el Gas ya consumido podrían no poder recuperarse.
Por último, falta esperar a que el bloque alcance el estado finalized. La documentación oficial lo advierte claramente: no se deben tomar incluido, removed o un accepted normal como una señal directa de finalización del pago.
Esto es muy importante para la futura liquidación de valores en servicios de Dusk. A las instituciones no les importa solo si la interfaz muestra un aviso verde, sino en qué estado irreversible se realiza la entrega de activos y el registro contable.
El indicador de finalización de red que ofrece el sitio web de Dusk es de aproximadamente 10 segundos, pero la aplicación aún debe reconocer correctamente el estado final, en lugar de intentar adivinar el resultado confiando en una espera fija de 10 segundos.
Creo que para evaluar si el sistema de liquidación a nivel institucional está maduro, observaría sobre todo:
1. La estabilidad del tiempo de confirmación final;
2. La tasa de fallo de ejecución;
3. El número de reversiones de bloques y de reconciliaciones nuevamente;
4. Si la aplicación distingue entre envío, ejecución y confirmación final;
5. Si el lado de activos y el lado de pagos usan el mismo estándar de finalización.
La verdadera liquidación on-chain no es que la transacción haya sido emitida, sino que todos los participantes tienen una respuesta一致（común） sobre cuándo se puede registrar la contabilidad. #dusk $DUSK
En los sistemas de pago tradicionales, “el banco ha recibido” y “los fondos ya se han acreditado” son dos estados diferentes. Tras estudiar el ciclo de vida de la transacción de @Dusk , descubrí que en la cadena también no basta con ver un único aviso de éxito.
Una transacción de Dusk L1 en general pasa por:
envío, prevalidación del nodo, entrada al mempool local, propagación a otros nodos, selección por el productor de bloques, ejecución y confirmación final.
Lo más fácil de malinterpretar es que el endpoint de envío de transacciones devuelva 202 Accepted: eso solo indica que el nodo recibió los datos y los prepara para propagarlos, pero no significa que ya haya entrado en un bloque.
Aunque la transacción entre en el mempool del nodo, solo significa que pasó las comprobaciones iniciales de ese nodo. Cuando entra en un bloque, aún hay que revisar si el campo err en el resultado de la ejecución está vacío. Si el contrato revierte por parámetros, estado o problemas de Gas, el Nonce y el Gas ya consumido podrían no poder recuperarse.
Por último, falta esperar a que el bloque alcance el estado finalized. La documentación oficial lo advierte claramente: no se deben tomar incluido, removed o un accepted normal como una señal directa de finalización del pago.
Esto es muy importante para la futura liquidación de valores en servicios de Dusk. A las instituciones no les importa solo si la interfaz muestra un aviso verde, sino en qué estado irreversible se realiza la entrega de activos y el registro contable.
El indicador de finalización de red que ofrece el sitio web de Dusk es de aproximadamente 10 segundos, pero la aplicación aún debe reconocer correctamente el estado final, en lugar de intentar adivinar el resultado confiando en una espera fija de 10 segundos.
Creo que para evaluar si el sistema de liquidación a nivel institucional está maduro, observaría sobre todo:
1. La estabilidad del tiempo de confirmación final;
2. La tasa de fallo de ejecución;
3. El número de reversiones de bloques y de reconciliaciones nuevamente;
4. Si la aplicación distingue entre envío, ejecución y confirmación final;
5. Si el lado de activos y el lado de pagos usan el mismo estándar de finalización.
La verdadera liquidación on-chain no es que la transacción haya sido emitida, sino que todos los participantes tienen una respuesta一致（común） sobre cuándo se puede registrar la contabilidad. #dusk $DUSK