Visión de la billetera Ethereum ideal: una actualización integral de la experiencia cross-chain a la protección de la privacidad

La capa de billetera en la infraestructura de Ethereum es crucial, pero a menudo subestimada por los investigadores y desarrolladores del núcleo L1. La billetera es la ventana a través de la cual los usuarios interactúan con el mundo de Ethereum; solo cuando la billetera en sí posee las características adecuadas, los usuarios pueden beneficiarse realmente de las propiedades de descentralización, resistencia a la censura, seguridad y privacidad que ofrece Ethereum y sus aplicaciones.

Recientemente, las billeteras de Ethereum han logrado avances significativos en la mejora de la experiencia del usuario, la seguridad y la funcionalidad. Este artículo tiene como objetivo describir algunas características que una billetera de Ethereum ideal debería tener. Esta no es una lista completa, sino que refleja la inclinación del autor hacia el ciberpunk, centrándose en la seguridad y la privacidad, lo que puede resultar en una falta de atención a la experiencia del usuario. Sin embargo, en comparación con simplemente implementar y iterar según los comentarios, una lista de deseos puede no ser muy efectiva para optimizar la experiencia del usuario, por lo que centrarse en las propiedades de seguridad y privacidad puede ser más valioso.

Experiencia del usuario en transacciones cross-chain L2

La hoja de ruta para mejorar la experiencia del usuario entre L2 se ha vuelto cada vez más clara, incluyendo partes a corto y largo plazo. Este artículo discutirá ideas que se pueden implementar a corto plazo.

La idea central es: (1) incorpora la funcionalidad de envío cross-chain L2, (2) direcciones específicas de la cadena y solicitudes de pago. La Billetera debería poder proporcionar a los usuarios una dirección que cumpla con un estilo específico de borrador ERC.

Cuando el usuario recibe una dirección en este formato, puede pegarla en el campo "Destinatario" de la Billetera y hacer clic en "Enviar". La Billetera debería manejar automáticamente el proceso de envío:

• Si ya hay suficientes tokens necesarios en la cadena de destino, envíalos directamente.
• Si se requieren tokens en otras cadenas, envíalos utilizando un protocolo DEX cross-chain similar a ERC-7683.
• Si hay diferentes tipos de tokens en la misma cadena o en otras cadenas, use DEX para convertir al tipo correcto y enviarlo, se requiere el permiso expreso del usuario.

Esto se aplica a los escenarios de "pago por dirección de copia y pega". En el caso de solicitudes de depósito de dapp, la práctica ideal es expandir la API de web3, permitiendo que la dapp emita solicitudes de pago específicas de la cadena. La Billetera puede satisfacer esta solicitud de manera flexible. Para lograr una buena experiencia de usuario, también es necesario estandarizar la solicitud de getAvailableBalance, y la Billetera debe considerar cuidadosamente en qué cadenas se almacenan por defecto los activos del usuario, para equilibrar la seguridad y la conveniencia de la transferencia.

Las solicitudes de pago específicas de la cadena también se pueden colocar en un código QR para que la billetera móvil lo escanee. En escenarios de pago de consumo cara a cara o en línea, el receptor puede emitir un código QR o una llamada a la API de web3 que indique "Necesito Y unidades del token Z en la cadena X, con ID de referencia W", y la billetera puede satisfacer esa solicitud de manera flexible. Otra opción es el protocolo de enlace de reclamación, donde la billetera del usuario genera un código QR o URL que contiene la autorización de reclamación, siendo el receptor responsable de transferir los fondos a su propia billetera.

Otro tema relacionado es el pago de gas. Si un usuario recibe activos en un L2 sin ETH y necesita enviar una transacción, la billetera debe poder utilizar automáticamente el protocolo ( como RIP-7755) para pagar el gas desde otras cadenas que tienen ETH. Si la billetera espera que el usuario realice más transacciones en ese L2 en el futuro, también puede usar DEX para enviar suficiente ETH que pague por cientos de gas, de modo que las transacciones futuras puedan pagar directamente el gas en L2 ( porque es más barato ).

Seguridad de la cuenta

Una buena forma de conceptualizar la seguridad de la cuenta es que una excelente Billetera debe desempeñar un papel en dos aspectos: ( proteger a los usuarios de ataques de hackers o comportamientos maliciosos de los desarrolladores de la Billetera, ) proteger a los usuarios de las consecuencias de sus propios errores.

La solución preferida es una billetera con recuperación social y múltiples firmas que tiene control de acceso jerárquico. Las cuentas de usuario tienen dos capas de llaves: la llave principal y N guardianes ( como N=5). La llave principal puede realizar operaciones de bajo valor y no financieras. Se requiere la mayoría de los guardianes para ejecutar: (1) operaciones de alto valor, como enviar todos los fondos de la cuenta, (2) cambiar la llave principal o cualquier guardián. Si es necesario, se puede permitir que la llave principal ejecute operaciones de alto valor a través de un bloqueo temporal.

Este es un diseño básico que se puede ampliar. Las claves de sesión y mecanismos de permisos como ERC-7715 pueden ayudar a equilibrar la conveniencia y la seguridad entre diferentes aplicaciones. Una arquitectura de guardianes más compleja, como tener múltiples períodos de bloqueo temporal bajo diferentes umbrales, puede maximizar las oportunidades de recuperar cuentas legítimas con éxito, al mismo tiempo que minimiza el riesgo de robo.

( selección de guardianes

Para los usuarios experimentados en la comunidad cripto, se puede elegir a las claves de amigos y familiares como tutores. Si se requiere que cada uno proporcione una nueva dirección, ni siquiera es necesario conocer la identidad de los demás. Sin embargo, esto no se aplica a la mayoría de los nuevos usuarios.

La segunda opción es un custodio institucional: un servicio que solo firma transacciones al recibir información de confirmación adicional solicitada por el usuario, como un código de confirmación o una videollamada de un usuario de alto valor ). Aunque ha habido intentos de establecer este tipo de servicios durante mucho tiempo, actualmente no han tenido mucho éxito.

La tercera opción son varios dispositivos personales ### como teléfonos móviles, computadoras de escritorio y billeteras de hardware (. Esto es viable, pero puede ser difícil de configurar y gestionar para los usuarios principiantes. También existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente si están ubicados en el mismo lugar.

Recientemente, hemos comenzado a ver más soluciones basadas en claves maestras. La clave puede respaldarse solo en el dispositivo, convirtiéndose en una solución de dispositivo personal, o puede respaldarse en la nube, cuya seguridad depende de complejas suposiciones de seguridad de contraseña híbrida, institucional y de hardware confiable. Aunque para el usuario promedio representa una valiosa ganancia de seguridad, depender únicamente de ellas no es suficiente para proteger los ahorros de toda una vida del usuario.

Afortunadamente, con ZK-SNARK, tenemos una cuarta opción: ID centralizada envuelta en ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, se pueden adoptar múltiples formas de ID centralizada de ) empresas o gobiernos ( y convertirlas en direcciones de Ethereum, los usuarios solo pueden enviar transacciones generando una prueba ZK-SNARK que posee el ID centralizado.

Las ID centralizadas empaquetadas en ZK tienen una "amigabilidad para principiantes" única. Para ello, se requiere lograrlo a través de una interfaz de usuario simplificada e integrada: el usuario solo necesita especificar que desea que "example@gmail.com" sea el tutor, y debería generar automáticamente la dirección zk-email de Ethereum correspondiente en segundo plano. Los usuarios avanzados deberían poder ingresar su correo electrónico ) y el posible valor de sal de privacidad ( en aplicaciones de terceros de código abierto y confirmar que la dirección generada es correcta. Lo mismo debería aplicarse a cualquier otro tipo de tutor admitido.

Es importante tener en cuenta que actualmente zk-email enfrenta un desafío práctico, ya que depende de la firma DKIM, que utiliza una clave que se rota cada pocos meses, y estas claves no están firmadas por ninguna otra entidad. Esto significa que el zk-email de hoy en día necesita confiar en el proveedor en cierta medida; si zk-email usara TLSNotary dentro de hardware de confianza para verificar las claves actualizadas, se podría reducir esta situación, pero no es ideal. Se espera que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Actualmente, se recomienda usar un zk-email como guardián, pero no se aconseja su uso por la mayoría de los guardianes: no almacene fondos en un zk-email, ya que su daño significa que los fondos no pueden ser utilizados.

![Vitalik nuevo artículo: la visión del Billetera ideal, desde la experiencia cross-chain hasta la actualización integral de la protección de la privacidad])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(

) Nuevos usuarios y Billetera en la aplicación

Los nuevos usuarios en realidad no quieren ingresar muchos guardianes al registrarse por primera vez. Por lo tanto, la billetera debería ofrecerles una opción muy simple. Una forma natural es usar zk-email en su dirección de correo electrónico, la clave almacenada localmente en el dispositivo del usuario ( puede ser la clave maestra ) y la clave de respaldo que posee el proveedor, para hacer una selección de 2 de 3. A medida que los usuarios acumulan más experiencia o activos, se les debería sugerir en algún momento que agreguen más guardianes.

La integración de la billetera en la aplicación es inevitable, ya que las aplicaciones que intentan atraer a usuarios no criptográficos no desean que los usuarios tengan que descargar dos nuevas aplicaciones al mismo tiempo, ### la propia aplicación y una billetera de Ethereum (, lo que generaría una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras dentro de la aplicación deberían poder vincular todas las billeteras juntas, de modo que solo tengan que centrarse en un "problema de control de acceso". La forma más sencilla es adoptar un enfoque jerárquico, a través de un rápido proceso de "enlace", que permita a los usuarios establecer la billetera principal como la guardiana de todas las billeteras dentro de la aplicación.

![Vitalik nuevo artículo: la visión de la Billetera ideal, una actualización integral desde la experiencia cross-chain hasta la protección de la privacidad])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(

) Proteger a los usuarios de fraudes y otras amenazas externas

Además de la seguridad de la cuenta, las billeteras de hoy en día también han hecho mucho trabajo para identificar direcciones falsas, phishing, fraudes y otras amenazas externas, y se esfuerzan por proteger al usuario. Al mismo tiempo, muchas de las contramedidas siguen siendo bastante primitivas: por ejemplo, se requiere hacer clic para enviar Ether u otros tokens a cualquier nueva dirección, sin importar el monto a enviar. No hay una solución única para todos, sino una serie de mejoras continuas dirigidas a diferentes categorías de amenazas. Seguir trabajando en esta área es muy valioso.

Privacidad

Ahora es el momento de tomar más en serio la privacidad de Ethereum. La tecnología ZK-SNARK ha avanzado mucho, no depende de puertas traseras para reducir el riesgo regulatorio, y las tecnologías de privacidad ###, como los pools de privacidad (, están madurando cada vez más. Infraestructuras de segunda capa como Waku y los mempools ERC-4337 también se están volviendo más estables. Sin embargo, actualmente, realizar transferencias privadas en Ethereum requiere que los usuarios descarguen y utilicen explícitamente una "Billetera" de privacidad. Esto aumenta enormemente la incomodidad y reduce el número de personas dispuestas a realizar transferencias privadas. La solución es integrar las transferencias privadas directamente en la billetera.

Una implementación simple es la siguiente. La billetera puede almacenar una parte de los activos del usuario como "saldo privado" en el fondo de privacidad. Cuando el usuario realiza una transferencia, saldrá automáticamente del fondo de privacidad. Si el usuario necesita recibir fondos, la billetera puede generar automáticamente una dirección invisible.

Además, la Billetera puede generar automáticamente una nueva dirección para cada aplicación en la que el usuario participe ), como los protocolos defi (. Los depósitos provendrán del grupo de privacidad, y los retiros irán directamente al grupo de privacidad. Esto permite que las actividades del usuario en una aplicación estén desconectadas de sus actividades en otras aplicaciones.

Esta tecnología no solo es un medio natural para proteger la transferencia de activos de privacidad, sino también un medio natural para proteger la identidad de privacidad. La identidad ya ha ocurrido en la cadena: cualquier aplicación que utilice pruebas de identidad controladas por puertas ) como Gitcoin Grants (, cualquier chat controlado por tokens, protocolos que siguen Ethereum, etc., son identidades en la cadena. Esperamos que este ecosistema también pueda proteger la privacidad. Esto significa que las actividades de los usuarios en la cadena no deben recopilarse en un solo lugar: cada proyecto debe almacenarse de manera individual, y la billetera del usuario debería ser lo único que tenga una "vista global" y que pueda ver simultáneamente todas las pruebas. Un ecosistema nativo donde cada usuario tiene múltiples cuentas ayuda a lograr este objetivo, al igual que los protocolos de prueba fuera de la cadena como EAS y Zupass.

Esto representa una visión pragmática de la privacidad de Ethereum a medio plazo. Aunque se pueden introducir algunas funciones en L1 y L2 para hacer que las transferencias con protección de privacidad sean más eficientes y confiables, ya se puede lograr ahora. Algunos defensores de la privacidad creen que lo único aceptable es la privacidad total de todas las cosas: cifrar todo el EVM. Esto podría ser el resultado ideal a largo plazo, pero requiere una reconsideración más fundamental del modelo de programación.