No Todos los Datos son Iguales: Cómo Soroban está Solucionando la Inflación de Estado

Como se mencionó anteriormente, el estado de una blockchain se refiere a la información actual registrada en la red en un momento dado. La información específica incluida en el estado puede variar dependiendo de la cadena, pero con Stellar y Soroban, el estado incluye todas las cuentas, contratos inteligentes, activos y sus respectivos saldos o datos.

Copias del estado de una blockchain son almacenadas por cada nodo validador y crecen con cada nueva entrada en el libro mayor. Por ejemplo, si Suzie airdropa 100 tokens SPINACH a Stephan, el tamaño del estado aumentaría. En el caso de Stellar, esto agregaría una entrada de saldo reclamable al libro mayor. Dado que las blockchains pueden procesar miles de transacciones (mucho más complejas) por segundo, el estado puede cambiar y crecer exponencialmente.

A medida que el estado de una blockchain aumenta con el tiempo, los requisitos de hardware de los validadores también aumentan y toma mucho más tiempo sincronizar un nuevo validador con la red. Aquellos que ejecutan un nodo validador deben poder costear los recursos de almacenamiento y computacionales necesarios para almacenar el estado completo de la blockchain y mantenerse al día con el procesamiento de nuevos bloques y transacciones. Estos requisitos técnicos en constante aumento hacen que mantener un validador sea más exigente y eleva la barrera de entrada para nuevos usuarios, lo que socava uno de los propósitos principales de blockchain: la descentralización.

Además, permitir que el tamaño del estado crezca sin límites tiene el potencial de afectar negativamente las transacciones por segundo (TPS) de una red. A medida que crece el estado del libro mayor, es más difícil para los validadores encontrar la información que buscan, como buscar una aguja en un pajar con el pajar creciendo exponencialmente. Esto causa que las transacciones se ralenticen y disminuye las TPS ya que es más difícil para los validadores encontrar la información que necesitan para validar transacciones.

Por lo tanto, permitir que el estado de blockchain crezca sin control 1) socava la descentralización al elevar la barrera de entrada para los validadores, y 2) disminuye el rendimiento de la red y las TPS a largo plazo. Estos son dos problemas fundamentales que necesitan ser resueltos si blockchain alguna vez va a escalar y tener éxito como un sistema del mundo real.

Para el lanzamiento de Mainnet, Stellar será la primera blockchain en emplear la expiración del estado de este diseño para solucionar la inflación del estado (ten en cuenta que esta solución solo se aplica a las entradas de contrato inteligente, `ContractData` y `ContractCode`), demostrando que está siendo construida para la longevidad y la usabilidad en el mundo real.

Inspirándose inicialmente en las propuestas de expiración del estado de Ethereum de 2021, los diseñadores de Soroban pasaron varios meses investigando, colaborando (internamente y con la comunidad) e iterando para llegar al modelo actual de expiración del estado de Soroban. Aunque todavía hay algunas decisiones técnicas por tomar, el diseño general es sólido e incluye: una base de datos para almacenar entradas de datos vencidas (Almacén de Estado Vencido), dos tipos distintos de almacenamiento de datos (Temporal y Persistente), y un modelo de alquiler/tasa para las entradas.

Almacén de Estado Vencido (ESS)

El ESS es un sistema secundario similar a Horizon que almacena las entradas de datos persistentes que han vencido y se han eliminado de la base de datos actual de Stellar, BucketListDB.

Cuando un usuario necesita restaurar una entrada (Persistente) vencida, ejecuta una operación de `Restauración` en la red de Stellar. Los nodos ESS ven esta operación y proporcionan las pruebas criptográficas necesarias para restaurar la entrada al BucketList. Cuando una entrada se restaura al BucketList, se puede usar como si fuera una LedgerEntry normal que nunca expiró.

Tipos de almacenamiento de datos Temporal y Persistente

Actualmente, la red de Stellar (y cada otra blockchain) trata cada entrada de datos por igual. 1,000 entradas de saldo reclamable de tokens SPINACH no aceptadas ocupan tanto almacenamiento en la red como entradas más importantes y útiles, como 1,000 entradas de saldo de USDC. Con dos tipos de almacenamiento distintos, podemos eliminar entradas redundantes o desactualizadas que están congestionando la red para hacer espacio para entradas más útiles.

Cuando un desarrollador está escribiendo un contrato inteligente en Soroban, debe definir en el contrato si las entradas de datos son 1) Temporales, o 2) Persistentes. Ambos tipos de almacenamiento funcionan igual con respecto a su interfaz pero difieren en sus tasas y comportamiento de expiración.

Almacenamiento Temporal

El tipo de entrada de almacenamiento Temporal es la opción de almacenamiento más barata. Cuando expira del BucketList, no se mueve al ESS, lo que significa que se elimina permanentemente y nunca se puede restaurar.

Las entradas Temporales son saludables para la red y excelentes para información que solo es relevante por períodos cortos de tiempo o que se puede recrear arbitrariamente.

Almacenamiento Persistente

El tipo de entrada de almacenamiento Persistente es más caro de mantener en el BucketList pero se envía al ESS al vencer y se puede restaurar con un RestoreFootprintOp. Esto lo hace adecuado para información que no te puedes permitir perder, como el saldo de tokens de un usuario.

Alquiler

Actualmente, ya sea que estés almacenando un saldo de cuenta o emitiendo un token SPINACH, cada entrada de datos requiere solo una tarifa única para sobrecargar los nodos validadores para siempre como parte del estado. Implementar un modelo de precios para la expiración permite priorizar datos importantes y que los datos menos importantes expiren y sean despriorizados.

En el diseño de expiración del estado de Soroban, cada entrada de contrato inteligente debe pagar alquiler para existir en el libro mayor antes de que expire. Esto es como pagar “alquiler” por el espacio que cada entrada ocupa en la red. La tarifa se basa en cuánto tiempo debe vivir la entrada en el libro mayor y cuán grande es la entrada. Y como las tarifas de transacciones, el alquiler irá al fondo de tarifas, que actualmente está bloqueado, solo puede ser desbloqueado por un cambio en el protocolo aprobado por un validador, y no es recogido por SDF ni por ninguna otra persona u organización.

Por supuesto, hay mucho más en el modelo de expiración del estado de Soroban que la descripción general de alto nivel descrita arriba. Si estás interesado en entender mejor o contribuir a las decisiones de diseño estructural y técnico, buscar en el canal soroban-dev en el Discord de Desarrolladores de Stellar o escuchar las discusiones de diseño disponibles en el canal de YouTube de Soroban son excelentes puntos de partida.

Aunque la propuesta de expiración del estado de Soroban fue inicialmente creada por ingenieros de SDF, la participación de la comunidad ha tenido un tremendo impacto en su diseño posteriormente. Con ayuda de la retroalimentación del ecosistema, la propuesta ha pasado por al menos diez iteraciones, y las preguntas técnicas más pequeñas se discuten en Discord constantemente. Diseñar algo tan pionero como la expiración del estado no se puede hacer en el vacío, y escuchar la retroalimentación de la comunidad de desarrolladores es vital para asegurarnos de que estamos entregando algo que el ecosistema apoya.

Ha habido numerosas discusiones sobre varios aspectos de la configuración de expiración del estado en Discord, donde muchas propuestas de diseño son documentos públicos.

Algunos temas muy debatidos incluyen:

• Preguntas abiertas sobre el tiempo de vida (TTL) y expiración de TemporaryEntry se discutieron en Discord y durante la discusión de diseño del 20 de abril;
• Cómo tratar las llaves para varios tipos de almacenamiento fue intensamente discutido en Discord;
• Una conversación animada sobre las diferentes duraciones de las entradas de almacenamiento se tuvo durante la discusión de diseño del 24 de abril;
• Un tema extremadamente controversial, la semántica de expiración del estado, también fue un problema popular en Discord.

Ten en cuenta que el desarrollo de Soroban está sucediendo extremadamente rápido. Algunos de los elementos discutidos en estos hilos y propuestas ahora son obsoletos (te estoy mirando, entradas fusionables).

Introducir la expiración de estado representa un cambio de paradigma para blockchain. Un aspecto de la tecnología que se ha hablado frecuentemente a lo largo de los años es que todos los datos en una blockchain estarán accesibles todo el tiempo, para siempre. Aunque esto es un buen sentimiento, no es sostenible ni realista si blockchain alguna vez va a tener un uso generalizado en el mundo real.

La expiración de estado sí requiere más trabajo por parte del desarrollador de contratos inteligentes al principio — tienen que considerar los diferentes tipos de almacenamiento de datos y asegurarse de que están pagando renta. Sin embargo, esta interfaz de almacenamiento ligeramente más compleja es un pequeño sacrificio por el mejor rendimiento y descentralización que la red experimentará en el futuro. Implementar la expiración de estado demuestra aún más cómo Stellar y Soroban están siendo construidos para la escalabilidad y la usabilidad en el mundo real.

La primera fase de la implementación de la expiración de estado de Soroban ya está disponible como parte de la décima versión preliminar en Futurenet. Esta primera fase proporcionará el modelo de renta de interfaz de usuario y la expiración de datos. Sin embargo, dado que los validadores tienen un caché de entrada expirada incorporado, no necesitaremos enviar entradas al ESS al principio. Las siguientes fases de la expiración de estado se implementarán durante el próximo año. Asegúrate de mantenerte al día sobre todas las noticias relacionadas con Soroban en el Discord de Desarrolladores de Stellar o siguiendo la cuenta de Twitter de Soroban!