Escalabilidad con archivo de estado en Stellar vs. compresión de estado de Solana

Esta es la parte 2 de una serie de análisis profundo sobre el problema del bloat de estado. Parte 1 fue una visión general de alto nivel de la solución de Archivo de Estado en la red de Stellar. Este artículo se enfoca en las características de escalabilidad del Archivo de Estado y analiza la versión menos eficiente de Archivo de Estado de Solana llamada “Compresión de Estado”.

El diseño de Compresión de Estado de Solana (Avocado) tiene defectos de diseño fundamentales:

• Se espera que los nodos RPC almacenen todas las cuentas comprimidas y los datos de cuenta.
• No hay garantías protocolarias para la disponibilidad de datos de cuenta comprimidos, por lo que los datos comprimidos pueden perderse o ser censurados.
• Algunos validadores todavía necesitan almacenar todas las cuentas comprimidas.
• El volumen de transacciones aumentará y el arbitraje de validadores de spam añadirá a los problemas de congestión de Solana.

El Archivo de Estado en la red de Stellar es mucho más eficiente y escalable:

• No hay aumento en el volumen de transacciones o spam.
• Las instantáneas de validadores a través de Archivos de Historia públicos garantizan la disponibilidad de datos archivados.
• Ningún validador necesita almacenar todas las cuentas archivadas.
• Los nodos RPC pueden fragmentar el estado archivado, reduciendo costos.

El problema del bloat de estado es el elefante más grande en la sala de blockchain. Cada día, se crean millones de nuevas entradas en blockchains públicas como Stellar y Solana, y cada validador necesita almacenar todo este estado indefinidamente. Cada meme NFT, contrato de prueba hello world y token de spam necesita ser conservado para siempre, sin importar cuán a menudo se use la información, o incluso si se usa en absoluto. A medida que más usuarios y casos de uso llegan a blockchain, el problema solo crecerá, causando que las redes se vuelvan más lentas y más caras mientras intentan mantener todo este bloat.

Este no es un problema nuevo. Vitalik inició la conversación en 2021 con su esquema de “Expiración de Estado” para Ethereum y Stellar Development Foundation comenzó a diseñar una solución de “Archivo de Estado” para la red de Stellar hace dos años. Anatoly Yakovenko, co-fundador de Solana, es el último participante en unirse a la fiesta, introduciendo el proyecto de Solana “Avocado” hace unas semanas. Aunque hay muchas ideas sobre cómo resolver el bloat de estado, tanto los diseños de Vitalik como los de Anatoly tienen defectos fundamentales significativos. Por ejemplo, la propuesta de expiración de estado de Ethereum tiene un bug de doble gasto que encontré, y su solución es fundamentalmente incompatible con otros planes en la hoja de ruta de Ethereum como “Avocado” hace unas semanas. Mientras hay muchas ideas sobre cómo resolver el bloat de estado, tanto los diseños de Vitalik como los de Anatoly tienen defectos fundamentales significativos. Por ejemplo, la propuesta de expiración de estado de Ethereum tiene un bug de doble gasto que encontré, y su solución es fundamentalmente incompatible con otros planes en la hoja de ruta de Ethereum como Estado Débil y Fuerte. Hablaré más sobre Ethereum en la Parte 3 cuando me enfoque en seguridad, pero por ahora, hablemos sobre Solana y problemas de escalabilidad.

A un nivel alto, la “Compresión de Índice” de Solana y el “Archivo de Estado” en Stellar funcionan de manera similar. Cada cuenta paga renta por permanecer activa en el libro mayor. Siempre que se acaba la renta, la cuenta se archiva (Stellar) o se comprime (Solana) y cualquier transacción que toque una cuenta archivada falla. Las cuentas archivadas se eliminan de los validadores y se almacenan fuera de la cadena en árboles de Merkle. Para desarchivar y reutilizar estas cuentas, los nodos RPC generan una prueba al estilo Merkle, los validadores verifican la prueba, y la entrada se agrega de nuevo al estado activo del libro mayor.

Aunque la estrategia de alto nivel es similar, el diablo está en los detalles. Explicaré cómo Avocado introduce más problemas de los que resuelve, con baja disponibilidad de datos, disminución del rendimiento de la red y tarifas más altas. También hablaré sobre cómo todos estos problemas se resuelven con el Archivo de Estado en Stellar.

La “Compresión de Estado” de Avocado no tiene garantías de disponibilidad de datos para datos de cuenta comprimidos. Cuando los datos de la cuenta se quedan sin renta, se reemplazan con un hash que es persistido por los validadores mientras que los datos en sí se eliminan. Para restaurar (o descomprimir) estos datos, una transacción sube los datos originales que los validadores verifican contra el hash persistido.

El problema es que el protocolo de Solana solo persiste y mantiene la disponibilidad del hash, no los datos en sí. El hash no se puede revertir para obtener los datos originales, así que mientras el protocolo puede verificar que los datos son correctos, no puede realmente almacenar o generar los datos. Más bien es responsabilidad del usuario que envía la transacción venir con los datos originales. La pregunta es, ¿cómo puede un usuario realmente encontrar estos datos?

La propuesta no discute la disponibilidad de datos. A diferencia de la pieza de “Compresión de Índice” de Avocado, los datos de la cuenta no se almacenan en árboles de Merkle, y no parece haber ningún mecanismo para mantener los datos a nivel de protocolo. Supongo que esta responsabilidad se dejará a los nodos RPC (un diseño común en Solana). El problema es que los nodos RPC de Solana ya son muy caros de operar hoy (como en 512 GB de RAM caro), y esto pondrá más en su plato. Es fácil imaginar que un costo como este finalmente se pasará al usuario, haciendo la descompresión cara.

Pero aún más preocupante que el precio es que no hay garantía ni requisito de que los nodos RPC almacenen fielmente esta información. Una vez eliminada, la carga de datos de la cuenta no es requerida para el consenso, por lo que enfoques como “Prueba de Replicación” no funcionarán. No hay forma de que la red de Solana garantice que los nodos RPC realmente guarden los datos eliminados. Los proveedores de RPC pueden elegir ignorar los datos comprimidos porque es demasiado caro almacenar, o podrían seleccionar y solo almacenar datos comprimidos que sean lo suficientemente valiosos para ser rentables. Piénsalo: si el protocolo no está obligando al RPC a almacenar todos los datos, y si almacenar los datos se está volviendo cada vez más caro, el proveedor de RPC puede buscar reducir costos para obtener beneficios. Si un proveedor de RPC se enfrenta con la elección de almacenar tu NFT que pensabas que se dispararía o el saldo de USDC de una ballena, uno puede comenzar a adivinar qué datos serán priorizados.

Si te importa recuperar tus datos después de que se archiven, construye en Stellar. Mientras que los nodos RPC fuera de la cadena en Stellar almacenan el estado archivado en caché, todos los datos están respaldados por garantías a nivel de protocolo. Los validadores publican rutinariamente “Instantáneas de Archivo” que contienen no solo el hash de tus datos, sino los datos en sí. Cada validador de Nivel 1 mantiene estas instantáneas y las ofrece públicamente de forma gratuita a través de los Archivos de Historia de la Red de Stellar. ¿Y quién está almacenando estos Archivos? No solo algunos de los nombres más confiables en el espacio blockchain, sino también las finanzas tradicionales, incluyendo la empresa Fortune 500 Franklin Templeton.

En Solana, los validadores completos no sirven Instantáneas de Archivo como parte del protocolo y el estado de cuenta archivado no se almacena en un árbol de Merkle, permitiendo que los nodos RPC elijan y escojan qué estado de archivo almacenar. La red de Stellar garantiza que tus datos se replican y están disponibles en todo momento, incluso si están archivados, almacenando el estado de cuenta archivado en un árbol de Merkle que se requiere publicar rutinariamente en los Archivos de Historia en su totalidad. Estos Archivos de Historia son auditables, verificables y disponibles gratuitamente al público, garantizando la disponibilidad de datos archivados de manera descentralizada.

Solana ha tenido históricamente períodos de altas tasas de caída de transacciones, como en abril de 2024 cuando la actividad de comercio de bots causó demasiada congestión y la capa de red de Solana no pudo mantenerse al día con el volumen de transacciones. Mientras Solana pudo mejorar la situación en un parche, las blockchains están fundamentalmente limitadas por la red cuando se trata de rendimiento, y la congestión de la red continuará siendo un problema a medida que aumenta el número de usuarios, validadores y TPS. Con Avocado, la congestión solo empeorará.

Hoy en día, los usuarios (y bots) tienen que quemar tarifas para enviar transacciones. Estas tarifas ayudan a prevenir la congestión de la red, porque sin estas tarifas, los atacantes y comerciantes de bots podrían abrumar la red con spam. Las tarifas actúan como un disuasivo y hacen que tales ataques sean demasiado caros financieramente para ser prácticos.

Aún cuando se cobran tarifas por transacciones, Solana ha tenido problemas significativos de congestión, y Avocado echará más leña al fuego. Con esta propuesta, se pagado para enviar más transacciones. Permíteme decirlo de nuevo. Solana, una red que ya tiene un problema con las transacciones causando congestión significativa, está proponiendo realmente pagar a los validadores por enviar una nueva categoría de transacciones, incentivando aún más transacciones en la ya sobrecargada red.

Cuando una cuenta se queda sin renta no se elimina automáticamente como el estado de la cuenta. En su lugar, una “transacción de compresión” usa pruebas de conocimiento cero para eliminar la cuenta y añadirla a un trie binario Merkle. Este trie contiene todas las cuentas comprimidas, pero los validadores solo necesitan almacenar la raíz del trie (más o menos). Para usar una cuenta comprimida, un usuario debe enviar una transacción con una prueba de la entrada generada desde el trie completo.

Aunque “técnicamente” los validadores solo necesitan almacenar la raíz del trie para participar en el consenso, los nodos RPC necesitan almacenar el trie completo para producir pruebas. Además, los validadores pueden ganar dinero extra almacenando el trie completo y enviando transacciones de compresión, y la red depende de estos validadores para que la compresión funcione correctamente.

Esto parece ser un pobre intercambio de diseño. Solana ya tiene un problema con demasiadas transacciones cuando las transacciones cuestan dinero, y con este cambio, los validadores serán compensados por enviar transacciones adicionales, no de usuario Podrías pensar que esto no es tan malo. Después de todo, es solo una transacción comprimiendo múltiples cuentas. Habrá algunas más transacciones de las que habría de otro modo, ¡pero puedes ahorrar tanto espacio de almacenamiento!

El problema es que Solana está diseñando el spam de arbitraje directamente en su red a nivel de protocolo. Dado que los validadores ganan dinero enviando estas transacciones, probablemente no tardará mucho en que los validadores compriman todas las cuentas expiradas preexistentes cuando esta “característica” se habilite por primera vez. Una vez que todas las cuentas viejas hayan sido comprimidas, los validadores estarán continuamente buscando nuevas cuentas expiradas. Siempre que una nueva cuenta expire, todos los validadores competirán por ser el primero en comprimirla para obtener la recompensa. Esto significa que cada vez que una cuenta se quede sin renta, cada validador enviará una transacción intentando ser el primero en ganar el premio de compresión, resultando en una gran cantidad de transacciones redundantes que intentan comprimir la misma cuenta. Estas transacciones redundantes ocuparán el limitado ancho de banda de la red que de otro modo podría haberse destinado a transacciones de usuario, reduciendo el TPS general.

Con la solución de Archivo de Estado en Stellar, todos los validadores archivan determinísticamente las mismas entradas en un horario dado, por lo que no es necesario enviar transacciones adicionales. Esto es muy importante, ya que la red es el principal cuello de botella en el rendimiento de blockchain. Anatoly consideró las compresiones determinísticas, pero decidió en contra de ello:

“Si todos los validadores tienen que hacer esto determinísticamente entonces todos ellos tienen que mantener lo que actualmente está en el trie binario y eso significa que el estado completo tiene que ser parte de la instantánea.”

Aunque eso podría ser cierto para el trie binario Merkle de Solana, la red Stellar estructura el estado archivado de manera mucho más eficiente. En lugar de usar un trie grande para almacenar toda la información archivada, la red Stellar almacena el estado archivado en una colección de pequeños árboles Merkle inmutables. Esto significa que los validadores pueden archivar nuevas entradas almacenando solo un pequeño árbol de entradas recientemente archivadas, mientras que la mayoría del estado archivado se descarga en Archivos de Historia:

Crucialmente, esto permite a los validadores de Stellar archivar entradas en un horario determinístico de tal manera que el Archivo de Estado no requiere transacciones adicionales, significando más ancho de banda para transacciones de usuario y un TPS más alto.

El punto entero del Archivo de Estado es reducir la cantidad de estado que los nodos de blockchain necesitan almacenar. Esto no solo incluye a los validadores, los nodos RPC también deberían beneficiarse del Archivo de Estado. Desafortunadamente, Anatoly ha decidido usar un trie único para almacenar todo el estado de cuenta comprimido. Esto es muy costoso. Para recapitular, aquí está quién necesita almacenar todo el estado de cuenta comprimido:

• Nodos RPC (para producir pruebas de descompresión)
• Validadores que ganan dinero extra de transacciones de compresión

La única entidad que no tiene que almacenar el estado completo son los validadores que no envían transacciones de compresión. Almacenar el estado comprimido es demasiado caro para la sostenibilidad a largo plazo de la red, por lo que la solución de Solana es hacer que los nodos RPC y muchos validadores almacenen el estado comprimido.

Como puedes ver, realmente no hay ahorro de costos con la compresión de estado de Solana. Las tarifas de la red aún aumentarán para compensar las recompensas para los validadores que necesitan almacenar el trie completo para producir pruebas de compresión. Las tarifas fuera de la cadena también continuarán aumentando, ya que los nodos RPC son tan caros de operar como antes, si no más. Aunque algunos validadores no necesiten almacenar el trie de archivo, la red aún depende de los validadores que sí lo almacenan. Esto no parece ser un beneficio significativo, especialmente al costo de tarifas más altas, más complejidad y más congestión de red.

El problema es, al usar un trie único, el estado archivado no puede ser fragmentado. Cualquier nodo que interactúe con la compresión o descompresión necesita almacenar todo el estado comprimido, ya sea un nodo RPC produciendo pruebas o un validador enviando transacciones de compresión.

La red Stellar tiene un diseño mucho más escalable. Porque el Archivo de Estado en Stellar usa una colección de pequeños árboles Merkle inmutables en lugar de un trie grande y mutable, el estado archivado es mucho más barato de almacenar a largo plazo. Los nodos RPC no necesitan almacenar todo el estado archivado para producir pruebas, pero pueden fragmentar árboles entre múltiples nodos, o elegir almacenar solo fragmentos que contengan cierto estado archivado relevante. Mientras que los Archivos de Historia deben mantener el estado archivado completo para la disponibilidad de datos y propósitos de descentralización, los operadores también pueden fragmentar árboles a través de múltiples nodos y almacenar el estado archivado en dispositivos de almacenamiento respaldados por la red baratos. El trie único de Solana no puede ser compartido, y dado que es mutable, debe ser almacenado en costosos discos NVMe locales.

El resultado es que con el diseño de Archivo de Estado para Stellar, ¡la red en realidad se vuelve más barata! Ningún validador o instancia RPC necesita almacenar todo el estado archivado, por lo que los creadores verán beneficios en rendimiento y ahorro de costos!

Si quieres leer más sobre el diseño de Archivo de Estado en Stellar revisa la especificación de interfaz aquí (disponible en mainnet desde febrero) y los detalles de implementación de la prueba aquí (llegando a mainnet más adelante este año).

No solo creas en la máquina de hype de Solana, #construyemejor en Stellar.