jakiro
Autor: Wei Han Ng, Carlos Pérez, equipo de investigación de consenso sobre apátridas; Traducción: @bitchainvisionxiaozou
Ethereum ha pasado de ser una red pequeña y experimental a un componente crítico de la infraestructura global. Liquida miles de millones de dólares en valor de liquidación diaria, coordina miles de aplicaciones y respalda todo el ecosistema de red de Capa 2 (L2).
En última instancia, todo depende de un componente central subyacente: el estado (estado).
1, que es«Estado«y su importancia
El saldo de un usuario no se almacena en su billetera, sino en el estado de Ethereum.El estado puede entenderse aproximadamente como «todo lo que Ethereum sabe actualmente»: cuentas, almacenamiento de contratos (todos los datos escritos en el contrato), código de bytes (la lógica que se ejecuta cuando se utilizan contratos inteligentes).
El estado es la base de casi todas las funciones:
Las billeteras dependen de él para mostrar saldos y registros de operaciones anteriores;
Las aplicaciones descentralizadas (Dapps) lo consultan para conocer posiciones, pedidos o mensajes existentes;
La infraestructura (exploradores de bloques, puentes entre cadenas, indexadores, etc.) lee continuamente el estado para proporcionar servicios además.
Si el Estado se vuelve demasiado grande, demasiado centralizado o difícil de servir, todas las capas anteriores se vuelven más frágiles, más caras y más difíciles de descentralizar.
2,L1La expansión tiene consecuencias
Ethereum ha seguido trabajando en la expansión de la red durante muchos años: a través de la red de segunda capa, EIP-4844, aumentando el límite de gas, la revalorización de las tarifas del gas y el mecanismo integrado de separación entre proponente y constructor.Cada paso ha mejorado las capacidades de procesamiento de la red, pero también ha traído nuevos desafíos.
Desafío 1: el estatus continúa expandiéndose
El tamaño del estado de Ethereum no hace más que aumentar. Cada nueva cuenta, operación de almacenamiento y escritura de código de bytes aumenta permanentemente la cantidad de datos que la red debe contener.
Esto resulta en costos específicos:
Los validadores y los nodos completos deben almacenar más datos.A medida que aumenta la escala estatal, la base de datos necesita manejar una carga de trabajo adicional y la eficiencia disminuye.
El proveedor de servicios RPC debe permanecer totalmente accesible y garantizar que cualquier cuenta o datos almacenados puedan consultarse en cualquier momento.
El crecimiento del estado da como resultado una sincronización de nodos más lenta y una estabilidad reducida.
Aumentar el límite de gas aumenta la inflación del estado porque cada bloque puede acomodar más operaciones de escritura. Este problema ya se ha dado en otras cadenas públicas.A medida que se expande la escala estatal, a los usuarios comunes les resulta difícil ejecutar nodos completos, lo que da como resultado que los datos estatales se concentren en manos de unos pocos grandes proveedores de servicios.
En Ethereum, la mayoría de los bloques han sido producidos por constructores profesionales.La principal preocupación es cuántas entidades independientes aún pueden completar la construcción de bloques de un extremo a otro en el momento crítico.Si sólo un número muy pequeño de participantes puede almacenar y proporcionar un estado completo, la resistencia a la censura y la neutralidad confiable se verán comprometidas, porque habrá menos directores capaces de construir bloques que contengan transacciones censuradas.
Parte del factor positivo es que mecanismos como FOCIL y VOPS están diseñados para garantizar la resistencia a la censura en el ecosistema de constructores profesionales.Pero su eficacia aún depende de un ecosistema saludable de nodos que puedan acceder, almacenar y proporcionar datos estatales a un costo asequible.Por lo tanto, controlar el crecimiento del Estado es un prerrequisito necesario, no una optimización opcional.
Para determinar el punto crítico del problema, estamos realizando activamente pruebas de estrés:
¿Cuándo el crecimiento del Estado se convierte en un cuello de botella creciente?
¿Cuándo el tamaño del estado dificulta que los nodos sigan la cabeza de la cadena?
Cuando las implementaciones de clientes fallan en escalas de estado extremas.
Desafío 2: En una arquitectura sin estado, ¿quién es responsable de almacenar y proporcionar el estado?
Incluso si Ethereum mantiene el límite de gasolina actual de forma permanente, eventualmente nos encontraremos con el problema de la inflación estatal.Al mismo tiempo, la comunidad claramente espera un mayor rendimiento.
Los esquemas sin estado eliminan una limitación importante: los validadores no necesitan mantener el estado completo para validar bloques, solo pruebas.Este es un avance de escalabilidad importante que aborda la necesidad de la comunidad de un mayor rendimiento y revela un hecho antes oculto de que el almacenamiento estatal puede evolucionar hacia una función independiente y más especializada, en lugar de estar vinculado a cada validador.
En ese momento, la mayor parte del estado sólo podrá ser almacenado por:
constructor de bloques;
proveedor de servicios RPC;
Otros operadores profesionales (como buscadores MEV y exploradores de bloques).
En otras palabras, el Estado se volverá más centralizado.
Esto tiene múltiples consecuencias:
Mayor dificultad en la sincronización: los proveedores de servicios centralizados pueden comenzar a restringir el acceso al estado, dificultando el inicio de nuevos proveedores de servicios;
Resistencia debilitada a la censura: si no se pueden obtener datos de estatus censurados, los mecanismos anticensura como FOCIL pueden fallar;
Riesgo de resiliencia del sistema: si solo unas pocas entidades almacenan y proporcionan el estado completo, la interrupción del servicio o la presión externa cortarán rápidamente el acceso a la mayoría de los componentes del ecosistema.
Aunque muchas entidades almacenan el estado, no existe una forma efectiva de verificar que realmente brindan servicios y los incentivos existentes son insuficientes.La sincronización de instantáneas es ampliamente compatible de forma predeterminada, pero los servicios RPC no.Sin reducir el costo de los servicios estatales y aumentar su atractivo universal, la capacidad de la red para acceder a su propio estado se limitará a un pequeño número de proveedores de servicios.
Este problema también afecta a las redes de Capa 2. La capacidad de los usuarios para forzar transacciones empaquetadas depende de un acceso confiable al estado del contrato acumulativo en L1.Si el acceso al estado L1 se vuelve frágil o altamente centralizado, estos mecanismos de válvula de seguridad serán difíciles de operar en aplicaciones prácticas.
3, las tres direcciones principales que vemos
(1) Período de validez del estado
No todos los datos estatales tienen la misma importancia permanente.Nuestro análisis reciente muestra que aproximadamente el 80% de los datos estatales no han sido accedidos en más de un año.Sin embargo, los nodos aún soportan el costo de almacenar este estado a perpetuidad.
La idea central del mecanismo de validez del estado es eliminar temporalmente el estado inactivo del «conjunto activo» y luego restaurarlo mediante algún tipo de prueba cuando sea necesario.A grandes rasgos, se pueden dividir en dos grandes categorías:
Categoría 1: Marca, Invalidación, Resurrección
En lugar de tratar a todos los estados como permanentemente activos, el protocolo marca rara vez los estados utilizados como inactivos para que ya no persistan en el conjunto activo mantenido por cada nodo, al tiempo que permite restaurarlos en el futuro a través de pruebas históricas de existencia.El efecto práctico es que los contratos y saldos de uso común permanecen activos y tienen bajos costos de acceso, mientras que los estados olvidados hace mucho tiempo no necesitan ser transportados continuamente por cada nodo y aún pueden recuperarse cuando alguien los necesita nuevamente.
Categoría 2: Mecanismo de falla de ciclos múltiples
En un diseño de períodos múltiples, no invalidamos las entradas individuales, sino que dividimos periódicamente el estado en períodos (por ejemplo, un período = un año).El ciclo actual es más pequeño y está completamente activo, el ciclo anterior se congela desde una perspectiva de ejecución en tiempo real y el nuevo estado se escribe en el ciclo actual.El antiguo estado sólo puede restaurarse demostrando su existencia en el ciclo anterior.
El mecanismo de marcar-invalidar-resurrección suele ser más sofisticado y el proceso de resurrección más sencillo, pero el proceso de marcado requiere que se almacenen metadatos adicionales.Las fallas de ciclos múltiples son conceptualmente más simples y se integran de manera más natural con los mecanismos de archivo, pero las pruebas de resurrección tienden a ser más complejas y más grandes.
En última instancia, estos dos enfoques comparten el mismo objetivo (mantener el estado activo eficiente eliminando temporalmente las partes inactivas y al mismo tiempo proporcionar un camino hacia la resurrección), pero hacen diferentes concesiones en complejidad, experiencia del usuario y asignación de trabajo a los clientes y la infraestructura.
(2) Archivo de estado
El archivo de estado divide el estado en estado frío y caliente.
Los estados calientes son partes de la red que requieren acceso frecuente;
El estado frío es la parte que sigue siendo importante para la historia y la verificabilidad, pero que rara vez se toca.
En el diseño del archivo estatal, los nodos almacenarán explícitamente por separado los estados activos y los datos históricos recientemente utilizados con frecuencia.Incluso a medida que el estado general continúa creciendo, las partes a las que se debe acceder rápidamente (conjuntos de datos activos) pueden seguir teniendo un tamaño limitado.En la práctica, esto significa que el rendimiento de ejecución del nodo (especialmente el costo de E/S para acceder al estado) puede permanecer básicamente estable a lo largo del tiempo, sin disminuir a medida que la cadena envejece.
(3) Reducir el umbral para el almacenamiento y los servicios estatales.
Una pregunta obvia es: ¿podemos lograr nuestros objetivos manteniendo menos datos? En otras palabras, ¿se pueden diseñar nodos y billeteras que no requieran almacenamiento permanente del estado completo y sigan funcionando como participantes válidos?
Una dirección prometedora son las soluciones parcialmente sin estado:
Los nodos almacenan y proporcionan solo un estado parcial (como datos relacionados con un usuario o aplicación específica);
Las carteras y los clientes ligeros desempeñan un papel más activo en el almacenamiento y almacenamiento en caché de los fragmentos de estado necesarios, en lugar de depender por completo de unos pocos grandes proveedores de servicios RPC.Si el almacenamiento se puede distribuir de forma segura a carteras y nodos «nichos», la carga para los operadores individuales se reducirá y el grupo de titulares estatales se volverá más diverso.
Otra dirección es reducir las barreras para el funcionamiento de infraestructura útil:
Simplificar el proceso de implementación de nodos RPC que solo prestan servicios a una parte del estado;
Diseñe protocolos y herramientas que permitan que las billeteras y las aplicaciones descubran e integren múltiples fuentes de datos locales en lugar de depender de un único punto final RPC completo.
4, dirección futura
El estado de Ethereum se está convirtiendo silenciosamente en la clave de varias cuestiones centrales para el futuro del protocolo:
¿Hasta qué punto el aumento del tamaño del Estado se convierte en una barrera a la participación?
Cuando los validadores puedan validar bloques de forma segura sin requerir estado, ¿quién almacenará el estado?
¿Quién proporcionará servicios de estado a los usuarios?¿Cuál es el incentivo?
Algunas cuestiones aún están por determinarse, pero la dirección es clara: reducir las limitaciones del estado sobre el rendimiento, reducir los costos de almacenamiento y mejorar la accesibilidad al servicio.
Nuestro enfoque actual está en promover el trabajo de bajo riesgo y alto retorno:
Esquema de archivo
Estamos probando soluciones fuera de protocolo para controlar el tamaño del estado activo mientras confiamos en soluciones de archivo para almacenar datos históricos. Esto proporcionará datos del mundo real sobre el rendimiento, la experiencia del usuario y la complejidad operativa.Si la verificación es válida, se puede promover a una actualización dentro del protocolo si es necesario.
Algunos nodos sin estado y mejoras de RPC
La mayoría de los usuarios y aplicaciones interactúan con Ethereum a través de proveedores de servicios RPC centralizados.Estamos trabajando en las siguientes mejoras:
Reducir la dificultad y el costo de ejecutar nodos, incluso si los nodos no almacenan todo el estado;
Permitir que múltiples nodos colaboren para brindar servicios estatales completos;
Aumente la diversidad de proveedores de servicios RPC y evite cuellos de botella en puntos únicos.
Estos proyectos han sido cuidadosamente seleccionados por su utilidad inmediata y compatibilidad prospectiva: mejorarán la salud actual de Ethereum y sentarán las bases para actualizaciones más profundas del protocolo en el futuro.
