Cambios de Base de Datos Próximos en el Protocolo 21
Autor
Garand Tyson
Fecha de publicación
En el Protocolo 21, Soroban recibe su primera gran actualización con la implementación de cinco nuevos CAPs que introducen algunas características emocionantes, como soporte para firma con passkey, una mejora en el archivo de estado y mejoras en los costos para transacciones de contratos inteligentes. Además de estas nuevas características, los validadores de Stellar también están recibiendo una de las optimizaciones de rendimiento más grandes hasta la fecha: una nueva base de datos llamada BucketListDB.
Para aquellos que no lo saben, BucketListDB es una base de datos construida desde cero para la blockchain de Stellar. BucketListDB ofrece lecturas y escrituras mucho más rápidas que los actuales backends de base de datos SQL de Stellar, al mismo tiempo que requiere menos memoria y espacio en disco. Lo más emocionante es que BucketListDB también admite IO paralelo sin conflictos, lo cual será crucial para futuras actualizaciones del Protocolo que introduzcan ejecución paralela de Soroban y redes Overlay multihilo. Si tienes curiosidad sobre cómo funciona todo por debajo, revisa esta charla técnica.
BucketListDB ha sido una característica experimental en stellar-core y después de un año de pruebas rigurosas, es hora de activarla por defecto. Esto significa que a partir de la versión 21.0 de stellar-core, el modo SQL y en memoria están oficialmente siendo obsoletos. Durante este período de transición, el modo SQL y en memoria aún serán compatibles, pero pueden ver una degradación significativa del rendimiento en comparación con BucketListDB y quedarse atrás del resto de la red.
Nota que SQL no desaparecerá por completo. SQL continuará utilizándose para almacenar pequeñas cantidades de metainformación no relacionada con el libro mayor y para algunas consultas de DEX. Sin embargo, la mayoría de las consultas y la mayor parte del estado del libro mayor solo serán atendidas por BucketListDB.
Lo que los Operadores de Validadores Necesitan Hacer
La versión 21.0 de stellar-core introducirá una nueva bandera de configuración llamada DEPRECATED_SQL_LEDGER_STATE. Esta bandera reemplaza a EXPERIMENTAL_BUCKETLIST_DB. Para apoyar la migración, ambas banderas serán compatibles en la versión 21.0 de stellar-core. Sin embargo, EXPERIMENTAL_BUCKETLIST_DB será eliminada en stellar-core 21.1. EXPERIMENTAL_BUCKETLIST_DB=true es idéntico a DEPRECATED_SQL_LEDGER_STATE=false. Mientras ambas banderas sean compatibles, solo una puede usarse en el archivo de configuración.
O DEPRECATED_SQL_LEDGER_STATE o EXPERIMENTAL_BUCKETLIST_DB deben definirse o stellar-core 21.0 no podrá iniciar. Una de estas banderas debe establecerse cuando un nodo se actualice al paquete stellar-core 21.0. Una de estas banderas debe establecerse cuando se despliegue el paquete, no cuando la red actualice realmente al Protocolo 21.
La configuración predeterminada de esta bandera, y la configuración que la mayoría de los operadores de validadores deberían usar, es DEPRECATED_SQL_LEDGER_STATE=false (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=true). Si DEPRECATED_SQL_LEDGER_STATE=true (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=false), el nodo puede experimentar degradación del rendimiento y quedarse atrás del resto de la red.
DEPRECATED_SQL_LEDGER_STATE=true (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=false) solo debe establecerse en true si tú:
- Debes ejecutar stellar-core con la bandera de modo “en memoria”.
- Consultas directamente datos del backend SQL de stellar-core, y los datos consultados no son compatibles con BucketListDB (ver “Características Obsoletas” abajo).
Solo los operadores que ejecuten un nodo validador o de observación independiente necesitarán establecer esta bandera. Si captive-core está ejecutándose como parte de Horizon o RPC, la bandera se establecerá automáticamente y no se requerirá ninguna acción.
DEPRECATED_SQL_LEDGER_STATE es una nueva bandera solo compatible con stellar-core 21.0+. Esto significa que esta bandera no puede establecerse en ningún paquete stellar-core 20.x. Para evitar tiempos de inactividad al recoger el nuevo paquete, se recomienda actualizar stellar-core con los siguientes pasos:
- En la actual configuración de stellar-core 20.x, establece EXPERIMENTAL_BUCKETLIST_DB=true. Esto desencadenará una migración única al nuevo backend BucketListDB (ver Guía de Migración abajo). Esta migración lleva tiempo, por lo que se recomienda que la configuración de un solo nodo se actualice a la vez.
- Actualiza stellar-core a 21.0. Dado que el nodo ya ha migrado y EXPERIMENTAL_BUCKETLIST_DB está definido, stellar-core debería reiniciar rápidamente sin tiempo de inactividad significativo.
- Después de actualizar, cambia EXPERIMENTAL_BUCKETLIST_DB=true a DEPRECATED_SQL_LEDGER_STATE=false. Estas banderas son equivalentes, pero EXPERIMENTAL_BUCKETLIST_DB será eliminada en una futura versión.
Guía de Migración
Cuando DEPRECATED_SQL_LEDGER_STATE=false (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=true) se establece por primera vez, se realiza una migración única de SQL a BucketListDB. Esta migración ocurre automáticamente la primera vez que se ejecuta `stellar-core run` o `stellar-core upgrade-db` y requiere permiso para realizar cambios en el esquema de la DB. Esta migración implica eliminar tablas SQL y configurar índices requeridos para BucketListDB y está limitada por el disco. En unidades SSD NVME, esta migración tarda alrededor de 3 minutos. En unidades respaldadas por EBS más lentas, la migración puede tardar hasta 45 minutos. Se recomienda que los operadores actualicen y migren cada nodo individualmente.
Después de la migración única, el tiempo de inicio y de recuperación de los validadores se reduce significativamente en comparación con SQL. Después de la migración, se espera que el uso de disco de stellar-core disminuya aproximadamente un 65%. Mientras que se espera que el uso de memoria del proceso stellar-core aumente alrededor de 1 GB, hay una reducción significativa en el uso de memoria por parte del backend SQL (nota que el uso específico de memoria del backend SQL depende mucho de la configuración del operador). Se espera que BucketListDB sea estrictamente más eficiente que los backends SQL preexistentes, por lo que los requisitos de los validadores y la utilización de recursos en general no deberían aumentar.
Características Obsoletas
Cuando DEPRECATED_SQL_LEDGER_STATE=false (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=true) las siguientes tablas en la base de datos SQL de stellar-core se eliminan:
- CUENTA
- LÍNEA DE CONFIANZA
- DATOS
- SALDO RECLAMABLE
- FONDO DE LIQUIDEZ
- DATOS DEL CONTRATO
- CÓDIGO DEL CONTRATO
- CONFIGURACIÓN
- TTL
Esto incluye todas las tablas de estado del libro mayor (con la excepción de OFERTAS). Además, la columna TXMETA en la tabla TXHISTORY será eliminada.
Nota que cuando DEPRECATED_SQL_LEDGER_STATE=false (o equivalentemente EXPERIMENTAL_BUCKETLIST_DB=true), estos datos se eliminan en la primera ejecución de `stellar-core run` o `stellar-core upgrade-db`. Para recuperar esta información, será necesario establecer DEPRECATED_SQL_LEDGER_STATE=true, ejecutar `stellar-core new-db`, luego reproducir datos de transacciones. En general, aconsejamos en contra de usar stellar-core para proporcionar esta información porque consultar bases de datos centrales directamente puede causar que el nodo pierda sincronización con la red, y la mejor práctica es ejecutar una instancia de Horizon o RPC. Sin embargo, si es necesario consultar esta información por tu aplicación, se recomienda establecer DEPRECATED_SQL_LEDGER_STATE=true a corto plazo. Esta bandera será eliminada en futuras versiones y estas tablas ya no serán compatibles. Como solución a largo plazo, considera ejecutar una instancia de Horizon o RPC.
Adicionalmente, el modo en memoria está siendo obsoleto y será eliminado en una futura actualización. BucketListDB ofrece un tiempo de inicio significativamente más rápido y puede alcanzar a la red mucho más rápido que SQL, eliminando la necesidad del modo en memoria.
¿Preguntas? ¿Comentarios? Por favor, plantealos en el canal #validators de Stellar Dev Discord.