Primero, defina claramente el problema que se va a demostrar.
Al examinar un bloque, las preguntas comunes incluyen si se incluye una transacción, cuál es el resultado de la ejecución y cuál es el estado de una cuenta en un bloque específico. Estas son preguntas diferentes que requieren datos y pruebas diferentes. El hash raíz en el encabezado del bloque proporciona un compromiso con la estructura de datos correspondiente, pero el hash raíz en sí no es una lista de cuentas directamente legible, ni explica por qué una transacción produce un determinado resultado comercial.
Las raíces de las transacciones corresponden al conjunto de transacciones.
Las raíces de las transacciones están relacionadas con las transacciones organizadas secuencialmente dentro de un bloque. Al verificar la relación de inclusión de una transacción, es necesario conocer simultáneamente la red, el encabezado del bloque y la estructura de prueba correspondiente. La inclusión de una transacción no garantiza su ejecución exitosa ni indica que la plataforma receptora la haya acreditado en la cuenta del cliente. Un enlace del navegador solo proporciona un punto de entrada para la consulta; para la verificación formal, es crucial aclarar si se confía en el nodo, el navegador o el encabezado del bloque verificado.
La raíz del recibo corresponde a los resultados de la ejecución.
Los recibos suelen contener información como el estado de ejecución, el consumo acumulado de gas y los registros. La raíz del recibo garantiza estos resultados de ejecución, no el saldo del cliente en la plataforma. Las aplicaciones pueden identificar la actividad mediante registros, pero el contrato emisor, la decodificación de parámetros y el estado de la transacción en los registros deben examinarse conjuntamente. Ver un evento denominado "Transferencia" no exime de las comprobaciones de autenticidad del contrato del token y del resultado de su ejecución.
Las raíces de estado describen el estado de un bloque específico.
Una raíz de estado corresponde a una instantánea de un estado y puede incluir la estructura asociada de saldos de cuenta, nonces, código y almacenamiento. Las pruebas requieren un bloque fijo; la prueba de ayer no se puede aplicar a la de hoy. Una prueba válida para una ranura de almacenamiento específica no garantiza la ausencia de riesgo para la economía del token, la autoridad administrativa ni los oráculos externos. El alcance de los compromisos técnicos debe ser más preciso que las afirmaciones de "verificación completa en la cadena" que aparecen en los materiales de marketing.
Ejemplo de verificación entre campos
Supongamos que un usuario desea confirmar una llamada de contrato. Primero, determine en qué bloque se registró la transacción, luego verifique si la recepción fue exitosa y los parámetros del evento, y finalmente consulte el estado de la cuenta o el contrato correspondiente según la pregunta. Si el navegador y la aplicación muestran información diferente, verifique si se hace referencia a diferentes alturas de bloque o redes diferentes, en lugar de asumir inmediatamente que una de las partes es fraudulenta. Este ejemplo ilustra los niveles de evidencia y no constituye una conclusión de auditoría para ningún contrato.
Conservar el contexto de la prueba
Conserve el identificador de la cadena, la altura del bloque y el hash, el tipo de hash raíz, el método de consulta, los datos de prueba y la versión de la herramienta. Si se utiliza un servicio de decodificación de terceros, indique su función y la posible latencia de almacenamiento en caché. La finalidad y la reorganización de la cadena aún afectan el estado del bloque seleccionado; Verificar una prueba de datos, respondiendo únicamente a preguntas técnicas explícitas, y no probar la entidad de servicio, las reservas de activos ni la posibilidad de reembolso futuro.