Escalabilidad con Archivo de Estado en Stellar vs. Avocado de Solana

Esta es la parte 2 en una serie de inmersión profunda 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 centra 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 aún 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úblicos 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 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 a medida que 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 fallos 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 alquiler por permanecer activa en el libro mayor. Siempre que el alquiler 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 alquiler, 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 costosa.

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 eliminados, los datos de la cuenta no son necesarios 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 optar por ignorar los datos comprimidos porque es demasiado caro almacenar, o podrían elegir y solo almacenar datos comprimidos que sean lo suficientemente valiosos como 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 ganancias. 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 se priorizarán.

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, 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 a los nodos RPC elegir y escoger 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, al almacenar 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 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 consumir tarifas para enviar transacciones. Estas tarifas ayudan a prevenir la congestión de la red, porque sin estas tarifas, atacantes y comerciantes bots podrían saturar la red con spam. Las tarifas actúan como un disuasivo y hacen que tales ataques sean demasiado caros financieramente para ser prácticos.

Aun así, incluso cobrando tarifas por transacciones, Solana ha tenido problemas significativos de congestión, y Avocado echará gasolina al fuego. Con esta propuesta, los validadores serán pagados para enviar más transacciones. Déjame decir eso de nuevo. Solana, una red que ya tiene un problema con transacciones causando significativa congestión, está proponiendo pagar realmente a los validadores por enviar una nueva categoría de transacciones, incentivando aún más transacciones en la red ya sobrecargada.

Cuando una cuenta se queda sin renta no se elimina automáticamente como el estado de la cuenta. En cambio, 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 transacciones más de lo que 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. Ya 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 antiguas 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 para intentar 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 ancho de banda limitado de la red que de otro modo podría haberse destinado a 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, por lo 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ó compresiones deterministas, pero decidió en contra de ello:

“Si todos los validadores tienen que hacer esto de manera determinista entonces todos ellos 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 de Stellar estructura el estado archivado de manera mucho más eficiente. En lugar de usar un gran trie para almacenar toda la información archivada, la red de 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, lo que significa 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 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 solo trie 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, 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 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 red también continuarán aumentando, ya que los nodos RPC son igual de costosos de operar como antes, si no más. Aunque algunos validadores no necesitarán 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 solo trie, 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 de 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 gran trie 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 solo almacenar 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 ya 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 de 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, #construyemejor en Stellar.