Visión de la billetera ideal de Ethereum: actualización integral de la experiencia cross-chain a 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 de L1. La billetera es la ventana a través de la cual los usuarios interactúan con el mundo de Ethereum, y si los usuarios pueden disfrutar de las características de descentralización, resistencia a la censura, seguridad y privacidad que ofrece Ethereum y sus aplicaciones, depende de si la billetera en sí posee estas propiedades.
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 compartir algunas de mis opiniones sobre las características que debería tener una billetera ideal de Ethereum. Esta no es una lista completa, refleja mi inclinación por el ciberpunk, centrándose en la seguridad y la privacidad, y puede carecer en términos de experiencia del usuario. Creo que, al optimizar la experiencia del usuario, desplegar de manera sencilla e iterar según los comentarios es más efectivo que una lista de deseos, por lo que considero que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones cross-chain de L2
Ahora hay una hoja de ruta cada vez más detallada para mejorar la experiencia del usuario en el cross-chain L2, que incluye partes a corto y largo plazo. Aquí se discute principalmente la parte a corto plazo: ideas que teóricamente aún se pueden implementar hoy.
La idea central es:(1) función de envío cruzado de L2 integrada,(2) dirección específica de la cadena y solicitud de pago. Su Billetera debe poder proporcionarle una dirección específica de la cadena, siguiendo el estilo del borrador ERC correspondiente.
Cuando alguien ( o alguna aplicación ) le proporcione una dirección en este formato, debe poder pegarla en el campo "destinatario" de la Billetera y luego hacer clic en "enviar". La Billetera debería procesar automáticamente los datos de envío de cualquier manera posible:
Si ya tiene suficientes tokens del tipo requerido en la cadena de destino, envíe directamente.
Si tiene el tipo de token necesario en otras cadenas, usar protocolos como ERC-7683, en realidad, es un DEX cross-chain (.
Si tiene diferentes tipos de tokens en la misma cadena o en otras cadenas, utilice DEX para convertirlos en la moneda correcta del tipo correcto en la cadena adecuada y enviarlos. Esto requiere el permiso explícito del usuario: el usuario verá los costos de la transacción y la cantidad que recibe el destinatario.
El escenario anterior se aplica a "copiar y pegar la dirección ) o ENS, como vitalik.eth@optimism.eth( si alguien le envía un pago". Para los casos en que dapp solicita un depósito, el proceso ideal es ampliar la API web3, permitiendo que dapp emita solicitudes de pago específicas de la cadena. Su billetera podrá cumplir con esa solicitud de cualquier manera necesaria. Para lograr una buena experiencia de usuario, también es necesario estandarizar la solicitud getAvailableBalance, y la billetera debe considerar cuidadosamente en qué cadenas almacenar los activos de los usuarios por defecto, para maximizar la seguridad y la conveniencia de las transferencias.
Las solicitudes de pago específicas de la cadena también se pueden colocar en un código QR para que las billeteras móviles las escaneen. En situaciones de pago cara a cara ) o en línea (, el receptor emitirá un código QR o llamará a la API web3, indicando "Quiero X unidades del token Z en la cadena, referencia ID o callback W", y la billetera puede elegir libremente cómo 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 que contiene la autorización de reclamación para obtener una cierta cantidad de fondos de su contrato en la cadena, y el receptor necesita averiguar cómo transferir los fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si recibe activos en un L2 que no tiene ETH, necesitará enviar transacciones en ese L2, la billetera debería poder utilizar automáticamente el protocolo ) como RIP-7755( para pagar el gas desde la cadena donde tiene ETH. Si la billetera anticipa que tendrá más transacciones en el L2 en el futuro, también debería enviar ETH a través de DEX que tenga un valor de cientos de transacciones de gas, para que las transacciones futuras puedan pagar el gas directamente allí ) porque es más barato (.
![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-e340d9eff581bff30a541c8aac3178af.webp(
Seguridad de la cuenta
Una forma de conceptualizar el desafío de la seguridad de la cuenta es que una buena Billetera debe desempeñar un papel en dos aspectos: ) proteger a los usuarios de ataques de hackers o comportamientos maliciosos por parte de los desarrolladores de la Billetera, ( proteger a los usuarios de los efectos de sus propios errores.
Mi solución preferida es la recuperación social y una billetera de múltiples firmas, con control de acceso jerárquico. Las cuentas de usuario tienen dos niveles de claves: una clave maestra y N custodios ) donde N=5(. La clave maestra puede realizar operaciones de bajo valor y no financieras. La mayoría de los custodios necesitan ejecutar: )1( operaciones de alto valor, como enviar el valor total de la cuenta, )2( cambiar la clave maestra o cualquier custodio. Si es necesario, se puede permitir que la clave maestra realice operaciones de alto valor a través de un bloqueo temporal.
Este es un diseño básico que se puede expandir. Los mecanismos de permisos como la clave de sesión y ERC-7715 pueden ayudar a equilibrar la conveniencia y la seguridad en diferentes aplicaciones. Una arquitectura de guardianes más compleja, como tener múltiples duraciones de bloqueo de tiempo bajo diferentes umbrales, puede ayudar a maximizar las oportunidades de recuperación exitosa de cuentas legítimas, al tiempo que minimiza el riesgo de robo.
![Vitalik nueva publicación: 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-66ec52b10d00460414381b99c15622ee.webp(
Selección de guardianes
Para los usuarios de criptomonedas experimentados, una opción viable son las claves de amigos y familiares. Si se requiere que cada persona proporcione una nueva dirección, nadie necesita saber quiénes son; de hecho, los guardianes ni siquiera necesitan conocer la identidad de los demás. Si no se comunican, la posibilidad de colusión es muy baja. Sin embargo, para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción es un custodio institucional: una empresa que proporciona servicios para firmar transacciones solo al recibir información de confirmación adicional de su solicitud, como un código de confirmación o una videollamada para usuarios de alto valor. Durante mucho tiempo, la gente ha intentado crear estas, como mi presentación de CryptoCorp en 2013. Sin embargo, hasta ahora estas empresas no han tenido mucho éxito.
La tercera opción son múltiples dispositivos personales ) como teléfonos móviles, computadoras de escritorio, Billetera de hardware (. Esto es viable, pero difícil de configurar y gestionar para los usuarios sin experiencia. También existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente cuando están en el mismo lugar.
Recientemente, hemos comenzado a ver más soluciones basadas en claves universales. Las claves pueden ser respaldadas solo en su dispositivo, convirtiéndolas en una solución de dispositivo personal, o pueden ser respaldadas en la nube, haciendo que su seguridad dependa de complejas suposiciones de seguridad de contraseñas híbridas, de instituciones y de hardware confiable. De hecho, las claves universales son una valiosa ganancia de seguridad para los usuarios comunes, pero depender únicamente de ellas no es suficiente para proteger los ahorros de toda la vida de los usuarios.
Afortunadamente, con ZK-SNARK, tenemos una cuarta opción: ID centralizado envuelto en ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, puede adoptar varias formas de ID centralizado de empresas o gobiernos ) y convertirlo en una dirección de Ethereum, y solo puede enviar transacciones generando una prueba de que posee el ID centralizado a través de ZK-SNARK.
Con este complemento, ahora tenemos una amplia selección, y la ID centralizada empaquetada en ZK tiene una "amigabilidad para principiantes" única.
Para ello, es necesario lograrlo a través de una interfaz de usuario simplificada e integrada: deberías poder especificar únicamente "example@gmail.com" como el guardián, y debería generar automáticamente la dirección de zk-email de Ethereum correspondiente. Los usuarios avanzados deberían poder ingresar el correo electrónico ( y posiblemente el valor de sal de privacidad guardado ) 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 guardián soportado.
Es importante tener en cuenta que el zk-email actual enfrenta un desafío real, ya que depende de la firma DKIM, que utiliza claves que se rotan cada pocos meses y que no han sido firmadas por ninguna otra entidad. Esto significa que el zk-email actual tiene un cierto grado de requisitos de confianza que van más allá del proveedor mismo; si zk-email utiliza la verificación TLSNotary en hardware confiable para actualizar las claves, se puede reducir esta situación, aunque no es ideal. Espero que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Actualmente, sugiero usar un guardián de zk-email, pero no recomiendo que la mayoría de los guardianes lo utilicen: no almacene fondos en zk-email, ya que una falla significaría que no se pueden utilizar los fondos.
Nuevos usuarios y billetera en la aplicación
Los nuevos usuarios, en realidad, no quieren ingresar una gran cantidad de guardianes al registrarse por primera vez. Por lo tanto, la billetera debe ofrecerles una opción muy simple. Un camino natural es usar zk-email en su dirección de correo electrónico, una clave almacenada localmente en el dispositivo del usuario ( que puede ser una clave universal ) y una clave de respaldo que posee el proveedor, para realizar una selección de 2 de 3. A medida que los usuarios se vuelven más experimentados o acumulan más activos, se les debería solicitar 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, ( la aplicación en sí, además de la Billetera de Ethereum ), lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras dentro de la aplicación deberían poder vincular todas las billeteras, de modo que solo tengan que preocuparse por un "problema de control de acceso". La forma más sencilla es adoptar un esquema jerárquico, teniendo un proceso de "enlace" rápido que permita a los usuarios configurar la billetera principal como el guardián de todas las billeteras dentro de la aplicación. El cliente Farcaster Warpcast ya ha apoyado esto.
Proteger a los usuarios de fraudes y otras amenazas externas
Además de la seguridad de la cuenta, las billeteras actuales también han hecho mucho trabajo para identificar direcciones falsas, phishing, fraudes y otras amenazas externas, y se esfuerzan por proteger a los usuarios. Al mismo tiempo, muchas de las contramedidas siguen siendo bastante primitivas: como requerir un clic para enviar Ether u otros tokens a cualquier nueva dirección, independientemente de si se envían 100 dólares o 100,000 dólares. No hay una única solución mágica. Se trata de una serie de reparaciones y mejoras lentas y continuas dirigidas a diferentes categorías de amenazas. Sin embargo, seguir esforzándose por mejorar es muy valioso.
Privacidad
Es hora de tomar más en serio la privacidad de Ethereum. La tecnología ZK-SNARK ha avanzado mucho, y las tecnologías de privacidad que no dependen de puertas traseras para reducir el riesgo regulatorio (, como el fondo de privacidad ), están madurando cada vez más. Infraestructuras secundarias como Waku y los mempools ERC-4337 también se están estabilizando gradualmente. Sin embargo, actualmente, realizar transferencias privadas en Ethereum requiere que los usuarios descarguen y utilicen explícitamente una "Billetera de privacidad", como Railway ( o Umbra ) para direcciones invisibles. Esto incrementa enormemente la inconveniencia 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. Al realizar una transferencia, primero se sale automáticamente del fondo de privacidad. Si el usuario necesita recibir fondos, la Billetera puede generar automáticamente una dirección oculta.
Además, la Billetera puede generar automáticamente nuevas direcciones para cada aplicación en la que el usuario participe, como el protocolo defi (. Los depósitos provienen de un fondo de privacidad, y los retiros entran directamente en el fondo de privacidad. Esto permite que las actividades del usuario en una aplicación se desvinculen de las actividades en otras aplicaciones.
Esta tecnología no solo es una vía natural para la transferencia de activos de privacidad, sino también una vía natural para proteger la identidad privada. La identidad ha ocurrido en la cadena: cualquier aplicación que use la identificación controlada por puerta ) como Gitcoin Grants (, cualquier chat controlado por tokens, los 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 en la cadena de los usuarios no deben concentrarse en un solo lugar: cada proyecto debe almacenarse por separado, y la billetera del usuario debe ser lo único que tenga una "vista global".
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
23 me gusta
Recompensa
23
6
Compartir
Comentar
0/400
SandwichDetector
· 07-16 06:01
La privacidad es la primera fuerza productiva ah ah ah
Ver originalesResponder0
MiningDisasterSurvivor
· 07-13 07:07
Las lecciones del desastre minero de 2018 aún no se han olvidado, primero asegurémonos de proteger la billetera antes de hablar de otras cosas.
Ver originalesResponder0
HappyToBeDumped
· 07-13 07:06
Solo miras un número y ya ves todo verde, ¿y qué billetera?
Ver originalesResponder0
DeepRabbitHole
· 07-13 06:48
Esta billetera es tan buena, ¿por qué siempre se están perdiendo las llaves privadas?
Ver originalesResponder0
HalfBuddhaMoney
· 07-13 06:45
No puedo ver, amigo. Solo me enfoco en la privacidad.
Ver originalesResponder0
Rugpull幸存者
· 07-13 06:45
En términos de privacidad, sigue siendo muy irrelevante.
Ethereum Billetera evolución: de la experiencia cross-chain a la actualización integral de la protección de la privacidad
Visión de la billetera ideal de Ethereum: actualización integral de la experiencia cross-chain a 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 de L1. La billetera es la ventana a través de la cual los usuarios interactúan con el mundo de Ethereum, y si los usuarios pueden disfrutar de las características de descentralización, resistencia a la censura, seguridad y privacidad que ofrece Ethereum y sus aplicaciones, depende de si la billetera en sí posee estas propiedades.
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 compartir algunas de mis opiniones sobre las características que debería tener una billetera ideal de Ethereum. Esta no es una lista completa, refleja mi inclinación por el ciberpunk, centrándose en la seguridad y la privacidad, y puede carecer en términos de experiencia del usuario. Creo que, al optimizar la experiencia del usuario, desplegar de manera sencilla e iterar según los comentarios es más efectivo que una lista de deseos, por lo que considero que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones cross-chain de L2
Ahora hay una hoja de ruta cada vez más detallada para mejorar la experiencia del usuario en el cross-chain L2, que incluye partes a corto y largo plazo. Aquí se discute principalmente la parte a corto plazo: ideas que teóricamente aún se pueden implementar hoy.
La idea central es:(1) función de envío cruzado de L2 integrada,(2) dirección específica de la cadena y solicitud de pago. Su Billetera debe poder proporcionarle una dirección específica de la cadena, siguiendo el estilo del borrador ERC correspondiente.
Cuando alguien ( o alguna aplicación ) le proporcione una dirección en este formato, debe poder pegarla en el campo "destinatario" de la Billetera y luego hacer clic en "enviar". La Billetera debería procesar automáticamente los datos de envío de cualquier manera posible:
El escenario anterior se aplica a "copiar y pegar la dirección ) o ENS, como vitalik.eth@optimism.eth( si alguien le envía un pago". Para los casos en que dapp solicita un depósito, el proceso ideal es ampliar la API web3, permitiendo que dapp emita solicitudes de pago específicas de la cadena. Su billetera podrá cumplir con esa solicitud de cualquier manera necesaria. Para lograr una buena experiencia de usuario, también es necesario estandarizar la solicitud getAvailableBalance, y la billetera debe considerar cuidadosamente en qué cadenas almacenar los activos de los usuarios por defecto, para maximizar la seguridad y la conveniencia de las transferencias.
Las solicitudes de pago específicas de la cadena también se pueden colocar en un código QR para que las billeteras móviles las escaneen. En situaciones de pago cara a cara ) o en línea (, el receptor emitirá un código QR o llamará a la API web3, indicando "Quiero X unidades del token Z en la cadena, referencia ID o callback W", y la billetera puede elegir libremente cómo 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 que contiene la autorización de reclamación para obtener una cierta cantidad de fondos de su contrato en la cadena, y el receptor necesita averiguar cómo transferir los fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si recibe activos en un L2 que no tiene ETH, necesitará enviar transacciones en ese L2, la billetera debería poder utilizar automáticamente el protocolo ) como RIP-7755( para pagar el gas desde la cadena donde tiene ETH. Si la billetera anticipa que tendrá más transacciones en el L2 en el futuro, también debería enviar ETH a través de DEX que tenga un valor de cientos de transacciones de gas, para que las transacciones futuras puedan pagar el gas directamente allí ) porque es más barato (.
![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-e340d9eff581bff30a541c8aac3178af.webp(
Seguridad de la cuenta
Una forma de conceptualizar el desafío de la seguridad de la cuenta es que una buena Billetera debe desempeñar un papel en dos aspectos: ) proteger a los usuarios de ataques de hackers o comportamientos maliciosos por parte de los desarrolladores de la Billetera, ( proteger a los usuarios de los efectos de sus propios errores.
Mi solución preferida es la recuperación social y una billetera de múltiples firmas, con control de acceso jerárquico. Las cuentas de usuario tienen dos niveles de claves: una clave maestra y N custodios ) donde N=5(. La clave maestra puede realizar operaciones de bajo valor y no financieras. La mayoría de los custodios necesitan ejecutar: )1( operaciones de alto valor, como enviar el valor total de la cuenta, )2( cambiar la clave maestra o cualquier custodio. Si es necesario, se puede permitir que la clave maestra realice operaciones de alto valor a través de un bloqueo temporal.
Este es un diseño básico que se puede expandir. Los mecanismos de permisos como la clave de sesión y ERC-7715 pueden ayudar a equilibrar la conveniencia y la seguridad en diferentes aplicaciones. Una arquitectura de guardianes más compleja, como tener múltiples duraciones de bloqueo de tiempo bajo diferentes umbrales, puede ayudar a maximizar las oportunidades de recuperación exitosa de cuentas legítimas, al tiempo que minimiza el riesgo de robo.
![Vitalik nueva publicación: 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-66ec52b10d00460414381b99c15622ee.webp(
Selección de guardianes
Para los usuarios de criptomonedas experimentados, una opción viable son las claves de amigos y familiares. Si se requiere que cada persona proporcione una nueva dirección, nadie necesita saber quiénes son; de hecho, los guardianes ni siquiera necesitan conocer la identidad de los demás. Si no se comunican, la posibilidad de colusión es muy baja. Sin embargo, para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción es un custodio institucional: una empresa que proporciona servicios para firmar transacciones solo al recibir información de confirmación adicional de su solicitud, como un código de confirmación o una videollamada para usuarios de alto valor. Durante mucho tiempo, la gente ha intentado crear estas, como mi presentación de CryptoCorp en 2013. Sin embargo, hasta ahora estas empresas no han tenido mucho éxito.
La tercera opción son múltiples dispositivos personales ) como teléfonos móviles, computadoras de escritorio, Billetera de hardware (. Esto es viable, pero difícil de configurar y gestionar para los usuarios sin experiencia. También existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente cuando están en el mismo lugar.
Recientemente, hemos comenzado a ver más soluciones basadas en claves universales. Las claves pueden ser respaldadas solo en su dispositivo, convirtiéndolas en una solución de dispositivo personal, o pueden ser respaldadas en la nube, haciendo que su seguridad dependa de complejas suposiciones de seguridad de contraseñas híbridas, de instituciones y de hardware confiable. De hecho, las claves universales son una valiosa ganancia de seguridad para los usuarios comunes, pero depender únicamente de ellas no es suficiente para proteger los ahorros de toda la vida de los usuarios.
Afortunadamente, con ZK-SNARK, tenemos una cuarta opción: ID centralizado envuelto en ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, puede adoptar varias formas de ID centralizado de empresas o gobiernos ) y convertirlo en una dirección de Ethereum, y solo puede enviar transacciones generando una prueba de que posee el ID centralizado a través de ZK-SNARK.
Con este complemento, ahora tenemos una amplia selección, y la ID centralizada empaquetada en ZK tiene una "amigabilidad para principiantes" única.
Para ello, es necesario lograrlo a través de una interfaz de usuario simplificada e integrada: deberías poder especificar únicamente "example@gmail.com" como el guardián, y debería generar automáticamente la dirección de zk-email de Ethereum correspondiente. Los usuarios avanzados deberían poder ingresar el correo electrónico ( y posiblemente el valor de sal de privacidad guardado ) 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 guardián soportado.
Es importante tener en cuenta que el zk-email actual enfrenta un desafío real, ya que depende de la firma DKIM, que utiliza claves que se rotan cada pocos meses y que no han sido firmadas por ninguna otra entidad. Esto significa que el zk-email actual tiene un cierto grado de requisitos de confianza que van más allá del proveedor mismo; si zk-email utiliza la verificación TLSNotary en hardware confiable para actualizar las claves, se puede reducir esta situación, aunque no es ideal. Espero que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Actualmente, sugiero usar un guardián de zk-email, pero no recomiendo que la mayoría de los guardianes lo utilicen: no almacene fondos en zk-email, ya que una falla significaría que no se pueden utilizar los fondos.
Nuevos usuarios y billetera en la aplicación
Los nuevos usuarios, en realidad, no quieren ingresar una gran cantidad de guardianes al registrarse por primera vez. Por lo tanto, la billetera debe ofrecerles una opción muy simple. Un camino natural es usar zk-email en su dirección de correo electrónico, una clave almacenada localmente en el dispositivo del usuario ( que puede ser una clave universal ) y una clave de respaldo que posee el proveedor, para realizar una selección de 2 de 3. A medida que los usuarios se vuelven más experimentados o acumulan más activos, se les debería solicitar 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, ( la aplicación en sí, además de la Billetera de Ethereum ), lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras dentro de la aplicación deberían poder vincular todas las billeteras, de modo que solo tengan que preocuparse por un "problema de control de acceso". La forma más sencilla es adoptar un esquema jerárquico, teniendo un proceso de "enlace" rápido que permita a los usuarios configurar la billetera principal como el guardián de todas las billeteras dentro de la aplicación. El cliente Farcaster Warpcast ya ha apoyado esto.
Proteger a los usuarios de fraudes y otras amenazas externas
Además de la seguridad de la cuenta, las billeteras actuales también han hecho mucho trabajo para identificar direcciones falsas, phishing, fraudes y otras amenazas externas, y se esfuerzan por proteger a los usuarios. Al mismo tiempo, muchas de las contramedidas siguen siendo bastante primitivas: como requerir un clic para enviar Ether u otros tokens a cualquier nueva dirección, independientemente de si se envían 100 dólares o 100,000 dólares. No hay una única solución mágica. Se trata de una serie de reparaciones y mejoras lentas y continuas dirigidas a diferentes categorías de amenazas. Sin embargo, seguir esforzándose por mejorar es muy valioso.
Privacidad
Es hora de tomar más en serio la privacidad de Ethereum. La tecnología ZK-SNARK ha avanzado mucho, y las tecnologías de privacidad que no dependen de puertas traseras para reducir el riesgo regulatorio (, como el fondo de privacidad ), están madurando cada vez más. Infraestructuras secundarias como Waku y los mempools ERC-4337 también se están estabilizando gradualmente. Sin embargo, actualmente, realizar transferencias privadas en Ethereum requiere que los usuarios descarguen y utilicen explícitamente una "Billetera de privacidad", como Railway ( o Umbra ) para direcciones invisibles. Esto incrementa enormemente la inconveniencia 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. Al realizar una transferencia, primero se sale automáticamente del fondo de privacidad. Si el usuario necesita recibir fondos, la Billetera puede generar automáticamente una dirección oculta.
Además, la Billetera puede generar automáticamente nuevas direcciones para cada aplicación en la que el usuario participe, como el protocolo defi (. Los depósitos provienen de un fondo de privacidad, y los retiros entran directamente en el fondo de privacidad. Esto permite que las actividades del usuario en una aplicación se desvinculen de las actividades en otras aplicaciones.
Esta tecnología no solo es una vía natural para la transferencia de activos de privacidad, sino también una vía natural para proteger la identidad privada. La identidad ha ocurrido en la cadena: cualquier aplicación que use la identificación controlada por puerta ) como Gitcoin Grants (, cualquier chat controlado por tokens, los 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 en la cadena de los usuarios no deben concentrarse en un solo lugar: cada proyecto debe almacenarse por separado, y la billetera del usuario debe ser lo único que tenga una "vista global".