Este artículo es de: cofundador de Ethereum Vitalik
Compilación | Odaily Planet Daily (@OdailyChina)
Traductor | Ethan（@ethanzhang_web3）
Además de las preocupaciones sobre la seguridad de la red, la crítica más común a aumentar el límite de Gas L1 es que esto dificultará la ejecución de nodos completos. En particular, en el contexto de un plan de ruta que se centra en la división de nodos completos, para abordar este problema, es necesario entender el papel de los nodos completos.
Históricamente, se ha considerado que un nodo completo se utiliza para validar los datos en la cadena; consulte aquí para conocer mi propia explicación sobre lo que podría suceder si los usuarios comunes no pueden validar. Si este es el único problema, entonces ZK-EVM puede desbloquear la extensión L1: la única limitación es mantener el costo de construcción de bloques y pruebas a un nivel suficientemente bajo, de modo que ambos puedan mantener la resistencia a la censura 1-of-n y la competitividad en el mercado.
Pero en realidad, este no es el único problema. Otro problema principal es que tener un nodo completo es muy valioso, ya que le permite tener un servidor RPC local para leer la cadena de una manera sin confianza, resistente a la censura y amigable con la privacidad. Este documento discutirá los ajustes realizados en la hoja de ruta actual de expansión de L1 para lograr este objetivo.
¿Por qué continuar implementando confianza cero y privacidad a través de ZK-EVM + PIR?
En la hoja de ruta de privacidad que publiqué el mes pasado, utilicé TEE + ORAM como un parche a corto plazo, y PIR como una solución a largo plazo. De esta manera, junto con la verificación de Helios y ZK-EVM, cualquier usuario puede conectarse a RPC externos y estar completamente seguro de que: (i) la cadena que obtienen es correcta; (ii) su privacidad de datos está protegida. Por lo tanto, no podemos evitar preguntarnos: ¿por qué no detenerse aquí? ¿No harán estas avanzadas soluciones de cifrado que los nodos auto-alojados se conviertan en reliquias obsoletas?
Aquí, puedo dar algunas respuestas:
Las soluciones criptográficas completamente sin confianza (es decir, 1-server PIR) serán muy caras. Los gastos actuales son demasiado altos para ser prácticos, y a pesar de múltiples mejoras en la eficiencia, es probable que sigan siendo caras.
Privacidad de los metadatos. Qué dirección IP hizo la solicitud y a qué hora, así como el patrón de la solicitud, estos datos por sí mismos son suficientes para revelar una gran cantidad de información sobre el usuario.
Revisión de vulnerabilidades: la estructura del mercado dominada por unos pocos proveedores de RPC enfrentará una fuerte presión para cancelar plataformas o censurar usuarios. Muchos proveedores de RPC ya han excluido a todo un país.
Por estas razones, continuar asegurando que sea más conveniente operar nodos personales es valioso.
Prioridades a corto plazo
Aumentar la prioridad de la promoción integral de EIP-4444, hasta que cada nodo almacene solo el estado final de aproximadamente 36 días de datos. Esto reducirá significativamente la demanda de espacio en disco, y la demanda de espacio en disco es el principal problema que impide que más personas ejecuten nodos. A partir de ahí, la demanda de espacio en disco de los nodos será: (i) tamaño del estado; (ii) rama Merkle del estado; (iii) 36 días de historial.
Construir soluciones de almacenamiento histórico distribuido, donde cada nodo puede almacenar una pequeña parte de datos históricos anteriores a la fecha límite. Utilizar códigos de borrado para maximizar la robustez. Esto puede asegurar la característica de que "la blockchain es eterna" sin depender de proveedores centralizados o imponer una pesada carga a los operadores de nodos.
Ajustar la fijación de Gas, aumentando el costo de almacenamiento y reduciendo el costo de ejecución. Se prioriza especialmente el aumento del costo de Gas para crear un nuevo estado: (i) SSTORE de un nuevo espacio de almacenamiento, (ii) creación de código de contrato, (iii) enviar ETH a cuentas que aún no tienen saldo o nonce.
Prioridades a medio plazo: validación sin estado
Una vez que habilitemos la verificación sin estado, será posible ejecutar nodos con funcionalidad RPC (es decir, nodos que almacenan estado) sin almacenar las ramas Merkle del estado. Esto reducirá aún más los requisitos de almacenamiento en aproximadamente 2 veces.
Un nuevo tipo de nodo: nodo sin estado parcial
Esta es una nueva idea y es clave para permitir que los nodos individuales funcionen en el caso de que el límite de Gas L1 crezca entre 10 y 100 veces.
Hemos añadido un tipo de nodo que puede validar bloques sin estado, validar toda la cadena (a través de validación sin estado o ZK-EVM) y mantener la parte del estado actualizada. Siempre que los datos necesarios estén dentro de ese subconjunto de estado, el nodo podrá responder a las solicitudes RPC; otras solicitudes fallarán (o deben ser retrocedidas a soluciones criptográficas alojadas externamente; si hacerlo es una opción del usuario).
La parte específica del estado a mantener depende de la configuración seleccionada por el usuario. A continuación se presentan ejemplos.
Todos los estados excepto los conocidos como contratos basura
Estado relacionado con todos los EOA y SCW, así como con todos los tokens y aplicaciones ERC 20 y ERC 721 más utilizados
Estado relacionado con todas las EOA y SCW visitadas en los últimos dos años, así como algunos tokens ERC 20 de uso común, más un conjunto limitado de aplicaciones de intercambio, defi y privacidad.
La configuración se puede gestionar a través de contratos en la cadena: los usuarios pueden ejecutar su nodo utilizando --save_state_by_config 0x 12345...67890; esta dirección especificará en algún idioma la dirección donde el nodo guardará y mantendrá el estado más reciente, lista de espacios de almacenamiento u otras áreas de filtrado. Tenga en cuenta que los usuarios no necesitan guardar la rama Merkle; solo necesitan guardar el valor original.
Este tipo de nodo permite a los usuarios acceder directamente en local al estado que necesitan observar, y maximiza la protección de la privacidad en el acceso a ese estado.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vitalik: Nueva solución para el problema de escalabilidad de Ethereum L1
Este artículo es de: cofundador de Ethereum Vitalik
Compilación | Odaily Planet Daily (@OdailyChina)
Traductor | Ethan（@ethanzhang_web3）
Además de las preocupaciones sobre la seguridad de la red, la crítica más común a aumentar el límite de Gas L1 es que esto dificultará la ejecución de nodos completos. En particular, en el contexto de un plan de ruta que se centra en la división de nodos completos, para abordar este problema, es necesario entender el papel de los nodos completos.
Históricamente, se ha considerado que un nodo completo se utiliza para validar los datos en la cadena; consulte aquí para conocer mi propia explicación sobre lo que podría suceder si los usuarios comunes no pueden validar. Si este es el único problema, entonces ZK-EVM puede desbloquear la extensión L1: la única limitación es mantener el costo de construcción de bloques y pruebas a un nivel suficientemente bajo, de modo que ambos puedan mantener la resistencia a la censura 1-of-n y la competitividad en el mercado.
Pero en realidad, este no es el único problema. Otro problema principal es que tener un nodo completo es muy valioso, ya que le permite tener un servidor RPC local para leer la cadena de una manera sin confianza, resistente a la censura y amigable con la privacidad. Este documento discutirá los ajustes realizados en la hoja de ruta actual de expansión de L1 para lograr este objetivo.
¿Por qué continuar implementando confianza cero y privacidad a través de ZK-EVM + PIR?
En la hoja de ruta de privacidad que publiqué el mes pasado, utilicé TEE + ORAM como un parche a corto plazo, y PIR como una solución a largo plazo. De esta manera, junto con la verificación de Helios y ZK-EVM, cualquier usuario puede conectarse a RPC externos y estar completamente seguro de que: (i) la cadena que obtienen es correcta; (ii) su privacidad de datos está protegida. Por lo tanto, no podemos evitar preguntarnos: ¿por qué no detenerse aquí? ¿No harán estas avanzadas soluciones de cifrado que los nodos auto-alojados se conviertan en reliquias obsoletas?
Aquí, puedo dar algunas respuestas:
Por estas razones, continuar asegurando que sea más conveniente operar nodos personales es valioso.
Prioridades a corto plazo
Prioridades a medio plazo: validación sin estado
Una vez que habilitemos la verificación sin estado, será posible ejecutar nodos con funcionalidad RPC (es decir, nodos que almacenan estado) sin almacenar las ramas Merkle del estado. Esto reducirá aún más los requisitos de almacenamiento en aproximadamente 2 veces.
Un nuevo tipo de nodo: nodo sin estado parcial
Esta es una nueva idea y es clave para permitir que los nodos individuales funcionen en el caso de que el límite de Gas L1 crezca entre 10 y 100 veces.
Hemos añadido un tipo de nodo que puede validar bloques sin estado, validar toda la cadena (a través de validación sin estado o ZK-EVM) y mantener la parte del estado actualizada. Siempre que los datos necesarios estén dentro de ese subconjunto de estado, el nodo podrá responder a las solicitudes RPC; otras solicitudes fallarán (o deben ser retrocedidas a soluciones criptográficas alojadas externamente; si hacerlo es una opción del usuario).
La parte específica del estado a mantener depende de la configuración seleccionada por el usuario. A continuación se presentan ejemplos.
La configuración se puede gestionar a través de contratos en la cadena: los usuarios pueden ejecutar su nodo utilizando --save_state_by_config 0x 12345...67890; esta dirección especificará en algún idioma la dirección donde el nodo guardará y mantendrá el estado más reciente, lista de espacios de almacenamiento u otras áreas de filtrado. Tenga en cuenta que los usuarios no necesitan guardar la rama Merkle; solo necesitan guardar el valor original.
Este tipo de nodo permite a los usuarios acceder directamente en local al estado que necesitan observar, y maximiza la protección de la privacidad en el acceso a ese estado.