Visión de la billetera Ethereum ideal: actualización integral de la experiencia cross-chain a la protección de la privacidad
La billetera es una capa clave en la pila de infraestructura de Ethereum, 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 se comunican con el mundo de Ethereum; los usuarios solo pueden beneficiarse de las características descentralizadas, resistentes a la censura, seguras y privadas que ofrece Ethereum y sus aplicaciones cuando la billetera posee las propiedades correspondientes.
Recientemente, las billeteras de Ethereum han logrado avances significativos en la mejora de la experiencia del usuario, la seguridad y las funciones. Este artículo tiene como objetivo compartir opiniones sobre las características que debería tener una billetera ideal de Ethereum. Esta no es una lista completa, refleja la inclinación del autor por el ciberpunk, centrándose en la seguridad y la privacidad, y puede que no sea lo suficientemente integral en términos de experiencia del usuario. Sin embargo, el autor cree que optimizar la experiencia del usuario mediante el despliegue e iteración simples basados en retroalimentación es más efectivo que una lista de deseos, por lo que considera que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
experiencia del usuario en transacciones cross-chain L2
Ahora hay un mapa de ruta cada vez más detallado para mejorar la experiencia de usuario entre cadenas L2, que incluye partes a corto y largo plazo. Aquí se discute la parte a corto plazo: ideas que teóricamente se pueden implementar ahora.
La idea central es: (i) envío incorporado cross-chain L2, así como (ii) direcciones específicas de la cadena y solicitudes de pago. La Billetera debería 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, debe poder pegarla en el campo "destinatario" de la Billetera y hacer clic en "enviar". La Billetera debe procesar automáticamente los datos de envío:
Si hay suficientes tokens del tipo requerido en la cadena de destino, envíalos directamente.
Si se necesita un tipo de token en otra cadena, envíe utilizando un protocolo similar a ERC-7683.
Si hay diferentes tipos de tokens, utilice DEX para convertir al tipo correcto y enviar.
Esto se aplica a los escenarios de "pago por dirección de copiar y pegar". En el caso de aplicaciones que solicitan depósitos, el proceso ideal es extender la API de web3 y permitir que la aplicación emita solicitudes de pago específicas de la cadena. La Billetera puede satisfacer esa solicitud de cualquier manera necesaria. 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 almacenar por defecto los activos del usuario, para maximizar 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 que las billeteras móviles lo escaneen. En escenarios de pago cara a cara o en línea, el receptor emitirá un código QR o llamará a la API web3, indicando "Quiero Y unidades del token Z en la cadena X, con el ID de referencia o el callback W", y la billetera puede satisfacer libremente 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, y el receptor es responsable de transferir los fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si se reciben activos en un L2 sin ETH y se necesita enviar una transacción, la Billetera debería poder utilizar automáticamente el protocolo ( como RIP-7755) para pagar el gas desde una cadena que tenga ETH. Si la Billetera espera que el usuario realice más transacciones en el L2 en el futuro, también debería usar solo DEX para enviar una cantidad suficiente de ETH, para que las futuras transacciones puedan pagar directamente el gas allí ( porque es más barato ).
seguridad de la cuenta
La conceptualización del desafío a la seguridad de la cuenta es que una buena Billetera debe funcionar en dos aspectos: (i) proteger a los usuarios de los ataques de hackers o comportamientos maliciosos por parte de los desarrolladores de la Billetera, (ii) proteger a los usuarios de los efectos de sus propios errores.
La solución preferida es la recuperación social y la Billetera de múltiples firmas, con control de acceso jerárquico. Las cuentas de usuario tienen dos capas de claves: la clave principal y N tutores ( donde N=5). La clave principal puede realizar operaciones de bajo valor y no financieras. La mayoría de los tutores necesitan ejecutar (i) operaciones de alto valor, como enviar el valor total de la cuenta, o (ii) cambiar la clave principal o cualquier tutor. Si es necesario, se puede permitir que la clave principal realice operaciones de alto valor a través de un bloqueo temporal.
El diseño básico es extensible. Mecanismos de autorización como la clave de sesión y ERC-7715 pueden ayudar a equilibrar la conveniencia y la seguridad entre diferentes aplicaciones. Estructuras de guardianes más complejas, como tener múltiples duraciones de bloqueo temporal bajo diferentes umbrales, pueden ayudar a maximizar las oportunidades de recuperar cuentas legítimas con éxito, al mismo tiempo que minimizan el riesgo de robo.
selección del tutor
Para los usuarios de criptomonedas con experiencia, una opción viable es la clave de amigos y familiares. Si se requiere que cada persona proporcione una nueva dirección, nadie necesita conocer la identidad del otro, por lo que la posibilidad de colusión es muy pequeña. Pero para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción es el custodio institucional: un servicio que firma transacciones solo cuando recibe otra información de confirmación. Durante mucho tiempo, la gente ha intentado crear este tipo de servicios, pero hasta ahora no ha tenido mucho éxito.
La tercera opción son varios dispositivos personales ( como teléfonos móviles, computadoras, billeteras de hardware ). Esto es viable, pero difícil de configurar y gestionar para los principiantes. Existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente cuando están en la misma ubicación.
Recientemente han aparecido más soluciones basadas en llaves universales. Las llaves se pueden respaldar en dispositivos o en la nube, y su seguridad depende de complejas suposiciones de seguridad de contraseñas mixtas, instituciones y hardware confiable. Para los usuarios comunes, es una valiosa mejora en la seguridad, pero solo depender 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 centralizada empaquetada en ZK. Este tipo de soluciones incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, se pueden adoptar diversas formas de ID centralizada de la empresa o del gobierno ( y convertirlas en direcciones de Ethereum, y las transacciones solo pueden enviarse generando una prueba de la posesión de la ID centralizada mediante ZK-SNARK.
Con esta adición, ahora tenemos una amplia selección, las ID centralizadas empaquetadas en ZK tienen una "amigabilidad para principiantes" única.
Para ello, se necesita implementar una UI simplificada e integrada: debe poder especificar solo "example@gmail.com" como guardián, generando automáticamente la dirección zk-email de Ethereum correspondiente. Los usuarios avanzados deben poder ingresar el correo ) y el posible valor de sal de privacidad guardado ( en aplicaciones de terceros de código abierto, confirmando que la dirección generada es correcta. Esto también debe aplicarse a otros tipos de guardianes soportados.
Atención, el desafío real que enfrenta zk-email hoy en día es la dependencia de la firma DKIM, utilizando claves que se rotan cada pocos meses, y que estas claves no están firmadas por otras entidades. Esto significa que el zk-email actual tiene un cierto grado de requisitos de confianza que van más allá del propio proveedor; por ejemplo, el uso de TLSNotary para verificar las claves actualizadas dentro de hardware confiable podría reducir esta situación, pero no es ideal. Se espera que los proveedores de correo electrónico comiencen a firmar directamente las claves DKIM. Actualmente se recomienda que un guardián use zk-email, pero no se aconseja a la mayoría de los guardianes que lo usen: no almacenen fondos en zk-email, ya que un daño implica la incapacidad de acceder a los fondos.
![Vitalik nuevo artículo: visión de la 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 desean ingresar una gran cantidad de guardianes al registrarse por primera vez. Por lo tanto, la billetera debe ofrecer una opción muy simple. La forma natural es utilizar zk-email en la dirección de correo electrónico, la clave almacenada localmente en el dispositivo del usuario ### que podría ser la clave maestra ( y la clave de respaldo mantenida por 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 sugerir en algún momento que agreguen más guardianes.
La integración de billeteras en aplicaciones es inevitable, ya que las aplicaciones que intentan atraer a usuarios no cripto no desean que los usuarios tengan que descargar dos aplicaciones nuevas, lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras de aplicaciones deberían poder vincular todas las billeteras, de modo que solo tengan que concentrarse en un "problema de control de acceso". La forma más sencilla es adoptar un esquema jerárquico, con un rápido proceso de "vinculación" que permite a los usuarios establecer la billetera principal como la guardiana de todas las billeteras dentro de la aplicación. El cliente de Farcaster Warpcast ya ha apoyado esto.
![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(
) protege 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 trabajado mucho para identificar direcciones falsas, phishing, estafas y otras amenazas externas, y se esfuerzan por proteger a los usuarios. Al mismo tiempo, muchas contramedidas siguen siendo bastante primarias: como exigir un clic para enviar ETH u otros tokens a cualquier nueva dirección, ya sea enviando 100 dólares o 100,000 dólares. No existe una única solución mágica aquí, sino una serie de mejoras continuas dirigidas a diferentes categorías de amenazas. Seguir trabajando en esto es muy valioso.
![Vitalik nuevo artículo: La visión de la billetera ideal, desde la experiencia cross-chain hasta la protección de la privacidad, una actualización integral]###https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
) privacidad
Ahora es el momento 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 los pools de privacidad (, están madurando cada vez más. Infraestructuras de segundo nivel, como Waku y los mempools ERC-4337, también se están volviendo más estables poco a poco. Sin embargo, actualmente, para realizar transferencias privadas en Ethereum, los usuarios deben descargar y usar 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.
La implementación simple es la siguiente: la billetera puede almacenar una parte de los activos del usuario como "saldo privado" en el pool de privacidad. Al realizar una transferencia, se sale automáticamente del pool 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 nuevas direcciones para cada aplicación en la que el usuario participe. Los depósitos provienen del grupo de privacidad, y los retiros van directamente al grupo de privacidad. Esto permite que las actividades del usuario en una aplicación no estén vinculadas a las actividades en otras aplicaciones.
Esta tecnología no solo es un medio natural para la transferencia de activos de privacidad, sino también un medio natural para proteger la identidad de privacidad. La identidad ha ocurrido en la cadena: cualquier aplicación con control de acceso mediante identificación como Gitcoin Grants), chat con control de tokens, protocolos que cumplen con 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, la billetera del usuario debe ser lo único que tenga una "vista global", pudiendo ver simultáneamente todas las pruebas. Un ecosistema nativo donde cada usuario tiene múltiples cuentas 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 de la privacidad de Ethereum a medio plazo. Aunque se pueden introducir algunas funciones en L1 y L2 para hacer que las transferencias de protección de privacidad sean más eficientes y confiables, esto se puede lograr ahora. Algunos defensores de la privacidad creen que la única opción 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, que aún no ha alcanzado un nivel de madurez listo para implementarse en Ethereum. Realmente necesitamos privacidad por defecto para obtener un conjunto de anonimato lo suficientemente grande. Sin embargo, primero es pragmático enfocarse en las transferencias entre cuentas (i), así como en (ii) la identidad y los casos de uso relacionados con la identidad (, como las pruebas privadas ), que son el primer paso práctico, más fáciles de realizar, y que las billeteras pueden comenzar a usar ahora.
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.
11 me gusta
Recompensa
11
8
Republicar
Compartir
Comentar
0/400
GateUser-ccc36bc5
· 07-08 14:33
¿Se puede arreglar el problema de la lentitud de la billetera?
Ver originalesResponder0
OnChainArchaeologist
· 07-08 03:57
¿Adivinanza ciega otra vez? ¿Qué es más importante, la privacidad o la experiencia?
Ver originalesResponder0
AirDropMissed
· 07-08 00:39
La billetera cross-chain es solo una trampa.
Ver originalesResponder0
BasementAlchemist
· 07-05 21:17
La privacidad es lo más importante, ¡vamos a hacerlo!
Ver originalesResponder0
BlockchainTalker
· 07-05 21:17
en realidad, es un poco basado, no voy a mentir... la privacidad es el verdadero MV aquí
Ver originalesResponder0
RektRecorder
· 07-05 21:17
Llave privada no protegida es como correr desnudo.
Ver originalesResponder0
PanicSeller
· 07-05 21:16
Pedir dinero prestado para apalancarse no es tan bueno como tomar medicina tradicional china.
Ver originalesResponder0
NFTArchaeologist
· 07-05 21:10
Lo más importante del cross-chain es la velocidad.
Visión ideal de la billetera Ethereum: experiencia cross-chain, protección de la privacidad y actualización de seguridad
Visión de la billetera Ethereum ideal: actualización integral de la experiencia cross-chain a la protección de la privacidad
La billetera es una capa clave en la pila de infraestructura de Ethereum, 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 se comunican con el mundo de Ethereum; los usuarios solo pueden beneficiarse de las características descentralizadas, resistentes a la censura, seguras y privadas que ofrece Ethereum y sus aplicaciones cuando la billetera posee las propiedades correspondientes.
Recientemente, las billeteras de Ethereum han logrado avances significativos en la mejora de la experiencia del usuario, la seguridad y las funciones. Este artículo tiene como objetivo compartir opiniones sobre las características que debería tener una billetera ideal de Ethereum. Esta no es una lista completa, refleja la inclinación del autor por el ciberpunk, centrándose en la seguridad y la privacidad, y puede que no sea lo suficientemente integral en términos de experiencia del usuario. Sin embargo, el autor cree que optimizar la experiencia del usuario mediante el despliegue e iteración simples basados en retroalimentación es más efectivo que una lista de deseos, por lo que considera que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
experiencia del usuario en transacciones cross-chain L2
Ahora hay un mapa de ruta cada vez más detallado para mejorar la experiencia de usuario entre cadenas L2, que incluye partes a corto y largo plazo. Aquí se discute la parte a corto plazo: ideas que teóricamente se pueden implementar ahora.
La idea central es: (i) envío incorporado cross-chain L2, así como (ii) direcciones específicas de la cadena y solicitudes de pago. La Billetera debería 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, debe poder pegarla en el campo "destinatario" de la Billetera y hacer clic en "enviar". La Billetera debe procesar automáticamente los datos de envío:
Esto se aplica a los escenarios de "pago por dirección de copiar y pegar". En el caso de aplicaciones que solicitan depósitos, el proceso ideal es extender la API de web3 y permitir que la aplicación emita solicitudes de pago específicas de la cadena. La Billetera puede satisfacer esa solicitud de cualquier manera necesaria. 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 almacenar por defecto los activos del usuario, para maximizar 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 que las billeteras móviles lo escaneen. En escenarios de pago cara a cara o en línea, el receptor emitirá un código QR o llamará a la API web3, indicando "Quiero Y unidades del token Z en la cadena X, con el ID de referencia o el callback W", y la billetera puede satisfacer libremente 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, y el receptor es responsable de transferir los fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si se reciben activos en un L2 sin ETH y se necesita enviar una transacción, la Billetera debería poder utilizar automáticamente el protocolo ( como RIP-7755) para pagar el gas desde una cadena que tenga ETH. Si la Billetera espera que el usuario realice más transacciones en el L2 en el futuro, también debería usar solo DEX para enviar una cantidad suficiente de ETH, para que las futuras transacciones puedan pagar directamente el gas allí ( porque es más barato ).
seguridad de la cuenta
La conceptualización del desafío a la seguridad de la cuenta es que una buena Billetera debe funcionar en dos aspectos: (i) proteger a los usuarios de los ataques de hackers o comportamientos maliciosos por parte de los desarrolladores de la Billetera, (ii) proteger a los usuarios de los efectos de sus propios errores.
La solución preferida es la recuperación social y la Billetera de múltiples firmas, con control de acceso jerárquico. Las cuentas de usuario tienen dos capas de claves: la clave principal y N tutores ( donde N=5). La clave principal puede realizar operaciones de bajo valor y no financieras. La mayoría de los tutores necesitan ejecutar (i) operaciones de alto valor, como enviar el valor total de la cuenta, o (ii) cambiar la clave principal o cualquier tutor. Si es necesario, se puede permitir que la clave principal realice operaciones de alto valor a través de un bloqueo temporal.
El diseño básico es extensible. Mecanismos de autorización como la clave de sesión y ERC-7715 pueden ayudar a equilibrar la conveniencia y la seguridad entre diferentes aplicaciones. Estructuras de guardianes más complejas, como tener múltiples duraciones de bloqueo temporal bajo diferentes umbrales, pueden ayudar a maximizar las oportunidades de recuperar cuentas legítimas con éxito, al mismo tiempo que minimizan el riesgo de robo.
selección del tutor
Para los usuarios de criptomonedas con experiencia, una opción viable es la clave de amigos y familiares. Si se requiere que cada persona proporcione una nueva dirección, nadie necesita conocer la identidad del otro, por lo que la posibilidad de colusión es muy pequeña. Pero para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción es el custodio institucional: un servicio que firma transacciones solo cuando recibe otra información de confirmación. Durante mucho tiempo, la gente ha intentado crear este tipo de servicios, pero hasta ahora no ha tenido mucho éxito.
La tercera opción son varios dispositivos personales ( como teléfonos móviles, computadoras, billeteras de hardware ). Esto es viable, pero difícil de configurar y gestionar para los principiantes. Existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente cuando están en la misma ubicación.
Recientemente han aparecido más soluciones basadas en llaves universales. Las llaves se pueden respaldar en dispositivos o en la nube, y su seguridad depende de complejas suposiciones de seguridad de contraseñas mixtas, instituciones y hardware confiable. Para los usuarios comunes, es una valiosa mejora en la seguridad, pero solo depender 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 centralizada empaquetada en ZK. Este tipo de soluciones incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, se pueden adoptar diversas formas de ID centralizada de la empresa o del gobierno ( y convertirlas en direcciones de Ethereum, y las transacciones solo pueden enviarse generando una prueba de la posesión de la ID centralizada mediante ZK-SNARK.
Con esta adición, ahora tenemos una amplia selección, las ID centralizadas empaquetadas en ZK tienen una "amigabilidad para principiantes" única.
Para ello, se necesita implementar una UI simplificada e integrada: debe poder especificar solo "example@gmail.com" como guardián, generando automáticamente la dirección zk-email de Ethereum correspondiente. Los usuarios avanzados deben poder ingresar el correo ) y el posible valor de sal de privacidad guardado ( en aplicaciones de terceros de código abierto, confirmando que la dirección generada es correcta. Esto también debe aplicarse a otros tipos de guardianes soportados.
Atención, el desafío real que enfrenta zk-email hoy en día es la dependencia de la firma DKIM, utilizando claves que se rotan cada pocos meses, y que estas claves no están firmadas por otras entidades. Esto significa que el zk-email actual tiene un cierto grado de requisitos de confianza que van más allá del propio proveedor; por ejemplo, el uso de TLSNotary para verificar las claves actualizadas dentro de hardware confiable podría reducir esta situación, pero no es ideal. Se espera que los proveedores de correo electrónico comiencen a firmar directamente las claves DKIM. Actualmente se recomienda que un guardián use zk-email, pero no se aconseja a la mayoría de los guardianes que lo usen: no almacenen fondos en zk-email, ya que un daño implica la incapacidad de acceder a los fondos.
![Vitalik nuevo artículo: visión de la 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 desean ingresar una gran cantidad de guardianes al registrarse por primera vez. Por lo tanto, la billetera debe ofrecer una opción muy simple. La forma natural es utilizar zk-email en la dirección de correo electrónico, la clave almacenada localmente en el dispositivo del usuario ### que podría ser la clave maestra ( y la clave de respaldo mantenida por 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 sugerir en algún momento que agreguen más guardianes.
La integración de billeteras en aplicaciones es inevitable, ya que las aplicaciones que intentan atraer a usuarios no cripto no desean que los usuarios tengan que descargar dos aplicaciones nuevas, lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras de aplicaciones deberían poder vincular todas las billeteras, de modo que solo tengan que concentrarse en un "problema de control de acceso". La forma más sencilla es adoptar un esquema jerárquico, con un rápido proceso de "vinculación" que permite a los usuarios establecer la billetera principal como la guardiana de todas las billeteras dentro de la aplicación. El cliente de Farcaster Warpcast ya ha apoyado esto.
![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(
) protege 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 trabajado mucho para identificar direcciones falsas, phishing, estafas y otras amenazas externas, y se esfuerzan por proteger a los usuarios. Al mismo tiempo, muchas contramedidas siguen siendo bastante primarias: como exigir un clic para enviar ETH u otros tokens a cualquier nueva dirección, ya sea enviando 100 dólares o 100,000 dólares. No existe una única solución mágica aquí, sino una serie de mejoras continuas dirigidas a diferentes categorías de amenazas. Seguir trabajando en esto es muy valioso.
![Vitalik nuevo artículo: La visión de la billetera ideal, desde la experiencia cross-chain hasta la protección de la privacidad, una actualización integral]###https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
) privacidad
Ahora es el momento 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 los pools de privacidad (, están madurando cada vez más. Infraestructuras de segundo nivel, como Waku y los mempools ERC-4337, también se están volviendo más estables poco a poco. Sin embargo, actualmente, para realizar transferencias privadas en Ethereum, los usuarios deben descargar y usar 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.
La implementación simple es la siguiente: la billetera puede almacenar una parte de los activos del usuario como "saldo privado" en el pool de privacidad. Al realizar una transferencia, se sale automáticamente del pool 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 nuevas direcciones para cada aplicación en la que el usuario participe. Los depósitos provienen del grupo de privacidad, y los retiros van directamente al grupo de privacidad. Esto permite que las actividades del usuario en una aplicación no estén vinculadas a las actividades en otras aplicaciones.
Esta tecnología no solo es un medio natural para la transferencia de activos de privacidad, sino también un medio natural para proteger la identidad de privacidad. La identidad ha ocurrido en la cadena: cualquier aplicación con control de acceso mediante identificación como Gitcoin Grants), chat con control de tokens, protocolos que cumplen con 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, la billetera del usuario debe ser lo único que tenga una "vista global", pudiendo ver simultáneamente todas las pruebas. Un ecosistema nativo donde cada usuario tiene múltiples cuentas 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 de la privacidad de Ethereum a medio plazo. Aunque se pueden introducir algunas funciones en L1 y L2 para hacer que las transferencias de protección de privacidad sean más eficientes y confiables, esto se puede lograr ahora. Algunos defensores de la privacidad creen que la única opción 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, que aún no ha alcanzado un nivel de madurez listo para implementarse en Ethereum. Realmente necesitamos privacidad por defecto para obtener un conjunto de anonimato lo suficientemente grande. Sin embargo, primero es pragmático enfocarse en las transferencias entre cuentas (i), así como en (ii) la identidad y los casos de uso relacionados con la identidad (, como las pruebas privadas ), que son el primer paso práctico, más fáciles de realizar, y que las billeteras pueden comenzar a usar ahora.
( Ether