Cambios en la Base de Datos Próximos en el Protocolo 21

Autor

Garand Tyson

Fecha de publicación

En el Protocolo 21, Soroban está recibiendo su primera gran actualización con la implementación de cinco nuevos CAPs que introducen algunas características emocionantes, como el soporte de firma con llave de paso, una mejora en el archivo de estado y mejoras en el costo para transacciones de contratos inteligentes. Además de estas nuevas características, los validadores de Stellar también están obteniendo 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 proporciona lecturas y escrituras mucho más rápidas que los actuales backends de base de datos SQL de Stellar, mientras que también requiere menos memoria y espacio en disco. Lo más emocionante es que BucketListDB también admite IO paralelo sin conflictos, lo cual será clave para futuras actualizaciones del Protocolo que introduzcan la ejecución paralela de Soroban y la red Overlay multihilo. Si tienes curiosidad por saber cómo funciona todo bajo el capó, 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 descontinuados. Durante este período de transición, el modo SQL y en memoria todavía serán compatibles, pero pueden experimentar 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á siendo utilizado 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ía 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. Si esta bandera no está establecida, stellar-core no podrá iniciar. Esta bandera debe establecerse cuando un nodo se actualice al paquete stellar-core 21.0. Esta bandera debe establecerse cuando el paquete se despliegue, no cuando la red realmente se actualice 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. Si DEPRECATED_SQL_LEDGER_STATE=true, el nodo puede experimentar una degradación del rendimiento y quedarse atrás del resto de la red. DEPRECATED_SQL_LEDGER_STATE=true solo debe establecerse en verdadero si:

  1. Debe ejecutar stellar-core con la bandera de modo “en memoria”.
  2. Consulta directamente datos desde el backend SQL de stellar-core, y los datos consultados no son compatibles con BucketListDB (ver “Características obsoletas” abajo).

Solo los operadores que ejecutan 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.

Guía de Migración

Cuando DEPRECATED_SQL_LEDGER_STATE=false 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 toma 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 del validador y el tiempo de recuperación se reducen 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%. Aunque se espera que el uso de memoria del proceso de stellar-core aumente alrededor de 1 GB, hay una reducción significativa en el uso de memoria por el backend SQL (nota que el uso específico de memoria del backend SQL depende en gran medida 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 general de recursos no deberían aumentar.

Características Obsoletas

Cuando DEPRECATED_SQL_LEDGER_STATE=false las siguientes tablas en la base de datos SQL de stellar-core son eliminadas:

  • CUENTA
  • LÍNEA DE CONFIANZA
  • DATOS
  • SALDO RECLAMABLE
  • FONDO DE LIQUIDEZ
  • DATOS DE CONTRATO
  • CÓDIGO DE 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, 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 los datos de transacción. En general, aconsejamos contra el uso de 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 se requiere consultar esta información por su aplicación, se recomienda establecer DEPRECATED_SQL_LEDGER_STATE=true a corto plazo. Esta bandera se eliminará en futuras versiones y estas tablas ya no serán compatibles. Como solución a largo plazo, considere ejecutar una instancia de Horizon o RPC.

Además, el modo en memoria está siendo descontinuado y será eliminado en una actualización futura. BucketListDB proporciona 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 Stellar Dev Discord canal #validators.