DISCLAIMER: Este artículo ha sido traducido de su idioma original para su conveniencia. A pesar de que nos esforzamos por ser precisos, pueden haber pequeños errores o diferencias en la interpretación. Para obtener una representación más precisa y verdadera, consulte la publicación original, disponible en []. Agradecemos su comprensión y le animamos a consultar la fuente original para obtener la información detallada.

Esto es un repost del blog de Nick Dodson en Ene. 30, 2024.

Una introducción a la Rehidratación del Estado Nativo, Técnicas de Minimización de Estados, y Modelo de Transacción de Minimización de Estados.

He hecho diversas charlas acerca del crecimiento de estados recientemente, y al ver más discusiones en X sobre este tópico pensé que serviría para ampliar mis presentaciones y el acercamiento que estamos tomando desde Fuel.

Así que vamos allá. Uno de los obstáculos más significativos que enfrentan las blockchains es el tema del “crecimiento de estados” - un problema que, si se dejara sin resolver, podría destruir la escalabilidad y eficiencia de las redes blockchains. Exploremos qué es el crecimiento de estados, por qué es un problema, y las soluciones propuestas para mantener las blockchains sostenidas y funcionales a medida que escalan.

Entendiendo el Procesamiento de los Cuellos de Botella de una Blockchain

Antes de adentrarnos en las complejidades del crecimiento de estados, analicemos los tres componentes principales de una blockchain que típicamente conforman los cuellos de botella al escalar el uso de una red.

• Ejecución. El trabajo que hace la CPU asegura una adecuada sincronización, validación, y creación del bloque futuro.  ✅ Resuelto: Hay muchas opciones que resuelven esto, como máquinas virtuales más eficientes (FuelVM, Stylus, SVM, MoveVM) y ejecución de transacción paralela (usando todos los centros de tu CPU), y mejores pre-compiles (funciones preajustadas en una VM).

• Datos (tanto almacenamiento como disponibilidad). Datos reales de transacción que dirigen transiciones de estados y permiten a otros nodos sincronizarse con la red blockchain y permiten pruebas de fraude y validación para las rollups. ✅ Resuelto: Hay unas cuantas opciones que resuelven esto, como EIP-4844, diseños de sharding, y capas de disponibilidad de datos externos como Celestia, EigenDA, y Avail.

• Estado. Esto es la información activa almacenada en una base de datos local que asegura la validación adecuada de la cadena y las transiciones de estados. Esto es lo que típicamente se encuentra en el “hot path” para el procesamiento de la blockchain, requiere mucho acceso aleatorio al disco e incurre en mucho IO que es típicamente el área más lenta del procesamiento a parte de las firmas y el hashing. ❌ No Resuelto.

Cada uno de estos componentes juega un papel crucial en la operación de una blockchain, pero es el 'estado' en lo que estamos particularmente interesados al discutir sobre temas de crecimiento.

El crecimiento de Estados

El crecimiento de estados se refiere a la siempre creciente acumulación de datos que debe ser almacenada y gestionada en su totalidad por los nodos en una red blockchain. Porque el estado es algo que crece en el tiempo, a menudo es descartado como “problema futuro”. Sin embargo, el crecimiento de estados se convierte en una bola de nieve hasta alcanzar su límite, la operación del nodo se sobrecarga drásticamente, y esto se vuelve en el cuello de botella para la escalabilidad - lo que resulta fatal cuando impide una más amplia adopción y frena la innovación.

El crecimiento de estados lleva a blockchains infladas, en las que tiempos de transacción más lentos y costes de almacenamiento más altos se convierten en la norma, lo que a su vez, puede limitar la escalabilidad y accesibilidad de una red. ¿Suena familiar? Eso es porque abordar el crecimiento de estados será el próximo catalizador que potencie la economía de las rollups, no como su problema predecesor, el throughput, que dio inicio a la revolución de las rollups.

Aproximaciones del tamaño de estados de cadenas EVM populares.

Los datos son indicativos y tienen sólo con propósitos ilustrativos.

…pero, ¿las rollups no resuelven el crecimiento de estados?

Las rollups permiten a Ethereum abrir la puerta a “algo nuevo”. Las soluciones existentes abordan la capa de ejecución, con algunas soluciones modulares yendo un paso más lejos para tratar la disponibilidad de datos. Pero si estas nuevas soluciones no abordan el tema central del estado, entonces vuelves a caer en el juego de suma cero. Cualquier blockchain diseñada a día de hoy, rollup o no, que no tenga una estrategia para abordar el crecimiento de estados, quedará en última instancia limitada por el estado inflado, sin importar su entorno de ejecución o datos.

Comparando los Diseños de Estados

Para ilustrar el problema, vamos a comparar la gestión de estados de Bitcoin y Ethereum:

• El Estado de Bitcoin: Utiliza un set UTXO (Unspent Transaction Output) que es más simple y tradicionalmente ha sido más fácil de gestionar, pero de programabilidad limitada.

• El Estado de Ethereum: Incluye balances de cuentas, código de contratos inteligentes, y estado de contratos inteligentes - incluyendo balances de tokens, aprobaciones, y más.

El modelo de gestión de estados de Bitcoin está optimizado pero su alcance es limitado. El estado de Bitcoin está gestionado mediante outputs de transacciones individuales que pueden ser gastadas o no gastadas. Su modelo UTXO (Unspent Transaction Output) mantiene un estado bien definido mediante outputs de transacciones que son o bien no gastadas y listas para transacciones futuras, o gastadas y por tanto archivadas en las historia de la blockchain. Esto hace que el modelo UTXO sea relativamente más manejable y asegura que el estado no crezca de forma incontrolada con cada transacción. Sin embargo, esta simplicidad conlleva la programabilidad limitada de Bitcoin en comparación con el sistema Turing-complete de Ethereum.

Contrasta esto con el modelo de estados de Ethereum, un rico ecosistema de balances de cuentas, códigos de contratos inteligentes, y una miríada de estados de contrato - cada interacción un hilo en el siempre creciente entramado de datos. Esta constante evolución de estados, al mismo tiempo que un testamento a la versatilidad de Ethereum, posee retos de escalabilidad significativos. Mientras el estado se infla con cada ejecución de contrato inteligente y transacción, lleva a una red inflada con creciente requerimiento de almacenamiento y tiempos de procesamiento más lentos, lo que a su vez ralentiza la innovación y la adopción de usuarios.

El contraste entre el enfoque de Bitcoin y Ethereum respecto a la gestión de estados pone de manifiesto un inconveniente fundamental en el diseño blockchain: la simplicidad y eficiencia de la gestión de estados versus la complejidad y potencial de las operaciones on-chain.

Soluciones Propuestas para el Crecimiento de Estados

Se han propuesto diversas estrategias para gestionar el crecimiento de estados:

Dejar que el Estado Crezca

Aceptar el crecimiento del estado a cambio de un mayor uso de ancho de banda. Esta no es una buena opción ya que implica mayores requerimientos para los nodos completos, lo cuál restringe la descentralización de la red.

Alquiler del Estado

Cobrar comisiones por almacenar el estado de los datos, con la desventaja de problemas potenciales como el 'tree rot' (si todos los elementos del estado de Ethereum están en un árbol y te olvidas de algunas hojas, corrompes algunas de las rutas ramificadas), entre otros problemas.

Que no haya Estado

Los nodos completos no necesitarían almacenar estados, si confiaran en pruebas de estado incluidas en las transacciones y bloques. En esencia, apartar el estado de la capa 1 a las rollups. Esta es la dirección en que va Ethereum, pero hay muchas preguntas sin respuesta sobre cuán eficiente y fácil de mantener será esto.

Desmerkelizando el Estado

Un enfoque técnico para gestionar el estado de datos de forma diferente. Efectivamente estarías usando nodos completos para validar todo o muestrear cosas con light clients y te olvidarías del árbol de estados por completo.

Compresión del Estado a nivel de Aplicación

Utilizando técnicas de llamada de datos para comprimir los datos del estado. Básicamente estarías intercambiando estados por ancho de banda. Un mayor ancho de banda exige dirección a redes restringidas, with implications weighed heavily against infrastructural robustness and efficiency trade-offs.

Ejemplo 1: Uniswap V3 staker (imagen izquierda). El estado debe ser rehidratado en el ancho de banda. Esto hace posible un diseño de estado muy minimizado, y la llamada de datos es mucho más barata que almacenar en Ethereum. Ejemplo 2: NFTs comprimidos (imagen derecha). Merkelizar los datos de propiedad de NFTs y almacenar la raíz en el estado.

Y Ahora… Rehidratación del Estado Nativo.

Filosofía del Estado de Fuel

Utilizando el modelo UTXO, tienes varios “regalitos”:

• Árboles de Estado Localizados: No árboles de estado globales, sólo árboles de estado locales para cada contrato inteligente.

• Activos Nativos: Todas las transferencias de activos sólo tocan un único elemento del estado. Los activos nativos pueden usarse para representar estados de no-valor (ej, y NFT para representar propiedad). Estos no necesitan ser merkelizados, simplificando así el estado.

• Estado de No Aprobación: Eliminando cambios de estado innecesarios de las funciones approve y transferFrom.

El modelo UTXO permite todo esto al tiempo que retiene clientes light criptográficos ricos y verificabilidad — creando un “modo rápido” para la interoperabilidad verdadera (más sobre esto en un futuro post). La principal filosofía detrás del enfoque de Fuel es: usa más ancho de banda y ejecución, mientras usas menos estados. Pero ¿cómo?

Rehidratación del Estado Nativo

La rehidratación del estado nativo describe los métodos que los desarrolladores de Fuel pueden utilizar para deshidratar o compartimentalizar el estado. Las cosas se rehidratan o compartimentalizan sobre el ancho de banda el cuál permite re-acceder al estado cuando se necesite. Esto se opondría al enfoque convencional “usa contratos inteligentes para todo” de Ethereum, utilizando búsquedas de estados de contrato.

El nuevo enfoque:

• Sólo store root hashes / cambios de estado

• Datos actuales sobre ancho de banda para “rehidratar” el estado

• Proporcionar técnicas de minimizado de estados al desarrollador para aprovechar esto.

Técnicas de Minimizado de Estados

Un enfoque en el bando de ancha y ejecución por encima del almacenamiento de estados.

• Scripts: La lógica efímera va incluida en las transacciones, no se almacena en los estados. A diferencia de las transacciones EVM que pueden llamar a un contrato directamente (pero sólo pueden llamar a un único contrato), las transacciones de Fuel ejecutan un script, que pueden llamar a cero o más contratos.

• Predicados: Contratos ligeros, sin estados. Un predicado es un nuevo mecanismo puro para autorizar transacciones. Un predicado sólo puede acceder a los datos de una transacción, no puede ver el estado actual de la cadena. Los predicados se pueden utilizar, entre otras cosas, para permitir la abstracción de cuentas nativas (sin estados).

Aprende más sobre Predicados en esta publicación de Ryan Sproule: Un predicado no es un contrato inteligente sino que aún permite la custom authentication logic for spending coins. Esto significa que los predicados pueden ser gastados sin la necesidad de una llave privada, a diferencia de cualquier transacción EVM. En la práctica, esto significa que los usuarios pueden construir predicados que pueden ser gastados completamente sin permiso. Cuando se combinan con el concepto de scripts de Fuel, la experiencia de usuario al interactuar con contratos inteligentes se vuelve superpotente.

El Modelo de Transacción de Minimizado de Estados

Combinar las técnicas de minimización de estados con el modelo UTXO nos permite crear un nuevo Modelo de Transacción Flexible. Esto permite más opciones a la hora de formar transacciones complejas multi-party que no requieren contratos inteligentes para acceder al estado.

¿Cómo se vería esto en la práctica? Ejemplo:

Las billeteras de contratos inteligentes (con sólo un elemento de estado de 32 bytes)

• El estado del contrato se almacena en un único root hash en un UTXO

• El estado se rehidrata en el ancho de banda cuando se necesita

• UTXOs aseguran la verificabilidad del light client sin árbol merkle

• Sólo requiere una lectura IO

• El estado se puede cambiar cuando el UTXO del estado ha sido gastado

• No pérdida de funcionabilidad de la billetera de contratos inteligentes VS Ethereum

• Se priorizan el ancho de banda y la ejecución sobre los estados

• Todo hecho en el nivel nativo (predicados)

La arquitectura de Fuel está diseñada para incorporar todas estas características junto con la ejecución de minimizado de estados para crear un paquete construido a propósito de las rollups de Ethereum. Fuel aporta nueva capacidad al ecosistema de Ethereum mientras preserva la seguridad con el asentamiento final en Ethereum.

Mientras continúa la batalla contra el crecimiento de estados, las herramientas y estrategias, como las de Fuel, ofrecen esperanza para un futuro eficiente y escalable. Como dice el proverbio, “La necesidad es la madre del invento”, y en el mundo blockchain, la necesidad de conquistar el crecimiento de estados ciertamente ha conducido a soluciones de cero a uno.