No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

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 鈥渄esechada鈥, 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 鈥渧isto鈥 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 鈥渄esechada鈥, 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 鈥渂la 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