Visión de la billetera ideal de Ethereum: una actualización integral de la experiencia cross-chain a la protección de la privacidad
Una capa clave de la pila de infraestructura de Ethereum es la Billetera, pero a menudo es subestimada por los investigadores y desarrolladores centrales de L1. La Billetera es la ventana entre los usuarios y el mundo de Ethereum, y los usuarios solo pueden beneficiarse de cualquier atributo descentralizado, resistente a la censura, seguro, privado u otros que ofrece Ethereum y sus aplicaciones, siempre que la Billetera en sí también tenga estas propiedades.
Recientemente, la Billetera de Ethereum ha logrado grandes avances en la mejora de la experiencia del usuario, la seguridad y la funcionalidad. El propósito de este artículo es dar una opinión sobre algunas características que debería tener una Billetera de Ethereum ideal. Esta no es una lista completa; refleja la tendencia de los criptopunks, enfocándose en la seguridad y la privacidad, y es casi seguro que es incompleta en términos de experiencia del usuario. Sin embargo, una lista de deseos no es tan efectiva como simplemente implementar y iterar según la retroalimentación para optimizar la experiencia del usuario, por lo que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones cross-chain L2
Ahora hay una hoja de ruta cada vez más detallada para mejorar la experiencia de usuario entre cadenas L2, que tiene partes a corto y largo plazo. Aquí se hablará de la parte a corto plazo: ideas que teóricamente aún se pueden implementar hoy.
La idea central es (i) envío cruzado de L2 integrado, así como (ii) direcciones específicas de cadena y solicitudes de pago. La billetera debería ser capaz de proporcionar a los usuarios una dirección, siguiendo el estilo del borrador ERC correspondiente.
Cuando alguien ( o algunas aplicaciones ) proporcionan a los usuarios una dirección en este formato, los usuarios deberían poder pegarla en el campo "destinatario" de la Billetera y luego hacer clic en "enviar". La Billetera debería procesar automáticamente los datos enviados de cualquier manera posible:
Si el usuario ya tiene suficientes tokens del tipo requerido en la cadena de destino, envíe los tokens directamente.
Si el usuario tiene el tipo de token requerido en otra cadena ( o en múltiples otras cadenas ), usar el protocolo relacionado ( es, de hecho, un DEX cross-chain ) para enviar tokens.
Si los usuarios tienen diferentes tipos de tokens en la misma cadena o en otras cadenas, deben usar un intercambio descentralizado para convertirlos en la moneda correcta del tipo correcto en la cadena adecuada y enviarlos. Esto debería requerir el consentimiento explícito del usuario: el usuario verá cuánto pagó en tarifas y cuánto recibió el destinatario.
El contenido anterior se aplica al caso de uso de "los usuarios copian y pegan la dirección ( o ENS, por ejemplo, vitalik.eth @ optimism.eth), y alguien le paga al usuario". Si el dapp solicita un depósito, entonces el proceso ideal es extender la API web3 y permitir que el dapp emita solicitudes de pago específicas de la cadena. Luego, la Billetera podrá satisfacer esa solicitud de cualquier manera necesaria. Para que la experiencia del usuario sea buena, también es necesario estandarizar la solicitud getAvailableBalance, y la Billetera debe considerar detenidamente en qué cadenas almacenar por defecto los activos del usuario para maximizar la seguridad y la conveniencia de la transferencia.
Las solicitudes de pago específicas de la cadena también se pueden incluir en un código QR, y las billeteras móviles pueden escanear el código QR. En los escenarios de pago de consumidores cara a cara ( o en línea ), el receptor emitirá un código QR o una llamada a la API web3, indicando "Quiero X unidades del token YZ en la cadena, con una ID de referencia o un callback W", y la billetera podrá satisfacer esa solicitud de cualquier forma. 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 trabajo del receptor es averiguar cómo transferir esos fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si un usuario recibe activos en una L2 sin tener ETH, y necesita enviar una transacción en esa L2, la Billetera debería poder usar automáticamente el protocolo para pagar el Gas en la cadena donde el usuario tiene ETH. Si la Billetera desea que el usuario realice más transacciones en el futuro en la L2, también debería utilizar solo un DEX para enviar, por ejemplo, ETH por valor de millones de Gas, para que las transacciones futuras puedan gastar Gas directamente allí porque es más barato (.
![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-66ec52b10d00460414381b99c15622ee.webp(
Seguridad de la cuenta
Una forma de conceptualizar los desafíos de seguridad de la cuenta es que una buena Billetera debería funcionar en dos aspectos: )i( proteger a los usuarios de los ataques de hackers o ataques maliciosos por parte de los desarrolladores de la Billetera, y )ii( proteger a los usuarios de los efectos de sus propios errores.
La solución preferida para esto, durante más de diez años, ha sido la recuperación social y las billeteras de múltiples firmas, con control de acceso jerárquico. Las cuentas de los usuarios tienen dos capas de claves: la clave principal y N guardianes ), por ejemplo, N = 5(. La clave principal es capaz de realizar operaciones de bajo valor y no financieras. La mayoría de los guardianes necesitan ejecutar )i( operaciones de alto valor, como enviar todo el valor en la cuenta, o )ii( 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 de tiempo.
Lo anterior es un diseño básico que se puede ampliar. Las claves de sesión y los mecanismos de permisos relacionados pueden ayudar a soportar el equilibrio entre la conveniencia y la seguridad de diferentes aplicaciones. Una arquitectura de guardianes más compleja, por ejemplo, con múltiples duraciones de bloqueo temporal bajo diferentes umbrales, puede ayudar a maximizar las oportunidades de recuperar cuentas legítimas con éxito, al mismo tiempo que minimiza el riesgo de robo.
![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-6e92b6b051653e68d5f93ed0d91891eb.webp(
¿Quién o qué debería ser el guardián?
Para los usuarios experimentados de criptomonedas en la comunidad, una opción viable son las claves de amigos y familiares del usuario. Si el usuario pide a cada uno que le proporcione una nueva dirección, entonces nadie necesita saber quiénes son; de hecho, los tutores del usuario ni siquiera necesitan saber quiénes son entre sí. Si no le han soplado a él, es poco probable que estén coludidos. Sin embargo, para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción son los custodios institucionales: empresas que ofrecen servicios que solo firman transacciones al recibir información de confirmación adicional a solicitud del usuario: por ejemplo, un código de confirmación, o una videollamada para usuarios de alto valor. Las personas han intentado crear estos desde hace mucho tiempo, como la introducció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, computadoras de escritorio, billeteras de hardware (. Esto puede funcionar, pero puede ser 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 si están ubicados en el mismo lugar.
Recientemente, hemos comenzado a ver más basados en la llave maestra. La llave solo se puede respaldar en el dispositivo del usuario, lo que la convierte en una solución de dispositivo personal, y también se puede respaldar en la nube, lo que hace que su seguridad dependa de supuestos complejos de seguridad de contraseñas mezcladas, institucionales y de hardware confiable. De hecho, la llave es una valiosa mejora de seguridad para el usuario promedio, pero 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, entre otros. Básicamente, los usuarios 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 de posesión de ID centralizada mediante ZK-SNARK.
Con esta adición, ahora tenemos una amplia gama de opciones, y la ID centralizada envuelta en ZK tiene una "amigabilidad para principiantes" única.
Para ello, necesita lograrlo a través de una interfaz de usuario simplificada e integrada: los usuarios deberían poder especificar que quieren "example@gmail.com" como tutor, y debería generar automáticamente la dirección de Ethereum zk-email correspondiente bajo el capó. Los usuarios avanzados deberían poder ingresar su correo electrónico ( y el posible valor de sal de privacidad ) que puede estar guardado en ese correo electrónico en aplicaciones de terceros de código abierto, y confirmar que la dirección generada es correcta. Esto debería aplicarse también a cualquier otro tipo de tutor compatible.
Por favor, tenga en cuenta que hoy en día zk-email enfrenta un desafío práctico, ya que depende de la firma DKIM, la cual utiliza claves que se rotan cada pocos meses, y esas claves en sí no están firmadas por ninguna otra entidad. Esto significa que el zk-email de hoy tiene un cierto nivel de requisitos de confianza que van más allá del propio proveedor; si zk-email usara TLSNotary en hardware de confianza para verificar las claves actualizadas, esto podría reducir la situación, pero no es ideal. Se espera que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Hoy en día, se recomienda que un tutor utilice zk-email, pero no se recomienda que la mayoría de los tutores lo use: no almacene fondos en zk-email, ya que una falla significa que los usuarios no pueden acceder a los fondos.
Nuevos usuarios y billetera dentro de la aplicación
Los nuevos usuarios en realidad no desean ingresar una gran cantidad de tutores al registrarse por primera vez. Por lo tanto, la billetera debería ofrecerles una opción muy sencilla. Un camino natural es utilizar zk-email en su dirección de correo electrónico, y una clave almacenada localmente en el dispositivo del usuario ( que podría ser la clave maestra ), así como una clave de respaldo en poder del proveedor, para hacer una selección de 2 de 3. A medida que los usuarios se vuelven más experimentados o acumulan más activos, en algún momento se les debería sugerir que agreguen más tutores.
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 quieren que los usuarios tengan que descargar dos nuevas aplicaciones al mismo tiempo: la propia aplicación (, además de la billetera Ethereum ), lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras de aplicaciones deberían poder vincular todas sus billeteras juntas, 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, donde hay un proceso de "enlace" rápido que permite a los usuarios establecer su billetera principal como el guardián de todas las billeteras dentro de la aplicación. Algunos clientes ya han comenzado a soportar esto.
Por defecto, la recuperación de ciertas cuentas dentro de la aplicación puede estar controlada por el equipo de desarrollo de la aplicación. Sin embargo, los usuarios pueden "tomar el control" de su cuenta y cambiar la recuperación a su propia dirección.
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 hacen mucho trabajo para identificar direcciones falsas, phishing, fraudes y otras amenazas externas, y se esfuerzan por proteger a los usuarios de tales amenazas. Al mismo tiempo, muchas contramedidas siguen siendo bastante primitivas: por ejemplo, se requiere hacer clic para enviar Ether u otros tokens a cualquier nueva dirección, sin importar si el usuario envía 100 dólares o
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.
13 me gusta
Recompensa
13
6
Compartir
Comentar
0/400
HackerWhoCares
· 07-28 09:01
La seguridad y la experiencia deben ser igualmente consideradas.
Ver originalesResponder0
BoredWatcher
· 07-28 08:33
¡La billetera debería haber sido actualizada hace tiempo!
Ver originalesResponder0
TokenUnlocker
· 07-25 09:53
¡La billetera es la primera fuerza productiva!
Ver originalesResponder0
BottomMisser
· 07-25 09:53
¿Seguridad? ¿Actualizaciones iterativas? Primero, que la Billetera no sea robada.
Ver originalesResponder0
MetaNeighbor
· 07-25 09:34
la cadena eth es el futuro
Ver originalesResponder0
DeFiChef
· 07-25 09:33
Mercado bajista practicar cocina alcista bajar platos
Billetera Ethereum ideal: actualización integral de la experiencia cross-chain, seguridad y privacidad.
Visión de la billetera ideal de Ethereum: una actualización integral de la experiencia cross-chain a la protección de la privacidad
Una capa clave de la pila de infraestructura de Ethereum es la Billetera, pero a menudo es subestimada por los investigadores y desarrolladores centrales de L1. La Billetera es la ventana entre los usuarios y el mundo de Ethereum, y los usuarios solo pueden beneficiarse de cualquier atributo descentralizado, resistente a la censura, seguro, privado u otros que ofrece Ethereum y sus aplicaciones, siempre que la Billetera en sí también tenga estas propiedades.
Recientemente, la Billetera de Ethereum ha logrado grandes avances en la mejora de la experiencia del usuario, la seguridad y la funcionalidad. El propósito de este artículo es dar una opinión sobre algunas características que debería tener una Billetera de Ethereum ideal. Esta no es una lista completa; refleja la tendencia de los criptopunks, enfocándose en la seguridad y la privacidad, y es casi seguro que es incompleta en términos de experiencia del usuario. Sin embargo, una lista de deseos no es tan efectiva como simplemente implementar y iterar según la retroalimentación para optimizar la experiencia del usuario, por lo que centrarse en las propiedades de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones cross-chain L2
Ahora hay una hoja de ruta cada vez más detallada para mejorar la experiencia de usuario entre cadenas L2, que tiene partes a corto y largo plazo. Aquí se hablará de la parte a corto plazo: ideas que teóricamente aún se pueden implementar hoy.
La idea central es (i) envío cruzado de L2 integrado, así como (ii) direcciones específicas de cadena y solicitudes de pago. La billetera debería ser capaz de proporcionar a los usuarios una dirección, siguiendo el estilo del borrador ERC correspondiente.
Cuando alguien ( o algunas aplicaciones ) proporcionan a los usuarios una dirección en este formato, los usuarios deberían poder pegarla en el campo "destinatario" de la Billetera y luego hacer clic en "enviar". La Billetera debería procesar automáticamente los datos enviados de cualquier manera posible:
El contenido anterior se aplica al caso de uso de "los usuarios copian y pegan la dirección ( o ENS, por ejemplo, vitalik.eth @ optimism.eth), y alguien le paga al usuario". Si el dapp solicita un depósito, entonces el proceso ideal es extender la API web3 y permitir que el dapp emita solicitudes de pago específicas de la cadena. Luego, la Billetera podrá satisfacer esa solicitud de cualquier manera necesaria. Para que la experiencia del usuario sea buena, también es necesario estandarizar la solicitud getAvailableBalance, y la Billetera debe considerar detenidamente en qué cadenas almacenar por defecto los activos del usuario para maximizar la seguridad y la conveniencia de la transferencia.
Las solicitudes de pago específicas de la cadena también se pueden incluir en un código QR, y las billeteras móviles pueden escanear el código QR. En los escenarios de pago de consumidores cara a cara ( o en línea ), el receptor emitirá un código QR o una llamada a la API web3, indicando "Quiero X unidades del token YZ en la cadena, con una ID de referencia o un callback W", y la billetera podrá satisfacer esa solicitud de cualquier forma. 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 trabajo del receptor es averiguar cómo transferir esos fondos a su propia billetera.
Otro tema relacionado es el pago de gas. Si un usuario recibe activos en una L2 sin tener ETH, y necesita enviar una transacción en esa L2, la Billetera debería poder usar automáticamente el protocolo para pagar el Gas en la cadena donde el usuario tiene ETH. Si la Billetera desea que el usuario realice más transacciones en el futuro en la L2, también debería utilizar solo un DEX para enviar, por ejemplo, ETH por valor de millones de Gas, para que las transacciones futuras puedan gastar Gas directamente allí porque es más barato (.
![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-66ec52b10d00460414381b99c15622ee.webp(
Seguridad de la cuenta
Una forma de conceptualizar los desafíos de seguridad de la cuenta es que una buena Billetera debería funcionar en dos aspectos: )i( proteger a los usuarios de los ataques de hackers o ataques maliciosos por parte de los desarrolladores de la Billetera, y )ii( proteger a los usuarios de los efectos de sus propios errores.
La solución preferida para esto, durante más de diez años, ha sido la recuperación social y las billeteras de múltiples firmas, con control de acceso jerárquico. Las cuentas de los usuarios tienen dos capas de claves: la clave principal y N guardianes ), por ejemplo, N = 5(. La clave principal es capaz de realizar operaciones de bajo valor y no financieras. La mayoría de los guardianes necesitan ejecutar )i( operaciones de alto valor, como enviar todo el valor en la cuenta, o )ii( 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 de tiempo.
Lo anterior es un diseño básico que se puede ampliar. Las claves de sesión y los mecanismos de permisos relacionados pueden ayudar a soportar el equilibrio entre la conveniencia y la seguridad de diferentes aplicaciones. Una arquitectura de guardianes más compleja, por ejemplo, con múltiples duraciones de bloqueo temporal bajo diferentes umbrales, puede ayudar a maximizar las oportunidades de recuperar cuentas legítimas con éxito, al mismo tiempo que minimiza el riesgo de robo.
![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-6e92b6b051653e68d5f93ed0d91891eb.webp(
¿Quién o qué debería ser el guardián?
Para los usuarios experimentados de criptomonedas en la comunidad, una opción viable son las claves de amigos y familiares del usuario. Si el usuario pide a cada uno que le proporcione una nueva dirección, entonces nadie necesita saber quiénes son; de hecho, los tutores del usuario ni siquiera necesitan saber quiénes son entre sí. Si no le han soplado a él, es poco probable que estén coludidos. Sin embargo, para la mayoría de los nuevos usuarios, esta opción no está disponible.
La segunda opción son los custodios institucionales: empresas que ofrecen servicios que solo firman transacciones al recibir información de confirmación adicional a solicitud del usuario: por ejemplo, un código de confirmación, o una videollamada para usuarios de alto valor. Las personas han intentado crear estos desde hace mucho tiempo, como la introducció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, computadoras de escritorio, billeteras de hardware (. Esto puede funcionar, pero puede ser 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 si están ubicados en el mismo lugar.
Recientemente, hemos comenzado a ver más basados en la llave maestra. La llave solo se puede respaldar en el dispositivo del usuario, lo que la convierte en una solución de dispositivo personal, y también se puede respaldar en la nube, lo que hace que su seguridad dependa de supuestos complejos de seguridad de contraseñas mezcladas, institucionales y de hardware confiable. De hecho, la llave es una valiosa mejora de seguridad para el usuario promedio, pero 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, entre otros. Básicamente, los usuarios 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 de posesión de ID centralizada mediante ZK-SNARK.
Con esta adición, ahora tenemos una amplia gama de opciones, y la ID centralizada envuelta en ZK tiene una "amigabilidad para principiantes" única.
Para ello, necesita lograrlo a través de una interfaz de usuario simplificada e integrada: los usuarios deberían poder especificar que quieren "example@gmail.com" como tutor, y debería generar automáticamente la dirección de Ethereum zk-email correspondiente bajo el capó. Los usuarios avanzados deberían poder ingresar su correo electrónico ( y el posible valor de sal de privacidad ) que puede estar guardado en ese correo electrónico en aplicaciones de terceros de código abierto, y confirmar que la dirección generada es correcta. Esto debería aplicarse también a cualquier otro tipo de tutor compatible.
Por favor, tenga en cuenta que hoy en día zk-email enfrenta un desafío práctico, ya que depende de la firma DKIM, la cual utiliza claves que se rotan cada pocos meses, y esas claves en sí no están firmadas por ninguna otra entidad. Esto significa que el zk-email de hoy tiene un cierto nivel de requisitos de confianza que van más allá del propio proveedor; si zk-email usara TLSNotary en hardware de confianza para verificar las claves actualizadas, esto podría reducir la situación, pero no es ideal. Se espera que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Hoy en día, se recomienda que un tutor utilice zk-email, pero no se recomienda que la mayoría de los tutores lo use: no almacene fondos en zk-email, ya que una falla significa que los usuarios no pueden acceder a los fondos.
Nuevos usuarios y billetera dentro de la aplicación
Los nuevos usuarios en realidad no desean ingresar una gran cantidad de tutores al registrarse por primera vez. Por lo tanto, la billetera debería ofrecerles una opción muy sencilla. Un camino natural es utilizar zk-email en su dirección de correo electrónico, y una clave almacenada localmente en el dispositivo del usuario ( que podría ser la clave maestra ), así como una clave de respaldo en poder del proveedor, para hacer una selección de 2 de 3. A medida que los usuarios se vuelven más experimentados o acumulan más activos, en algún momento se les debería sugerir que agreguen más tutores.
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 quieren que los usuarios tengan que descargar dos nuevas aplicaciones al mismo tiempo: la propia aplicación (, además de la billetera Ethereum ), lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras de aplicaciones deberían poder vincular todas sus billeteras juntas, 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, donde hay un proceso de "enlace" rápido que permite a los usuarios establecer su billetera principal como el guardián de todas las billeteras dentro de la aplicación. Algunos clientes ya han comenzado a soportar esto.
Por defecto, la recuperación de ciertas cuentas dentro de la aplicación puede estar controlada por el equipo de desarrollo de la aplicación. Sin embargo, los usuarios pueden "tomar el control" de su cuenta y cambiar la recuperación a su propia dirección.
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 hacen mucho trabajo para identificar direcciones falsas, phishing, fraudes y otras amenazas externas, y se esfuerzan por proteger a los usuarios de tales amenazas. Al mismo tiempo, muchas contramedidas siguen siendo bastante primitivas: por ejemplo, se requiere hacer clic para enviar Ether u otros tokens a cualquier nueva dirección, sin importar si el usuario envía 100 dólares o