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

Este artículo es parte de una serie de análisis profundo sobre el problema de la inflación del estado en la industria, que debe resolverse para que las blockchains permanezcan económicas, ofrezcan un alto TPS y escale a más usuarios. Este artículo ofrecerá una visión general de alto nivel sobre la solución de Stellar para la inflación del estado: Archivo de Estado. Las continuaciones discutirán la optimización del rendimiento, características de seguridad y compararán el Archivo de Estado con propuestas alternativas de escalabilidad.

Cuando se trata de la escalabilidad de blockchain, la inflación del 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 que las redes blockchain asignen de manera justa recursos limitados de manera descentralizada, mientras siguen estando 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. La inflación del estado, o inflación 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 de la “inflación del estado”, donde la inflación del estado se refiere a todos los datos en una blockchain que no se están utilizando, pero que aún deben almacenarse en las bases de datos de los validadores. El problema se agrava cuando se considera 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 utiliza 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 una pieza antigua de datos no fue utilizada por ninguna transacción en un bloque, si el hash de los datos es similar al hash de una nueva entrada que fue actualizada por una transacción, los datos antiguos deben leerse para actualizar el árbol Merkle. Aunque algunas estructuras optimizadas para escritura, como la BucketList, no tienen que bloquear 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 Ethereum Foundation, una vez que el estado de blockchain alcanza un tamaño significativo, la red está limitada a 214 TPS con un SSD SATA, o aproximadamente 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 blockchain ha crecido exponencialmente a lo largo de los años. Para comparación, 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, la inflación del 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 de operación del validador, así como a una reducción del rendimiento de la red.Introduce el protocolo de Archivo de Estado en Stellar. Con 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 se “archiva” y se elimina 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 principal a principios de este año, y si estás interesado en saber más sobre la interfaz de usuario, consulta la documentación aquí. Aunque la interfaz está disponible en la red principal, 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, repasará el diseño y discutirá 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 recientemente archivadas, llamado el “Archivo Caliente”. Siempre que una entrada se queda sin renta y se archiva, 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 alcanzar cierto 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 una transacción con la entrada y una prueba de inclusión al estilo Merkle para esa entrada en AST[1] a la red. Los validadores pueden verificar que la entrada restaurada 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 (nótese 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 la tienda canónica 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 pruebas de manera eficiente durante la simulación de transacciones. Actualmente, en Stellar y muchas otras redes 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, las entradas relevantes serán desarchivadas 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 de los desarrolladores como de los usuarios finales. Examinemos una aplicación de billetera y veamos qué cambios deben realizarse 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:
  • Consulta el punto final RPC para el saldo actual de la clave de usuarios
  • Muestra el saldo devuelto al usuario
• Para enviar transacción de pago:
  • Envía la transacción al punto final de simulación RPC
  • Envía la transacción simulada devuelta por RPC a la red

Una vez implementado el Archivo de Estado completo, la billetera 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 billeteras simples, ni siquiera es necesario notificar al usuario que su saldo está en vivo o archivado, ya que el usuario aún puede enviar rápidamente transacciones de pago incluso si el saldo está archivado. Mientras que las billeteras 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 billetera puede querer automatizar pagos de renta periódicos. Sin embargo, la Red Stellar tiene algunas de las tarifas más bajas de cualquier blockchain, y el Archivo de Estado asegurará que estas tarifas permanezcan bajas durante años.

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 de la historia del ledger. El resultado es una red de capa 1 más barata, rápida y económica.

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 la seguridad o la descentralización.

Debido a 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, profundizaré en características específicas de seguridad y rendimiento, así como compararé el Archivo de Estado en la red Stellar con soluciones menos escalables en Solana y Ethereum en futuras publicaciones de blog.