Escalabilidad con Archivo de Estado en Stellar vs. la 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 de protocolo 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 spam de arbitraje de validadores 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 la 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 de hola mundo y token de spam necesita ser conservado para siempre, no importa 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 jugador 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 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 la renta se agota, 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 pobre 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, 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, los nodos RPC de Solana ya son muy caros de operar hoy (como en 512 GB de RAM caros), 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 eliminado, el payload de datos de la cuenta no es requerido 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 datos comprimidos porque es demasiado caro almacenar, o podrían seleccionar y solo almacenar datos comprimidos que sean lo suficientemente valiosos como para ser rentables. Piénsalo: si el protocolo no está forzando al RPC a almacenar todos los datos, y si almacenar los datos se está volviendo más y 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 mismos. Cada validador de Tier 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 de 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 una parche, las blockchains son fundamentalmente limitadas por la red cuando se trata de rendimiento, y la congestión de la red continuará siendo un problema a medida que el número de usuarios, validadores y TPS aumenta. Con Avocado, la congestión solo empeorará.

Hoy, 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, atacantes y comerciantes bot 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á 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 pagar realmente 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 de 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 como un mal 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 lo que de otra manera habría, ¡pero puedes ahorrar tanto espacio de almacenamiento!

El problema es, Solana está diseñando spam de arbitraje directamente en su red a nivel de protocolo. Dado que los validadores ganan dinero enviando estas transacciones, probablemente no tardará mucho para 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 siempre que una cuenta se quede sin renta, cada validador enviará una transacción tratando de 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 dirigido hacia transacciones de usuarios, reduciendo el TPS general.

Con la solución de Archivo de Estado en Stellar, todos los validadores archivan las mismas entradas de manera determinista en un horario dado, así que no hay necesidad de 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 deterministas, pero decidió en contra:

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

Aunque eso podría ser cierto para el trie binario de Merkle de Solana, la red Stellar estructura el estado archivado mucho más eficientemente. 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 de 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 determinista de tal manera que el Archivo de Estado no requiere transacciones adicionales, significando más ancho de banda para transacciones de usuarios y un TPS más alto.

El punto entero del Archivo de Estado es reducir la cantidad de estado que los nodos 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 costoso para la sostenibilidad a largo plazo de la red, así 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 del estado de compresión 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 igual de caros de operar que 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 la 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 de 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, ¡así 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í (en vivo en la red principal desde febrero) y los detalles de implementación de la prueba aquí (llegando a la red principal más adelante este año).

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