Dominar el jefe final en la escalabilidad de Blockchain: el crecimiento del estado

Esta es una nueva publicación del blog de Nick Dodson el 30 de enero de 2024.

Presentación de la rehidratación del estado nativo, técnicas de minimización del estado y un modelo de transacción que minimiza el estado.

He dado  varias charlas  sobre el crecimiento del estado recientemente y, al ver más discusiones en X sobre este tema, pensé que ampliaría mis presentaciones y el enfoque que estamos adoptando con Fuel.

Así que vayamos directamente al grano. Uno de los obstáculos más importantes que enfrentan las cadenas de bloques es la cuestión del "crecimiento del estado", un problema que, si no se controla, podría destruir la escalabilidad y la eficiencia de las redes de cadenas de bloques. Exploremos qué es el crecimiento estatal, por qué es un problema y las soluciones propuestas para mantener las cadenas de bloques eficientes y funcionales a medida que escalan.

Comprender los cuellos de botella en el procesamiento de una cadena de bloques

Antes de profundizar en las complejidades del crecimiento estatal, analicemos los tres componentes principales de una cadena de bloques que suelen ser los obstáculos para escalar el uso de la red:

• Ejecución.  El trabajo que realiza la CPU para garantizar una sincronización, validación y creación futura de bloques adecuadas. ✅  Resuelto : Hay muchas opciones que resuelven esto, como máquinas virtuales más eficientes (FuelVM, Stylus, SVM, MoveVM) y ejecución de transacciones paralelas (usando todos los núcleos de su CPU), y mejores precompilaciones (funciones preestablecidas en Av M).

• Datos (tanto de almacenamiento como de disponibilidad).  Datos de transacciones reales que impulsan las transiciones de estado y permiten que otros nodos se sincronicen con la red blockchain y permiten el fraude o la prueba de validez de los resúmenes. ✅  Resuelto : Hay algunas opciones que resuelven esto, como EIP-4844, diseños de fragmentación y capas externas de disponibilidad de datos como Celestia, EigenDA y Avail.

• Estado . Esta es la información almacenada activa en una base de datos local que garantiza una validación de cadena y transiciones de estado adecuadas. Por lo general, esto se encuentra en la "ruta activa" para el procesamiento de blockchain, requiere mucho acceso aleatorio al disco e incurre en una gran cantidad de E/S, que suele ser el área de procesamiento más lenta, aparte de las firmas y el hash. ❌  No resuelto.

Cada uno de estos componentes desempeña un papel crucial en el funcionamiento de una cadena de bloques, pero es el "estado" lo que nos interesa especialmente cuando hablamos de cuestiones de crecimiento.

El desafío del crecimiento del Estado

El crecimiento del estado se refiere a la acumulación cada vez mayor de datos que deben ser almacenados y administrados en su totalidad por nodos en una red blockchain. Como el Estado es algo que crece con el tiempo, a menudo se lo descarta como un “problema futuro”. Sin embargo, a medida que el crecimiento del estado aumenta hasta alcanzar su umbral, la operación de los nodos se ve drásticamente sobrecargada, y esto se convierte en el cuello de botella para la escalabilidad, lo que resulta fatal cuando impide una adopción más amplia y desacelera la innovación.

https://x.com/peter_szilagyi/status/1706563595264295411?s=20

El crecimiento estatal conduce a cadenas de bloques infladas, donde los tiempos de transacción más lentos y los costos 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? Esto se debe a que abordar el crecimiento estatal será el próximo catalizador para potenciar la economía acumulativa, no muy diferente de su problema predecesor, el rendimiento, que desató la revolución acumulativa.

Aproximaciones del tamaño estatal de cadenas EVM populares.

…pero, ¿los rollups no resuelven el crecimiento del estado?

Los rollups permiten a Ethereum abrir la puerta a "algo nuevo". Las soluciones existentes abordan la capa de ejecución, y algunas soluciones modulares van un paso más allá para abordar la disponibilidad de datos. Pero si estas nuevas soluciones no abordan la cuestión central del Estado, entonces volveremos a luchar en un juego de suma cero. Cualquier  cadena de bloques diseñada hoy, acumulada o no, que no tenga una estrategia para abordar el crecimiento del estado, en última instancia se verá limitada por la inflación estatal, independientemente de su ejecución o entorno de datos.

Comparación de diseños estatales

Para ilustrar el problema, comparemos la gestión del estado de Bitcoin y Ethereum:

• Estado de Bitcoin:  utiliza un conjunto UTXO (salida de transacciones no gastadas) que es más simple y tradicionalmente ha sido más fácil de administrar, pero con una programabilidad limitada.

• Estado de Ethereum:  incluye saldos de cuentas, código de contrato inteligente y estado de contrato inteligente, que abarca saldos de tokens, aprobaciones y más.

El modelo de gestión estatal de Bitcoin es simplificado pero de alcance limitado. El estado de Bitcoin se gestiona a través de resultados de transacciones individuales que pueden gastarse o no gastarse. Su modelo UTXO (Salida de transacciones no gastadas) mantiene un estado claro a través de salidas de transacciones que no se gastan y están listas para transacciones futuras, o se gastan y, por lo tanto, se archivan en el historial de blockchain. Esto hace que el modelo UTXO sea relativamente más manejable y garantiza que el estado no crezca incontrolablemente con cada transacción. Sin embargo, esta simplicidad tiene el costo de la programabilidad limitada de Bitcoin en comparación con el sistema completo de Turing de Ethereum.

Compare esto con el modelo de estado de Ethereum, un rico ecosistema de saldos de cuentas, códigos de contratos inteligentes e innumerables estados de contratos: cada interacción es un hilo en el creciente tapiz de datos. Esta constante evolución del estado, si bien es un testimonio de la versatilidad de Ethereum, plantea importantes desafíos de escalabilidad. A medida que el estado se infla con cada ejecución y transacción de contrato inteligente, genera una red inflada con mayores requisitos de almacenamiento y tiempos de procesamiento más lentos, lo que a su vez frena la innovación y la adopción por parte de los usuarios.

El contraste entre los enfoques de Bitcoin y Ethereum sobre la gestión estatal subraya una compensación fundamental en el diseño de blockchain: la simplicidad y eficiencia de la gestión estatal frente a la complejidad y el potencial de las operaciones en cadena.

Soluciones propuestas para el crecimiento del Estado

Se han propuesto varias estrategias para gestionar el crecimiento del estado:

Dejar crecer al Estado

Aceptar el crecimiento del Estado a cambio de un mayor uso del ancho de banda. Esta no es una buena opción ya que impone requisitos más altos a los nodos completos, lo que limita la descentralización de la red.

https://x.com/aeyakovenko/status/1699460999697555512?s=20

Alquiler estatal

Cobrar tarifas por almacenar datos estatales, con la compensación de problemas potenciales como la "podredumbre del árbol" (si todos los elementos estatales en Ethereum están en un árbol y olvidas algunas de las hojas, corrompes algunas de las rutas de ramificación), entre otras cuestiones.

Apatridia

Los nodos completos no necesitarían almacenar el estado, ya que dependen de las pruebas de estado incluidas con las transacciones y los bloques. Básicamente, alejar el estado de la cadena de la capa 1 a los paquetes acumulativos. Esta es la dirección en la que va Ethereum, pero hay muchas preguntas sin respuesta sobre qué tan eficiente y mantenible será.

árboles verkle

https://vitalik.eth.limo/general/2021/06/18/verkle.html

Desmerkalizar el Estado

Un enfoque técnico para gestionar los datos estatales de manera diferente. Efectivamente, estaría utilizando nodos completos para validar todo o probar cosas con clientes ligeros y olvidarse por completo del árbol de estado.

https://x.com/TrustlessState/status/1699457615615402147?s=20

Compresión de estado a nivel de aplicación

Usar técnicas de datos de llamadas para comprimir datos de estado. Básicamente, estás intercambiando estado por ancho de banda. Las mayores demandas de ancho de banda conducen a redes restringidas, con implicaciones que pesan mucho en contra de la solidez de la infraestructura y las compensaciones por la eficiencia.

Ejemplo 1: apostador Uniswap V3 (imagen del lado izquierdo).  El estado debe rehidratarse a través del ancho de banda. Esto permite un diseño muy minimizado y los datos de llamada son mucho más baratos que el almacenamiento en Ethereum. Ejemplo 2: NFT comprimidos ( imagen del lado derecho ). Merklize los datos de propiedad de NFT y almacene la raíz en el estado.

Y ahora… Rehidratación del Estado Nativo.

Filosofía del Estado del combustible

Al aprovechar el modelo UTXO, se obtienen varios “obsequios”:

• Árboles de estado localizados:  no hay árbol de estado global, solo árboles de estado locales para cada contrato inteligente.

• Activos nativos:  todas las transferencias de activos solo tocan un único elemento estatal. Los activos nativos se pueden utilizar para representar un estado sin valor (por ejemplo, y NFT para representar la propiedad). No es necesario merkalizarlos, lo que simplifica el estado.

• Estado sin aprobación:  eliminación de cambios de estado innecesarios en las funciones de aprobación y transferencia.

El modelo UTXO permite todo esto al mismo tiempo que conserva clientes ligeros criptográficos enriquecidos y verificabilidad, creando un "modo rápido" para una verdadera interoperabilidad (más sobre esto en una publicación futura). La principal filosofía detrás del enfoque de Fuel es:  usar más ancho de banda y ejecución, mientras usa menos estado. Pero  cómo ?

Rehidratación del estado nativo

La rehidratación del estado nativo describe los métodos que los desarrolladores de combustible pueden utilizar para  deshidratar  o compartimentar el estado. Las cosas se  rehidratan  a través del ancho de banda, lo que permite volver a acceder al estado cuando sea necesario. Esto se opondría al enfoque convencional (“usar contratos inteligentes para todo”) de Ethereum, que utiliza búsquedas de estado de contratos.

El nuevo enfoque:

• Almacenar hashes raíz/cambios de estado únicamente

• Presentar datos a través del ancho de banda para "rehidratar" el estado

• Proporcione técnicas de estado minimizado para que el desarrollador aproveche esto.

Técnicas minimizadas por el estado

Un enfoque en el ancho de banda y la ejecución sobre el almacenamiento estatal. Fuel ofrece al desarrollador muchas formas de hacer cosas además del almacenamiento de contratos inteligentes:

• Scripts : la lógica efímera se incluye en las transacciones, no se almacena en el estado. A diferencia de las transacciones EVM que pueden llamar a un contrato directamente (pero solo pueden llamar a un contrato único), las transacciones de Fuel ejecutan un script, que puede llamar a cero o más contratos.

• Predicados : Contratos ligeros y sin estado. Un predicado es un mecanismo nuevo y puro para autorizar transacciones. Un predicado solo 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 habilitar la abstracción de cuentas nativas (sin estado).

Obtenga más información sobre los predicados en esta publicación de Ryan Sproule:  Un predicado no es un contrato inteligente, pero aún permite una lógica de autenticación personalizada para gastar monedas. Esto significa que los predicados se pueden gastar sin necesidad de una clave privada, a diferencia de cualquier transacción EVM. En la práctica, esto significa que los usuarios pueden construir predicados que se pueden utilizar sin permiso. Cuando se combina con el concepto de scripts Fuel, la experiencia del usuario para interactuar con contratos inteligentes se potencia.

Modelo de transacción minimizado por el estado

Combinar técnicas de estado minimizado con el modelo UTXO nos permite crear un nuevo  modelo de transacción flexible.  Esto permite más opciones para formar transacciones complejas de múltiples partes que no requieren contratos inteligentes para acceder al estado.

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

Carteras de contrato inteligente (con solo un elemento de estado de 32 bytes)

• El estado del contrato se almacena en un único hash raíz en un UTXO

• El estado se rehidrata a través del ancho de banda cuando es necesario

• Los UTXO garantizan una verificabilidad ligera del cliente sin el árbol merkle global

• Solo requiere una lectura IO

• El estado se puede cambiar cuando se gasta el estado UTXO

• Sin pérdida de funcionalidad de billetera de contrato inteligente frente a Ethereum

• El ancho de banda y la ejecución tienen prioridad sobre el estado.

• Todo hecho a nivel nativo (predicados)

La arquitectura de Fuel está diseñada para incorporar todas estas características junto con una ejecución minimizada por estado para crear un paquete diseñado específicamente para paquetes acumulativos de Ethereum. Fuel aporta nuevas capacidades al ecosistema de Ethereum y al mismo tiempo preserva la seguridad mediante la liquidación final de Ethereum.

Mientras continúa la batalla contra el crecimiento del estado, las herramientas y estrategias, como las de Fuel, ofrecen esperanza para un futuro escalable y eficiente. Como dice el proverbio, "La necesidad es la madre de la invención", y en el mundo de blockchain, la necesidad de conquistar el crecimiento del estado ha llevado a algunas soluciones de cero a uno.