¿Los clientes de Ethereum almacenan el 'estado histórico' o simplemente el 'estado actual'?

Supongo, dada la reciente autorización del estado, que los clientes de Ethereum solo deben almacenar el estado actual de cada cuenta en lugar de todo el estado histórico. (De lo contrario, si almacenara un registro de todos los estados anteriores de cada cuenta, ¿no seguiría almacenando las 20 000 000 cuentas vacías?)

Pero, si los clientes solo almacenan el estado actual, ¿cómo informan de manera eficiente sobre los saldos anteriores como lo hacen bajo esta llamada RPC ( https://github.com/ethereum/wiki/blob/master/JSON-RPC.md#eth_getbalance ) que toma una altura de bloque opcional?

¿Los clientes revisan la lista de todas las transacciones para generar saldos anteriores o los clientes realmente almacenan saldos anteriores? Si almacenan saldos anteriores, ¿almacenan algún otro historial por cuenta?

Muy bueno. Eso explica algo de eso, pero no responde la pregunta. Curiosamente, hay un comentario en la parte inferior de la publicación a la que se hace referencia que básicamente hace la misma pregunta. ¿Cómo recoge eth_getBalance los saldos históricos si el cliente no almacena el estado histórico? Me sorprendió esa pregunta de seguimiento al final de la publicación a la que se hace referencia. Es mio de hace un par de meses.

Respuestas (1)

Un nodo completo de Ethereum almacena el estado histórico. De hecho, cada bloque contiene la raíz del árbol de estado, de modo que "toma instantáneas" de todo el estado de cada bloque. La razón por la que esto no es un enorme desperdicio de espacio es que los árboles Patricia se pueden combinar fácilmente con el tiempo. Puede almacenar el código del contrato una vez, y cada vez que se hace referencia a él, puede volver a hacer referencia a él.

La limpieza estatal fue principalmente para nodos ligeros. Si todo lo que le importa es cuál es el estado ahora , no hay necesidad de tener los estados inflados de antes. Para la sincronización rápida de geth y la sincronización warp de parity, es aún más importante que el estado sea pequeño; de lo contrario, tendrá mucho más para descargar. Además, cuanto mayor sea el estado actual, más recursos consume un nodo completo en ejecución, lo que en sí mismo es una razón para borrar el estado.

Gracias. Ahora que me lo indicaste, está bien explicado en la sección 4.1 del Libro Amarillo. Hay 4 elementos de datos: nonce, balance, storageRoot y codeHash. ¿Es por eso que los clientes pueden devolver rápidamente el saldo y el nonce de una cuenta y su codeHash (pero no el código de bytes real) y el hash de storageRoot (pero no el almacenamiento real)? ¿Y es más correcto que debido a que todo lo que está almacenado no es posible un acceso tan rápido a una lista de transacciones de una cuenta sin girar a través de los bloques en busca de dichas transacciones, o también hay un atajo para hacerlo?
Puede obtener fácilmente el código: no es tan difícil para una implementación hacer un mapeo de hash a código, y es bastante útil ya que los contratos también pueden cargar el código de cada uno. Pero no parece haber un atajo para encontrar transacciones desde (y mucho menos hacia, o transacciones internas en total).