Mientras investigaba sobre los diferentes modos de sincronización y sus comportamientos, aprendí que la sincronización completa de geth reproducirá todas las transacciones desde el génesis y conservará todos los estados del historial, mientras que la sincronización rápida solo descargará datos de bloque sin declaración hasta alrededor de 100 bloques antes de la última cabeza de bloque, y luego actuar como un nodo completo.
Decidí verificar estos comportamientos de esta manera:
Esto es lo que descubrí:
eth.getBalance(eth.accounts[0], <blockNumber>)) solo para los últimos 128 bloques.En ambos casos, la consulta de estados de bloques más antiguos da como resultado un missing trie nodeerror. Profundizando en el código, descubrí que esos nodos trie (raíces estatales de bloques antiguos) simplemente no se guardan en el leveldb subyacente.
Los comportamientos no coincidieron con lo que esperaba. Me pregunto si hay algún problema en la configuración de mi experimento. ¿Hay una poda de prueba de estado predeterminada de la que no estoy al tanto? Estoy usando el último geth 1.8. Cualquier sugerencia es bienvenida.
El comportamiento ha cambiado con el lanzamiento de geth v1.8.0
De las notas de la versión
Rastreo y poda: Por defecto, estado de los últimos 128 bloques guardados en la memoria. La mayoría de los estados son basura recolectada. Si está ejecutando un explorador de bloques u otro servicio que depende del seguimiento de transacciones sin un nodo de archivo (--gcmode=archive), ¡debe realizar el seguimiento dentro de esta ventana! Alternativamente, especifique la opción de rastreador "reexec" para permitir la regeneración del estado histórico; e, idealmente, cambiar al rastreo en cadena, que amortiza los gastos generales en todos los bloques rastreados.
xiaoyao