No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

No se trata de lo que quieres comprar, sino de quién quieres ser. Invierte en tu educación con el precio especial

Antes: $249

Currency
$209

Paga en 4 cuotas sin intereses

Paga en 4 cuotas sin intereses
Suscríbete

Termina en:

12 Días
11 Hrs
5 Min
15 Seg
Curso de Bitcoin Core y Script

Curso de Bitcoin Core y Script

Juan Sebastián Marulanda

Juan Sebastián Marulanda

Almacenamiento

5/19
Recursos

Las Blockchains son sistemas que cada día tienen más y más información que almacenar. Deben poseer importantes sistemas de persistencia de datos para guardar diversos tipos de información y asegurar que los mismos perduren en el tiempo por siempre.

Persistencia de datos en Bitcoin Core

Bitcoin Core utiliza múltiples herramientas, servicios y formatos para el guardado de información.

Archivos .dat

La información que se almacena en archivos que utilizan la extensión .dat se guardan en forma binaria o serializada y que solo el programa que lo crea puede entender, leer y utilizar. No son archivos de edición manual por parte de una persona.

En Bitcoin Core, este tipo de archivos contienen datos estructurados de diferentes tipos y los mismos se serializan o deserialización para la utilización de esta información.

Algunos de los archivos .dat más importantes son:

  • blocks/blk.dat: información serializada de los bloques.
  • blocks/rev.dat: información “desechada”, UTXO añadidas y removidas por un bloque. Estos datos ya no sirven para la cadena principal, pero puede ser útil para el desarrollador para tener una trazabilidad de las transacciones.
  • mempool.dat: lista serializada de componentes del mempool (transacciones no confirmadas).
  • peers.dat: pares serializados, información de otros nodos.
  • banlist.dat: lista de IP restringidas por el nodo por posibles detecciones de comportamiento malicioso u otros problemas.

LevelDB

LevelDB es una base de datos NoSQL clave/valor para almacenar información. Es un popular sistema para el guardado y acceso rápido a la información que es desarrollado y mantenido por Google y otras importantes bases de datos como IndexedDB lo utilizan.

Podemos encontrar la siguiente información que se guarda en LevelDB:

  • blocks/index: contiene todos los bloques que el nodo ha visto. Se habla de “visto” porque el nodo puede no estar sincronizado y que le falten bloques a su cadena.
  • chainstate: contiene un conjunto de UTXO (salidas no gastadas) para controlar la red y validar que las salidas que un usuario quiere gastar, se encuentren en este conjunto.

BarkeleyDB

BarkeleyDB es una base de datos muy similar a LevelDB pero con menor utilización. La misma se implementa para desarrollar wallets. Causa algo de controversia en la comunidad de desarrolladores de Bitcoin, dado que solo se utiliza para ambientes de desarrollo y no productivos.

Esta base de datos dejará de utilizarse aproximadamente en el 2023 y será reemplazada por SQLite.

Únicamente guarda la siguiente información:

  • wallets/wallet.dat: archivo que contiene la información de la billetera del nodo.

Estructuras de datos

Toda la información que Bitcoin Core necesita guardar, se realiza de forma ordenada por medio de estructuras predefinidas. Podemos encontrar en el código fuente las siguientes estructuras:

  • CBlockheader: contiene la información de un encabezado como la versión, el hash, y la información del árbol de Merkle.
  • CBlock: contiene la misma información que CBlockheader junto con la lista de transacciones.
  • CBlockIndex: la cadena de bloques es una estructura en forma de árbol que comienza con el bloque de génesis en la raíz, y cada bloque tiene potencialmente múltiples candidatos para ser el próximo bloque.
  • CChainstate: almacena y proporciona una API para actualizar nuestro conocimiento local de la mejor cadena actual.

Conclusión

Sin duda un sistema tan grande como lo es Bitcoin Core requiere de complejos mecanismos de almacenamiento de información y estructuras los mismos.

Has visto hasta este punto los múltiples métodos de persistencia de datos que Bitcoin Core utiliza y las estructuras de datos para darle forma y manipular la información.


Contribución creada por: Kevin Fiorentino (Platzi Contributor).

Aportes 9

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

class CBlockIndex
La cadena de bloques es una estructura en forma de árbol que comienza con el bloque de génesis en la raíz, y cada bloque tiene potencialmente múltiples candidatos para ser el próximo bloque. Un blockindex puede tener múltiples punteros apuntando hacia él, pero como máximo uno de ellos puede ser parte de la rama actualmente activa.
No estoy seguro lo he hecho mirando el código fuente y casi no se C++, ya me corregiréis si esta mal.
Saludos

Fases de estado de cadena
Chainstate dentro del sistema pasa por una serie de fases cuando las instantáneas UTXO son
utilizadas, según lo gestionado por ChainstateManager. En varios puntos puede haber múltiples
objetos CChainState` existentes para facilitar el mantenimiento de la punta de la red y realizar
la validación histórica de la cadena supuestamente válida.

RESUMEN CLASE 5:
ALMACENAMIENTO

I.- ALMACENAMIENTO

  • Bitcoin almacena alguna información en archivos .dat

    • .dat: Contiene los bytes de una estructura de datos serializada.

      • serialize.h
    • tree ~/bitcoin/testnet3

II.- ARCHIVOS .dat

  • blocks/blk.dat: Información serializada de bloques.

  • blocks/rev.dat: información “desechada”, UTXOs añadidas y removidas por un bloque.

  • mempool.dat: lista serializada de componentes del mempool.

  • peers.dat: pares serializados.

  • banlist.dat: Ips baneadas por el nodo.

III.- LEVELDB

  • Almacenamiento ordenado de tipo llave-valor.

  • Permite escrituras en volumen y snapshots.

  • Disminuye posibles bugs.

IV.- CONTENIDO LEVELDB

  • blocks/index: Contiene todos los bloques que el nodo ha visto.

  • chainstate: Conjunto de UTXO.

V.- BERKELEYDB

  • BerkeleyDB es similar a leveldb.

  • Usada principalmente para la implementación de billetera.

  • En proceso de ser reemplazada por SQLite.

  • Línea de tiempo propuesta.

VI.- CONTENIDO BERKELEYDB

  • Wallet:

    • Wallets/wallet.dat: archivo que contiene la billetera.

VII.- ESTRUCTURA DE DATOS

  • CBlockheader: Nos tiene la informacion de un encabezado la version, hash, arbol de merkle.

  • CBlock: Nos tiene la informacion de un encabezado la version, hash, arbol de merkle y la lista de transacciones.

  • CBlockIndex: Puede tener múltiples pprev apuntando hacia él, pero como máximo uno de ellos puede ser parte de la rama actualmente activa.

  • CChainstate: Almacena y proporciona una API para actualizar nuestro conocimiento local de la mejor cadena actual.

Otro curso de “bla bla bla”… Qué lástima que trajeran a este profesor robot

Llamaremos Chainstate a la base de datos de LevelDB que proporciona la capacidad de consultar el estado de las outputs de las transacciones no gastadas. La Chainstate nos permitirá determinar si existe una transacción en particular y si el valor de esta transacción no esta gastada
/blockchainlanzaroteorg.

ESTRUCTURA DE DATOS

CBlockheader: Nos tiene la informacion de un encabezado la version, hash, arbol de merkle.

CBlock: Nos tiene la informacion de un encabezado la version, hash, arbol de merkle y la lista de transacciones.

CBlockIndex: Puede tener múltiples pprev apuntando hacia él, pero como máximo uno de ellos puede ser parte de la rama actualmente activa.

CChainstate: Almacena y proporciona una API para actualizar nuestro conocimiento local de la mejor cadena actual.

Según mi punto de vista y concuerdo con el profesor, BarkeleyDB esta mandado a recoger. Que un nodo maneje también la billetera me parece muy engorroso y que tiene muy poca flexibilidad. Desde que se creo Bitcoin y tener un software que lo hace todo (crear wallets, manejar transacciones, verificarlas) esta bien. Pero para la actualidad no es nada practico tener un nodo que maneje las billeteras.
Es 2023 y todavia no se ha cambiado berkeleydb a sqllite