Vitalik: Un plan de optimización de la hoja de ruta de escalabilidad enfocado en nodos locales.

Escrito por: Vitalik, fundador de Ethereum

Compilado por: Jinse Caijing xiaozhou

La crítica más común a aumentar el límite de Gas L1, además de las preocupaciones sobre la seguridad de la red, es que dificultará aún más la operación de los nodos completos. Especialmente en el contexto de una hoja de ruta centrada en "desvincular nodos completos", para resolver este problema es necesario entender primero el significado de la existencia de nodos completos.

La perspectiva tradicional considera que los nodos completos se utilizan para verificar los datos en la cadena. Si este es el único problema, entonces ZK-EVM podría desbloquear la escalabilidad de L1: la única limitación es mantener los costos de construcción de bloques y de pruebas lo suficientemente bajos, de modo que ambos puedan mantener la resistencia a la censura 1 de n y formar un mercado competitivo.

Pero en la realidad, esta no es la única consideración. Otro factor importante es que ejecutar un nodo completo te permite tener un servidor RPC local, lo que te permite leer datos en la cadena de manera sin necesidad de confianza, resistente a la censura y protegiendo la privacidad. Este artículo discutirá cómo ajustar la actual hoja de ruta de escalabilidad de L1 para lograr este objetivo.

1. ¿Por qué no estar satisfecho con la descentralización y la privacidad logradas a través de ZK-EVM+PIR?

La hoja de ruta de privacidad que publiqué el mes pasado aboga por la adopción de TEEs + ORAM a corto plazo y el cambio a la tecnología PIR a largo plazo. En combinación con la validación de Helios y ZK-EVM, los usuarios pueden conectarse a RPC externos con total confianza de que el (i) está obteniendo los datos de la cadena correctos y (ii) la privacidad de los datos está protegida. Esto plantea la pregunta: ¿por qué no detenerse allí? ¿Estos esquemas de criptografía avanzados hacen que los nodos autoalojados queden obsoletos?

A esto tengo algunas respuestas:

Los esquemas criptográficos completamente desconfianzados (como PIR de un solo servidor) son costosos. Los gastos actuales son demasiado altos para ser prácticos, y a pesar de múltiples optimizaciones de eficiencia, los precios pueden seguir siendo altos.

Problemas de privacidad de los metadatos. Los metadatos como la hora de la solicitud de la dirección IP y el patrón de solicitudes pueden revelar una gran cantidad de información del usuario.

Revisión de vulnerabilidades: la estructura del mercado dominada por unos pocos proveedores de RPC enfrentará una fuerte presión de bloqueo o censura por parte de los usuarios. Muchos proveedores de RPC han comenzado a bloquear completamente ciertos países.

Por lo tanto, continuar garantizando la conveniencia de funcionamiento de los nodos personales sigue siendo valioso.

2. Prioridades a corto plazo

Priorizar el despliegue completo de EIP-4444, logrando que cada nodo almacene solo alrededor de 36 días de datos. Esto reducirá significativamente la necesidad de espacio en disco, que es el principal obstáculo que impide a las personas operar nodos. Después de esto, los requisitos de almacenamiento de nodos incluirán solo: (i) datos de estado, (ii) ramas de Merkle de estado, (iii)36 días de datos históricos.

Construir un sistema de almacenamiento histórico distribuido, de modo que cada nodo almacene una pequeña cantidad de datos históricos obsoletos. Maximizar la fiabilidad mediante tecnología de códigos de borrado. Esto asegura tanto la característica de "almacenamiento permanente de la cadena de bloques" como la no dependencia de proveedores centralizados o la carga pesada para los operadores de nodos.

Ajustar la estrategia de precios de Gas, aumentar los costos de almacenamiento y reducir los costos de ejecución. Enfocarse en aumentar los costos de Gas de las siguientes operaciones: (i) ejecutar SSTORE para un nuevo espacio de almacenamiento (storage slot), (ii) crear código de contrato, (iii) transferir ETH a cuentas con saldo cero / nonce cero.

3. Objetivo a medio plazo: verificación sin estado

Después de implementar la verificación sin estado, los nodos que soportan RPC (es decir, los nodos que almacenan el estado) no tendrán que guardar la rama de Merkle del estado. Esto puede reducir aún más los requisitos de almacenamiento en aproximadamente un 50%.

4, Nuevos nodos: algunos nodos sin estado

Esta innovadora idea será clave para que los nodos personales sigan funcionando incluso después de aumentar el límite de gas de L1 entre 10 y 100 veces.

Hemos añadido un nuevo tipo de nodo: validar bloques de manera sin estado, validando toda la cadena a través de validación sin estado o ZK-EVM, pero manteniendo solo un subconjunto de los datos de estado. Siempre que los datos requeridos por la solicitud RPC se encuentren dentro de este subconjunto de estado, el nodo puede responder; otras solicitudes fallarán (o necesitarán retroceder a una solución criptográfica alojada externamente — si se debe retroceder, debe ser elección del usuario).

La mantenimiento de qué estados específicos depende de la configuración del usuario, por ejemplo:

Excluir todos los estados fuera de los contratos basura conocidos.

Estado relacionado con todas las cuentas EOA, SCW y los tokens y aplicaciones ERC20/ERC721 comunes.

Estado de cuentas EOA/SCW activas en los últimos dos años + estado de algunos de los tokens ERC20 más utilizados + estado de aplicaciones seleccionadas de swap/DeFi/privacidad.

La configuración se puede gestionar a través de contratos en la cadena: cuando el usuario ejecuta un nodo, utiliza el parámetro 「--save_state_by_config 0x12345...67890」. Esta dirección definirá una lista de direcciones que el nodo debe guardar y actualizar en tiempo real, así como los slots de almacenamiento (storage slot) o las reglas de filtrado de estado en un idioma específico. Tenga en cuenta que el usuario no necesita guardar la rama de Merkle, solo necesita guardar el valor original.

Este tipo de nodos puede proporcionar ventajas de acceso directo local a estados clave, al mismo tiempo que garantiza una privacidad de acceso completa.