Autor: Vitalik, fundador de Ethereum; Traducción: Jinse Caijing xiaozhou
La crítica más común a la elevación del límite de gas L1, además de las preocupaciones sobre la seguridad de la red, es que esto dificultará aún más la operación de 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 visión tradicional sostiene que los nodos completos se utilizan para verificar los datos en la cadena. Si este es el único problema, entonces ZK-EVM puede desbloquear la escalabilidad de L1: la única limitación es mantener el costo de construcción de bloques y pruebas lo suficientemente bajo, 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: ejecutar un nodo completo te permite tener un servidor RPC local, lo que te permite leer datos en la cadena de manera que no requiere confianza, es resistente a la censura y protege la privacidad. Este artículo discutirá cómo ajustar la hoja de ruta actual de escalabilidad L1 para lograr este objetivo.
1、¿Por qué no estar satisfecho con la descentralización y la privacidad logradas por ZK-EVM+PIR?
El mapa de ruta de privacidad que publiqué el mes pasado propone: adoptar a corto plazo la solución TEE+ORAM, y a largo plazo cambiar a la tecnología PIR. Combinando Helios y la verificación ZK-EVM, los usuarios pueden estar completamente seguros al conectar con RPC externos: (i) que los datos de la cadena obtenidos son correctos, (ii) que la privacidad de los datos está protegida. Esto plantea una pregunta: ¿por qué no detenerse aquí? ¿Acaso estos avanzados esquemas criptográficos han vuelto obsoletos a los nodos de autocustodia?
A esto tengo algunas respuestas:
--Las soluciones criptográficas completamente desconfianzadas (como el PIR de un solo servidor) son costosas. Los costos actuales son tan altos que no son prácticos, incluso después de múltiples optimizaciones de eficiencia, pueden seguir manteniendo precios elevados.
--Problemas de privacidad de los metadatos. La hora de la solicitud de la dirección IP, el patrón de solicitud y otros metadatos 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, seguir garantizando la conveniencia del funcionamiento de los nodos personales sigue siendo valioso.
2. Prioridades a corto plazo
Priorizar el despliegue completo de EIP-4444, logrando finalmente que cada nodo solo almacene aproximadamente 36 días de datos. Esto reducirá drásticamente la necesidad de espacio en disco, que actualmente es el principal obstáculo que impide a las personas operar nodos. A partir de entonces, los requisitos de almacenamiento de nodos incluirán solo: (i) datos de estado, (ii) ramas de Merkle de estado, (iii) datos históricos de 36 días.
Construir un esquema de almacenamiento histórico distribuido, donde cada nodo almacene una pequeña cantidad de datos históricos obsoletos. Maximizar la fiabilidad mediante la tecnología de código de borrado. De esta manera, se puede garantizar la característica de "almacenamiento permanente de blockchain" sin depender de proveedores centralizados o imponer una carga pesada a los operadores de nodos.
Ajustar la estrategia de precios del Gas, aumentar los costos de almacenamiento y reducir los costos de ejecución. Enfocarse en aumentar el costo del Gas para las siguientes operaciones: (i) para ejecutar SSTORE en un nuevo almacenamiento (storage slot), (ii) para crear código de contrato, (iii) para 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 estado) no necesitarán 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 mantener la operación de nodos individuales incluso después de que el límite de gas L1 se eleve de 10 a 100 veces.
Hemos añadido un nuevo tipo de nodo: validar bloques de manera sin estado, verificando toda la cadena a través de validación sin estado o ZK-EVM, pero solo manteniendo parte de los datos de estado. Siempre que los datos requeridos por la solicitud RPC estén dentro de este subconjunto de estado, el nodo podrá responder; otras solicitudes fallarán (o necesitarán retroceder a una solución criptográfica alojada externamente — si se debe retroceder debe ser elegido por el usuario).
El mantenimiento específico de qué estados depende de la configuración del usuario, por ejemplo:
--Excluir todos los estados excepto los contratos basura conocidos.
--Estado relacionado con todas las cuentas EOA, SCW y los tokens y aplicaciones ERC20/ERC721 más comunes.
--Estado de cuentas EOA/SCW activas en los últimos dos años + estado de algunos tokens ERC20 comunes + estado de aplicaciones seleccionadas de swap/DeFi/privacidad.
La configuración se puede gestionar a través de contratos en la cadena: cuando los usuarios ejecutan un nodo, utilizan el parámetro “--save_state_by_config 0x12345...67890”, y esta dirección definirá en un idioma específico la lista de direcciones que el nodo necesita guardar y actualizar en tiempo real, así como las ranuras de almacenamiento (storage slot) o las reglas de filtrado de estado. Tenga en cuenta que los usuarios no necesitan guardar la rama de Merkle, solo deben guardar el valor original.
Este tipo de nodos no solo puede proporcionar acceso local directo a estados clave, sino que también garantiza una privacidad de acceso total.
Ver originales
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: un plan de optimización de la hoja de ruta de escalado centrado en nodos locales
Autor: Vitalik, fundador de Ethereum; Traducción: Jinse Caijing xiaozhou
La crítica más común a la elevación del límite de gas L1, además de las preocupaciones sobre la seguridad de la red, es que esto dificultará aún más la operación de 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 visión tradicional sostiene que los nodos completos se utilizan para verificar los datos en la cadena. Si este es el único problema, entonces ZK-EVM puede desbloquear la escalabilidad de L1: la única limitación es mantener el costo de construcción de bloques y pruebas lo suficientemente bajo, 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: ejecutar un nodo completo te permite tener un servidor RPC local, lo que te permite leer datos en la cadena de manera que no requiere confianza, es resistente a la censura y protege la privacidad. Este artículo discutirá cómo ajustar la hoja de ruta actual de escalabilidad L1 para lograr este objetivo.
1、¿Por qué no estar satisfecho con la descentralización y la privacidad logradas por ZK-EVM+PIR?
El mapa de ruta de privacidad que publiqué el mes pasado propone: adoptar a corto plazo la solución TEE+ORAM, y a largo plazo cambiar a la tecnología PIR. Combinando Helios y la verificación ZK-EVM, los usuarios pueden estar completamente seguros al conectar con RPC externos: (i) que los datos de la cadena obtenidos son correctos, (ii) que la privacidad de los datos está protegida. Esto plantea una pregunta: ¿por qué no detenerse aquí? ¿Acaso estos avanzados esquemas criptográficos han vuelto obsoletos a los nodos de autocustodia?
A esto tengo algunas respuestas:
--Las soluciones criptográficas completamente desconfianzadas (como el PIR de un solo servidor) son costosas. Los costos actuales son tan altos que no son prácticos, incluso después de múltiples optimizaciones de eficiencia, pueden seguir manteniendo precios elevados.
--Problemas de privacidad de los metadatos. La hora de la solicitud de la dirección IP, el patrón de solicitud y otros metadatos 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, seguir garantizando la conveniencia del funcionamiento de los nodos personales sigue siendo valioso.
2. Prioridades a corto plazo
Priorizar el despliegue completo de EIP-4444, logrando finalmente que cada nodo solo almacene aproximadamente 36 días de datos. Esto reducirá drásticamente la necesidad de espacio en disco, que actualmente es el principal obstáculo que impide a las personas operar nodos. A partir de entonces, los requisitos de almacenamiento de nodos incluirán solo: (i) datos de estado, (ii) ramas de Merkle de estado, (iii) datos históricos de 36 días.
Construir un esquema de almacenamiento histórico distribuido, donde cada nodo almacene una pequeña cantidad de datos históricos obsoletos. Maximizar la fiabilidad mediante la tecnología de código de borrado. De esta manera, se puede garantizar la característica de "almacenamiento permanente de blockchain" sin depender de proveedores centralizados o imponer una carga pesada a los operadores de nodos.
Ajustar la estrategia de precios del Gas, aumentar los costos de almacenamiento y reducir los costos de ejecución. Enfocarse en aumentar el costo del Gas para las siguientes operaciones: (i) para ejecutar SSTORE en un nuevo almacenamiento (storage slot), (ii) para crear código de contrato, (iii) para 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 estado) no necesitarán 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 mantener la operación de nodos individuales incluso después de que el límite de gas L1 se eleve de 10 a 100 veces.
Hemos añadido un nuevo tipo de nodo: validar bloques de manera sin estado, verificando toda la cadena a través de validación sin estado o ZK-EVM, pero solo manteniendo parte de los datos de estado. Siempre que los datos requeridos por la solicitud RPC estén dentro de este subconjunto de estado, el nodo podrá responder; otras solicitudes fallarán (o necesitarán retroceder a una solución criptográfica alojada externamente — si se debe retroceder debe ser elegido por el usuario).
El mantenimiento específico de qué estados depende de la configuración del usuario, por ejemplo:
--Excluir todos los estados excepto los contratos basura conocidos.
--Estado relacionado con todas las cuentas EOA, SCW y los tokens y aplicaciones ERC20/ERC721 más comunes.
--Estado de cuentas EOA/SCW activas en los últimos dos años + estado de algunos tokens ERC20 comunes + estado de aplicaciones seleccionadas de swap/DeFi/privacidad.
La configuración se puede gestionar a través de contratos en la cadena: cuando los usuarios ejecutan un nodo, utilizan el parámetro “--save_state_by_config 0x12345...67890”, y esta dirección definirá en un idioma específico la lista de direcciones que el nodo necesita guardar y actualizar en tiempo real, así como las ranuras de almacenamiento (storage slot) o las reglas de filtrado de estado. Tenga en cuenta que los usuarios no necesitan guardar la rama de Merkle, solo deben guardar el valor original.
Este tipo de nodos no solo puede proporcionar acceso local directo a estados clave, sino que también garantiza una privacidad de acceso total.