Autor original: fundador de Ethereum Vitalik Buterin
Un agradecimiento especial a Dan Finlay, Karl Floersch, David Hoffman y los equipos de Scroll y SoulWallet por sus comentarios, revisiones y sugerencias.
A medida que Ethereum pasa de ser una tecnología joven y experimental a una pila de tecnología madura capaz de ofrecer verdaderamente una experiencia abierta, global y sin permisos a los usuarios comunes, la pila deberá pasar por tres transiciones tecnológicas principales aproximadamente simultáneamente:
Transición de expansión L2: todos se mueven a acumulaciones
Transición de la seguridad de la billetera: todos se mudan a billeteras de contrato inteligente
Transición de privacidad: asegúrese de que las transferencias de dinero que preservan la privacidad estén disponibles y asegúrese de que todos los demás widgets en desarrollo (recuperación social, identidad, reputación) preserven la privacidad
Triángulo de transición del ecosistema.
Sin el primero, Ethereum fracasaría ya que cada transacción cuesta $ 3,75 ($ 82,48 si tenemos otra carrera alcista) y cada producto dirigido al mercado masivo inevitablemente se olvidará de la cadena y adoptará una solución centralizada para todo.
Sin el segundo, Ethereum habría fallado ya que los usuarios se mostraban reacios a almacenar sus fondos (y activos no financieros) y todos recurrieron a intercambios centralizados.
Sin un tercero, Ethereum fallaría porque todas las transacciones (y POAP, etc.) Una solución centralizada que oculta sus datos en la mayor medida.
Estas tres transiciones son críticas por las razones descritas anteriormente. Pero también son desafiantes, porque abordarlos adecuadamente requiere una estrecha coordinación. No es solo la funcionalidad del protocolo lo que debe mejorarse; en algunos casos, la forma en que interactuamos con Ethereum debe cambiar fundamentalmente, lo que requiere cambios profundos en las aplicaciones y billeteras.
Estas tres transiciones remodelarán fundamentalmente 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 se basa en Optimism? ¡Entonces tienes una cuenta Optimism! ¿Tiene CDP en el sistema de monedas estables en ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Has probado algunas de las aplicaciones en kakarot? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que un usuario tenía una sola dirección.
*Según mi vista de Brave Wallet, tengo ETH en cuatro lugares. Sí, Arbitrum y Arbitrum Nova son diferentes. ¡No te preocupes, se volverá más desordenado con el tiempo! *
Las billeteras de contratos inteligentes agregan complejidad y hacen que sea más difícil 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 hashes de las claves públicas utilizadas para verificar las firmas, por lo que nada cambia entre L1 y L2. Sin embargo, con las carteras de contratos inteligentes, se vuelve más difícil reservar una dirección. Si bien se ha trabajado mucho para tratar de hacer que las direcciones sean un hash de código que sea equivalente en todas las redes, especialmente en las fábricas de singleton CREATE2 y ERC-2470, ha sido difícil hacer que esto funcione sin problemas. Algunos L2 (como "Tipo 4 ZK-EVM") no son exactamente equivalentes a EVM, por lo general, se utilizan Solidity o ensamblajes intermedios para evitar 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 poco intuitivas.
La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones con las que estamos tratando. Si la propuesta de dirección sigilosa se usa ampliamente, en lugar de solo unas pocas direcciones por usuario, o una dirección por L2, los usuarios podrían tener 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 deberá confiar en el propio sistema de direccionamiento interno del esquema de privacidad.
Como hemos visto, cada una de estas tres transiciones debilita el modelo mental "un usuario ~ = una dirección" de diferentes maneras, y algunos de estos efectos retroalimentan la complejidad de implementar la transición. Dos puntos especiales de complicación son:
Si quisiera pagarle a alguien, ¿cómo obtendría información sobre cómo pagarle?
Si un usuario tiene muchos activos en cadenas almacenados en diferentes lugares, ¿cómo realiza cambios clave y recuperación social?
Tres transiciones y pagos en cadena (e identidades)
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 puedes recibir monedas en Taiko. qué hacer
Básicamente hay dos soluciones:
La billetera receptora (que puede ser un comerciante o una persona común) trabaja muy duro para admitir cada L2, con cierta automatización para integrar fondos de forma asíncrona.
El beneficiario 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 sistema puente entre L2.
Por supuesto, estas soluciones se pueden combinar: el destinatario proporciona una lista de L2 que está dispuesto a aceptar, y la billetera del remitente calcula el pago, lo que puede implicar un envío directo o una ruta puente a través de la L2 si tiene suerte.
Pero este es solo un ejemplo de un desafío clave que presentan estas tres transiciones: operaciones simples como pagarle a alguien comienzan a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, la transición a las carteras de contratos inteligentes no sobrecargará el sistema de direccionamiento, pero aún quedan algunos problemas técnicos por resolver en otras partes de la pila de aplicaciones. Las billeteras deberán actualizarse para asegurarse de que no solo envíen 21000 de gasolina con la transacción, y es más importante asegurarse de que el extremo receptor del pago de la billetera no solo rastree la transferencia de ETH desde el EOA, sino que también rastree la ETH. enviado por el código de contrato inteligente. Las aplicaciones que se basan en la suposición de la propiedad inmutable de las direcciones (por ejemplo, NFT que prohíben los contratos inteligentes para hacer cumplir las tarifas de regalías) tendrán que encontrar otras formas de lograr sus objetivos. Las billeteras de contrato inteligente también facilitarán las cosas, en particular, si alguien solo recibe un token ERC20 que no es ETH, podrá usar ese token para pagar el gas usando los pagadores ERC-4337.
La privacidad, por otro lado, nuevamente plantea un gran desafío que aún no hemos abordado. El Tornado Cash original no presentaba ninguno de estos problemas porque no admitía transferencias internas: los usuarios solo podían depositar en el sistema y retirar dinero. 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" 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) alguna forma para que el remitente envíe la criptomoneda. únicamente Información que el beneficiario puede descifrar para ayudarlo a descubrir el pago.
El protocolo de dirección sigilosa se basa en el concepto de metadirección, que funciona de esta manera: parte de la metadirección es una versión ciega de la clave de gastos del remitente y la otra parte es la clave de cifrado del remitente (aunque las implementaciones mínimas pueden establecer ambas las teclas son las mismas).
Diagrama esquemático de un esquema abstracto de direcciones sigilosas basado en cifrado y ZK-SNARK.
Una lección clave aquí es que en un ecosistema amigable con la privacidad, los usuarios tendrán tanto claves públicas de consumo como claves públicas de cifrado, y la "información de pago" del usuario debe incluir ambas claves. Más allá de los pagos, existen buenas razones para expandirse en 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 las claves de cuenta para esto, pero en el mundo de las billeteras seguras de contratos inteligentes, probablemente deberíamos proporcionar una función 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.
Tres transiciones y recuperación de claves
La forma predeterminada de implementar cambios críticos y recuperación social en un mundo donde cada usuario tiene varias direcciones es simplemente hacer que el usuario ejecute el proceso de recuperación en cada dirección por separado. Esto se puede hacer con un solo clic: las billeteras pueden contener software que puede realizar procedimientos de recuperación en todas las direcciones de un usuario simultáneamente. Sin embargo, incluso con esta simplificación de la experiencia del usuario, existen tres problemas con la recuperación simple de múltiples direcciones:
El costo del gas no es práctico: este se explica por sí mismo.
Direcciones contrafácticas: direcciones que el contrato inteligente aún no ha emitido (en realidad, esto significa cuentas desde las que aún no ha enviado fondos). Como usuario, puede tener una cantidad infinita de direcciones hipotéticas: una o más direcciones en cada L2, incluidas las L2 que aún no existen, y otro conjunto infinito de direcciones hipotéticas resultantes del esquema de direcciones ocultas.
Privacidad: si un usuario tiene intencionalmente varias direcciones para evitar vincularlas entre sí, ¡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 elegante que funciona razonablemente bien: una arquitectura que 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, donde la lógica de validación para cada dirección es un puntero al contrato de almacén de claves. El gasto de estas direcciones requiere una prueba de entrada en el contrato del almacén de claves que muestre la clave pública de gasto actual (o, de manera más realista, más reciente).
La prueba se puede lograr de varias maneras:
Acceso directo a L1 de solo lectura en L2. L2 se puede modificar para leer el estado L1 directamente. Si el contrato del almacén de claves está en L1, esto significa que los contratos dentro de L2 tienen acceso "gratuito" al almacén de claves.
Sucursal Merkel. Las sucursales de Merkle pueden certificar el estado L1 en L2, o el estado L2 en L1, o puede combinar los dos para certificar el estado parcial de una L2 en otra 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, pero esto se reducirá a < 1 kB en el futuro gracias a los árboles de Verkle.
ZK-SNARK. Puede reducir los costos de datos utilizando ZK-SNARK de las bifurcaciones de Merkle en lugar de las propias bifurcaciones. Se pueden construir técnicas de agregación fuera de la cadena (p. ej., encima de EIP-4337) para que un ZK-SNARK verifique todas las pruebas de estado de cadena cruzada en un bloque.
Promesa KZG. L2, o los esquemas construidos sobre ellos, pueden introducir un sistema de direccionamiento secuencial, lo que permite que las pruebas de estado dentro de ese sistema tengan solo 48 bytes de longitud. 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 hacer una prueba para cada transacción, podemos implementar un esquema más ligero que solo requiere una prueba cruzada L2 para recuperarse. 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 para copiar la clave pública de gasto actual en el almacén de claves. Los fondos en direcciones hipotéticas están seguros incluso si sus claves anteriores no lo están: "activar" una dirección hipotética para convertirla en un contrato de trabajo requiere una prueba L2 cruzada para duplicar el gasto actual_pubkey. Este hilo en los foros de Safe describe cómo funciona una arquitectura similar.
Para agregar privacidad a dicho esquema, simplemente encriptamos este puntero y luego hacemos 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 ZK-SNARK y hacer un esquema basado en KZG más simple.
Estos escenarios pueden complicarse. En el lado positivo, hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contratos de almacén de claves" también puede resolver el desafío de la "dirección" mencionado en la sección anterior: si queremos que los usuarios tengan direcciones permanentes que no cambien cada vez que el usuario vuelve a ingresar, podemos colocar las metadirecciones ocultas , las claves 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.
Es necesario actualizar una gran cantidad de infraestructura secundaria
Usar ENS es costoso. Hoy, en junio de 2023, las cosas no están tan mal: las tarifas de transacción son altas, pero aún comparables a las tarifas de dominio de ENS. Registrarme en zuzalu.eth me costó alrededor de $ 27, de los cuales $ 11 fueron tarifas de transacción. Pero si tenemos otro mercado alcista, las tarifas se dispararán. Incluso sin el aumento del precio de ETH, mover las tarifas de gas de nuevo a 200 gwei elevaría la tarifa de tx para registros 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 exigen un registro casi gratuito (y las tarifas de dominio de ENS no son un problema ya que estas plataformas brindan a sus usuarios subdominios), necesitamos ENS en L2 para trabajar .
¡Afortunadamente, el equipo de ENS dio un paso adelante y ENS en L2 está sucediendo! ERC-3668 (también conocido como "estándar CCIP"), junto con ENSIP-10, proporciona una manera de hacer que los subdominios ENS en cualquier L2 sean verificables automáticamente. El estándar CCIP requiere la creación de un contrato inteligente que describa un método de verificación de pruebas de datos L2, y que los dominios (por ejemplo, Optinames use ecc.eth) puedan estar bajo el control de dicho contrato. Una vez que el contrato CCIP toma el control de ecc.eth en L1, acceder a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar la prueba de estado (por ejemplo, la sucursal de Merkle) en L2 donde ese subdominio en particular está realmente almacenado.
En realidad, obtener pruebas implica una lista de URL almacenadas en el contrato, que ciertamente se siente centralizado, pero creo que en realidad no lo es: es un modelo de confianza 1 de N (las pruebas no válidas son capturadas por la lógica de verificación en la función de devolución de llamada del contrato CCIP, siempre que una de las URL devuelva una prueba válida, está bien). La lista de URL puede contener docenas.
El esfuerzo de ENS CCIP es una historia de éxito, y debe verse como una señal de que el tipo de reforma radical que necesitamos es realmente posible. Pero todavía hay muchas reformas en la capa de aplicación que deben realizarse. Algunos ejemplos:
Muchos dapps dependen de los usuarios para proporcionar firmas fuera de la cadena. Con una cuenta 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; tendrán que hacerlo.
Las dapps que usan "¿Es esto EOA?" para diferenciar a los usuarios y los contratos (p. ej., evitar transferencias o aplicar regalías) no funcionarán. En general, desaconsejaría buscar aquí soluciones puramente técnicas; determinar si una transferencia particular de control criptográfico es una transferencia de propiedad real es un problema difícil que no puede resolverse sin abordar algunos mecanismos impulsados por la comunidad fuera de la cadena. Lo más probable es que las aplicaciones tengan que depender menos de la prevención de desvíos y más de técnicas como los impuestos Harberger.
Debe mejorar la forma en que las billeteras interactúan con los pagos y las claves de cifrado. Actualmente, las billeteras suelen usar firmas deterministas para generar claves específicas de la aplicación: firmar un nonce estándar (como un hash del nombre de la aplicación) con la clave privada de EOA genera un valor determinista que no se puede generar sin la clave privada, por lo que es seguro en un sentido puramente técnico. Sin embargo, estas técnicas son "opacas" para las billeteras, lo que impide que las billeteras implementen controles de seguridad a nivel de interfaz de usuario. En ecosistemas más maduros, 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 autenticarse L2 y no solo L1. Hoy en día, los clientes ligeros se centran en verificar la validez de los encabezados L1 (usando el protocolo de sincronización de clientes ligeros) y verificar las bifurcaciones Merkle del estado L1 y las transacciones enraizadas en los encabezados L1. Mañana, también necesitan verificar la prueba del estado de L2, que está arraigada en la raíz de estado almacenada en L1 (la versión más avanzada en realidad analiza la confirmación previa de L2).
Las carteras deberán proteger los activos y los datos
Hoy en día, las billeteras están en el negocio de proteger los activos. Todo está en cadena, y lo único que la billetera necesita proteger son las claves privadas que actualmente protegen estos activos. Si cambia su clave, puede publicar de manera segura su clave privada anterior en Internet al día siguiente. Sin embargo, en el mundo ZK, esto ya no es cierto: la billetera no solo protege las credenciales de autenticación, sino que también guarda sus datos.
Vimos los primeros signos de un mundo así con Zupass, el sistema de identidad basado en ZK-SNARK utilizado por Zuzalu. El usuario tiene una clave privada para autenticarse en el sistema, que puede usarse para hacer pruebas básicas como "demostrar que soy residente de Zuzalu sin revelar cuál". Pero el sistema Zupass también comenzó a crear otras aplicaciones, sobre todo Stamp (la versión de Zupass de POAP).
Uno de mis muchos sellos Zupass que confirma que soy un miembro orgulloso del Team Cat.
La característica clave que ofrecen los sellos en comparación con POAP es que los sellos son privados: mantienes los datos localmente y si quieres que alguien tenga información sobre ti, solo tienes que probar un sello (o algún cálculo en un sello) a alguien. Pero eso añade riesgo: si pierdes esa información, pierdes el sello.
Por supuesto, el problema de mantener los datos se puede reducir al problema de tener una sola clave de cifrado: algún tercero (o incluso una 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 otro lado, si alguien ve su clave de encriptación, puede 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á y usar un recurso compartido secreto para almacenar claves, distribuidas 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 podrían coludirse para robar sus activos, lo cual es un riesgo inaceptablemente alto. Pero el riesgo de una violación de la privacidad suele ser menor que el riesgo total de pérdida de activos, y las personas con casos de alto uso de privacidad siempre pueden aceptar un mayor riesgo de pérdida al no hacer una copia de seguridad de las claves asociadas con estas operaciones que exigen privacidad.
Para evitar que los usuarios se vean abrumados por los sistemas bizantinos con 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.
Volver a la identidad
Una de las cosas que estos cambios tienen en común es que el concepto de "dirección", el identificador criptográfico que usa para representarlo a "usted" en la cadena, tiene que cambiar fundamentalmente. Las "Instrucciones sobre cómo interactuar conmigo" ya no serán solo una dirección ETH; deben ser una combinación de múltiples direcciones en múltiples L2, metadirecciones sigilosas, claves de cifrado y otros datos de alguna forma.
Una forma es hacer que ENS sea su identidad: su registro de ENS puede contener toda esta información, y si le envía a alguien bob.eth (o bob.ecc.eth, o...), puede buscar y ver todo sobre cómo paga e interactúa con usted, incluidos métodos más complejos entre dominios y de preservación de la privacidad.
Pero este enfoque centrado en ENS tiene dos puntos débiles:
Asocia demasiadas cosas con tu nombre de dominio. Su nombre de dominio no es usted, su nombre de dominio es uno de sus muchos atributos. Debería ser posible cambiar su nombre de dominio sin mover todo su perfil de identidad y actualizar un montón de registros en muchas aplicaciones.
No se puede tener maíz contrafactual no confiable. 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, hay una trampa 22: la interacción con la cadena requiere el pago de tarifas de transacción, lo que requiere... ya tener monedas. Las direcciones ETH, incluidas las direcciones de contratos inteligentes con CREATE2, tienen esta funcionalidad. Los nombres ENS no lo harán, porque si dos Bobs deciden que son bob.ecc.eth fuera de la cadena, no hay forma de elegir cuál de ellos recibe el nombre.
Una posible solución es colocar más contenido en el contrato de almacén de claves mencionado anteriormente en la arquitectura de este artículo. El contrato de almacén de claves puede contener todo tipo de información sobre usted y cómo interactúa con él (para CCIP, parte de esta información puede estar fuera de la cadena), y los usuarios utilizarán su contrato de almacén de claves como su identificador principal. Pero los activos reales que reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves son independientes del nombre y son amigables contrafactualmente: puede generar una dirección que se puede probar que solo se inicializa mediante un contrato de almacén de claves con algunos parámetros iniciales fijos.
Otro tipo de solución es similar al protocolo de pago de Bitcoin, abandonando por completo el concepto de direcciones orientadas al usuario. 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 seguir su voluntad de aceptar el pago.
Independientemente de si el remitente o el destinatario se mueven primero, depender más de las billeteras para generar directamente información de pago actualizada en tiempo real reduce la fricción. Dicho esto, los identificadores persistentes son convenientes (especialmente con ENS), mientras que la suposición de comunicación directa entre el remitente y el receptor es muy complicada en la práctica, por lo que podemos terminar viendo una combinación de diferentes tecnologías.
En todos estos diseños, lo más importante es hacer que las cosas sean discretas y fáciles de entender para los usuarios. Necesitamos asegurarnos de que los usuarios tengan fácil acceso a la última vista de cuáles son sus activos actuales y qué noticias se publican para ellos. Estas perspectivas deberían basarse en herramientas abiertas, no en soluciones propietarias. 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 al nuevo entorno requerirá un trabajo arduo. A pesar de los desafíos, lograr la escalabilidad, la seguridad de la billetera y la privacidad para los usuarios comunes es fundamental para el futuro de Ethereum. No se trata solo de la viabilidad técnica, se trata de la accesibilidad real para el usuario promedio. Tenemos que estar a la altura de 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 Buterin: las tres transiciones técnicas de Ethereum
Autor original: fundador de Ethereum Vitalik Buterin
Un agradecimiento especial a Dan Finlay, Karl Floersch, David Hoffman y los equipos de Scroll y SoulWallet por sus comentarios, revisiones y sugerencias.
A medida que Ethereum pasa de ser una tecnología joven y experimental a una pila de tecnología madura capaz de ofrecer verdaderamente una experiencia abierta, global y sin permisos a los usuarios comunes, la pila deberá pasar por tres transiciones tecnológicas principales aproximadamente simultáneamente:
Sin el primero, Ethereum fracasaría ya que cada transacción cuesta $ 3,75 ($ 82,48 si tenemos otra carrera alcista) y cada producto dirigido al mercado masivo inevitablemente se olvidará de la cadena y adoptará una solución centralizada para todo.
Sin el segundo, Ethereum habría fallado ya que los usuarios se mostraban reacios a almacenar sus fondos (y activos no financieros) y todos recurrieron a intercambios centralizados.
Sin un tercero, Ethereum fallaría porque todas las transacciones (y POAP, etc.) Una solución centralizada que oculta sus datos en la mayor medida.
Estas tres transiciones son críticas por las razones descritas anteriormente. Pero también son desafiantes, porque abordarlos adecuadamente requiere una estrecha coordinación. No es solo la funcionalidad del protocolo lo que debe mejorarse; en algunos casos, la forma en que interactuamos con Ethereum debe cambiar fundamentalmente, lo que requiere cambios profundos en las aplicaciones y billeteras.
Estas tres transiciones remodelarán fundamentalmente 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 se basa en Optimism? ¡Entonces tienes una cuenta Optimism! ¿Tiene CDP en el sistema de monedas estables en ZkSync? ¡Entonces tienes una cuenta en ZkSync! ¿Has probado algunas de las aplicaciones en kakarot? ¡Entonces tienes una cuenta en Kakarotto! Atrás quedaron los días en que un usuario tenía una sola dirección.
Las billeteras de contratos inteligentes agregan complejidad y hacen que sea más difícil 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 hashes de las claves públicas utilizadas para verificar las firmas, por lo que nada cambia entre L1 y L2. Sin embargo, con las carteras de contratos inteligentes, se vuelve más difícil reservar una dirección. Si bien se ha trabajado mucho para tratar de hacer que las direcciones sean un hash de código que sea equivalente en todas las redes, especialmente en las fábricas de singleton CREATE2 y ERC-2470, ha sido difícil hacer que esto funcione sin problemas. Algunos L2 (como "Tipo 4 ZK-EVM") no son exactamente equivalentes a EVM, por lo general, se utilizan Solidity o ensamblajes intermedios para evitar 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 poco intuitivas.
La privacidad requiere más direcciones por usuario e incluso puede cambiar los tipos de direcciones con las que estamos tratando. Si la propuesta de dirección sigilosa se usa ampliamente, en lugar de solo unas pocas direcciones por usuario, o una dirección por L2, los usuarios podrían tener 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 deberá confiar en el propio sistema de direccionamiento interno del esquema de privacidad.
Como hemos visto, cada una de estas tres transiciones debilita el modelo mental "un usuario ~ = una dirección" de diferentes maneras, y algunos de estos efectos retroalimentan la complejidad de implementar la transición. Dos puntos especiales de complicación son:
Si quisiera pagarle a alguien, ¿cómo obtendría información sobre cómo pagarle?
Si un usuario tiene muchos activos en cadenas almacenados en diferentes lugares, ¿cómo realiza cambios clave y recuperación social?
Tres transiciones y pagos en cadena (e identidades)
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 puedes recibir monedas en Taiko. qué hacer
Básicamente hay dos soluciones:
Por supuesto, estas soluciones se pueden combinar: el destinatario proporciona una lista de L2 que está dispuesto a aceptar, y la billetera del remitente calcula el pago, lo que puede implicar un envío directo o una ruta puente a través de la L2 si tiene suerte.
Pero este es solo un ejemplo de un desafío clave que presentan estas tres transiciones: operaciones simples como pagarle a alguien comienzan a requerir más información que solo una dirección de 20 bytes.
Afortunadamente, la transición a las carteras de contratos inteligentes no sobrecargará el sistema de direccionamiento, pero aún quedan algunos problemas técnicos por resolver en otras partes de la pila de aplicaciones. Las billeteras deberán actualizarse para asegurarse de que no solo envíen 21000 de gasolina con la transacción, y es más importante asegurarse de que el extremo receptor del pago de la billetera no solo rastree la transferencia de ETH desde el EOA, sino que también rastree la ETH. enviado por el código de contrato inteligente. Las aplicaciones que se basan en la suposición de la propiedad inmutable de las direcciones (por ejemplo, NFT que prohíben los contratos inteligentes para hacer cumplir las tarifas de regalías) tendrán que encontrar otras formas de lograr sus objetivos. Las billeteras de contrato inteligente también facilitarán las cosas, en particular, si alguien solo recibe un token ERC20 que no es ETH, podrá usar ese token para pagar el gas usando los pagadores ERC-4337.
La privacidad, por otro lado, nuevamente plantea un gran desafío que aún no hemos abordado. El Tornado Cash original no presentaba ninguno de estos problemas porque no admitía transferencias internas: los usuarios solo podían depositar en el sistema y retirar dinero. 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" 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) alguna forma para que el remitente envíe la criptomoneda. únicamente Información que el beneficiario puede descifrar para ayudarlo a descubrir el pago.
El protocolo de dirección sigilosa se basa en el concepto de metadirección, que funciona de esta manera: parte de la metadirección es una versión ciega de la clave de gastos del remitente y la otra parte es la clave de cifrado del remitente (aunque las implementaciones mínimas pueden establecer ambas las teclas son las mismas).
Una lección clave aquí es que en un ecosistema amigable con la privacidad, los usuarios tendrán tanto claves públicas de consumo como claves públicas de cifrado, y la "información de pago" del usuario debe incluir ambas claves. Más allá de los pagos, existen buenas razones para expandirse en 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 las claves de cuenta para esto, pero en el mundo de las billeteras seguras de contratos inteligentes, probablemente deberíamos proporcionar una función 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.
Tres transiciones y recuperación de claves
La forma predeterminada de implementar cambios críticos y recuperación social en un mundo donde cada usuario tiene varias direcciones es simplemente hacer que el usuario ejecute el proceso de recuperación en cada dirección por separado. Esto se puede hacer con un solo clic: las billeteras pueden contener software que puede realizar procedimientos de recuperación en todas las direcciones de un usuario simultáneamente. Sin embargo, incluso con esta simplificación de la experiencia del usuario, existen tres problemas con la recuperación simple de múltiples direcciones:
Resolver estos problemas es difícil. Afortunadamente, existe una solución elegante que funciona razonablemente bien: una arquitectura que separa la lógica de validación de la tenencia de activos.
La prueba se puede lograr de varias maneras:
Para agregar privacidad a dicho esquema, simplemente encriptamos este puntero y luego hacemos todas las pruebas en ZK-SNARK:
Estos escenarios pueden complicarse. En el lado positivo, hay muchas sinergias potenciales entre ellos. Por ejemplo, el concepto de "contratos de almacén de claves" también puede resolver el desafío de la "dirección" mencionado en la sección anterior: si queremos que los usuarios tengan direcciones permanentes que no cambien cada vez que el usuario vuelve a ingresar, podemos colocar las metadirecciones ocultas , las claves 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.
Es necesario actualizar una gran cantidad de infraestructura secundaria
Usar ENS es costoso. Hoy, en junio de 2023, las cosas no están tan mal: las tarifas de transacción son altas, pero aún comparables a las tarifas de dominio de ENS. Registrarme en zuzalu.eth me costó alrededor de $ 27, de los cuales $ 11 fueron tarifas de transacción. Pero si tenemos otro mercado alcista, las tarifas se dispararán. Incluso sin el aumento del precio de ETH, mover las tarifas de gas de nuevo a 200 gwei elevaría la tarifa de tx para registros 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 exigen un registro casi gratuito (y las tarifas de dominio de ENS no son un problema ya que estas plataformas brindan a sus usuarios subdominios), necesitamos ENS en L2 para trabajar .
¡Afortunadamente, el equipo de ENS dio un paso adelante y ENS en L2 está sucediendo! ERC-3668 (también conocido como "estándar CCIP"), junto con ENSIP-10, proporciona una manera de hacer que los subdominios ENS en cualquier L2 sean verificables automáticamente. El estándar CCIP requiere la creación de un contrato inteligente que describa un método de verificación de pruebas de datos L2, y que los dominios (por ejemplo, Optinames use ecc.eth) puedan estar bajo el control de dicho contrato. Una vez que el contrato CCIP toma el control de ecc.eth en L1, acceder a algún subdominio.ecc.eth implicará automáticamente encontrar y verificar la prueba de estado (por ejemplo, la sucursal de Merkle) en L2 donde ese subdominio en particular está realmente almacenado.
El esfuerzo de ENS CCIP es una historia de éxito, y debe verse como una señal de que el tipo de reforma radical que necesitamos es realmente posible. Pero todavía hay muchas reformas en la capa de aplicación que deben realizarse. Algunos ejemplos:
Las carteras deberán proteger los activos y los datos
Hoy en día, las billeteras están en el negocio de proteger los activos. Todo está en cadena, y lo único que la billetera necesita proteger son las claves privadas que actualmente protegen estos activos. Si cambia su clave, puede publicar de manera segura su clave privada anterior en Internet al día siguiente. Sin embargo, en el mundo ZK, esto ya no es cierto: la billetera no solo protege las credenciales de autenticación, sino que también guarda sus datos.
Vimos los primeros signos de un mundo así con Zupass, el sistema de identidad basado en ZK-SNARK utilizado por Zuzalu. El usuario tiene una clave privada para autenticarse en el sistema, que puede usarse para hacer pruebas básicas como "demostrar que soy residente de Zuzalu sin revelar cuál". Pero el sistema Zupass también comenzó a crear otras aplicaciones, sobre todo Stamp (la versión de Zupass de POAP).
La característica clave que ofrecen los sellos en comparación con POAP es que los sellos son privados: mantienes los datos localmente y si quieres que alguien tenga información sobre ti, solo tienes que probar un sello (o algún cálculo en un sello) a alguien. Pero eso añade riesgo: si pierdes esa información, pierdes el sello.
Por supuesto, el problema de mantener los datos se puede reducir al problema de tener una sola clave de cifrado: algún tercero (o incluso una 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 otro lado, si alguien ve su clave de encriptación, puede 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á y usar un recurso compartido secreto para almacenar claves, distribuidas 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 podrían coludirse para robar sus activos, lo cual es un riesgo inaceptablemente alto. Pero el riesgo de una violación de la privacidad suele ser menor que el riesgo total de pérdida de activos, y las personas con casos de alto uso de privacidad siempre pueden aceptar un mayor riesgo de pérdida al no hacer una copia de seguridad de las claves asociadas con estas operaciones que exigen privacidad.
Para evitar que los usuarios se vean abrumados por los sistemas bizantinos con 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.
Volver a la identidad
Una de las cosas que estos cambios tienen en común es que el concepto de "dirección", el identificador criptográfico que usa para representarlo a "usted" en la cadena, tiene que cambiar fundamentalmente. Las "Instrucciones sobre cómo interactuar conmigo" ya no serán solo una dirección ETH; deben ser una combinación de múltiples direcciones en múltiples L2, metadirecciones sigilosas, claves de cifrado y otros datos de alguna forma.
Una forma es hacer que ENS sea su identidad: su registro de ENS puede contener toda esta información, y si le envía a alguien bob.eth (o bob.ecc.eth, o...), puede buscar y ver todo sobre cómo paga e interactúa con usted, incluidos métodos más complejos entre dominios y de preservación de la privacidad.
Pero este enfoque centrado en ENS tiene dos puntos débiles:
Una posible solución es colocar más contenido en el contrato de almacén de claves mencionado anteriormente en la arquitectura de este artículo. El contrato de almacén de claves puede contener todo tipo de información sobre usted y cómo interactúa con él (para CCIP, parte de esta información puede estar fuera de la cadena), y los usuarios utilizarán su contrato de almacén de claves como su identificador principal. Pero los activos reales que reciben se almacenarán en una variedad de lugares diferentes. Los contratos de almacén de claves son independientes del nombre y son amigables contrafactualmente: puede generar una dirección que se puede probar que solo se inicializa mediante un contrato de almacén de claves con algunos parámetros iniciales fijos.
Otro tipo de solución es similar al protocolo de pago de Bitcoin, abandonando por completo el concepto de direcciones orientadas al usuario. 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 seguir su voluntad de aceptar el pago.
En todos estos diseños, lo más importante es hacer que las cosas sean discretas y fáciles de entender para los usuarios. Necesitamos asegurarnos de que los usuarios tengan fácil acceso a la última vista de cuáles son sus activos actuales y qué noticias se publican para ellos. Estas perspectivas deberían basarse en herramientas abiertas, no en soluciones propietarias. 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 al nuevo entorno requerirá un trabajo arduo. A pesar de los desafíos, lograr la escalabilidad, la seguridad de la billetera y la privacidad para los usuarios comunes es fundamental para el futuro de Ethereum. No se trata solo de la viabilidad técnica, se trata de la accesibilidad real para el usuario promedio. Tenemos que estar a la altura de este desafío.