Un agradecimiento especial a Micah Zoltu, Toni Wahrstätter, Justin Traglia y pcaversaccio por la discusión

La crítica más común de aumentar el límite de gas L1, más allá de las preocupaciones sobre la seguridad de la red, es que hace más difícil ejecutar un nodo completo.

Especialmente en el contexto de un roadmap centrado endesagregaciónel nodo completo, abordar esto requiere comprender para qué sirven los nodos completos.

Históricamente, se ha pensado que los nodos completos son para validar la cadena; veraquípara mi propia exposición de lo que podría suceder si los usuarios regulares no pueden verificar. Si este es el único problema, entonces la escalabilidad L1 se desbloquea mediante ZK-EVMs: el único límite es mantener los costos de construcción de bloques y de demostración lo suficientemente bajos como para que ambos puedan permanecer1-de-nresistente a la censura y un mercado competitivo.

Sin embargo, en realidad, esta no es realmente la única preocupación. La otra preocupación importante es: es valioso tener un nodo completo para que pueda tener un servidor RPC local que pueda usar para leer la cadena de manera confiable, resistente a la censura y amigable con la privacidad. Este documento discutirá los ajustes al actual plan de escalado L1 que hacen que esto suceda.

¿Por qué no detenerse con la falta de confianza y la privacidad a través de ZK-EVM + PIR?

La hoja de ruta de privacidad que publiqué el mes pasadose centra en TEEs +ORAMcomo un parche a corto plazo plusPIRcomo solución a largo plazo. Esto, junto con la verificación de Helios y ZK-EVM, permitiría a cualquier usuario conectarse a RPC externos y tener plena confianza en que (i) la cadena que están obteniendo es correcta y (ii) su privacidad de datos está protegida. Entonces, vale la pena hacer la pregunta: ¿por qué no detenerse aquí? ¿No hacen este tipo de soluciones criptográficas avanzadas que los nodos autohospedados sean un vestigio obsoleto?

Aquí puedo dar algunas respuestas:

• Las soluciones criptográficas totalmente confiables (es decir, PIR de 1 servidor) serán costosas. Actualmente, los costos indirectos son tan altos que resultan impracticables, y aun después de muchas mejoras de eficiencia es probable que sigan siendo costosos.
• Privacidad de metadatos. Los datos de qué dirección IP hace solicitudes en qué momentos, y el patrón de solicitudes, son suficientes para revelar mucha información sobre los usuarios.
• Vulnerabilidad a la censura: una estructura de mercado dominada por unos pocos proveedores de RPC es aquella que enfrentará una fuerte presión para desplataformar o censurar a los usuarios. Muchos proveedores de RPC ya excluyen países enteros.

Por estas razones, tiene valor seguir asegurando una mayor facilidad para ejecutar un nodo personal.

Prioridades a corto plazo

• Priorizar al máximo una implementación completa de EIP-4444, hasta llegar al estado final en el que cada nodo almacena datos durante solo ~36 días. Esto reduce en gran medida los requisitos de espacio en disco, que son el problema principal que impide que más personas ejecuten nodos. Después de esto, los requisitos de espacio en disco para un nodo serán (i) tamaño del estado, (ii) ramas Merkle del estado, (iii) 36 días de historial.
• Construir una solución de almacenamiento de historial distribuido, mediante la cual cada nodo pueda almacenar un pequeño porcentaje de datos históricos más antiguos que el límite. Utilizar codificación de borrado para maximizar la robustez. Esto garantiza la propiedad de que "un blockchain es para siempre" sin depender de proveedores centralizados o poner cargas pesadas en los operadores de nodos
• Ajustar el precio del gas para hacer que el almacenamiento sea más caro y la ejecución menos costosa. Una prioridad especialmente alta es aumentar el costo del gas de crear un nuevo estado: (i) SSTORE para nuevas ranuras de almacenamiento, (ii) creación de código de contrato, (iii) enviar ETH a cuentas que aún no tienen saldo o nonce.

Prioridad a medio plazo: verificación sin estado

Una vez que habilitamos la verificación sin estado, se vuelve posible ejecutar un nodo capaz de RPC (es decir, uno que almacena el estado) sin almacenar ramas de Merkle de estado. Esto reduce aún más los requisitos de almacenamiento en ~2x.

Un nuevo tipo de nodo: nodos parcialmente sin estado

Esta es la nueva idea, y será clave para permitir la operación de nodo personal incluso en un contexto donde el límite de gas L1 crezca de 10 a 100 veces.

Agregamos un tipo de nodo que verifica los bloques de manera sin estado, y verifica toda la cadena (ya sea a través de validación sin estado o ZK-EVM) y mantiene actualizada una parte del estado. El nodo es capaz de responder a las solicitudes RPC siempre que los datos requeridos estén dentro de ese subconjunto del estado; otras solicitudes fallarán (o tendrán que recurrir a una solución criptográfica alojada externamente; si hacerlo o no debe ser elección del usuario).

partial_statelessness.drawio776×341 19.9 KB

La parte exacta del estado que se mantendrá dependerá de una configuración elegida por el usuario. Algunos ejemplos podrían ser:

• Todos los estados excepto los contratos que se sabe que son spam
• Estado asociado con todas las EOAs y SCWs y todos los tokens y aplicaciones ERC20 y ERC721 comúnmente utilizados
• Estado asociado con todas las EOAs y SCWs a las que se ha accedido en los últimos dos años, algunos tokens ERC20 comúnmente utilizados, además de un conjunto limitado y seleccionado de aplicaciones de intercambio, defi y privacidad

La configuración podría ser gestionada por un contrato en cadena: un usuario ejecutaría su nodo con —save_state_by_config 0x12345…67890, y la dirección especificaría en algún lenguaje una lista de direcciones, espacios de almacenamiento u otras regiones filtradas del estado que el nodo guardaría y mantendría actualizadas. Tenga en cuenta que no es necesario que el usuario guarde ramas de Merkle; solo necesitan guardar los valores en bruto.

Este tipo de nodo proporcionaría los beneficios de acceso local directo al estado que un usuario necesita tener en cuenta, así como la máxima privacidad total de acceso a ese estado.

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [ethresear]. Todos los derechos de autor pertenecen al autor original [vbuterin]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.