Autor: Vitalik, fundador de Ethereum; Traducción: Jinse Finance cryptonaitive
A medida que Ethereum evoluciona de una tecnología joven y experimental a una pila de tecnología madura capaz de brindar una experiencia abierta, global y sin permiso a los usuarios comunes, hay tres transiciones tecnológicas principales que deben ocurrir simultáneamente:
El primero es la transformación de la expansión de la capacidad L2: todos recurren a la tecnología Rollup;
El segundo es la transformación de la seguridad de la billetera: todos comienzan a usar billeteras con contratos inteligentes;
La tercera es la transformación de la privacidad: garantizar que la funcionalidad de transferencia de fondos para preservar la privacidad esté disponible y garantizar que todas las demás herramientas que se están desarrollando (recuperación social, verificación de identidad, reputación, etc.) tengan características para preservar la privacidad.
*Triángulo de transformación del ecosistema Ethereum. Solo puedes elegir los tres. *
Sin el primer elemento, Ethereum fallará porque cada transacción cuesta $ 3,75 ($ 82,48 si pasamos por otra carrera alcista), y cada producto del mercado masivo inevitablemente abandonará el comercio en cadena y adoptará una solución centralizada.
Sin el segundo elemento, Ethereum fallaría ya que los usuarios no estarían dispuestos a almacenar sus fondos (y activos no financieros) y todos recurrirían a intercambios centralizados.
Sin el tercer elemento, Ethereum fallaría porque para muchos usuarios, todas las transacciones (y POAP, etc.) serían visibles públicamente, el sacrificio de la privacidad sería demasiado grande y todos recurrirían al menos a algún nivel de solución centralizada de datos ocultos.
Por las razones descritas anteriormente, estas tres transiciones son críticas. Pero también son desafiantes debido a la complejidad de la coordinación involucrada. No es solo la funcionalidad del protocolo lo que debe mejorarse; en algunos casos, la forma en que interactuamos con Ethereum debe cambiar de manera fundamental y profunda, lo que requiere cambios importantes en las aplicaciones y las billeteras.
Estas tres transformaciones remodelarán fundamentalmente la relación entre usuarios y direcciones
En un mundo de escalamiento L2, los usuarios existirán en múltiples redes L2. ¿Eres miembro de ExampleDAO? ExampleDAO está en el optimismo. ¡Entonces tienes una cuenta en Optimism! ¿Tiene un CDP de un sistema de moneda estable en ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Alguna vez has probado algunas de las aplicaciones ubicadas en Kakarotto? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que los usuarios solo tenían una dirección.
*Mi vista de billetera Brave, tengo Ethereum en cuatro lugares. Sí, Arbitrum y Arbitrum Nova son diferentes. ¡No te preocupes, las cosas se complicarán con el tiempo! *
**Las billeteras de contrato inteligente agregan más complejidad, ya que hace que sea más difícil tener la misma dirección en L1 y varias redes L2. **La mayoría de los usuarios de hoy usan cuentas de propiedad externa cuyas direcciones son en realidad hashes de las claves públicas utilizadas para verificar las firmas, por lo que nada cambia entre L1 y L2. Sin embargo, mantener una dirección se vuelve más difícil cuando se usa una billetera de contrato inteligente. Si bien se ha trabajado mucho para tratar de hacer que las direcciones sean un hash de código que sea equivalente en diferentes redes, siendo las más importantes CREATE2 y ERC-2470 singleton factory, es difícil lograrlo a la perfección. Algunas redes L2 (por ejemplo, "ZK-EVM del cuarto tipo") no son exactamente equivalentes a las EVM, a menudo usan Solidity o lenguaje ensamblador intermedio en lugar de equivalentes hash. Incluso si se pudiera lograr la equivalencia de hash, la posibilidad de que las billeteras cambien de propietario a través de cambios clave conduce a otras consecuencias menos predecibles.
**La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones que manejamos. **Si la propuesta de dirección sigilosa se usa ampliamente, los usuarios pueden tener una dirección por transacción en lugar de solo unas pocas direcciones por usuario o una dirección por red L2. Otros esquemas de privacidad, incluso los existentes como Tornado Cash, cambian la forma en que se almacenan los activos de diferentes maneras: los fondos de muchos usuarios se almacenan en el mismo contrato inteligente (y, por lo tanto, en la misma dirección). Para enviar fondos a un usuario específico, el usuario deberá confiar en el propio sistema de direccionamiento interno del esquema de privacidad.
Como hemos visto, estas tres transformaciones debilitan el modelo mental "un usuario ≈ una dirección" de diferentes maneras, algunos de cuyos efectos a su vez aumentan la complejidad de ejecutar estas transformaciones. Dos de los temas particularmente complejos son:
**1. Si desea pagarle a alguien, ¿cómo obtendrá la información de pago? **
**2. Si los usuarios almacenan activos en diferentes ubicaciones en diferentes cadenas, ¿cómo realizan los cambios clave y la recuperación social? **
Estas tres transformaciones y pagos en cadena (e identidad)
Tengo fichas en Scroll y quiero usarlas para comprar café (si la "I" literal se refiere a Vitalik, el autor de este artículo, entonces "café", por supuesto, significa "té verde"). Vendes café en Taiko, pero solo aceptas tokens en Taiko. ¿qué hacer?
Básicamente hay dos soluciones:
La billetera receptora (que puede ser un comerciante o un individuo común) se esfuerza por respaldar cada L2 y tiene algunas funciones de fusión de fondos asíncronos.
El beneficiario proporciona su información L2 junto a la dirección, y la billetera del remitente enruta automáticamente los fondos a la L2 de destino a través de algún tipo de sistema puente entre L2.
Por supuesto, estas soluciones se pueden usar en combinación: el beneficiario proporciona la lista L2 que está dispuesto a aceptar, y la billetera del remitente determina el método de pago, que se puede enviar directamente (con suerte) o pagar a través de una ruta puente a través del L2.
Pero este es solo un ejemplo de un desafío clave presentado por las tres transformaciones: Los comportamientos de pago simples comienzan a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, cambiar a billeteras de contratos inteligentes no es una carga enorme para el sistema de direcciones, pero todavía hay algunos problemas técnicos que deben resolverse en otras partes de la pila de aplicaciones. Las billeteras deben actualizarse para garantizar que no solo envíen 21000 gas al enviar transacciones, sino que se debe prestar más atención para garantizar que el extremo receptor de la billetera rastree no solo las transferencias ETH desde el EOA, sino también las transferencias ETH desde el código de contrato inteligente. Las aplicaciones que se basan en la propiedad inmutable de las direcciones (por ejemplo, NFT que prohíben los contratos inteligentes para hacer cumplir las regalías) tendrán que encontrar otras formas de lograr sus objetivos. Las billeteras de contrato inteligente también facilitarán algunas cosas, especialmente si alguien solo acepta tokens ERC20 que no son ETH, podrá usar un pagador ERC-4337 para pagar el gas usando ese token.
Por otro lado, el tema de la privacidad vuelve a ser un gran desafío que aún no hemos resuelto realmente. El Tornado Cash original no presentaba estos problemas porque no admitía transferencias internas: los usuarios solo podían depositar y retirar dinero en el sistema. Sin embargo, una vez que las transferencias internas sean posibles, los usuarios deberán utilizar el esquema de direccionamiento interno del sistema de privacidad. En la práctica, el "mensaje de pago" del usuario deberá contener (i) algún tipo de "clave pública de gasto", un compromiso secreto que el receptor puede usar para gastar, y (ii) el remitente puede enviar mensajes encriptados que solo el receptor puede descifrar El destinatario de la ayuda descubre el método de pago.
El protocolo Stealth de dirección se basa en el concepto de una metadirección, que funciona de la siguiente manera: parte de la metadirección es la clave de gasto engañada del remitente y la otra parte es la clave cifrada del remitente (aunque una implementación mínima podría configurar ambas claves ser lo mismo).
Una descripción general de los esquemas abstractos de direcciones sigilosas basados en cifrado y ZK-SNARK
Una lección clave aquí es que **en un ecosistema amigable con la privacidad, el usuario tendrá tanto la clave pública de gasto como la clave pública de cifrado, y la "información de pago" del usuario deberá contener ambas claves. **Además de pagar, hay otras buenas razones para expandir esta dirección. Por ejemplo, si queremos correos electrónicos cifrados basados en Ethereum, los usuarios deberán proporcionar públicamente algún tipo de clave de cifrado. En el "mundo EOA" podríamos reutilizar claves de cuenta, pero en el mundo de las billeteras seguras de contratos inteligentes, probablemente deberíamos proporcionar una funcionalidad más explícita para esto. Esto también ayuda a que las identidades basadas en Ethereum sean más compatibles con los ecosistemas de privacidad descentralizados que no son de Ethereum, especialmente las claves PGP.
Estas tres transiciones y recuperación de claves
En un mundo donde cada usuario tiene varias direcciones, la forma predeterminada de implementar cambios clave y la recuperación social es hacer que los usuarios ejecuten el proceso de recuperación en cada dirección individualmente. Esto se puede hacer con un solo clic: la billetera puede proporcionar una función de software para realizar el proceso de recuperación simultáneamente en todas las direcciones del usuario. Sin embargo, incluso con esta simplificación de la experiencia del usuario, existen tres problemas con la recuperación de direcciones múltiples:
1. El costo de la gasolina no es realista: Esto es evidente.
2. Direcciones contrafactuales: direcciones que aún no han emitido un contrato inteligente (en realidad, esto significará cuentas desde las que aún no ha enviado fondos). Como usuario, puede tener una cantidad infinita de direcciones virtuales: una o más en cada L2, incluidas las L2 que aún no existen, y todo un conjunto infinito de direcciones virtuales que surgen del esquema de direcciones ocultas.
3. Privacidad: si un usuario usa intencionalmente varias direcciones para evitar asociarlas entre sí, entonces ciertamente no querrá asociarlas todas públicamente restaurándolas al mismo tiempo o casi al mismo tiempo.
Resolver estos problemas es difícil. Afortunadamente, existe una solución bastante elegante que funciona bastante bien: Esta arquitectura separa la lógica de validación de la tenencia de activos.
Cada usuario tiene un contrato de almacén de claves que existe en una ubicación (podría ser la red principal o una L2 específica). Luego, los usuarios tienen direcciones en diferentes L2 y la lógica de verificación para cada dirección es un puntero al contrato de almacenamiento de claves. Gastar fondos de estas direcciones requerirá proporcionar una prueba de una clave pública de gasto actual (o más realista, muy reciente) para los fondos.
Esta prueba se puede lograr de varias maneras:
** Acceso de solo lectura a L1 directamente dentro de L2. ** L2 se puede modificar para permitirle leer el estado L1 directamente. Si el contrato del almacén de claves está en L1, significa que los contratos en L2 tienen acceso "gratuito" al almacén de claves.
**Sucursales Merkle. **Las ramas de Merkle pueden probar el estado L1 a L2, o el estado L2 a L1, o una combinación de ambos puede probar el estado parcial de una L2 a otra L2. La principal debilidad de las pruebas de Merkle es el alto costo del gas debido a la longitud de la prueba, que puede requerir una longitud de prueba de 5kB, pero debido al uso de árboles de Verkle, esto se reducirá a <1kB en el futuro.
**ZK-SNARK. **Puede reducir los costos de datos usando ZK-SNARKs de las sucursales de Merkle en lugar de usar las propias sucursales. Se pueden construir técnicas de agregación fuera de la cadena (p. ej., encima de EIP-4337) para permitir que un solo ZK-SNARK verifique todas las pruebas de estado de cadena cruzada en un bloque.
** Promesa KZG. **Ya sea L2 o el esquema construido sobre él, se puede introducir un sistema de direccionamiento secuencial, lo que permite que la prueba de estado dentro del sistema sea de solo 48 bytes. Al igual que los ZK-SNARK, los esquemas de pruebas múltiples pueden combinar todas estas pruebas en una sola prueba para cada bloque.
Si queremos evitar la necesidad de una prueba para cada transacción, podemos implementar un esquema más ligero que solo requiera la recuperación en las pruebas L2. El gasto de una cuenta dependería de una clave de gasto con su clave pública correspondiente almacenada dentro de la cuenta, pero la recuperación requeriría una transacción para copiar la clave pública de gasto actual en el almacén de claves. Incluso si sus claves anteriores no son seguras, los fondos en la dirección virtual están seguros: "activar" la dirección virtual para convertirla en un contrato utilizable requerirá una prueba cruzada L2 para replicar la clave pública de gasto actual. Hay un hilo en los foros de Safe que describe cómo funciona una arquitectura similar.
Para agregar privacidad a dicho esquema, solo necesitamos encriptar punteros y hacer todas las pruebas dentro de ZK-SNARKs:
Con más trabajo (por ejemplo, usando este trabajo como punto de partida), también podemos quitar ZK: la mayor parte de la complejidad de SNARK, creando un esquema basado en KZG más simplificado.
Estos escenarios pueden complicarse. La ventaja es que hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contrato de almacén de claves" también puede ser una solución a la "dirección" mencionada en la sección anterior: si queremos que los usuarios tengan una dirección persistente que no cambie cada vez que el usuario actualice la clave, debemos puede poner el sigilo La dirección meta, la clave de cifrado y otra información se colocan en el contrato del almacén de claves, y la dirección del contrato del almacén de claves se utiliza como la "dirección" del usuario.
Mucha infraestructura secundaria necesita ser actualizada
Usar ENS es costoso. Aunque no es tan caro como antes en junio de 2023, la tarifa de transacción para registrar un nombre de dominio sigue siendo relativamente alta, comparable al costo de un nombre de dominio ENS. Por ejemplo, cuesta alrededor de $ 27 registrarse en zuzalu.eth, $ 11 de los cuales son tarifas de transacción. Pero si el mercado vuelve a ser alcista, las tarifas se dispararán. Incluso si el precio de ETH no aumenta, si la tarifa del gas vuelve a 200 gwei, la tarifa de transacción para el registro del nombre de dominio alcanzará los $104. Entonces, si queremos que las personas realmente usen ENS, especialmente para casos de uso como redes sociales descentralizadas donde los usuarios solicitan un registro casi gratuito (las tarifas de dominio de ENS no son un problema ya que estas plataformas pueden proporcionar subdominios a los usuarios), necesitamos que ENS se use en Capa 2.
Afortunadamente, el equipo de ENS ya ha dado un paso al frente y ¡ENS se está implementando en la Capa 2! ERC-3668 (también conocido como el "estándar CCIP") y ENSIP-10 proporcionan una forma de verificar automáticamente los subdominios ENS en cualquier Capa 2. El estándar CCIP requiere establecer un contrato inteligente que describa el método para verificar las pruebas de datos en la Capa 2, y un nombre de dominio (por ejemplo, ecc.eth para Optinames) puede colocarse bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, al acceder a un cierto subdominio.ecc.eth se encontrará y verificará automáticamente una prueba que almacene el estado de Capa 2 de ese subdominio específico (por ejemplo, una sucursal de Merkle).
en realidad, obtener estas pruebas implica acceder a una lista de URL almacenadas en el contrato, aunque esto es De alguna manera, puede parecer una centralización, pero diría que en realidad no lo es: es un modelo de confianza de 1 a N (las pruebas no válidas son detectadas por la lógica de validación en la función de devolución de llamada del contrato CCIP, siempre que uno de los A URL que devuelve una prueba válida está bien). La lista de URL puede contener docenas de URL.
**El esfuerzo CCIP de ENS es una historia de éxito y debe verse como una señal de que las reformas radicales que necesitamos son realmente posibles. ** Pero todavía hay muchas reformas a nivel de aplicación que deben realizarse. Aquí hay unos ejemplos:
**Muchas DApps dependen de los usuarios para proporcionar firmas fuera de la cadena. **Para cuentas externas (EOA), es fácil. ERC-1271 proporciona una forma estandarizada de hacer esto para billeteras de contrato inteligente. Sin embargo, muchas DApps aún no son compatibles con ERC-1271 y deben adaptarse.
** Las DApps que usan "¿es esto un EOA?" para diferenciar entre usuarios y contratos (por ejemplo, para evitar transferencias o hacer cumplir regalías) tendrán problemas. **En general, desaconsejaría tratar de encontrar una solución puramente técnica aquí; determinar si una transferencia de control criptográfico en particular es una transferencia de titularidad real es un problema difícil que puede no resolverse sin recurrir a alguna iniciativa comunitaria fuera de la cadena. Los mecanismos resuelven. Lo más probable es que las aplicaciones se basen menos en medios técnicos para bloquear transferencias y más en técnicas como el impuesto Harberger.
**La interacción de la billetera con pagos y claves de encriptación necesitará mejoras. **Actualmente, las billeteras generalmente usan firmas deterministas para generar claves específicas de la aplicación: firmar un nonce estándar (por ejemplo, un hash del nombre de la aplicación) con la clave privada de EOA generará un valor determinista a menos que la clave privada esté en posesión, de lo contrario, el valor no se puede generar y, por lo tanto, es puramente técnicamente seguro. Sin embargo, estas técnicas son "opacas" para la billetera, lo que impide que las billeteras implementen controles de seguridad a nivel de interfaz de usuario. En un ecosistema más maduro, la firma, el cifrado y las funciones relacionadas deberán ser manejadas de manera más explícita por las billeteras.
Los clientes ligeros (como Helios) deberán autenticar la Capa 2 en lugar de solo la Capa 1**. **Actualmente, el cliente ligero se centra en verificar la validez de la información del encabezado del bloque L1 (usando el protocolo de sincronización del cliente ligero) y verificar la rama Merkle del estado L1 y las transacciones basadas en la información del encabezado del bloque L1. En el futuro, también deberán verificar las pruebas del estado L2 enraizado en la raíz del estado almacenada en L1 (las versiones más avanzadas en realidad verán la confirmación previa de L2).
Las carteras deberán proteger los activos y los datos
Actualmente, la misión de la billetera es proteger los activos. Todo se almacena en la cadena, todo lo que la billetera necesita proteger son las claves privadas que actualmente protegen estos activos. Si cambia la clave, puede publicar de forma segura la clave privada anterior en Internet al día siguiente. Sin embargo, en un mundo de conocimiento cero, este ya no es el caso: las billeteras no solo protegen las credenciales de autenticación, sino que también guardan sus datos.
Vemos los primeros signos de un mundo así en Zuzalu con Zupass, un sistema de identidad basado en ZK-SNARK. El usuario tiene una clave privada que se usa para autenticarse en el sistema, que se puede usar para generar pruebas básicas como "demostrar que soy residente de Zuzalu sin revelar qué residente soy". El sistema Zupass también comenzó a crear otras aplicaciones, sobre todo sellos (la versión de Zupass de POAP).
*Uno de mis muchos sellos Zupass que confirma que soy miembro del Team Cat. *
La característica clave de los sellos en relación con POAP es que son privados: guarda los datos localmente y solo prueba un sello para su ZK (o realiza algún cálculo en los sellos) si desea brindar esa información a alguien. Pero esto también conlleva un riesgo adicional: si pierde esa información, perderá sus sellos.
Por supuesto, el problema de mantener los datos se puede reducir al problema de tener una sola clave de cifrado: un tercero (incluso en la cadena) puede tener una copia cifrada de los datos. Esto tiene la conveniente ventaja de que la acción que realiza no cambia la clave de cifrado, por lo que no se requiere interacción con el sistema que contiene la clave de cifrado. Pero incluso entonces, si pierde la clave de cifrado, perderá todos sus datos. Y, a su vez, si alguien ve tu clave de encriptación, podrá ver todo lo encriptado con esa clave. **
La solución práctica de Zupass es alentar a las personas a almacenar sus claves en varios dispositivos (como una computadora portátil y un teléfono), ya que las posibilidades de que pierdan el acceso a todos ellos al mismo tiempo son escasas. Podemos ir un paso más allá al usar el uso compartido de claves para dividir el almacenamiento de claves entre varios protectores.
La recuperación social a través de MPC no es una solución adecuada para las billeteras, ya que significa que no solo el protector actual, sino también los protectores anteriores podrían coludirse para robar sus activos, lo cual es un riesgo inaceptablemente alto. Si bien una violación de la privacidad suele ser menos riesgosa que una pérdida completa de activos, para casos de uso con necesidades de privacidad altas, se puede aceptar un mayor riesgo de pérdida si no se realiza una copia de seguridad de las claves asociadas con esas necesidades de privacidad.
Para evitar atascar a los usuarios en un sistema complejo de múltiples rutas de recuperación, es posible que las billeteras que admiten la recuperación social deban administrar ambos aspectos, la recuperación de activos y la recuperación de claves de cifrado.
Volver a la identidad
Un tema común entre estos cambios es que el concepto de una "dirección" como representación de la identidad en la cadena de bloques deberá cambiar fundamentalmente. ** "Instrucciones sobre cómo interactuar conmigo" ya no será solo una dirección ETH; express. **
Una de estas formas es usar ENS como su identidad: su registro de ENS puede contener toda la información sobre cómo pagar e interactuar con usted, si envía a alguien bob.eth (o bob.ecc.eth, etc.), pueden consultar y aprenda sobre todo lo que interactúa con usted, incluso de formas más complejas entre dominios y con protección de la privacidad.
Sin embargo, este enfoque centrado en ENS adolece de dos debilidades:
**Asocia demasiado contenido a tu nombre. **Tu nombre no significa todo sobre ti, es solo uno de los muchos atributos sobre ti. Debería ser posible cambiar su nombre sin migrar todo su perfil de identidad y actualizar registros en muchas aplicaciones.
**No puede tener nombres contrafácticos que no requieran confianza. **Una característica clave de la experiencia del usuario de cualquier cadena de bloques es la capacidad de enviar tokens a personas que aún no han interactuado con la cadena. Sin dicha funcionalidad, existe un dilema: interactuar con la cadena requiere pagar tarifas de transacción, y pagar tarifas de transacción requiere... ya poseer tokens. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta funcionalidad. Los nombres de ENS no lo hacen, porque si ambos Bobs deciden fuera de la cadena que son bob.ecc.eth, no hay forma de elegir qué Bob recibe el nombre.
Una posible solución es poner más contenido en el contrato de almacén de claves mencionado anteriormente en la arquitectura de este artículo. Un contrato de almacén de claves puede contener diversa información sobre usted e interacciones con usted (y con CCIP, parte de esta información puede estar fuera de la cadena), los usuarios utilizarán su contrato de almacén de claves como su identificador principal. Sin embargo, los activos que realmente reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves son independientes del nombre y admiten nombres virtuales: puede generar una dirección que solo puede inicializarse mediante un contrato de almacén de claves con ciertos parámetros iniciales fijos.
Otra clase de soluciones implica abandonar por completo la noción de direcciones orientadas al usuario, similar al protocolo de pago de Bitcoin. Una idea es confiar más en los canales de comunicación directos entre el remitente y el receptor; por ejemplo, el remitente podría enviar un enlace de solicitud (como una URL explícita o un código QR), que el receptor podría usar para enviar cualquier solicitud que desee aceptar. pago.
Ya sea el remitente o el destinatario quien actúa primero, depender más de las billeteras para generar información de pago actualizada en tiempo real reduce la fricción. Sin embargo, los identificadores persistentes son convenientes (especialmente con ENS), mientras que en la práctica confiar en la comunicación directa entre el remitente y el receptor es un problema muy complicado, por lo que se puede ver una combinación de diferentes técnicas.
En todos estos diseños, es fundamental permanecer descentralizado y comprensible para los usuarios. Necesitamos asegurarnos de que los usuarios puedan acceder fácilmente a una vista actualizada de sus activos actuales y mensajes dirigidos a ellos. Estas vistas deben basarse en herramientas abiertas en lugar de soluciones propietarias. Se necesitará mucho trabajo para evitar que la mayor complejidad de la infraestructura de pago se convierta en una "torre de abstracción" opaca que es difícil de entender y adaptar a los nuevos entornos. A pesar de los desafíos, es primordial lograr la escalabilidad, la seguridad de la billetera y la privacidad de Ethereum para los usuarios comunes. No se trata solo de la viabilidad técnica, se trata de la accesibilidad real para el usuario promedio. Tenemos que hacer frente a este desafío.
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: El ecosistema Ethereum necesita tres transformaciones tecnológicas
Autor: Vitalik, fundador de Ethereum; Traducción: Jinse Finance cryptonaitive
A medida que Ethereum evoluciona de una tecnología joven y experimental a una pila de tecnología madura capaz de brindar una experiencia abierta, global y sin permiso a los usuarios comunes, hay tres transiciones tecnológicas principales que deben ocurrir simultáneamente:
*Triángulo de transformación del ecosistema Ethereum. Solo puedes elegir los tres. *
Sin el primer elemento, Ethereum fallará porque cada transacción cuesta $ 3,75 ($ 82,48 si pasamos por otra carrera alcista), y cada producto del mercado masivo inevitablemente abandonará el comercio en cadena y adoptará una solución centralizada.
Sin el segundo elemento, Ethereum fallaría ya que los usuarios no estarían dispuestos a almacenar sus fondos (y activos no financieros) y todos recurrirían a intercambios centralizados.
Sin el tercer elemento, Ethereum fallaría porque para muchos usuarios, todas las transacciones (y POAP, etc.) serían visibles públicamente, el sacrificio de la privacidad sería demasiado grande y todos recurrirían al menos a algún nivel de solución centralizada de datos ocultos.
Por las razones descritas anteriormente, estas tres transiciones son críticas. Pero también son desafiantes debido a la complejidad de la coordinación involucrada. No es solo la funcionalidad del protocolo lo que debe mejorarse; en algunos casos, la forma en que interactuamos con Ethereum debe cambiar de manera fundamental y profunda, lo que requiere cambios importantes en las aplicaciones y las billeteras.
Estas tres transformaciones remodelarán fundamentalmente la relación entre usuarios y direcciones
En un mundo de escalamiento L2, los usuarios existirán en múltiples redes L2. ¿Eres miembro de ExampleDAO? ExampleDAO está en el optimismo. ¡Entonces tienes una cuenta en Optimism! ¿Tiene un CDP de un sistema de moneda estable en ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Alguna vez has probado algunas de las aplicaciones ubicadas en Kakarotto? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que los usuarios solo tenían una dirección.
**Las billeteras de contrato inteligente agregan más complejidad, ya que hace que sea más difícil tener la misma dirección en L1 y varias redes L2. **La mayoría de los usuarios de hoy usan cuentas de propiedad externa cuyas direcciones son en realidad hashes de las claves públicas utilizadas para verificar las firmas, por lo que nada cambia entre L1 y L2. Sin embargo, mantener una dirección se vuelve más difícil cuando se usa una billetera de contrato inteligente. Si bien se ha trabajado mucho para tratar de hacer que las direcciones sean un hash de código que sea equivalente en diferentes redes, siendo las más importantes CREATE2 y ERC-2470 singleton factory, es difícil lograrlo a la perfección. Algunas redes L2 (por ejemplo, "ZK-EVM del cuarto tipo") no son exactamente equivalentes a las EVM, a menudo usan Solidity o lenguaje ensamblador intermedio en lugar de equivalentes hash. Incluso si se pudiera lograr la equivalencia de hash, la posibilidad de que las billeteras cambien de propietario a través de cambios clave conduce a otras consecuencias menos predecibles.
**La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones que manejamos. **Si la propuesta de dirección sigilosa se usa ampliamente, los usuarios pueden tener una dirección por transacción en lugar de solo unas pocas direcciones por usuario o una dirección por red L2. Otros esquemas de privacidad, incluso los existentes como Tornado Cash, cambian la forma en que se almacenan los activos de diferentes maneras: los fondos de muchos usuarios se almacenan en el mismo contrato inteligente (y, por lo tanto, en la misma dirección). Para enviar fondos a un usuario específico, el usuario deberá confiar en el propio sistema de direccionamiento interno del esquema de privacidad.
Como hemos visto, estas tres transformaciones debilitan el modelo mental "un usuario ≈ una dirección" de diferentes maneras, algunos de cuyos efectos a su vez aumentan la complejidad de ejecutar estas transformaciones. Dos de los temas particularmente complejos son:
**1. Si desea pagarle a alguien, ¿cómo obtendrá la información de pago? **
**2. Si los usuarios almacenan activos en diferentes ubicaciones en diferentes cadenas, ¿cómo realizan los cambios clave y la recuperación social? **
Estas tres transformaciones y pagos en cadena (e identidad)
Tengo fichas en Scroll y quiero usarlas para comprar café (si la "I" literal se refiere a Vitalik, el autor de este artículo, entonces "café", por supuesto, significa "té verde"). Vendes café en Taiko, pero solo aceptas tokens en Taiko. ¿qué hacer?
Básicamente hay dos soluciones:
La billetera receptora (que puede ser un comerciante o un individuo común) se esfuerza por respaldar cada L2 y tiene algunas funciones de fusión de fondos asíncronos.
El beneficiario proporciona su información L2 junto a la dirección, y la billetera del remitente enruta automáticamente los fondos a la L2 de destino a través de algún tipo de sistema puente entre L2.
Por supuesto, estas soluciones se pueden usar en combinación: el beneficiario proporciona la lista L2 que está dispuesto a aceptar, y la billetera del remitente determina el método de pago, que se puede enviar directamente (con suerte) o pagar a través de una ruta puente a través del L2.
Pero este es solo un ejemplo de un desafío clave presentado por las tres transformaciones: Los comportamientos de pago simples comienzan a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, cambiar a billeteras de contratos inteligentes no es una carga enorme para el sistema de direcciones, pero todavía hay algunos problemas técnicos que deben resolverse en otras partes de la pila de aplicaciones. Las billeteras deben actualizarse para garantizar que no solo envíen 21000 gas al enviar transacciones, sino que se debe prestar más atención para garantizar que el extremo receptor de la billetera rastree no solo las transferencias ETH desde el EOA, sino también las transferencias ETH desde el código de contrato inteligente. Las aplicaciones que se basan en la propiedad inmutable de las direcciones (por ejemplo, NFT que prohíben los contratos inteligentes para hacer cumplir las regalías) tendrán que encontrar otras formas de lograr sus objetivos. Las billeteras de contrato inteligente también facilitarán algunas cosas, especialmente si alguien solo acepta tokens ERC20 que no son ETH, podrá usar un pagador ERC-4337 para pagar el gas usando ese token.
Por otro lado, el tema de la privacidad vuelve a ser un gran desafío que aún no hemos resuelto realmente. El Tornado Cash original no presentaba estos problemas porque no admitía transferencias internas: los usuarios solo podían depositar y retirar dinero en el sistema. Sin embargo, una vez que las transferencias internas sean posibles, los usuarios deberán utilizar el esquema de direccionamiento interno del sistema de privacidad. En la práctica, el "mensaje de pago" del usuario deberá contener (i) algún tipo de "clave pública de gasto", un compromiso secreto que el receptor puede usar para gastar, y (ii) el remitente puede enviar mensajes encriptados que solo el receptor puede descifrar El destinatario de la ayuda descubre el método de pago.
El protocolo Stealth de dirección se basa en el concepto de una metadirección, que funciona de la siguiente manera: parte de la metadirección es la clave de gasto engañada del remitente y la otra parte es la clave cifrada del remitente (aunque una implementación mínima podría configurar ambas claves ser lo mismo).
Una descripción general de los esquemas abstractos de direcciones sigilosas basados en cifrado y ZK-SNARK
Una lección clave aquí es que **en un ecosistema amigable con la privacidad, el usuario tendrá tanto la clave pública de gasto como la clave pública de cifrado, y la "información de pago" del usuario deberá contener ambas claves. **Además de pagar, hay otras buenas razones para expandir esta dirección. Por ejemplo, si queremos correos electrónicos cifrados basados en Ethereum, los usuarios deberán proporcionar públicamente algún tipo de clave de cifrado. En el "mundo EOA" podríamos reutilizar claves de cuenta, pero en el mundo de las billeteras seguras de contratos inteligentes, probablemente deberíamos proporcionar una funcionalidad más explícita para esto. Esto también ayuda a que las identidades basadas en Ethereum sean más compatibles con los ecosistemas de privacidad descentralizados que no son de Ethereum, especialmente las claves PGP.
Estas tres transiciones y recuperación de claves
En un mundo donde cada usuario tiene varias direcciones, la forma predeterminada de implementar cambios clave y la recuperación social es hacer que los usuarios ejecuten el proceso de recuperación en cada dirección individualmente. Esto se puede hacer con un solo clic: la billetera puede proporcionar una función de software para realizar el proceso de recuperación simultáneamente en todas las direcciones del usuario. Sin embargo, incluso con esta simplificación de la experiencia del usuario, existen tres problemas con la recuperación de direcciones múltiples:
1. El costo de la gasolina no es realista: Esto es evidente.
2. Direcciones contrafactuales: direcciones que aún no han emitido un contrato inteligente (en realidad, esto significará cuentas desde las que aún no ha enviado fondos). Como usuario, puede tener una cantidad infinita de direcciones virtuales: una o más en cada L2, incluidas las L2 que aún no existen, y todo un conjunto infinito de direcciones virtuales que surgen del esquema de direcciones ocultas.
3. Privacidad: si un usuario usa intencionalmente varias direcciones para evitar asociarlas entre sí, entonces ciertamente no querrá asociarlas todas públicamente restaurándolas al mismo tiempo o casi al mismo tiempo.
Resolver estos problemas es difícil. Afortunadamente, existe una solución bastante elegante que funciona bastante bien: Esta arquitectura separa la lógica de validación de la tenencia de activos.
Cada usuario tiene un contrato de almacén de claves que existe en una ubicación (podría ser la red principal o una L2 específica). Luego, los usuarios tienen direcciones en diferentes L2 y la lógica de verificación para cada dirección es un puntero al contrato de almacenamiento de claves. Gastar fondos de estas direcciones requerirá proporcionar una prueba de una clave pública de gasto actual (o más realista, muy reciente) para los fondos.
Esta prueba se puede lograr de varias maneras:
Si queremos evitar la necesidad de una prueba para cada transacción, podemos implementar un esquema más ligero que solo requiera la recuperación en las pruebas L2. El gasto de una cuenta dependería de una clave de gasto con su clave pública correspondiente almacenada dentro de la cuenta, pero la recuperación requeriría una transacción para copiar la clave pública de gasto actual en el almacén de claves. Incluso si sus claves anteriores no son seguras, los fondos en la dirección virtual están seguros: "activar" la dirección virtual para convertirla en un contrato utilizable requerirá una prueba cruzada L2 para replicar la clave pública de gasto actual. Hay un hilo en los foros de Safe que describe cómo funciona una arquitectura similar.
Para agregar privacidad a dicho esquema, solo necesitamos encriptar punteros y hacer todas las pruebas dentro de ZK-SNARKs:
Estos escenarios pueden complicarse. La ventaja es que hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contrato de almacén de claves" también puede ser una solución a la "dirección" mencionada en la sección anterior: si queremos que los usuarios tengan una dirección persistente que no cambie cada vez que el usuario actualice la clave, debemos puede poner el sigilo La dirección meta, la clave de cifrado y otra información se colocan en el contrato del almacén de claves, y la dirección del contrato del almacén de claves se utiliza como la "dirección" del usuario.
Mucha infraestructura secundaria necesita ser actualizada
Usar ENS es costoso. Aunque no es tan caro como antes en junio de 2023, la tarifa de transacción para registrar un nombre de dominio sigue siendo relativamente alta, comparable al costo de un nombre de dominio ENS. Por ejemplo, cuesta alrededor de $ 27 registrarse en zuzalu.eth, $ 11 de los cuales son tarifas de transacción. Pero si el mercado vuelve a ser alcista, las tarifas se dispararán. Incluso si el precio de ETH no aumenta, si la tarifa del gas vuelve a 200 gwei, la tarifa de transacción para el registro del nombre de dominio alcanzará los $104. Entonces, si queremos que las personas realmente usen ENS, especialmente para casos de uso como redes sociales descentralizadas donde los usuarios solicitan un registro casi gratuito (las tarifas de dominio de ENS no son un problema ya que estas plataformas pueden proporcionar subdominios a los usuarios), necesitamos que ENS se use en Capa 2.
Afortunadamente, el equipo de ENS ya ha dado un paso al frente y ¡ENS se está implementando en la Capa 2! ERC-3668 (también conocido como el "estándar CCIP") y ENSIP-10 proporcionan una forma de verificar automáticamente los subdominios ENS en cualquier Capa 2. El estándar CCIP requiere establecer un contrato inteligente que describa el método para verificar las pruebas de datos en la Capa 2, y un nombre de dominio (por ejemplo, ecc.eth para Optinames) puede colocarse bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, al acceder a un cierto subdominio.ecc.eth se encontrará y verificará automáticamente una prueba que almacene el estado de Capa 2 de ese subdominio específico (por ejemplo, una sucursal de Merkle).
**El esfuerzo CCIP de ENS es una historia de éxito y debe verse como una señal de que las reformas radicales que necesitamos son realmente posibles. ** Pero todavía hay muchas reformas a nivel de aplicación que deben realizarse. Aquí hay unos ejemplos:
Las carteras deberán proteger los activos y los datos
Actualmente, la misión de la billetera es proteger los activos. Todo se almacena en la cadena, todo lo que la billetera necesita proteger son las claves privadas que actualmente protegen estos activos. Si cambia la clave, puede publicar de forma segura la clave privada anterior en Internet al día siguiente. Sin embargo, en un mundo de conocimiento cero, este ya no es el caso: las billeteras no solo protegen las credenciales de autenticación, sino que también guardan sus datos.
Vemos los primeros signos de un mundo así en Zuzalu con Zupass, un sistema de identidad basado en ZK-SNARK. El usuario tiene una clave privada que se usa para autenticarse en el sistema, que se puede usar para generar pruebas básicas como "demostrar que soy residente de Zuzalu sin revelar qué residente soy". El sistema Zupass también comenzó a crear otras aplicaciones, sobre todo sellos (la versión de Zupass de POAP).
*Uno de mis muchos sellos Zupass que confirma que soy miembro del Team Cat. *
La característica clave de los sellos en relación con POAP es que son privados: guarda los datos localmente y solo prueba un sello para su ZK (o realiza algún cálculo en los sellos) si desea brindar esa información a alguien. Pero esto también conlleva un riesgo adicional: si pierde esa información, perderá sus sellos.
Por supuesto, el problema de mantener los datos se puede reducir al problema de tener una sola clave de cifrado: un tercero (incluso en la cadena) puede tener una copia cifrada de los datos. Esto tiene la conveniente ventaja de que la acción que realiza no cambia la clave de cifrado, por lo que no se requiere interacción con el sistema que contiene la clave de cifrado. Pero incluso entonces, si pierde la clave de cifrado, perderá todos sus datos. Y, a su vez, si alguien ve tu clave de encriptación, podrá ver todo lo encriptado con esa clave. **
La solución práctica de Zupass es alentar a las personas a almacenar sus claves en varios dispositivos (como una computadora portátil y un teléfono), ya que las posibilidades de que pierdan el acceso a todos ellos al mismo tiempo son escasas. Podemos ir un paso más allá al usar el uso compartido de claves para dividir el almacenamiento de claves entre varios protectores.
La recuperación social a través de MPC no es una solución adecuada para las billeteras, ya que significa que no solo el protector actual, sino también los protectores anteriores podrían coludirse para robar sus activos, lo cual es un riesgo inaceptablemente alto. Si bien una violación de la privacidad suele ser menos riesgosa que una pérdida completa de activos, para casos de uso con necesidades de privacidad altas, se puede aceptar un mayor riesgo de pérdida si no se realiza una copia de seguridad de las claves asociadas con esas necesidades de privacidad.
Para evitar atascar a los usuarios en un sistema complejo de múltiples rutas de recuperación, es posible que las billeteras que admiten la recuperación social deban administrar ambos aspectos, la recuperación de activos y la recuperación de claves de cifrado.
Volver a la identidad
Un tema común entre estos cambios es que el concepto de una "dirección" como representación de la identidad en la cadena de bloques deberá cambiar fundamentalmente. ** "Instrucciones sobre cómo interactuar conmigo" ya no será solo una dirección ETH; express. **
Una de estas formas es usar ENS como su identidad: su registro de ENS puede contener toda la información sobre cómo pagar e interactuar con usted, si envía a alguien bob.eth (o bob.ecc.eth, etc.), pueden consultar y aprenda sobre todo lo que interactúa con usted, incluso de formas más complejas entre dominios y con protección de la privacidad.
Sin embargo, este enfoque centrado en ENS adolece de dos debilidades:
Una posible solución es poner más contenido en el contrato de almacén de claves mencionado anteriormente en la arquitectura de este artículo. Un contrato de almacén de claves puede contener diversa información sobre usted e interacciones con usted (y con CCIP, parte de esta información puede estar fuera de la cadena), los usuarios utilizarán su contrato de almacén de claves como su identificador principal. Sin embargo, los activos que realmente reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves son independientes del nombre y admiten nombres virtuales: puede generar una dirección que solo puede inicializarse mediante un contrato de almacén de claves con ciertos parámetros iniciales fijos.
Otra clase de soluciones implica abandonar por completo la noción de direcciones orientadas al usuario, similar al protocolo de pago de Bitcoin. Una idea es confiar más en los canales de comunicación directos entre el remitente y el receptor; por ejemplo, el remitente podría enviar un enlace de solicitud (como una URL explícita o un código QR), que el receptor podría usar para enviar cualquier solicitud que desee aceptar. pago.
Ya sea el remitente o el destinatario quien actúa primero, depender más de las billeteras para generar información de pago actualizada en tiempo real reduce la fricción. Sin embargo, los identificadores persistentes son convenientes (especialmente con ENS), mientras que en la práctica confiar en la comunicación directa entre el remitente y el receptor es un problema muy complicado, por lo que se puede ver una combinación de diferentes técnicas.
En todos estos diseños, es fundamental permanecer descentralizado y comprensible para los usuarios. Necesitamos asegurarnos de que los usuarios puedan acceder fácilmente a una vista actualizada de sus activos actuales y mensajes dirigidos a ellos. Estas vistas deben basarse en herramientas abiertas en lugar de soluciones propietarias. Se necesitará mucho trabajo para evitar que la mayor complejidad de la infraestructura de pago se convierta en una "torre de abstracción" opaca que es difícil de entender y adaptar a los nuevos entornos. A pesar de los desafíos, es primordial lograr la escalabilidad, la seguridad de la billetera y la privacidad de Ethereum para los usuarios comunes. No se trata solo de la viabilidad técnica, se trata de la accesibilidad real para el usuario promedio. Tenemos que hacer frente a este desafío.