Hacer referencia a una cuenta olvidada hace mucho tiempo

En el blog de Etherem

Vitalik dice: "pero no almacenamos el historial de más de 5000 bloques".

1) ¿Se debe entender que el estado Trie no contiene el estado de las cuentas que no estuvieron en uso durante los últimos 5000 bloques?

2) Digamos que un tipo se despierta de una hibernación después de 50 años y quiere hacer una transacción que haga referencia a un bloque que ocurrió hace años. Teniendo en cuenta todos los algoritmos de poda de blockchain actuales implementados o que se implementarán pronto en Ethereum; ¿Cómo funcionaría el protocolo al respecto? Supongo que la mayoría de los nodos completos típicos ni siquiera contendrían los bloques que contienen transacciones que mencionan esa cuenta en particular en sus HDD (nuevamente, ¿hay algún algoritmo de poda de blockchain (no Trie State) en este momento?) Probablemente estaría contenido en algunos de los nodos de archivo. ¿Cómo sería el protocolo al respecto?

Entonces, la pregunta se extiende un poco a través de la arquitectura de Ethereum en sí (sugiere que en realidad tenemos algunos tipos de nodos completos, unos que almacenan todos los datos y otros que decidieron usar algunos algoritmos de poda). No es que amenace la criptografía. seguridad, ya que los hashes recientes serían suficientes para verificar si los colocados hace 50 años son correctos, pero eso requeriría verificar todos los bloques nuevamente una vez que los eliminemos del estado Trie. Otra opción sería CONFIAR en un nodo de archivo de inmediato, pero entonces no la seguridad criptográfica PERO, la naturaleza descentralizada de los servicios sufre mucho.

Curioso soy.

Respuestas (1)

  1. Esto es incorrecto. Creo que la desconexión es que el bloque no solo contiene cambios en el estado, sino que también contiene la raíz del estado en sí, que se genera utilizando todo el estado actual. Esencialmente, esto significa que, para los últimos 5000 bloques, el estado completo se almacena para cada uno de esos bloques, pero se descarta para los bloques anteriores. Entonces tiene el estado de cada cuenta en los bloques n a n-5000, pero no antes de eso.

  2. Nuevamente, vea el #1. La persona no tendría problemas porque su cuenta aún existiría en el estado actual. Sin embargo, no estoy muy seguro de lo que quiere decir con "hacer referencia a un bloque que sucedió hace años". No hace referencia a un bloque al realizar una transacción. Sin embargo, pueden estar confundidos, ya que en 10 años, la cadena de bloques de Ethereum probablemente se verá bastante diferente con fragmentación, plasma, casper, etc.

Sé que cada bloque contiene una raíz de estado. Los bloques contienen transacciones que alteran/actualizan el estado actual. Eso está claro.
Creo que lo que escribiste es en gran medida incorrecto. Sugiere que Ethereum almacena la copia completa de un trie para cada uno de los últimos 5000 bloques, mientras que los blogs y la lógica de Vitalik sugieren que los nodos no modificados simplemente se mencionan en la nueva instancia de Trie.
Mi único problema es; ¿Cómo procesa la red una transacción que hace referencia a una cuenta cuyo estado ya no forma parte de State Trie? Según tengo entendido, después de 5000 bloques, ya no es parte del State Trie, se ha podado y ahora debe volver a calcularse a partir del historial de transacciones. ¿Equivocado?
No necesita almacenar una copia completa del estado trie para cada uno de los 5000 bloques. Gran parte de los datos no se modifican, por lo que no los vuelve a almacenar. Pero la raíz del estado es el árbol merkle patricia de todo el estado. Todavía almacena el estado completo de los últimos 5000 bloques, aunque gran parte no ha cambiado en esos bloques y hace referencia al bloque más antiguo para el que aún se almacena el estado. En realidad, no es una referencia al bloque anterior.
Por ejemplo: un contrato que no cambia del bloque 1 al bloque 2 y al bloque 3 tendrá el mismo hash, por lo que el estado de ese contrato solo se almacena una vez en la base de datos, y las búsquedas de los hash apuntan a los mismos datos.
Una vez más, esto no significa que se eliminen los datos que no han cambiado en los últimos 5000 bloques. Simplemente significa que los estados obsoletos (por ejemplo, el saldo de su dirección hace 6000 bloques que ahora tiene un saldo diferente) se descartan.
Digamos que tenemos un estado Trie.Now muy grande. Durante los próximos 5000 bloques, hacemos transacciones solo entre dos cuentas. El algoritmo continúa actualizando los saldos de la cuenta (agregando nuevos nodos al estado trie que hacen referencia a los nodos principales de los estados anteriores de las dos cuentas). Esto continúa durante 5000 bloques. Ahora. Después de que tenemos más de 5000 bloques, comienza la poda. La mayoría del estado de Trie está ahora en el bloque 5001. ¿Se eliminan todos esos estados?
No estoy muy seguro de lo que estás diciendo. El estado en el bloque actual es siempre el estado actual de todo el sistema. No contiene estados obsoletos, solo los estados más actualizados de las cuentas. Los estados de las cuentas en n-5001 solo se almacenan en la base de datos si aún son relevantes, por ejemplo, si el estado de la cuenta aún es correcto. Si ya no es exacto, entonces se poda.
Gracias por intentar ayudar. En realidad, mi muestra y mi pregunta fueron muy específicas. github.com/ethereum/go-ethereum/pull/2111 No hemos mencionado que la propuesta inicial de Vitalik incorporaba el conteo para resolver problemas como este Y, lo que es más importante, que el algoritmo descrito nunca llegó a implementarse. ¿Alguna idea de cuáles son los algoritmos de poda actuales?