Introduciendo Archivo de Estado: La Solución al Bloat Estatal en Stellar

Este artículo es parte de una serie de análisis profundo sobre el problema del bloat de estado en la industria, el cual debe ser resuelto para que las blockchains permanezcan económicas, ofrezcan un alto TPS y escalen a más usuarios. Este artículo ofrecerá una visión general de alto nivel sobre la solución de Stellar al bloat de estado: Archivo de Estado. Los siguientes artículos discutirán la optimización del rendimiento, características de seguridad y compararán el Archivo de Estado con propuestas alternativas de escalado.

Cuando se trata de la escalabilidad de blockchain, el bloat de estado es la mayor pregunta abierta de la industria. En cada blockchain pública, como Stellar, Ethereum, etc., cualquiera puede enviar una transacción para su ejecución, siempre y cuando pague una tarifa por los recursos que la transacción consume. Estas tarifas permiten a las redes de blockchain asignar de manera justa recursos limitados de manera descentralizada, mientras aún están protegidas de ataques de denegación de servicio (DOS) y spam. Sin embargo, cuando se trata de almacenamiento, las tarifas de blockchain están fundamentalmente rotas.

El estado en blockchain se refiere a la instantánea actual de todos los datos registrados en el libro mayor. El bloat de estado, o bloat del libro mayor, se refiere al crecimiento continuo del estado de la blockchain a medida que se almacenan información de cuentas, activos, contratos inteligentes y datos asociados. Considera una transacción que acuña un nuevo NFT. El remitente de esta transacción paga una tarifa única por los recursos de almacenamiento consumidos cuando la transacción escribe la imagen del NFT en la blockchain.

El problema es que cada validador en la red tendrá que almacenar este NFT permanentemente, incluso si el NFT nunca se transfiere o usa después de su creación inicial. Este es el problema del "bloat de estado", donde el bloat de estado se refiere a todos los datos en una blockchain que no se están utilizando, pero que aún deben ser almacenados en las bases de datos de los validadores. El problema se agrava aún más cuando consideras que los validadores deben almacenar este estado en estructuras de datos que permitan un hash rápido, como los árboles Merkle. Aunque no todas las blockchains usan árboles Merkle (Stellar usa una estructura optimizada para escritura llamada BucketList), son la estructura de hash rápido más común, y todas las estructuras de hash rápido comparten problemas similares en cuanto a caché y rendimiento de escritura.

En particular, para los árboles Merkle, actualizar cualquier entrada requiere un número arbitrario de lecturas y escrituras aleatorias. Debido a que el hash Merkle raíz debe incluirse en la blockchain, los validadores deben bloquear estas operaciones de actualización costosas y no pueden pasar al siguiente bloque y comenzar a procesar nuevas transacciones hasta que el árbol Merkle haya terminado de actualizarse. Incluso si un viejo dato no fue utilizado por ninguna transacción en un bloque, si el hash del dato es similar al hash de una nueva entrada que fue actualizada por una transacción, el dato antiguo debe ser leído para actualizar el árbol Merkle. Aunque algunas estructuras optimizadas para escritura, como la BucketList, no tienen que bloquearse en las escrituras como los árboles Merkle, aún deben releer y reescribir el estado del libro mayor arbitrario, incluso si los datos no están siendo utilizados activamente por transacciones.

Esto significa que un meme NFT acuñado en 2015 podría tener que ser leído para procesar una transacción completamente no relacionada en 2024. El resultado es que las técnicas tradicionales de caché no son aplicables, ya que cualquier hash de entrada aleatoria en el libro mayor puede tener que ser leído para procesar cualquier transacción aleatoria. Según un estudio de la Fundación Ethereum, una vez que el estado de la blockchain alcanza un tamaño significativo, la red está limitada a 214 TPS con un SSD SATA, o alrededor de 2400 TPS con la unidad PCIe NVMe más nueva y más cara. Por supuesto, algunas redes pueden superar estas limitaciones almacenando grandes partes del estado del libro mayor en memoria, pero esto hace que la operación del validador sea muy costosa, especialmente ya que el estado de la blockchain ha crecido exponencialmente a lo largo de los años. Para comparar, los validadores de Solana actualmente requieren al menos 256 GB de RAM, en comparación con solo 16 GB para un validador de Stellar.

Si una red quiere permanecer económica, ofrecer un alto TPS y escalar a más usuarios, el bloat de estado no puede continuar. El problema fundamental es que una tarifa de almacenamiento de transacción única incurre en un costo recurrente en la red para mantener este almacenamiento, lo que lleva a mayores costos operativos de los validadores, así como a una reducción del rendimiento de la red.Introduzca el protocolo de Archivo de Estado en Stellar. Con el Archivo de Estado,

• Cada pieza de estado en el libro mayor tiene un saldo de renta asociado.
• Cuando el saldo de renta llega a 0, la entrada es “archivada” y eliminada del libro mayor.
• Las entradas archivadas no pueden ser utilizadas por ninguna transacción.
• Las entradas archivadas siempre pueden ser “restauradas” y agregadas de nuevo al libro mayor.

Stellar implementó una interfaz de Archivo de Estado en la interfaz de mainnet a principios de este año, y si estás interesado en aprender más sobre la interfaz de usuario, consulta la documentación aquí. Aunque la interfaz está disponible en mainnet, las entradas archivadas aún no se eliminan de los validadores. Este blog proporcionará un resumen de alto nivel sobre cómo funciona el protocolo completo de Archivo de Estado. Específicamente, se discutirá el diseño y cómo

• Incluso después de ser eliminadas de los validadores, las entradas archivadas están aseguradas por la blockchain
• La restauración de entradas archivadas es sin confianza y descentralizada sin una autoridad central
• El Archivo de Estado es seguro y mantiene la inmutabilidad de la blockchain
• El Archivo de Estado reduce significativamente los costos de la red mientras aumenta el rendimiento de la red

Cada validador mantiene localmente dos bases de datos en disco, el estado del libro mayor en vivo y un árbol Merkle construido perezosamente que contiene entradas archivadas recientemente, llamado el “Archivo Caliente”. Siempre que una entrada se queda sin renta y es archivada, los validadores mueven la entrada de la base de datos de estado en vivo al Archivo Caliente. Eventualmente, el Archivo Caliente se llenará después de que se alcance algún límite de capacidad. Cuando el Archivo Caliente está lleno, los validadores lo publican en los Archivos de Historia, almacenan solo la raíz Merkle del árbol y eliminan el resto de las entradas archivadas. Luego, los validadores inicializan un nuevo Archivo Caliente vacío y repiten el proceso.

Con el tiempo, el Archivo de Historia contendrá muchos árboles Merkle inmutables de entradas archivadas generadas por los validadores. Esto se llama el Árbol de Estado Archivado (AST), donde cada árbol Merkle inmutable es un subárbol indexado AST[0]...AST[n]:

Supongamos que una entrada fue archivada y está en AST[1]. Para restaurar esa entrada, se envía al red una transacción con la entrada y una prueba de inclusión al estilo Merkle para esa entrada en AST[1]. Los validadores pueden verificar que la entrada que se está restaurando no ha sido manipulada verificando la prueba de inclusión contra el hash raíz guardado para AST[1]. Si la prueba es válida, la entrada se agrega de nuevo al estado en vivo. De esta manera, los validadores aún pueden asegurar la validez y seguridad de las entradas archivadas y la inmutabilidad de la blockchain, aunque los validadores no almacenen las entradas ellos mismos.

En la red de Stellar, cada validador completo mantiene un Archivo de Historia (nota que un Validador Completo de Stellar es equivalente a un Nodo de Archivo en otros ecosistemas como Ethereum). Estos Archivos son gratuitos, auditables y verificables. Los validadores completos incluyen no solo algunos de los nombres más antiguos en blockchain, sino también instituciones financieras convencionales de confianza, como la empresa Fortune 500 Franklin Templeton. Al publicar toda la información requerida para la restauración de entradas en los Archivos de Historia, el protocolo de Stellar asegura que las entradas archivadas siempre estén disponibles de manera descentralizada.

Aunque los Archivos de Historia son el almacén canónico de entradas archivadas a nivel de protocolo, sería ineficiente y poco amigable para el usuario generar pruebas directamente de estos archivos. En su lugar, las instancias RPC mantienen copias locales para generar eficientemente pruebas durante la simulación de transacciones. Actualmente, en Stellar y muchas otras redes de blockchain, los usuarios simulan transacciones a través de RPC antes de enviarlas a la red para establecer recursos, tarifas de inclusión, etc. Cuando el Archivo de Estado completo está habilitado, los nodos RPC detectarán si una transacción dada requiere entradas archivadas durante la simulación. Para cada entrada archivada, el nodo RPC generará automáticamente y adjuntará una prueba a la transacción. Después de la simulación, el usuario podrá enviar la transacción, se desarchivarán las entradas relevantes y la transacción se ejecutará contra las entradas ahora en vivo.

Además de simular transacciones, los nodos RPC también expondrán puntos finales para consultar tanto el estado en vivo como el archivado. Esto permite a los desarrolladores abstraer la complejidad del Archivo de Estado de los usuarios finales en la mayoría de las aplicaciones.

Con RPC como el punto de entrada principal, la mayor parte de la complejidad que rodea al Archivo de Estado se abstrae tanto para los desarrolladores como para los usuarios finales. Examinemos una aplicación de billetera y veamos qué cambios deben hacerse para que la billetera sea compatible con el Archivo de Estado. Para este ejemplo, la billetera tiene dos funciones: mostrar al usuario su saldo de cuenta y enviar transacciones de pago. En un mundo previo al Archivo de Estado, la billetera funciona de la siguiente manera:

• Para mostrar el saldo:
  • Consultar el punto final RPC para el saldo actual de la clave de usuarios
  • Mostrar el saldo devuelto al usuario
• Para enviar una transacción de pago:
  • Enviar la transacción a la simulación del punto final RPC
  • Envía la transacción simulada devuelta por RPC a la red

Una vez implementado el Archivo de Estado completo, la cartera se comporta casi idénticamente desde la perspectiva del usuario y del desarrollador:

• Para mostrar el saldo:
  • Consulta el punto final de RPC para la clave de los usuarios. Especifica que se deben devolver tanto las entradas en vivo como las archivadas
  • Muestra el saldo devuelto al usuario, independientemente de si está en vivo o archivado
• Para enviar transacción de pago:
  • Envía la transacción al punto final de simulación de RPC
  • Envía la transacción simulada devuelta por RPC a la red

Como puedes ver, RPC maneja casi toda la complejidad adicional del Archivo de Estado. Para carteras simples, ni siquiera es necesario notificar al usuario que su saldo está en vivo o archivado, ya que el usuario aún puede enviar transacciones de pago rápidamente incluso si el saldo está archivado. Mientras que las carteras dirigidas a usuarios más avanzados podrían decidir mostrar estos datos, muchas dApps pueden abstraer completamente el Archivo de Estado. Aunque el flujo de desarrollador y usuario es casi idéntico, las tarifas cambiarán. Por ejemplo, hacer pagos de renta frecuentes es más barato que restaurar entradas, por lo que un usuario o implementación de cartera puede querer automatizar pagos de renta periódicos. Sin embargo, la Red Stellar tiene algunas de lastarifas más bajas de cualquier blockchain, y el Archivo de Estado asegurará que estas tarifas permanezcan bajas por años venideros.

Con el Archivo de Estado, la red Stellar sigue siendo una de las blockchains más escalables. Los validadores mantienen bases de datos muy pequeñas, lo que lleva a una ejecución de transacciones rápida y un alto rendimiento. Además, bases de datos más pequeñas significa que los nuevos nodos pueden sincronizarse rápidamente con la red y reduce el tamaño del historial del libro mayor. El resultado es una red de capa 1 más barata, rápida.

Mientras que los nodos no validadores aún necesitan almacenar el estado archivado, esto sigue siendo muy eficiente. El AST es una estructura de datos inmutable, solo de adición, lo que significa que los Archivos de Historia pueden almacenarlo en unidades de red económicas en lugar de las costosas unidades NVMe locales requeridas para validadores de alto rendimiento. Además, dado que todos los datos están asegurados por la blockchain, puede haber significativamente menos copias del estado archivado en comparación con el estado en vivo sin sacrificar seguridad o descentralización.

Dado que el AST es inmutable, también puede ser fragmentado. Esto es especialmente útil para los proveedores de RPC que pueden fragmentar el estado archivado a través de múltiples nodos y equilibrar la carga de las solicitudes entrantes en consecuencia. Dado que los nodos RPC están fuera de la cadena y no participan en el consenso, esta fragmentación es significativamente más eficiente y no tiene riesgos de seguridad en comparación con la fragmentación de validadores. El resultado final es un sistema altamente escalable y fácil de usar tanto para desarrolladores como para usuarios.

¡Pero eso es solo la punta del iceberg! Esta ha sido una introducción rápida, pero el protocolo de Archivo de Estado es complejo, especialmente cuando se trata de optimización de seguridad y rendimiento. La especificación técnica completa para la Interfaz de Archivo de Estado se puede encontrar aquí, mientras que la especificación de prueba se puede encontrar aquí. En las próximas semanas, haré un análisis profundo de características específicas de seguridad y rendimiento, así como comparaciones del Archivo de Estado en la red Stellar con soluciones menos escalables en Solana y Ethereum en futuras publicaciones de blog.