Profundizando en Ethereum: ¿Cómo se almacenan los datos en Ethereum? by@vasa
55,068 lecturas

Profundizando en Ethereum: ¿Cómo se almacenan los datos en Ethereum?

2018/07/29
por @vasa 55,068 lecturas
ES
Read on Terminal Reader

Demasiado Largo; Para Leer


Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Profundizando en Ethereum: ¿Cómo se almacenan los datos en Ethereum?
Vaibhav Saini HackerNoon profile picture

@vasa

Vaibhav Saini

Entrepreneur | Co-founder @tbc_inc, an MIT CIC incubated startup |...

Sobre @vasa
LEARN MORE ABOUT @VASA'S EXPERTISE AND PLACE ON THE INTERNET.
react to story with heart

En esta publicación, veremos cómo se almacenan los estados y las transacciones en Ethereum y en qué se diferencia de Bitcoin.

image

Esta publicación es una continuación de mi serie Getting Deep Into iniciada en un esfuerzo por proporcionar una comprensión más profunda del funcionamiento interno y otras cosas interesantes sobre Ethereum y blockchain en general que no encontrará fácilmente en la web. Aquí están las otras partes de la Serie:

Profundizando en Geth: por qué la sincronización del nodo Ethereum es lenta _La descarga de los bloques es solo una pequeña parte. Están sucediendo muchas cosas... Esta publicación marca la primera de una nueva..._hackernoon.com

Profundizando en EVM: cómo funciona Ethereum entre bastidores _Una explicación definitiva y detallada de qué es EVM y cómo funciona EVM._hackernoon.com

En esta publicación, nos sumergiremos en la capa de almacenamiento de datos de Ethereum. Presentaremos el concepto de "estado" de blockchain. Cubriremos la teoría detrás de la estructura de datos de Patricia Trie y demostraremos la implementación concreta de intentos de Ethereum utilizando la base de datos leveldb de Google.

¿Qué almacenamos en la capa de almacenamiento?

En primer lugar, tenemos que ver qué cosas necesitamos almacenar para que el sistema blockchain funcione. Tomemos un ejemplo simple de Alice dándole a Bob 10$.

image

Como podemos ver aquí, podemos cambiar el estado ejecutando una transacción en él.

Aquí tenemos que realizar un seguimiento de los saldos y otros detalles de diferentes personas ( estados ) y los detalles de lo que sucede entre ellos en blockchain ( transacciones ). Diferentes plataformas manejan esto de manera diferente. Aquí veremos cómo Bitcoin y Ethereum manejan esto.

Bitcoin

El "estado" de Bitcoin está representado por su colección global de Salidas de transacciones no gastadas (UTXO). La transferencia de valor en bitcoin se realiza a través de transacciones. Más específicamente, un usuario de bitcoin puede gastar uno o más de sus UTXO creando una transacción y agregando uno o más de sus UTXO como entrada de la transacción.

Este modelo de UTXO hace que Bitcoin sea diferente de Ethereum. Veamos algunos ejemplos para entender la diferencia.

En primer lugar, los UTXO de bitcoin no se pueden gastar parcialmente. Si un usuario de bitcoin gasta 0,5 bitcoin (usando su único UTXO que vale 1 bitcoin) tiene que autodireccionarse deliberadamente (enviarse a sí mismo) 0,5 bitcoin a cambio de cambio. Si no se envían a sí mismos el cambio, perderán el cambio de 0,5 bitcoins para el minero de bitcoins que extrae su transacción.

image

transacción UTXO

En segundo lugar, en el nivel más fundamental, bitcoin no mantiene los saldos de las cuentas de los usuarios. Con bitcoin, un usuario simplemente tiene las claves privadas de uno o más UTXO en un momento dado. Las billeteras digitales hacen que parezca que la cadena de bloques de bitcoin almacena y organiza automáticamente los saldos de las cuentas de los usuarios, etc. Este no es el caso.

image

Una visualización de cómo funcionan las billeteras en bitcoin

El sistema UTXO en bitcoin funciona bien, en parte, debido al hecho de que las billeteras digitales pueden facilitar la mayoría de las tareas asociadas con las transacciones. Incluyendo pero no limitado a:

a) manejo de UTXO

b) almacenar claves

c) establecer tarifas de transacción

d) proporcionar direcciones de cambio de devolución

e) agregación de UTXO (para mostrar los saldos disponibles, pendientes y totales)

Una analogía para las transacciones en el modelo UTXO son las facturas en papel (billetes de banco). Cada cuenta realiza un seguimiento de cuánto dinero tiene al sumar el número de billetes (UTXO) en el monedero (asociado con esta dirección/billetera). Cuando queremos gastar dinero, usamos uno o más billetes (UTXO existentes), lo suficiente para cubrir el costo y tal vez recibir algún cambio (UTXO nuevo). Cada factura solo se puede gastar una vez ya que, una vez gastada, la UTXO se elimina del fondo común.

Para resumir, sabemos que:

  • la cadena de bloques de bitcoin no tiene saldos de cuenta
  • Las billeteras de bitcoin tienen claves para UTXO
  • si se incluye en una transacción, se gasta un UTXO completo (en algunos casos, se recibe parcialmente como "cambio" en forma de un UTXO nuevo)

Etéreo

A diferencia de la información anterior, el estado mundial de Ethereum puede administrar los saldos de las cuentas y más. El estado de Ethereum no es un concepto abstracto. Es parte del protocolo de capa base de Ethereum. Como menciona el documento amarillo, Ethereum es una máquina de "estado" basada en transacciones; una tecnología sobre la cual se pueden construir todos los conceptos de máquinas de estado basadas en transacciones.

Empecemos desde el principio. Al igual que con todas las demás cadenas de bloques, la cadena de bloques de Ethereum comienza su vida en su propio bloque de génesis. Desde este punto (estado de génesis en el bloque 0) en adelante, actividades como transacciones, contratos y minería cambiarán continuamente el estado de la cadena de bloques de Ethereum. En Ethereum, un ejemplo de esto sería un saldo de cuenta (almacenado en el estado trie) que cambia cada vez que se realiza una transacción, en relación con esa cuenta.

Es importante destacar que los datos, como los saldos de las cuentas, no se almacenan directamente en los bloques de la cadena de bloques de Ethereum. Solo los hashes del nodo raíz de la transacción trie, state trie y recibos trie se almacenan directamente en la cadena de bloques. Esto se ilustra en el siguiente diagrama.

image

Fuente

También notará, en el diagrama anterior, que el hash del nodo raíz del trie de almacenamiento (donde se guardan todos los datos del contrato inteligente) en realidad apunta al trie de estado, que a su vez apunta a la cadena de bloques. Nos acercaremos y cubriremos todo esto con más detalle pronto.

Hay dos tipos de datos muy diferentes en Ethereum; datos permanentes y datos efímeros. Un ejemplo de datos permanentes sería una transacción. Una vez que una transacción ha sido completamente confirmada, se registra en el registro de transacciones; nunca se altera. Un ejemplo de datos efímeros sería el saldo de una dirección de cuenta de Ethereum en particular. El saldo de una dirección de cuenta se almacena en el estado trie y se modifica cada vez que se producen transacciones contra esa cuenta en particular. Tiene sentido que los datos permanentes, como las transacciones extraídas, y los datos efímeros, como los saldos de las cuentas, se almacenen por separado. Ethereum utiliza estructuras de datos trie para administrar datos.

El mantenimiento de registros de Ethereum es como el de un banco. Una analogía es usar una tarjeta de cajero automático/débito. El banco rastrea cuánto dinero tiene cada tarjeta de débito, y cuando necesitamos gastar dinero, el banco verifica su registro para asegurarse de que tengamos suficiente saldo antes de aprobar la transacción.

Una comparación entre UTXO y el enfoque de cuenta

Los beneficios del Modelo UTXO:

  • Escalabilidad : dado que es posible procesar múltiples UTXO al mismo tiempo, permite transacciones paralelas y fomenta la innovación en escalabilidad.
  • Privacidad : incluso Bitcoin no es un sistema completamente anónimo, pero UTXO brinda un mayor nivel de privacidad, siempre que los usuarios usen nuevas direcciones para cada transacción. Si existe la necesidad de mejorar la privacidad, se pueden considerar esquemas más complejos, como las firmas de anillo.

Los beneficios del Modelo de Cuenta/Saldo:

  • Simplicidad : Ethereum optó por un modelo más intuitivo en beneficio de los desarrolladores de contratos inteligentes complejos, especialmente aquellos que requieren información estatal o involucran a varias partes. Un ejemplo es un contrato inteligente que realiza un seguimiento de los estados para realizar diferentes tareas en función de ellos. El modelo apátrida de UTXO obligaría a que las transacciones incluyan información estatal, y esto complica innecesariamente el diseño de los contratos.
  • Eficiencia : además de la simplicidad, el modelo de cuenta/saldo es más eficiente, ya que cada transacción solo necesita validar que la cuenta de envío tiene saldo suficiente para pagar la transacción.

Un inconveniente del modelo de cuenta/saldo es la exposición a ataques de doble gasto. Se puede implementar un nonce incremental para contrarrestar este tipo de ataque. En Ethereum, cada cuenta tiene un nonce visible al público y cada vez que se realiza una transacción, el nonce aumenta en uno. Esto puede evitar que la misma transacción se envíe más de una vez. (Tenga en cuenta que este nonce es diferente del nonce de prueba de trabajo de Ethereum, que es un valor aleatorio).

Como la mayoría de las cosas en la arquitectura de computadoras, ambos modelos tienen ventajas y desventajas. Algunas cadenas de bloques, en particular Hyperledger, adoptan UTXO porque pueden beneficiarse de la innovación derivada de la cadena de bloques de Bitcoin. Analizaremos más tecnologías que se basan en estos dos modelos de mantenimiento de registros.

Una mirada más cercana a la estructura trie en Ethereum

Veamos los intentos de estado, almacenamiento y transacción con un poco más de profundidad.

State trie: el único

Hay una, y solo una, prueba de estado global en Ethereum.

Este trie de estado global se actualiza constantemente.

El estado trie contiene un par de clave y valor para cada cuenta que existe en la red Ethereum.

La "clave" es un identificador único de 160 bits (la dirección de una cuenta de Ethereum).

El "valor" en el trie de estado global se crea codificando los siguientes detalles de cuenta de una cuenta de Ethereum (usando el método de codificación de prefijo de longitud recursiva (RLP)):- nonce- balance- storageRoot- codeHash

El nodo raíz del estado trie (un hash de todo el estado trie en un momento dado) se usa como un identificador seguro y único para el estado trie; el nodo raíz del estado trie depende criptográficamente de todos los datos internos del estado trie.

image

Relación entre State Trie (implementación leveldb de Merkle Patricia Trie) y un bloque Ethereum ( Fuente )

image

State Trie: hash Keccak de 256 bits del nodo raíz de state trie almacenado como el valor "stateRoot" en un bloque dado. stateRoot: '0x8c77785e3e9171715dd34117b047dffe44575c32ede59bde39fbf5dc074f2976' ( Fuente )

Prueba de almacenamiento: donde residen los datos del contrato

Una prueba de almacenamiento es donde residen todos los datos del contrato. Cada cuenta de Ethereum tiene su propia prueba de almacenamiento. Un hash de 256 bits del nodo raíz del trie de almacenamiento se almacena como el valor de storageRoot en el trie de estado global (que acabamos de analizar).

image

Fuente

Prueba de transacción: una por bloque

Cada bloque de Ethereum tiene su propia prueba de transacción separada. Un bloque contiene muchas transacciones. El orden de las transacciones en un bloque, por supuesto, lo decide el minero que ensambla el bloque. La ruta a una transacción específica en el trie de transacción es a través de (la codificación RLP de) el índice de dónde se encuentra la transacción en el bloque. Los bloques extraídos nunca se actualizan; la posición de la transacción en un bloque nunca cambia. Esto significa que una vez que localiza una transacción en la prueba de transacción de un bloque, puede volver a la misma ruta una y otra vez para recuperar el mismo resultado.

image

Fuente

Ejemplos concretos de intentos en Ethereum

Los principales clientes de Ethereum utilizan dos soluciones de software de base de datos diferentes para almacenar sus intentos. El cliente Rust de Ethereum, Parity, usa rocksdb. Mientras que los clientes Go, C++ y Python de Ethereum usan leveldb.

Ethereum y rocksdb

Rocksdb está fuera del alcance de esta publicación. Es posible que esto se cubra en una fecha posterior, pero por ahora, exploremos cómo 3 de los 4 principales clientes de Ethereum utilizan leveldb.

Ethereum y leveldb

LevelDB es una biblioteca de almacenamiento de clave-valor de código abierto de Google que proporciona, entre otras cosas, iteraciones hacia adelante y hacia atrás sobre datos, asignación ordenada de claves de cadena a valores de cadena, funciones de comparación personalizadas y compresión automática. Los datos se comprimen automáticamente utilizando "Snappy", una biblioteca de compresión/descompresión de código abierto de Google. Si bien Snappy no apunta a la máxima compresión, apunta a velocidades muy altas. Leveldb es un importante mecanismo de almacenamiento y recuperación que gestiona el estado de la red Ethereum. Como tal, leveldb es una dependencia para los clientes (nodos) de Ethereum más populares, como go-ethereum, cpp-ethereum y pyethereum.

Si bien la implementación de la estructura de datos trie se puede realizar en el disco (utilizando un software de base de datos como leveldb), es importante tener en cuenta que existe una diferencia entre atravesar un trie y simplemente mirar la base de datos plana de clave/valor.

Para obtener más información, tenemos que acceder a los datos en leveldb usando las bibliotecas Patricia trie apropiadas. Para ello necesitaremos una instalación de Ethereum.

Aquí hay un tutorial fácil de seguir para configurar su propia red privada de Ethereum.

Cómo: crear su propia cadena de bloques de Ethereum privada _Aspectos destacados de desarrollo de esta semana_medium.com

Una vez que haya configurado su red privada de Ethereum, podrá ejecutar transacciones y explorar cómo responde el "estado" de Ethereum a las actividades de la red, como transacciones, contratos y minería. Si no está en condiciones de instalar una red privada de Ethereum, está bien. Proporcionaremos nuestros ejemplos de código y capturas de pantalla de nuestra red privada Ethereum.

Analizando la base de datos de Ethereum

Como mencionamos anteriormente, hay muchos Merkle Patricia Tries (referenciados en cada bloque) dentro de la cadena de bloques de Ethereum:

  • Estado Trie
  • prueba de almacenamiento
  • Prueba de transacciones
  • Recibos Trie

Las siguientes secciones asumen que ha instalado y configurado su propia red privada de Ethereum , o que está feliz de simplemente seguirnos mientras ejecutamos algún software y hablamos con la base de datos leveldb de Ethereum.

Para hacer referencia a un Merkle Patricia Trie en particular en un bloque en particular, necesitamos obtener su hash raíz, como referencia. Los siguientes comandos nos permiten obtener los hashes raíz de los intentos de estado, transacción y recepción en el bloque génesis.

image

image

Nota: si desea los hash raíz del último bloque (en lugar del bloque de génesis), utilice el siguiente comando.

image

Instalación de npm, nodo, nivel y ethereumjs

Usaremos una combinación de nodejs, level y ethereumjs (que implementa la VM de Ethereum en Javascript) para inspeccionar la base de datos leveldb. Los siguientes comandos prepararán aún más nuestro entorno.

image

Desde este punto, ejecutar el siguiente código imprimirá una lista de las claves de la cuenta de Ethereum (que se almacenan en la raíz del estado de su red privada de Ethereum). El código se conecta a la base de datos leveldb de Ethereum, ingresa al estado mundial de Ethereum (usando un valor stateRoot de un bloque en la cadena de bloques) y luego accede a las claves de todas las cuentas en la red privada de Ethereum.

image

image

Salida para el código anterior

Curiosamente, las cuentas en Ethereum solo se agregan al estado una vez que se ha realizado una transacción (en relación con esa cuenta específica). Por ejemplo, la simple creación de una nueva cuenta usando "obtener cuenta nueva" no incluirá esa cuenta en el estado trie; incluso después de que se hayan minado muchos bloques. Sin embargo, si una transacción exitosa (una que cuesta gasolina y está incluida en un bloque minado) se registra contra esa cuenta, entonces y solo entonces esa cuenta aparecerá en el estado trie. Esta es una lógica inteligente que protege contra atacantes maliciosos que crean continuamente nuevas cuentas e inflan el estado.

Decodificando los datos

Habrá notado que consultar leveldb devuelve resultados codificados. Esto se debe al hecho de que Ethereum utiliza su propia implementación especial "Merkle Patricia Trie modificada" cuando interactúa con leveldb. Ethereum Wiki proporciona información en relación con el diseño y la implementación de la codificación de prefijo de longitud recursiva (RLP) y Merkle Patricia Trie modificada de Ethereum. En resumen, Ethereum se ha extendido en las estructuras de datos trie. Por ejemplo, el Merkle Patricia modificado contiene un método que puede acortar el descenso (hacia abajo del trie) mediante el uso de un nodo de "extensión".

En Ethereum, un solo nodo trie modificado de Merkle Patricia es:

  • una cadena vacía (denominada NULL)
  • una matriz que contiene 17 elementos (referida como una rama)
  • una matriz que contiene 2 elementos (referidos como una hoja)
  • una matriz que contiene 2 elementos (referidos como una extensión)

Como los intentos de Ethereum están diseñados y construidos con reglas rígidas, la mejor manera de inspeccionarlos es mediante el uso de código informático. El siguiente ejemplo usa ethereumjs. Los repositorios de ethereumjs son fáciles de instalar y usar; serán perfectos para que podamos ver rápidamente la base de datos leveldb de Ethereum.

El siguiente código (cuando se proporciona con el stateRoot de un bloque en particular, así como con una dirección de cuenta de Ethereum) devolverá el saldo correcto de esa cuenta en una forma legible por humanos.

image

Salida del siguiente código (saldo de cuenta para la dirección 0xccc6b46fa5606826ce8c18fece6f519064e6130b)

image

Conclusión

Hemos demostrado anteriormente que Ethereum tiene la capacidad de administrar su "estado". Este ingenioso diseño inicial tiene muchas ventajas.

Movilidad

Dado que los dispositivos móviles y los dispositivos de Internet de las cosas (IoT) ahora son omnipresentes, el futuro del comercio electrónico depende de aplicaciones móviles seguras, robustas y rápidas.

image

A medida que reconocemos los avances en movilidad, también reconocemos que el aumento constante del tamaño de la cadena de bloques es inevitable. No es factible almacenar cadenas de bloques completas en dispositivos móviles cotidianos.

Velocidad, sin comprometer la seguridad

El diseño del estado mundial de Ethereum y su uso del Merkle Patricia Trie modificado brinda muchas oportunidades en este espacio. Cada función (poner, actualizar y eliminar) realizada en un intento en Ethereum utiliza un hash criptográfico determinista. Además, el hash criptográfico único del nodo raíz de un trie se puede utilizar como evidencia de que el trie no ha sido alterado.

Por ejemplo, cualquier cambio en los datos de un trie, en cualquier nivel (como aumentar el saldo de una cuenta en la base de datos leveldb) cambiará por completo el hash raíz. Esta característica criptográfica brinda una oportunidad para que los clientes ligeros (dispositivos que no almacenan la cadena de bloques completa) consulten la cadena de bloques de manera rápida y confiable, es decir, ¿la cuenta "0x... 4857" tiene fondos suficientes para completar esta compra a la altura del bloque "5044866"?

“La complejidad del tamaño de una prueba de Merkle es logarítmica en la cantidad de datos almacenados. Esto significa que, incluso si todo el árbol de estado tiene un tamaño de unos pocos gigabytes, si un nodo recibe una raíz de estado de una fuente confiable, ese nodo tiene la capacidad de saber con total certeza la validez de cualquier información con el árbol con solo descargar un pocos kilobytes de datos en una prueba.”

Límites de gasto

Una idea interesante, mencionada en el libro blanco de Ethereum, es la noción de una cuenta de ahorros. En este escenario, dos usuarios (quizás un esposo y una esposa, o socios comerciales) pueden retirar cada uno el 1% del saldo total de la cuenta por día. Esta idea solo se menciona en la sección "más aplicaciones" del documento técnico, pero despierta interés por el hecho de que, en teoría, podría implementarse como parte de la capa de protocolo base de Ethereum (en lugar de tener que escribirse como parte de una solución de segunda capa o billetera de terceros). Puede recordar nuestra discusión sobre los UTXO de bitcoin al comienzo de este artículo. Los UTXO son ciegos a los datos de la cadena de bloques y, como comentamos, la cadena de bloques de bitcoin en realidad no almacena el saldo de la cuenta de un usuario. Por esta razón, es mucho menos probable (o quizás incapaz) que la capa de protocolo base de bitcoin implemente algún tipo de límite de gasto diario.

Confianza del consumidor

A medida que continúe el trabajo en este espacio, veremos mucho desarrollo en los clientes ligeros. Más específicamente, aplicaciones móviles seguras, robustas y rápidas, que pueden interactuar con tecnologías blockchain.

image

Una implementación exitosa de blockchain en el espacio de comercio electrónico debe reforzar la velocidad, la seguridad y la facilidad de uso. Siempre es posible mejorar la confianza del consumidor, así como aumentar la adopción generalizada al proporcionar una usabilidad, seguridad y rendimiento superiores a través de un diseño inteligente.

Gracias a Timothy McCallum por su maravillosa explicación sobre los estados en Ethereum .

Gracias por leer ;)

¿Aprendiste algo? Mantenga presionado el 👏 para decir "¡gracias!" y ayudar a otros a encontrar este artículo.

¡Mantén presionado el botón de aplaudir si te gustó el contenido! Me ayuda a ganar exposición.

¿Querer aprender más? Echa un vistazo a mis artículos anteriores.

HackPedia: 16 Solidity Hacks/Vulnerabilidades, sus arreglos y ejemplos del mundo real _Una lista completa de todos los Solidity Hacks/Vulnerabilidades, sus arreglos y ejemplos del mundo real_hackernoon.com

ConsensusPedia: una enciclopedia de 30 algoritmos de consenso _Una lista completa de todos los algoritmos de consenso._hackernoon.com

ContractPedia: una enciclopedia de 40 plataformas de contratos inteligentes _Una lista completa de todas las plataformas compatibles con contratos inteligentes_hackernoon.com

Diferencia entre SideChains y State Channels _Una comparación completa de los dos métodos de escalado._hackernoon.com

Aplaude 50 veces y sígueme en Twitter : @vasa_develop

Vaibhav Saini HackerNoon profile picture
by Vaibhav Saini @vasa.Entrepreneur | Co-founder @tbc_inc, an MIT CIC incubated startup | Speaker |https://vaibhavsaini.com
Invite me as a Speaker

HISTORIAS RELACIONADAS

L O A D I N G
. . . comments & more!
Hackernoon hq - po box 2206, edwards, colorado 81632, usa