Artículo del Blog
Cuando Dos Se Convierten en Uno: Una Introducción a Nuestra Nueva Estructura de Datos, BucketListDB
Autor
Veronica Irwin
Fecha de publicación
Bucketlistdb
Datos
El tamaño de la red Stellar está creciendo. Mientras que en 2018 la red Stellar alojaba solo 2.6 millones de entradas de ledger, el año pasado alojó 43.4 millones. Para finales de 2023, esperamos ver más de 300 millones alojados en el ledger.
Si estás en el ecosistema de Stellar, ya sabes esto. De hecho, probablemente te interese Stellar no por lo que nuestra blockchain puede hacer, sino por lo que ya hace. Stellar tiene un historial probado de funcionalidad, y cada día más personas la utilizan.
Pero pronto la red crecerá demasiado para la casa en la que creció. Mientras que la base de datos de Stellar, actualmente implementada por un almacén de valores clave primario y una estructura Merkle secundaria, es suficiente hoy, no puede escalar con el resto de la red. La situación solo se volverá más crítica con el próximo lanzamiento en la red principal de Soroban, lo que aumentará tanto el tamaño de los ledgers como la cantidad de ellos que necesita ser almacenada.
Stellar no puede continuar con un sistema tan tedioso. Por eso Stellar utilizará un nuevo mecanismo de almacenamiento único en su tipo que usará solo una estructura de datos, en lugar de dos.
Se llama BucketListDB, y fue anunciado por primera vez en nuestra conferencia anual Meridian en Roma el año pasado. Mira una presentación sobre ello del ingeniero de SDF Garand Tyson aquí:
Las Bases de Datos que Conoces y Amas
Si alguna vez has trabajado con una base de datos blockchain antes, lo más probable es que tuviera dos estructuras de datos: una “estructura Merkle”, que produce hashes, y un almacén de valores clave para buscar entradas. Mientras que las estructuras Merkle producen hashes rápidamente, no son muy buenas buscando entradas. Los almacenes de valores clave, por otro lado, no pueden producir hashes pero ofrecen búsquedas rápidas. Esto significa mantener una copia de todo el ledger en dos lugares en disco, uno en un almacén de valores clave y otro en una estructura Merkle.
Árboles Merkle
Los árboles Merkle son, de lejos, la estructura Merkle más común utilizada en blockchains hoy en día, pero hay un pero: los árboles Merkle, con todos sus beneficios, son realmente lentos al añadir y modificar entradas de ledger. Es decir, no pueden ser más rápidos que 200 TPS, según expertos. Como organización enfocada en casos de uso prácticos que resuelven problemas del mundo real, creemos que Stellar necesita poder procesar muchas más transacciones, mucho más rápido que eso. La ayuda humanitaria no puede ser distribuida a 200 TPS, ni un alto volumen de remesas internacionales, ni la mayoría de otros movimientos críticos de dinero en el mundo real.
Stellar no utiliza árboles Merkle, sino una estructura Merkle diferente para crear hashes llamada Lista de Cubos. Los validadores revisan la Lista de Cubos para comparar hashes con otros validadores y si los hashes de algún validador no coinciden, pueden descargar los archivos faltantes de un par. Al diseñar Stellar, preferimos Listas de Cubos a árboles Merkle en parte porque están estructuradas temporalmente y registran cambios en las entradas en lugar de almacenar las entradas mismas. Esto significa que si un nodo se desincroniza, puede ponerse al día revisando solo las pocas horas que estuvo fuera de línea, comparando sus registros con los nodos vecinos para ver qué está desactualizado.
Además, mientras que podría tomarle a un árbol Merkle cientos de operaciones de disco para actualizar una sola entrada, actualizar una entrada en la Lista de Cubos es enteramente en memoria y no requiere ninguna operación de disco. Esto es más eficiente que un árbol Merkle, que contiene muchos hashes interconectados que todos deben ser actualizados al mismo tiempo.
Almacenes de valores clave
Además de usar la Lista de Cubos para hashing, Stellar ha utilizado históricamente un almacén de valores clave SQL para buscar entradas de ledger. Ha funcionado hasta ahora, pero podría ser más eficiente, porque no está perfectamente adaptado a los patrones de lectura/escritura en disco de Stellar. Por un lado, para obtener un cambio registrado en la Lista de Cubos copiado a SQL, Stellar tiene que realizar una cantidad excesiva de operaciones de escritura en disco.
Las versiones de SQL que Stellar admite también son compatibles con ACID, lo que impide que las operaciones de lectura interfieran con las escrituras. Esto es innecesario para Stellar porque ya ejecuta operaciones de lectura y escritura en momentos diferentes durante el consenso, y por lo tanto no corre el riesgo de realizar operaciones de lectura y escritura en conflicto simultáneamente. En otras palabras, la compatibilidad con ACID crea una sobrecarga innecesaria que ralentiza nuestras operaciones sin una buena razón.
Combinadas, estas dos estructuras de datos crean una ineficiencia más: porque todas las entradas de ledger están duplicadas de manera redundante en el disco, una vez en la Lista de Cubos y una vez en el almacén de valores clave SQL, Stellar utiliza el doble del espacio en disco necesario. Mientras que las bases de datos SQL funcionan bien para aplicaciones centralizadas tradicionales, no son muy rápidas cuando se trata de los patrones de acceso de blockchains descentralizadas.
Velocidad y Almacenamiento
Queremos que Stellar valide transacciones más rápido. Así que en lugar de tener dos estructuras de datos, Stellar las combinará en una que es tanto más eficiente en búsqueda como en hashing que lo que usaba antes: una Lista de Cubos buscable llamada BucketListDB.
En una Lista de Cubos, el hilo principal escribe entradas en el cubo superior que vive enteramente en memoria. Cuando el nivel se llena, se derrama en el siguiente nivel y se fusiona con ese cubo más grande:
Sin embargo, las Listas de Cubos son difíciles de leer. Para encontrar en qué nivel se encuentra una entrada, los validadores tendrían que buscar a través de cada nivel. Incluso si la Lista de Cubos supiera en qué nivel se encuentra una entrada, los validadores aún tendrían que buscar a través del nivel en sí, y podría ser de varios gigabytes de tamaño.
Para solucionar este problema y hacer que la Lista de Cubos sea un almacén de valores clave más eficiente, BucketListDB agrega dos tipos de índices: un filtro de bloom y un índice de cubo. Un filtro de bloom, que es un tipo de conjunto ligero y de baja memoria, nos ayuda a identificar en qué nivel se encuentra una entrada. Una vez que el filtro de bloom sabe en qué nivel está la entrada, BucketListDB utiliza el índice de cubo para encontrar dónde está nuestra entrada dentro del nivel.
Suena complejo, pero el resultado es simple: cuanto mayor es el índice, más rápidas serán las lecturas. Para no usar demasiada memoria, configura los requisitos de memoria según sea necesario, configurándolo a los mismos requisitos que postgresql es probablemente óptimo.
Bajo el Capó: Cómo Usarlo
En resumen, BucketListDB ofrece algunas mejoras claras en comparación con el sistema de Lista de Cubos y almacén de valores clave SQL que Stellar ha estado utilizando. El uso de disco disminuye en más del 45%, las velocidades de lectura aumentan 400%, y el tiempo de inicio del validador se reduce a la mitad.
Si estás operando una instancia de horizon con captive-core, BucketListDB ya está activado. Pero si estás ejecutando un nodo validador, verás BucketListDB oculto detrás de una bandera experimental.
Adelante, actívalo si quieres acostumbrarte a él con anticipación. Se activará para todos los nodos en la red Stellar con una actualización próxima, y nos encantaría recibir tus comentarios mientras tanto.