En una actualización de Boreas detecté un detalle que puede hacer que un indexador “confunda las cuentas”: después de un rollback en la ejecución del contrato, algunos event aún podrían conservarse en el archivo. Ver un registro no significa que el estado realmente se haya aplicado.
Las reglas de la red principal de Boreas se habilitaron durante el reinicio coordinado del 10 de junio, correspondiente a los bloques 4,414,095 y Rusk 1.7. Después, los event que fueron revertidos pueden permanecer en los datos de archivo y llevar un indicador de reverted; sin embargo, no entran en las estructuras de filtrado de eventos que se usan para la búsqueda en bloques canónicos, y los eventos de staking revertidos tampoco modifican el estado de los participantes de consenso. Separar el flujo en realidad es en tres capas: durante la ejecución se generaron eventos → el resultado de la ejecución se revierte → se archiva como evidencia para auditoría y para conservar trazas de la reproducción histórica; pero el estado finalmente efectivo no reconoce este cambio. Los desarrolladores de ETH suelen estar más acostumbrados a indexar por event, y aquí es especialmente importante no actualizar solo el saldo, el staking o el estado del negocio basándose únicamente en el nombre del evento. $ETH
Los usuarios de BTC normalmente miran si un activo ha sido finalmente gastado; en ese caso, los eventos de aplicación no son la principal puerta de decisión. Ya en el entorno del contrato de Dusk, el front-end y los servicios de datos tienen una capa adicional de validación: “si el registro equivale a un estado efectivo”. Al leer en la práctica, al menos hay que comprobar reverted y combinarlo con el resultado de la ejecución. $BTC
El impacto de esta regla para los usuarios comunes no es que tengan que aprender a leer un indexador, sino que las carteras, los navegadores y los paneles de datos no deben mostrar “existe en el archivo” como “ya se completó”. @Dusk En esta ocasión separan con claridad la rastreabilidad histórica del estado actual. Ahora me interesa especialmente ver si los servicios de datos de terceros manejan de forma unificada esta marca, porque si se omite, los errores en la visualización suelen confundir más que los errores en la cadena. No es una diferencia menor de la capa de presentación, sino el límite de la semántica del estado. $DUSK
#dusk
Las reglas de la red principal de Boreas se habilitaron durante el reinicio coordinado del 10 de junio, correspondiente a los bloques 4,414,095 y Rusk 1.7. Después, los event que fueron revertidos pueden permanecer en los datos de archivo y llevar un indicador de reverted; sin embargo, no entran en las estructuras de filtrado de eventos que se usan para la búsqueda en bloques canónicos, y los eventos de staking revertidos tampoco modifican el estado de los participantes de consenso. Separar el flujo en realidad es en tres capas: durante la ejecución se generaron eventos → el resultado de la ejecución se revierte → se archiva como evidencia para auditoría y para conservar trazas de la reproducción histórica; pero el estado finalmente efectivo no reconoce este cambio. Los desarrolladores de ETH suelen estar más acostumbrados a indexar por event, y aquí es especialmente importante no actualizar solo el saldo, el staking o el estado del negocio basándose únicamente en el nombre del evento. $ETH
Los usuarios de BTC normalmente miran si un activo ha sido finalmente gastado; en ese caso, los eventos de aplicación no son la principal puerta de decisión. Ya en el entorno del contrato de Dusk, el front-end y los servicios de datos tienen una capa adicional de validación: “si el registro equivale a un estado efectivo”. Al leer en la práctica, al menos hay que comprobar reverted y combinarlo con el resultado de la ejecución. $BTC
El impacto de esta regla para los usuarios comunes no es que tengan que aprender a leer un indexador, sino que las carteras, los navegadores y los paneles de datos no deben mostrar “existe en el archivo” como “ya se completó”. @Dusk En esta ocasión separan con claridad la rastreabilidad histórica del estado actual. Ahora me interesa especialmente ver si los servicios de datos de terceros manejan de forma unificada esta marca, porque si se omite, los errores en la visualización suelen confundir más que los errores en la cadena. No es una diferencia menor de la capa de presentación, sino el límite de la semántica del estado. $DUSK
#dusk