Cuando Ethereum se transforma de una tecnología experimental joven a una pila de tecnología madura que realmente puede brindar una experiencia abierta, global y sin permisos a los usuarios comunes, la pila debe pasar por tres transformaciones tecnológicas importantes, más o menos simultáneamente:
Cambio de escala L2: todo migrado a acumulaciones
Cambio de seguridad de billetera: todos migran a billeteras de contrato inteligente
Cambio de privacidad: garantizar transferencias de dinero que preserven la privacidad y garantizar que todas las demás herramientas que se están desarrollando (recuperación social, identidad, reputación) preserven la privacidad
Este es el triángulo de la transformación del ecosistema. Solo puedes elegir 3 de 3.
Sin el primero, Ethereum fracasaría porque cada transacción costaría $ 3,75 ($ 82,48 si tuviéramos otra carrera alcista), y cada producto del mercado masivo eventualmente olvidaría la cadena y tomaría una solución centralizada para todo.
Sin el segundo, Ethereum fracasaría ya que los usuarios se mostrarían reacios a almacenar sus fondos (y activos no financieros) y todo se trasladaría a intercambios centralizados.
Sin un tercero, Ethereum fracasaría, ya que todas las transacciones (y POAP, etc.) serían públicas para que cualquiera las viera, lo que sería un sacrificio exorbitante de privacidad para muchos usuarios, y todos se moverían para tener al menos algunos datos ocultos centralizados. solución.
Por las razones mencionadas anteriormente, estas tres transiciones son críticas. Pero también son desafiantes debido a la intensa coordinación requerida para resolverlos. No solo se debe mejorar la funcionalidad del protocolo, hay casos en los que se deben realizar cambios bastante fundamentales en la forma en que interactuamos con Ethereum, lo que requiere cambios profundos en las aplicaciones y las billeteras.
Estos tres turnos revolucionarán la relación entre usuarios y direcciones
En un mundo con L2 extendido, los usuarios existirán en muchos L2. ¿Eres miembro de ExampleDAO, que está en Optimism? ¡Entonces tienes una cuenta en Optimism! ¿Tiene CDP en el sistema de monedas estables de ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Has probado algunas aplicaciones que están en Kakarot? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que los usuarios solo tenían una dirección.
Tengo ETH en cuatro lugares, según mi vista de Brave Wallet. Sí, Arbitrum y Arbitrum Nova son diferentes. ¡No te preocupes, esto se volverá más complicado con el tiempo!
Las billeteras de contratos inteligentes agregan más complejidad, lo que dificulta tener la misma dirección en L1 y varias L2. Hoy en día, la mayoría de los usuarios utilizan cuentas de propiedad externa cuyas direcciones son en realidad el hash de la clave pública utilizada para verificar la firma, por lo que nada cambia entre L1 y L2. Sin embargo, con las carteras de contratos inteligentes, mantener una dirección se vuelve más difícil. Si bien se ha trabajado mucho tratando de hacer que las direcciones sean un hash de código equivalente en toda la red, en particular las fábricas de singleton CREATE2 y ERC-2470, ha sido muy difícil hacerlo a la perfección. Algunos L2 (como los "ZK-EVM de tipo 4") no son completamente equivalentes a los EVM, por lo general usan Solidity o un ensamblaje intermedio en su lugar, lo que impide la equivalencia de hash. Incluso si pudiera tener una equivalencia de hash, la posibilidad de que las billeteras cambien de propietario a través de cambios de clave tiene otras consecuencias no intuitivas.
La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones que manejamos. Si la propuesta de dirección privada se usa ampliamente, en lugar de solo unas pocas direcciones por usuario, o una dirección por L2, podría haber una dirección por transacción. Otros esquemas de privacidad, incluso los existentes como Tornado Cash, cambian la forma en que se almacenan los activos de manera diferente: 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 debe confiar en el propio sistema de dirección interna del esquema de privacidad.
Como hemos visto, los tres cambios debilitaron el modelo mental de "un usuario ~ = una dirección" de diferentes maneras, y algunos de estos efectos retroalimentaron la complejidad de implementar los cambios. Dos complicaciones particulares son:
Si desea pagarle a alguien, ¿cómo obtiene la información para pagarle?
Si un usuario almacena muchos activos en diferentes lugares en diferentes cadenas, ¿cómo realiza el reemplazo de claves y la recuperación social?
Tres transiciones están relacionadas con los pagos en cadena (y la identidad)
Tengo monedas en Scroll y quiero pagar el café (si "yo" se refiere literalmente a mí como el autor de este artículo, entonces "café" es, por supuesto, una metonimia de "té verde"). Me estás vendiendo café, pero solo vas a recibir monedas en Taiko. ¿Qué debo hacer?
Básicamente hay dos soluciones:
La billetera receptora (podría ser un comerciante o simplemente una persona normal) se esfuerza por admitir cada L2, con alguna funcionalidad automática para integrar fondos de forma asíncrona.
El receptor proporciona su L2 y su 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 combinar: el receptor proporciona la lista L2 que está dispuesto a aceptar, y la billetera del remitente calcula el pago, lo que puede implicar el envío directo (si tiene suerte) o a través de una ruta puente a través de L2.
Pero ese es solo un ejemplo del desafío clave presentado por los tres turnos: algo tan simple como pagarle a alguien comienza a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, el cambio a billeteras de contrato inteligente no ha sobrecargado mucho el sistema de direcciones, pero todavía hay algunos problemas técnicos que deben abordarse en otras partes de la pila de aplicaciones. Las billeteras deben actualizarse para garantizar que no solo envíen 21000 gas en transacciones, sino que, lo que es más importante, para garantizar que el lado de la billetera que recibe el pago no solo rastree las transferencias ETH de los EOA, sino también ETH enviado por código de contrato inteligente. Las aplicaciones que se basan en la suposición de 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; en particular, si alguien solo acepta tokens ERC20 que no son ETH, podrá usar un pagador ERC-4337 para pagar la gasolina con ese token.
Por otro lado, la privacidad nuevamente presenta grandes desafíos 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 en el sistema y retirar. Una vez que pueda realizar transferencias internas, los usuarios deben utilizar el esquema de direcciones internas del sistema de privacidad. En la práctica, el "mensaje de pago" de un usuario debe contener (i) algún tipo de "clave pública de gasto", una promesa de un secreto que el destinatario puede usar para gastar, y (ii) el remitente envía un mensaje encriptado que solo el el destinatario puede descifrar la forma de ayudar a los destinatarios a descubrir los pagos.
El protocolo de dirección de privacidad se basa en el concepto de metadirección, que funciona de la siguiente manera: parte de la metadirección es una versión oculta de la clave de gasto del remitente, y la otra parte es la clave de cifrado del remitente (aunque las implementaciones mínimas puede configurar esto Ambas teclas son iguales).
La lección clave aquí es que en un ecosistema centrado en la privacidad, los usuarios tendrán que gastar claves públicas y claves públicas de cifrado, y la "información de pago" de los usuarios tendrá que contener ambas claves. Además de pagar, hay otras buenas razones para expandirse en esta dirección. Por ejemplo, si quisiéramos correo electrónico encriptado en Ethereum, los usuarios tendrían que proporcionar públicamente algún tipo de clave de encriptación. En un "mundo EOA", podríamos reutilizar claves de cuenta para lograr esto, pero en un mundo de billeteras seguras de contratos inteligentes, probablemente deberíamos tener una funcionalidad más explícita para lograr esto. Esto también ayudará a que las identidades basadas en Ethereum sean más compatibles con los ecosistemas de privacidad descentralizados que no son de Ethereum, siendo el ejemplo más destacado las claves PGP.
Tres transformaciones y recuperación de claves
En un mundo donde un usuario puede tener varias direcciones, la forma predeterminada de implementar cambios clave y recuperación social es hacer que el usuario realice procedimientos de recuperación en cada dirección individualmente. Esto se puede hacer con un solo clic: las billeteras pueden contener software para realizar procedimientos de recuperación en las direcciones de todos los usuarios simultáneamente. Sin embargo, incluso con tal simplificación de UX, hay tres problemas con la recuperación ingenua de múltiples direcciones:
Facturas de gas poco realistas: Esta habla por sí sola.
Dirección contrafáctica: una dirección cuyo contrato inteligente aún no se ha publicado (en realidad, esto significa una cuenta desde la que aún no ha enviado fondos). Como usuario, tiene una cantidad potencialmente infinita de direcciones hipotéticas: una o más en cada L2, incluidas las L2 que aún no existen, y un conjunto completamente diferente de direcciones hipotéticas infinitas, derivadas del esquema de direcciones esteganográficas.
Privacidad: si un usuario tiene intencionalmente muchas direcciones para evitar vincularlas, ¡ciertamente no querrá vincularlas 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: una arquitectura que separa la lógica de validación de la posesión 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, donde la lógica de verificación para cada dirección es un puntero al contrato de almacenamiento de claves. El gasto de estas direcciones requerirá una prueba en el contrato del almacén de claves que muestre la clave pública de gasto actual (o más realista, más reciente).
La prueba se puede lograr de varias maneras:
Lea el acceso L1 de solo lectura directamente en L2. L2 se puede modificar para darles una forma de leer el estado de L1 directamente. Si el contrato del almacén de claves está en L1, esto significará que los contratos en L2 tienen acceso "gratuito" al almacén de claves.
Sucursal de Merkel. Las ramas de Merkle pueden probar los estados L1 a L2, o los estados L2 a L1, o puede combinar los dos para probar partes de un estado L2 a otro L2. La principal debilidad de las pruebas de Merkle es el alto costo del gas debido a la longitud de la prueba: una prueba puede requerir 5 kB, aunque esto se reducirá a menos de 1 kB en el futuro gracias a los árboles de Verkle.
ZK-SNARK. Puede reducir los costos de datos utilizando ZK-SNARK de las sucursales de Merkle en lugar de las propias sucursales. Se pueden construir técnicas de agregación fuera de la cadena (p. ej., basadas en EIP-4337) para que un solo ZK-SNARK verifique todas las pruebas de estado entre cadenas en un bloque.
Compromiso KZG. L2, o los esquemas construidos sobre él, pueden introducir un sistema de direccionamiento secuencial que permite que las pruebas de estado dentro de este sistema tengan solo 48 bytes de longitud. Al igual que ZK-SNARK, un esquema de pruebas múltiples puede combinar todas estas pruebas en una sola prueba para cada bloque.
Si queremos evitar hacer una prueba para cada transacción, podemos implementar una solución más liviana, solo necesitamos hacer una prueba cruzada L2 al recuperar. El gasto de una cuenta dependerá de una clave de gasto cuya clave pública correspondiente esté almacenada en la cuenta, pero la recuperación requerirá una transacción que copie la clave pública de gasto actual en el almacén de claves. Los fondos en una dirección hipotética están seguros incluso si su clave anterior no lo está: "activar" una dirección hipotética, convertirla en un contrato de trabajo requerirá hacer una prueba cruzada L2 que replique la clave pública de gasto actual. Este hilo en los foros de Safe describe cómo podría funcionar una arquitectura similar.
Para agregar privacidad a dicho esquema, solo necesitamos encriptar el puntero y luego hacer todas las pruebas en ZK-SNARK:
Con más trabajo (por ejemplo, usando este trabajo como punto de partida), también podemos eliminar la mayor parte de la complejidad de los ZK-SNARK y hacer un esquema basado en KZG más simple.
Estos escenarios pueden complicarse. Sin embargo, existen muchas sinergias potenciales entre estos programas. Por ejemplo, el concepto de un "contrato de almacén de claves" también podría ser una solución al desafío de la "dirección" mencionado en la sección anterior: si queremos que los usuarios tengan direcciones persistentes que no cambien cuando los usuarios actualicen sus claves, es posible colocar metadirecciones secretas, claves de cifrado y otra información en un contrato de almacén de claves, y usar la dirección del contrato de almacén de claves como la "dirección" del usuario.
Es necesario actualizar una gran cantidad de infraestructura secundaria
Usar ENS es costoso. Hoy, junio de 2023, las cosas no están tan mal: las tarifas de transacción, aunque altas, son comparables a las tarifas de dominio de ENS. Registrarme en zuzalu.eth me costó alrededor de $ 27, de los cuales $ 11 son tarifas de transacción. Pero si tenemos otro mercado alcista, las tarifas se dispararán. Incluso sin el aumento del precio de ETH, el regreso de la tarifa de gas a 200 gwei elevaría la tarifa de transacción para el registro de dominio a $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 proporcionan subdominios para sus usuarios), necesitamos que ENS se ejecute en L2. .
Afortunadamente, el equipo de ENS ya está en movimiento, ¡y ENS en L2 realmente está sucediendo! ERC-3668 (también conocido como el "estándar CCIP"), junto con ENSIP-10, proporciona un método para validar automáticamente los subdominios ENS en cualquier L2. El estándar CCIP requiere establecer un contrato inteligente que describa un método para verificar pruebas de datos L2, y los nombres de dominio (ecc.eth para Optinames, por ejemplo) pueden colocarse bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, acceder a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar el estado L2 de la prueba (p. ej., sucursal de Merkle) que realmente almacena ese subdominio en particular.
En realidad, obtener pruebas implica acceder a una serie de URL almacenadas en el contrato, lo que ciertamente se siente como una centralización, aunque diría que en realidad no lo es: es un modelo de confianza 1 de N (las pruebas no válidas serían bloqueadas por CCIP La verificación la lógica en la función de devolución de llamada del contrato captura que, siempre que haya una URL que devuelva una prueba válida, no hay problema). Esta lista de URL puede contener docenas de URL.
El trabajo de la ENS CCIP es una historia de éxito y debe verse como una señal de que el tipo de reforma radical que necesitamos es posible. Pero se necesitan más reformas a nivel de aplicación. Algunos ejemplos incluyen:
Muchos dapps dependen de los usuarios para proporcionar firmas fuera de la cadena. Para cuentas de propiedad externa (EOA), es fácil. ERC-1271 proporciona una forma estandarizada para que las carteras de contratos inteligentes hagan esto. Sin embargo, muchas dapps aún no son compatibles con ERC-1271; necesitan admitirlo.
Las dapps que usan "¿Es esto EOA?" para diferenciar entre usuarios y contratos (p. ej., para evitar transferencias o hacer cumplir regalías) no funcionarán. En general, desaconsejaría tratar de encontrar una solución puramente técnica; la cuestión de averiguar si una transferencia particular de control criptográfico es una transferencia de intereses beneficiosos es difícil y no puede resolverse sin recurrir a alguna comunidad fuera de la cadena. mecanismos impulsados A continuación, resuelva. Lo más probable es que las aplicaciones tengan que depender menos del bloqueo de transferencias y más de técnicas como el impuesto Harberger.
Será necesario mejorar la forma en que las billeteras interactúan con el gasto y las claves de cifrado. Actualmente, las billeteras suelen utilizar firmas deterministas para generar claves específicas de la aplicación: un nonce estándar (por ejemplo, un hash del nombre de la aplicación) se firma con la clave privada del EOA, lo que genera un nonce que no se puede generar sin la clave privada. de , por lo que es 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, las billeteras deben manejar de manera más explícita la firma, el cifrado y las funciones relacionadas.
Los clientes ligeros (por ejemplo, Helios) deberán verificar L2, no solo L1. Hoy en día, los clientes ligeros se centran en verificar la validez del encabezado L1 (utilizando el protocolo de sincronización de clientes ligeros) y en validar el estado L1 y las bifurcaciones Merkle de las transacciones que se originan en el encabezado L1. Mañana, también deben verificar la prueba del estado L2 que se origina en la raíz del estado almacenada en L1 (esta versión más avanzada en realidad analiza la confirmación previa de L2).
Las billeteras necesitan proteger los activos y los datos
Ahora, el negocio de la billetera es proteger los activos. Todo está en cadena, y lo único que la billetera necesita proteger son las claves privadas que actualmente protegen esos activos. Si cambia las claves, puede publicar de forma segura su clave privada anterior en Internet al día siguiente. Sin embargo, en un mundo de pruebas de conocimiento cero, este ya no es el caso: las billeteras no solo protegen las credenciales de autenticación, también protegen sus datos.
Vimos los primeros signos de un mundo así con Zupass, el sistema de identidad basado en ZK-SNARK utilizado en Zuzalu. Los usuarios tienen una clave privada, que usan para autenticar el sistema, que se puede usar para hacer pruebas básicas como "demostrar que soy residente de Zuzalu, pero no revelar cuál". Sin embargo, el sistema Zupass también comenzó a tener otras aplicaciones integradas, sobre todo Stamps (la versión de Zupass de POAP).
Uno de mis muchos sellos Zupass que demuestra que soy un miembro orgulloso del Team Cat.
La característica clave que ofrecen los sellos sobre los POAP es que los sellos son privados: usted conserva los datos localmente y solo les prueba el sello (o algún cálculo) si desea que tengan esta información sobre usted. Pero esto aumenta el riesgo: si pierdes esta información, pierdes tu sello.
Por supuesto, el problema de mantener los datos se reduce al problema de tener una clave criptográfica: un tercero (o incluso 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 mantiene segura su clave de cifrado. Pero incluso entonces, si pierde su clave de cifrado, lo pierde todo. Por el contrario, si alguien ve su clave de encriptación, puede ver todo encriptado con esa clave.
La solución de facto de Zupass es alentar a las personas a almacenar sus claves en varios dispositivos (por ejemplo, una computadora portátil y un teléfono), ya que las posibilidades de que las pierdan todas al mismo tiempo son escasas. Podemos ir un paso más allá y usar un recurso compartido secreto para almacenar la clave, dividiéndola entre varios guardianes.
Esta recuperación social a través de MPC no es una solución adecuada para las billeteras, ya que significa que no solo los tutores actuales, sino también los tutores anteriores pueden coludirse para robar sus activos, lo cual es un alto riesgo inaceptable. Sin embargo, una violación de la privacidad suele ser un riesgo menor que una pérdida total de activos, y si alguien requiere un caso de uso que preserve la privacidad en gran medida, puede aceptar un mayor riesgo de pérdida si no realiza una copia de seguridad de las claves asociadas que requieren privacidad. acciones de conservación.
Para evitar abrumar a los usuarios con un sistema complejo de múltiples rutas de recuperación, es posible que las billeteras que admiten la recuperación social deban administrar tanto la recuperación de activos como la recuperación de claves de cifrado.
Volvamos a la cuestión de la identidad
Un tema común de estos cambios es que el concepto de una "dirección" que usa en la cadena como un identificador criptográfico que lo representa a "usted" tiene que cambiar radicalmente. Las "Instrucciones sobre cómo interactuar conmigo" ya no son solo una dirección ETH; deben contener alguna combinación de múltiples direcciones en múltiples L2, metadirecciones secretas, claves de cifrado y otros datos de alguna forma.
Una forma de hacer esto es hacer que ENS sea su identidad: su registro ENS puede contener toda esta información, y si le envía a alguien bob.eth (o bob.ecc.eth, o...), pueden averiguar y aprender sobre todas las cosas que pagan e interactúan con usted, incluso de formas transversales más complejas y de preservación de la privacidad.
Sin embargo, este enfoque centrado en ENS tiene dos puntos débiles:
Une demasiadas cosas a tu nombre. Tu nombre no eres tú, tu nombre es solo uno de tus muchos atributos. Debería poder cambiar su nombre sin mover todo su perfil de identidad y actualizar un montón de registros en muchas aplicaciones.
No puede tener nombres contrafactuales que no sean de confianza. Una característica clave de UX de cualquier cadena de bloques es la capacidad de enviar monedas a personas que aún no han interactuado con la cadena. Sin dicha funcionalidad, existe el problema del huevo y la gallina: interactuar con la cadena requiere pagar tarifas de transacción, y pagar tarifas requiere... ya poseer monedas. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta función. El nombre ENS no lo hace, porque si dos Bobs deciden que son bob.ecc.eth fuera de la cadena, no hay forma de elegir cuál recibe el nombre.
Una posible solución es poner más cosas en el contrato de almacén de claves mencionado en la arquitectura anteriormente en esta publicación. El contrato del almacén de claves puede contener diversa información sobre usted y cómo interactúa con él (a través de CCIP, algunos de los cuales pueden estar fuera de la cadena), y los usuarios pueden usar su contrato del almacén de claves como identificador principal. Pero los activos reales que reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves no están vinculados a nombres, son amigables contrafactualmente: puede generar una dirección que solo puede inicializarse mediante un contrato de almacén de claves con algunos parámetros iniciales fijos.
Otra categoría de soluciones tiene que ver con abandonar el concepto de direcciones orientadas al usuario, que es similar en espíritu al protocolo de pago de Bitcoin. Una idea es confiar más en los canales de comunicación directos entre el remitente y el destinatario; por ejemplo, el remitente podría enviar un enlace de reclamo (como una URL explícita o un código QR) que el destinatario podría usar para aceptar pagos de la manera que desee.
Ya sea el remitente o el destinatario quien actúa primero, depender más de las billeteras para generar directamente información de pago actualizada en tiempo real reduce la fricción. Habiendo dicho eso, los identificadores persistentes son convenientes (especialmente con ENS) y, en la práctica, la suposición de comunicación directa entre el remitente y el destinatario es un problema muy complicado, por lo que podríamos considerar una combinación de diferentes tecnologías.
En todos estos diseños, es fundamental mantener las cosas descentralizadas y comprensibles para los usuarios. Necesitamos asegurarnos de que los usuarios puedan acceder fácilmente a la vista más actualizada de sus activos actuales, así como a la información publicada destinada a ellos. Estas vistas deben basarse en herramientas abiertas en lugar de soluciones propietarias. Se necesitará mucho trabajo para evitar que una infraestructura de pago más compleja se convierta en una "torre de abstracción" opaca donde los desarrolladores tienen dificultades para comprender lo que está sucediendo y adaptarlo 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.
Un agradecimiento especial a Dan Finlay, Karl Floersch, David Hoffman y los equipos de Scroll y SoulWallet por sus comentarios, revisiones y sugerencias.
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: transformación necesaria de Ethereum: escalado L2, seguridad de billetera y privacidad
Cuando Ethereum se transforma de una tecnología experimental joven a una pila de tecnología madura que realmente puede brindar una experiencia abierta, global y sin permisos a los usuarios comunes, la pila debe pasar por tres transformaciones tecnológicas importantes, más o menos simultáneamente:
Cambio de escala L2: todo migrado a acumulaciones
Cambio de seguridad de billetera: todos migran a billeteras de contrato inteligente
Cambio de privacidad: garantizar transferencias de dinero que preserven la privacidad y garantizar que todas las demás herramientas que se están desarrollando (recuperación social, identidad, reputación) preserven la privacidad
Este es el triángulo de la transformación del ecosistema. Solo puedes elegir 3 de 3.
Sin el primero, Ethereum fracasaría porque cada transacción costaría $ 3,75 ($ 82,48 si tuviéramos otra carrera alcista), y cada producto del mercado masivo eventualmente olvidaría la cadena y tomaría una solución centralizada para todo.
Sin el segundo, Ethereum fracasaría ya que los usuarios se mostrarían reacios a almacenar sus fondos (y activos no financieros) y todo se trasladaría a intercambios centralizados.
Sin un tercero, Ethereum fracasaría, ya que todas las transacciones (y POAP, etc.) serían públicas para que cualquiera las viera, lo que sería un sacrificio exorbitante de privacidad para muchos usuarios, y todos se moverían para tener al menos algunos datos ocultos centralizados. solución.
Por las razones mencionadas anteriormente, estas tres transiciones son críticas. Pero también son desafiantes debido a la intensa coordinación requerida para resolverlos. No solo se debe mejorar la funcionalidad del protocolo, hay casos en los que se deben realizar cambios bastante fundamentales en la forma en que interactuamos con Ethereum, lo que requiere cambios profundos en las aplicaciones y las billeteras.
Estos tres turnos revolucionarán la relación entre usuarios y direcciones
En un mundo con L2 extendido, los usuarios existirán en muchos L2. ¿Eres miembro de ExampleDAO, que está en Optimism? ¡Entonces tienes una cuenta en Optimism! ¿Tiene CDP en el sistema de monedas estables de ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Has probado algunas aplicaciones que están en Kakarot? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que los usuarios solo tenían una dirección.
Tengo ETH en cuatro lugares, según mi vista de Brave Wallet. Sí, Arbitrum y Arbitrum Nova son diferentes. ¡No te preocupes, esto se volverá más complicado con el tiempo!
Las billeteras de contratos inteligentes agregan más complejidad, lo que dificulta tener la misma dirección en L1 y varias L2. Hoy en día, la mayoría de los usuarios utilizan cuentas de propiedad externa cuyas direcciones son en realidad el hash de la clave pública utilizada para verificar la firma, por lo que nada cambia entre L1 y L2. Sin embargo, con las carteras de contratos inteligentes, mantener una dirección se vuelve más difícil. Si bien se ha trabajado mucho tratando de hacer que las direcciones sean un hash de código equivalente en toda la red, en particular las fábricas de singleton CREATE2 y ERC-2470, ha sido muy difícil hacerlo a la perfección. Algunos L2 (como los "ZK-EVM de tipo 4") no son completamente equivalentes a los EVM, por lo general usan Solidity o un ensamblaje intermedio en su lugar, lo que impide la equivalencia de hash. Incluso si pudiera tener una equivalencia de hash, la posibilidad de que las billeteras cambien de propietario a través de cambios de clave tiene otras consecuencias no intuitivas.
La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones que manejamos. Si la propuesta de dirección privada se usa ampliamente, en lugar de solo unas pocas direcciones por usuario, o una dirección por L2, podría haber una dirección por transacción. Otros esquemas de privacidad, incluso los existentes como Tornado Cash, cambian la forma en que se almacenan los activos de manera diferente: 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 debe confiar en el propio sistema de dirección interna del esquema de privacidad.
Como hemos visto, los tres cambios debilitaron el modelo mental de "un usuario ~ = una dirección" de diferentes maneras, y algunos de estos efectos retroalimentaron la complejidad de implementar los cambios. Dos complicaciones particulares son:
Si desea pagarle a alguien, ¿cómo obtiene la información para pagarle?
Si un usuario almacena muchos activos en diferentes lugares en diferentes cadenas, ¿cómo realiza el reemplazo de claves y la recuperación social?
Tres transiciones están relacionadas con los pagos en cadena (y la identidad)
Tengo monedas en Scroll y quiero pagar el café (si "yo" se refiere literalmente a mí como el autor de este artículo, entonces "café" es, por supuesto, una metonimia de "té verde"). Me estás vendiendo café, pero solo vas a recibir monedas en Taiko. ¿Qué debo hacer?
Básicamente hay dos soluciones:
La billetera receptora (podría ser un comerciante o simplemente una persona normal) se esfuerza por admitir cada L2, con alguna funcionalidad automática para integrar fondos de forma asíncrona.
El receptor proporciona su L2 y su 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 combinar: el receptor proporciona la lista L2 que está dispuesto a aceptar, y la billetera del remitente calcula el pago, lo que puede implicar el envío directo (si tiene suerte) o a través de una ruta puente a través de L2.
Pero ese es solo un ejemplo del desafío clave presentado por los tres turnos: algo tan simple como pagarle a alguien comienza a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, el cambio a billeteras de contrato inteligente no ha sobrecargado mucho el sistema de direcciones, pero todavía hay algunos problemas técnicos que deben abordarse en otras partes de la pila de aplicaciones. Las billeteras deben actualizarse para garantizar que no solo envíen 21000 gas en transacciones, sino que, lo que es más importante, para garantizar que el lado de la billetera que recibe el pago no solo rastree las transferencias ETH de los EOA, sino también ETH enviado por código de contrato inteligente. Las aplicaciones que se basan en la suposición de 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; en particular, si alguien solo acepta tokens ERC20 que no son ETH, podrá usar un pagador ERC-4337 para pagar la gasolina con ese token.
Por otro lado, la privacidad nuevamente presenta grandes desafíos 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 en el sistema y retirar. Una vez que pueda realizar transferencias internas, los usuarios deben utilizar el esquema de direcciones internas del sistema de privacidad. En la práctica, el "mensaje de pago" de un usuario debe contener (i) algún tipo de "clave pública de gasto", una promesa de un secreto que el destinatario puede usar para gastar, y (ii) el remitente envía un mensaje encriptado que solo el el destinatario puede descifrar la forma de ayudar a los destinatarios a descubrir los pagos.
El protocolo de dirección de privacidad se basa en el concepto de metadirección, que funciona de la siguiente manera: parte de la metadirección es una versión oculta de la clave de gasto del remitente, y la otra parte es la clave de cifrado del remitente (aunque las implementaciones mínimas puede configurar esto Ambas teclas son iguales).
La lección clave aquí es que en un ecosistema centrado en la privacidad, los usuarios tendrán que gastar claves públicas y claves públicas de cifrado, y la "información de pago" de los usuarios tendrá que contener ambas claves. Además de pagar, hay otras buenas razones para expandirse en esta dirección. Por ejemplo, si quisiéramos correo electrónico encriptado en Ethereum, los usuarios tendrían que proporcionar públicamente algún tipo de clave de encriptación. En un "mundo EOA", podríamos reutilizar claves de cuenta para lograr esto, pero en un mundo de billeteras seguras de contratos inteligentes, probablemente deberíamos tener una funcionalidad más explícita para lograr esto. Esto también ayudará a que las identidades basadas en Ethereum sean más compatibles con los ecosistemas de privacidad descentralizados que no son de Ethereum, siendo el ejemplo más destacado las claves PGP.
Tres transformaciones y recuperación de claves
En un mundo donde un usuario puede tener varias direcciones, la forma predeterminada de implementar cambios clave y recuperación social es hacer que el usuario realice procedimientos de recuperación en cada dirección individualmente. Esto se puede hacer con un solo clic: las billeteras pueden contener software para realizar procedimientos de recuperación en las direcciones de todos los usuarios simultáneamente. Sin embargo, incluso con tal simplificación de UX, hay tres problemas con la recuperación ingenua de múltiples direcciones:
Facturas de gas poco realistas: Esta habla por sí sola.
Dirección contrafáctica: una dirección cuyo contrato inteligente aún no se ha publicado (en realidad, esto significa una cuenta desde la que aún no ha enviado fondos). Como usuario, tiene una cantidad potencialmente infinita de direcciones hipotéticas: una o más en cada L2, incluidas las L2 que aún no existen, y un conjunto completamente diferente de direcciones hipotéticas infinitas, derivadas del esquema de direcciones esteganográficas.
Privacidad: si un usuario tiene intencionalmente muchas direcciones para evitar vincularlas, ¡ciertamente no querrá vincularlas 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: una arquitectura que separa la lógica de validación de la posesión 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, donde la lógica de verificación para cada dirección es un puntero al contrato de almacenamiento de claves. El gasto de estas direcciones requerirá una prueba en el contrato del almacén de claves que muestre la clave pública de gasto actual (o más realista, más reciente).
La prueba se puede lograr de varias maneras:
Lea el acceso L1 de solo lectura directamente en L2. L2 se puede modificar para darles una forma de leer el estado de L1 directamente. Si el contrato del almacén de claves está en L1, esto significará que los contratos en L2 tienen acceso "gratuito" al almacén de claves.
Sucursal de Merkel. Las ramas de Merkle pueden probar los estados L1 a L2, o los estados L2 a L1, o puede combinar los dos para probar partes de un estado L2 a otro L2. La principal debilidad de las pruebas de Merkle es el alto costo del gas debido a la longitud de la prueba: una prueba puede requerir 5 kB, aunque esto se reducirá a menos de 1 kB en el futuro gracias a los árboles de Verkle.
ZK-SNARK. Puede reducir los costos de datos utilizando ZK-SNARK de las sucursales de Merkle en lugar de las propias sucursales. Se pueden construir técnicas de agregación fuera de la cadena (p. ej., basadas en EIP-4337) para que un solo ZK-SNARK verifique todas las pruebas de estado entre cadenas en un bloque.
Compromiso KZG. L2, o los esquemas construidos sobre él, pueden introducir un sistema de direccionamiento secuencial que permite que las pruebas de estado dentro de este sistema tengan solo 48 bytes de longitud. Al igual que ZK-SNARK, un esquema de pruebas múltiples puede combinar todas estas pruebas en una sola prueba para cada bloque.
Si queremos evitar hacer una prueba para cada transacción, podemos implementar una solución más liviana, solo necesitamos hacer una prueba cruzada L2 al recuperar. El gasto de una cuenta dependerá de una clave de gasto cuya clave pública correspondiente esté almacenada en la cuenta, pero la recuperación requerirá una transacción que copie la clave pública de gasto actual en el almacén de claves. Los fondos en una dirección hipotética están seguros incluso si su clave anterior no lo está: "activar" una dirección hipotética, convertirla en un contrato de trabajo requerirá hacer una prueba cruzada L2 que replique la clave pública de gasto actual. Este hilo en los foros de Safe describe cómo podría funcionar una arquitectura similar.
Para agregar privacidad a dicho esquema, solo necesitamos encriptar el puntero y luego hacer todas las pruebas en ZK-SNARK:
Con más trabajo (por ejemplo, usando este trabajo como punto de partida), también podemos eliminar la mayor parte de la complejidad de los ZK-SNARK y hacer un esquema basado en KZG más simple.
Estos escenarios pueden complicarse. Sin embargo, existen muchas sinergias potenciales entre estos programas. Por ejemplo, el concepto de un "contrato de almacén de claves" también podría ser una solución al desafío de la "dirección" mencionado en la sección anterior: si queremos que los usuarios tengan direcciones persistentes que no cambien cuando los usuarios actualicen sus claves, es posible colocar metadirecciones secretas, claves de cifrado y otra información en un contrato de almacén de claves, y usar la dirección del contrato de almacén de claves como la "dirección" del usuario.
Es necesario actualizar una gran cantidad de infraestructura secundaria
Usar ENS es costoso. Hoy, junio de 2023, las cosas no están tan mal: las tarifas de transacción, aunque altas, son comparables a las tarifas de dominio de ENS. Registrarme en zuzalu.eth me costó alrededor de $ 27, de los cuales $ 11 son tarifas de transacción. Pero si tenemos otro mercado alcista, las tarifas se dispararán. Incluso sin el aumento del precio de ETH, el regreso de la tarifa de gas a 200 gwei elevaría la tarifa de transacción para el registro de dominio a $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 proporcionan subdominios para sus usuarios), necesitamos que ENS se ejecute en L2. .
Afortunadamente, el equipo de ENS ya está en movimiento, ¡y ENS en L2 realmente está sucediendo! ERC-3668 (también conocido como el "estándar CCIP"), junto con ENSIP-10, proporciona un método para validar automáticamente los subdominios ENS en cualquier L2. El estándar CCIP requiere establecer un contrato inteligente que describa un método para verificar pruebas de datos L2, y los nombres de dominio (ecc.eth para Optinames, por ejemplo) pueden colocarse bajo el control de dicho contrato. Una vez que el contrato CCIP controla ecc.eth en L1, acceder a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar el estado L2 de la prueba (p. ej., sucursal de Merkle) que realmente almacena ese subdominio en particular.
En realidad, obtener pruebas implica acceder a una serie de URL almacenadas en el contrato, lo que ciertamente se siente como una centralización, aunque diría que en realidad no lo es: es un modelo de confianza 1 de N (las pruebas no válidas serían bloqueadas por CCIP La verificación la lógica en la función de devolución de llamada del contrato captura que, siempre que haya una URL que devuelva una prueba válida, no hay problema). Esta lista de URL puede contener docenas de URL.
El trabajo de la ENS CCIP es una historia de éxito y debe verse como una señal de que el tipo de reforma radical que necesitamos es posible. Pero se necesitan más reformas a nivel de aplicación. Algunos ejemplos incluyen:
Muchos dapps dependen de los usuarios para proporcionar firmas fuera de la cadena. Para cuentas de propiedad externa (EOA), es fácil. ERC-1271 proporciona una forma estandarizada para que las carteras de contratos inteligentes hagan esto. Sin embargo, muchas dapps aún no son compatibles con ERC-1271; necesitan admitirlo.
Las dapps que usan "¿Es esto EOA?" para diferenciar entre usuarios y contratos (p. ej., para evitar transferencias o hacer cumplir regalías) no funcionarán. En general, desaconsejaría tratar de encontrar una solución puramente técnica; la cuestión de averiguar si una transferencia particular de control criptográfico es una transferencia de intereses beneficiosos es difícil y no puede resolverse sin recurrir a alguna comunidad fuera de la cadena. mecanismos impulsados A continuación, resuelva. Lo más probable es que las aplicaciones tengan que depender menos del bloqueo de transferencias y más de técnicas como el impuesto Harberger.
Será necesario mejorar la forma en que las billeteras interactúan con el gasto y las claves de cifrado. Actualmente, las billeteras suelen utilizar firmas deterministas para generar claves específicas de la aplicación: un nonce estándar (por ejemplo, un hash del nombre de la aplicación) se firma con la clave privada del EOA, lo que genera un nonce que no se puede generar sin la clave privada. de , por lo que es 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, las billeteras deben manejar de manera más explícita la firma, el cifrado y las funciones relacionadas.
Los clientes ligeros (por ejemplo, Helios) deberán verificar L2, no solo L1. Hoy en día, los clientes ligeros se centran en verificar la validez del encabezado L1 (utilizando el protocolo de sincronización de clientes ligeros) y en validar el estado L1 y las bifurcaciones Merkle de las transacciones que se originan en el encabezado L1. Mañana, también deben verificar la prueba del estado L2 que se origina en la raíz del estado almacenada en L1 (esta versión más avanzada en realidad analiza la confirmación previa de L2).
Las billeteras necesitan proteger los activos y los datos
Ahora, el negocio de la billetera es proteger los activos. Todo está en cadena, y lo único que la billetera necesita proteger son las claves privadas que actualmente protegen esos activos. Si cambia las claves, puede publicar de forma segura su clave privada anterior en Internet al día siguiente. Sin embargo, en un mundo de pruebas de conocimiento cero, este ya no es el caso: las billeteras no solo protegen las credenciales de autenticación, también protegen sus datos.
Vimos los primeros signos de un mundo así con Zupass, el sistema de identidad basado en ZK-SNARK utilizado en Zuzalu. Los usuarios tienen una clave privada, que usan para autenticar el sistema, que se puede usar para hacer pruebas básicas como "demostrar que soy residente de Zuzalu, pero no revelar cuál". Sin embargo, el sistema Zupass también comenzó a tener otras aplicaciones integradas, sobre todo Stamps (la versión de Zupass de POAP).
Uno de mis muchos sellos Zupass que demuestra que soy un miembro orgulloso del Team Cat.
La característica clave que ofrecen los sellos sobre los POAP es que los sellos son privados: usted conserva los datos localmente y solo les prueba el sello (o algún cálculo) si desea que tengan esta información sobre usted. Pero esto aumenta el riesgo: si pierdes esta información, pierdes tu sello.
Por supuesto, el problema de mantener los datos se reduce al problema de tener una clave criptográfica: un tercero (o incluso 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 mantiene segura su clave de cifrado. Pero incluso entonces, si pierde su clave de cifrado, lo pierde todo. Por el contrario, si alguien ve su clave de encriptación, puede ver todo encriptado con esa clave.
La solución de facto de Zupass es alentar a las personas a almacenar sus claves en varios dispositivos (por ejemplo, una computadora portátil y un teléfono), ya que las posibilidades de que las pierdan todas al mismo tiempo son escasas. Podemos ir un paso más allá y usar un recurso compartido secreto para almacenar la clave, dividiéndola entre varios guardianes.
Esta recuperación social a través de MPC no es una solución adecuada para las billeteras, ya que significa que no solo los tutores actuales, sino también los tutores anteriores pueden coludirse para robar sus activos, lo cual es un alto riesgo inaceptable. Sin embargo, una violación de la privacidad suele ser un riesgo menor que una pérdida total de activos, y si alguien requiere un caso de uso que preserve la privacidad en gran medida, puede aceptar un mayor riesgo de pérdida si no realiza una copia de seguridad de las claves asociadas que requieren privacidad. acciones de conservación.
Para evitar abrumar a los usuarios con un sistema complejo de múltiples rutas de recuperación, es posible que las billeteras que admiten la recuperación social deban administrar tanto la recuperación de activos como la recuperación de claves de cifrado.
Volvamos a la cuestión de la identidad
Un tema común de estos cambios es que el concepto de una "dirección" que usa en la cadena como un identificador criptográfico que lo representa a "usted" tiene que cambiar radicalmente. Las "Instrucciones sobre cómo interactuar conmigo" ya no son solo una dirección ETH; deben contener alguna combinación de múltiples direcciones en múltiples L2, metadirecciones secretas, claves de cifrado y otros datos de alguna forma.
Una forma de hacer esto es hacer que ENS sea su identidad: su registro ENS puede contener toda esta información, y si le envía a alguien bob.eth (o bob.ecc.eth, o...), pueden averiguar y aprender sobre todas las cosas que pagan e interactúan con usted, incluso de formas transversales más complejas y de preservación de la privacidad.
Sin embargo, este enfoque centrado en ENS tiene dos puntos débiles:
Une demasiadas cosas a tu nombre. Tu nombre no eres tú, tu nombre es solo uno de tus muchos atributos. Debería poder cambiar su nombre sin mover todo su perfil de identidad y actualizar un montón de registros en muchas aplicaciones.
No puede tener nombres contrafactuales que no sean de confianza. Una característica clave de UX de cualquier cadena de bloques es la capacidad de enviar monedas a personas que aún no han interactuado con la cadena. Sin dicha funcionalidad, existe el problema del huevo y la gallina: interactuar con la cadena requiere pagar tarifas de transacción, y pagar tarifas requiere... ya poseer monedas. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta función. El nombre ENS no lo hace, porque si dos Bobs deciden que son bob.ecc.eth fuera de la cadena, no hay forma de elegir cuál recibe el nombre.
Una posible solución es poner más cosas en el contrato de almacén de claves mencionado en la arquitectura anteriormente en esta publicación. El contrato del almacén de claves puede contener diversa información sobre usted y cómo interactúa con él (a través de CCIP, algunos de los cuales pueden estar fuera de la cadena), y los usuarios pueden usar su contrato del almacén de claves como identificador principal. Pero los activos reales que reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves no están vinculados a nombres, son amigables contrafactualmente: puede generar una dirección que solo puede inicializarse mediante un contrato de almacén de claves con algunos parámetros iniciales fijos.
Otra categoría de soluciones tiene que ver con abandonar el concepto de direcciones orientadas al usuario, que es similar en espíritu al protocolo de pago de Bitcoin. Una idea es confiar más en los canales de comunicación directos entre el remitente y el destinatario; por ejemplo, el remitente podría enviar un enlace de reclamo (como una URL explícita o un código QR) que el destinatario podría usar para aceptar pagos de la manera que desee.
Ya sea el remitente o el destinatario quien actúa primero, depender más de las billeteras para generar directamente información de pago actualizada en tiempo real reduce la fricción. Habiendo dicho eso, los identificadores persistentes son convenientes (especialmente con ENS) y, en la práctica, la suposición de comunicación directa entre el remitente y el destinatario es un problema muy complicado, por lo que podríamos considerar una combinación de diferentes tecnologías.
En todos estos diseños, es fundamental mantener las cosas descentralizadas y comprensibles para los usuarios. Necesitamos asegurarnos de que los usuarios puedan acceder fácilmente a la vista más actualizada de sus activos actuales, así como a la información publicada destinada a ellos. Estas vistas deben basarse en herramientas abiertas en lugar de soluciones propietarias. Se necesitará mucho trabajo para evitar que una infraestructura de pago más compleja se convierta en una "torre de abstracción" opaca donde los desarrolladores tienen dificultades para comprender lo que está sucediendo y adaptarlo 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.
Un agradecimiento especial a Dan Finlay, Karl Floersch, David Hoffman y los equipos de Scroll y SoulWallet por sus comentarios, revisiones y sugerencias.