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

La capa de billetera en la pila de infraestructura de Ethereum es crucial, pero a menudo es subestimada por los investigadores y desarrolladores centrales. Como ventana entre el usuario y el mundo de Ethereum, la billetera misma debe poseer características como descentralización, resistencia a la censura, seguridad y privacidad, para que los usuarios puedan disfrutar verdaderamente de estas propiedades que ofrece Ethereum y sus aplicaciones.

Recientemente, las billeteras de Ethereum han tenido avances significativos en experiencia del usuario, seguridad y funcionalidad. Este artículo tiene como objetivo compartir algunas de mis opiniones sobre las características que debería tener una billetera de Ethereum ideal. Esta no es una lista completa, refleja más bien mis inclinaciones de criptopunk, centrándose en la seguridad y la privacidad, lo que puede no ser del todo exhaustivo en cuanto a la experiencia del usuario. Sin embargo, creo que, en comparación con simplemente optimizar la experiencia del usuario a través de la implementación y la iteración basadas en comentarios, enfocarse en las propiedades de seguridad y privacidad puede ser más valioso.

Experiencia del usuario en transacciones cross-chain L2

Actualmente hay una hoja de ruta cada vez más completa para mejorar la experiencia de usuario en cross-chain L2, que incluye partes a corto y largo plazo. Aquí discutiré ideas que se pueden implementar a corto plazo.

La idea central es: (1) funcionalidad de envío cruzado L2 incorporada, (2) dirección específica de la cadena y solicitud de pago. La Billetera debe poder proporcionar a los usuarios una dirección que siga el estilo del borrador ERC.

Cuando el usuario recibe una dirección en este formato, solo necesita pegarla en el campo "destinatario" de la Billetera y hacer clic en "enviar", la Billetera debería procesar el envío automáticamente:

• Si ya hay suficientes tokens en la cadena objetivo, envíalos directamente.
• Si se requieren tokens en otras cadenas, use el protocolo DEX cross-chain para enviar.
• Si hay diferentes tipos de tokens, conviértelos a la tipo correcto usando DEX y luego envía (, se requiere confirmación del usuario ).

Para el escenario en el que dapp solicita depósitos, la práctica ideal es extender la API web3, permitiendo que dapp emita solicitudes de pago específicas de la cadena. La Billetera necesita estandarizar la solicitud getAvailableBalance y considerar cuidadosamente en qué cadenas se almacenan de manera predeterminada los activos del usuario, para equilibrar la seguridad y la conveniencia de las transferencias.

Las solicitudes de pago específicas de la cadena también se pueden incluir en un código QR para ser escaneadas por una Billetera móvil. En escenarios de pago cara a cara o en línea, el código QR o la llamada API emitida por el receptor indica "Quiero Z token de Y unidades en la cadena X, con ID de referencia W", y la Billetera puede elegir libremente la forma de satisfacer esa solicitud. Otra opción es el protocolo de enlace de reclamación, donde la Billetera del usuario genera un código QR o URL autorizado, y el receptor es responsable de extraer los fondos.

El pago de gas también es un tema relacionado. Si un usuario recibe activos en un L2 pero no tiene ETH, la billetera debe poder utilizar automáticamente el protocolo para pagar el gas en la cadena donde el usuario tenga ETH. Si la billetera prevé que el usuario realizará más transacciones en ese L2 en el futuro, también se puede utilizar un DEX para enviar una cierta cantidad de ETH como reserva de gas.

Seguridad de la cuenta

Creo que la clave de la seguridad de la cuenta radica en proteger al usuario tanto de los ataques de hackers o comportamientos maliciosos de los desarrolladores de la Billetera, como de los errores del propio usuario.

La solución a la que he tendido a lo largo del tiempo 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 claves: una clave principal y N guardianes ( donde N=5). La clave principal se puede utilizar para operaciones de bajo valor y no financieras. La mayoría de los guardianes necesitan ejecutar: (1) operaciones de alto valor, como enviar todos los fondos de la cuenta, (2) cambiar la clave principal o cualquier guardián. Si es necesario, se puede permitir que la clave principal ejecute operaciones de alto valor a través de un bloqueo temporal.

Este diseño básico se puede ampliar aún más. Los mecanismos de claves de sesión y permisos pueden apoyar un equilibrio entre conveniencia y seguridad en diferentes aplicaciones. Una arquitectura de guardianes más compleja, como establecer múltiples períodos de bloqueo de tiempo a diferentes umbrales, ayuda a maximizar la tasa de éxito en la recuperación de cuentas legítimas mientras se minimiza el riesgo de robo.

Para la selección de tutores, hay varias opciones:

1. Para los usuarios de criptomonedas con experiencia, pueden elegir las claves de amigos y familiares.
2. Custodio institucional: empresa que proporciona servicios de firma, necesita confirmar información adicional.
3. Varios dispositivos personales ( como teléfonos móviles, computadoras, billeteras de hardware ), pero los nuevos usuarios pueden encontrar difícil configurarlos y gestionarlos.
4. Soluciones basadas en gestores de contraseñas, que pueden respaldarse localmente o en la nube, pero depender únicamente de ellas no es suficiente para proteger todos los activos del usuario.
5. ID centralizado envuelto en ZK: como zk-email, Anon Aadhaar, etc., que puede convertir ID centralizado en dirección Ethereum.

La ID centralizada empaquetada en ZK es amigable para los nuevos usuarios. La billetera debe proporcionar una interfaz de usuario de integración simplificada, permitiendo a los usuarios especificar directamente un correo electrónico como guardián, generando automáticamente la dirección zk-email de Ethereum correspondiente. Los usuarios avanzados deben poder verificar la corrección de la dirección generada.

Para los nuevos usuarios, la Billetera puede ofrecer opciones simples, como un esquema de 2 de 3 basado en zk-email, almacenamiento local de claves y claves de respaldo del proveedor. A medida que la experiencia del usuario crezca o aumenten los activos, se debe sugerir agregar más guardianes.

La integración de billeteras dentro de la aplicación es inevitable, pero los usuarios deben poder vincular todas las billeteras entre sí y gestionar un control de acceso unificado. Un método simple es adoptar un esquema jerárquico que permita a los usuarios configurar la billetera principal como la guardiana de todas las billeteras dentro de la aplicación.

Proteger a los usuarios de estafas y otras amenazas externas

Además de la seguridad de la cuenta, la actual Billetera ha realizado un gran trabajo en la identificación de direcciones falsas, phishing, estafas, etc. Sin embargo, muchas de las medidas siguen siendo bastante primitivas, como la exigencia uniforme de hacer clic en confirmar antes de enviar tokens a una nueva dirección, sin importar el tamaño de la cantidad. Esto requiere mejoras continuas en función de las diferentes categorías de amenazas; no hay una solución definitiva.

Privacidad

Es hora de tomar más en serio la privacidad de Ethereum. La tecnología ZK-SNARK ha avanzado considerablemente, y las tecnologías de privacidad que no dependen de puertas traseras, como los pools de privacidad (, están madurando. Infraestructuras de segundo nivel como Waku y los mempools ERC-4337 también se están estabilizando gradualmente. Sin embargo, actualmente, para realizar transferencias privadas, los usuarios deben descargar y usar explícitamente una "Billetera" de privacidad, lo que aumenta la incomodidad y disminuye el número de usuarios. La solución es integrar las transferencias privadas directamente en la billetera.

Una implementación simple es: la billetera almacena una parte de los activos del usuario como "saldo privado" en un fondo de privacidad. Al transferir, se sale automáticamente del fondo de privacidad y al recibir fondos, se genera automáticamente una dirección invisible.

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

Además, la billetera puede generar automáticamente nuevas direcciones para cada aplicación en la que el usuario participe. Los depósitos provienen de un grupo de privacidad, y los retiros van directamente al grupo de privacidad. Esto permite a los usuarios desacoplar las actividades en diferentes aplicaciones.

Esta no solo es una forma natural de proteger la privacidad de la transferencia de activos, sino también una manera de proteger la privacidad de la identidad. La identidad en cadena ya existe, como en aplicaciones que utilizan identificación, chats con control de tokens, etc. Esperamos que este ecosistema también pueda proteger la privacidad, es decir, las actividades en cadena de los usuarios no deben concentrarse en un solo lugar: cada proyecto debe almacenarse por separado, y solo la billetera del usuario puede ver todas las pruebas simultáneamente. Un ecosistema que soporte cuentas múltiples por usuario ayuda a lograr este objetivo, así como los protocolos de prueba fuera de la cadena como EAS y Zupass.

Esto representa una visión pragmática a medio plazo para la privacidad en Ethereum. 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, eso ya se puede lograr ahora. Algunos defensores de la privacidad creen que solo la privacidad total es aceptable, como cifrar todo el EVM. Esto podría ser el resultado ideal a largo plazo, pero requeriría una reconsideración más fundamental del modelo de programación, que aún no ha alcanzado la madurez de implementación. Realmente necesitamos privacidad por defecto para obtener un conjunto anónimo lo suficientemente grande. Sin embargo, enfocarse primero en las transferencias entre cuentas ), ( identidades y casos de uso relacionados ) como pruebas privadas ( es un primer paso pragmático, más fácil de implementar, y la billetera ya puede comenzar a usarse.

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

La Billetera de Ethereum también necesita convertirse en una billetera de datos

Cualquier solución de privacidad efectiva generará la necesidad de que los usuarios almacenen datos fuera de la cadena, ya sea para pagos, identidad u otros casos de uso. Los protocolos de privacidad modernos a veces almacenan datos cifrados en la cadena, utilizando una sola clave privada para descifrarlos. Esto conlleva riesgos, ya que si la clave se filtra o si las computadoras cuánticas se vuelven viables, todos los datos se harán públicos. La prueba fuera de la cadena requiere de manera más significativa el almacenamiento de datos fuera de la cadena.

La billetera no solo necesita almacenar los permisos de acceso en la cadena, sino que también necesita almacenar los datos privados del usuario. El mundo no criptográfico también está reconociendo cada vez más esto. Necesitamos construir garantías robustas en torno a la accesibilidad de los datos y la prevención de filtraciones. Quizás se puedan superponer estas soluciones: si hay N guardianes, se puede usar el compartimiento secreto M-of-N entre estos N guardianes para almacenar los datos. Proteger los datos es esencialmente más difícil, ya que no se puede revocar la parte de datos de alguien, pero deberíamos proponer soluciones de custodia descentralizadas que sean lo más seguras posible.

Acceso seguro a la cadena

Actualmente, la Billetera depende de proveedores de RPC para obtener información de la cadena, lo que presenta dos vulnerabilidades:

1. Los proveedores de RPC pueden robar fondos al proporcionar información falsa como el precio del mercado ).
2. Los proveedores de RPC pueden obtener información privada del usuario sobre su interacción con la aplicación.

En un escenario ideal, esperamos cerrar estas dos vulnerabilidades. Resolver el primer problema requiere la estandarización de clientes ligeros L1 y L2, que verifiquen directamente el consenso de la cadena de bloques. Helios ya se ha implementado para L1 y ha comenzado a soportar algunos L2. Para cubrir todos los L2, necesitamos un estándar que obtenga la raíz de estado más reciente y verifique la lógica de prueba de estado y recibos a través de contratos de configuración que representen L2. De esta manera, puede haber un cliente ligero universal que permita a la billetera verificar de manera segura cualquier estado o evento en L1 y L2.

Para la privacidad, actualmente la única forma realista es ejecutar su propio nodo completo. Pero con la popularidad de L2, se vuelve cada vez más difícil ejecutar nodos completos que manejen todo. Aquí, el equivalente de un cliente ligero es la recuperación de información privada (PIR). PIR implica servidores que mantienen copias de todos los datos y clientes que envían solicitudes cifradas a los servidores. Los servidores realizan cálculos sobre todos los datos y devuelven a los clientes los datos cifrados que necesitan, sin saber qué datos accedió el cliente.

Para garantizar la honestidad del servidor, cada elemento de la base de datos es en sí mismo una rama de Merkle, y el cliente puede verificarlo utilizando un cliente ligero.

El cálculo de PIR es muy grande. Las soluciones incluyen:

• Fuerza bruta: mejoras en algoritmos o hardware especializado pueden hacer que el PIR funcione lo suficientemente rápido.
• Debilitar los requisitos de privacidad: como buscar solo 1 millón de "mixins" cada vez.
• PIR de múltiples servidores: al usar varios servidores, asumiendo que 1 de N es honesto, el algoritmo PIR suele ser más rápido.
• Anonimato en lugar de confidencialidad: Se envían solicitudes a través de una red de mezcla, ocultando al remitente en lugar del contenido. Pero esto aumentará la latencia.

Encontrar la combinación técnica correcta en el entorno de Ethereum para maximizar la privacidad mientras se mantiene la utilidad es un problema de investigación abierto.

Billetera de clave ideal

En el contexto de cross-chain L2, otro proceso importante que necesita funcionar sin problemas es el cambio de la verificación de cuentas.