Experiencia del usuario de transacciones cruzadas-L2

Ahora hay una hoja de ruta cada vez más detallada para mejorar la experiencia del usuario entre diferentes capas (cross-L2), que tiene una parte a corto plazo y otra a largo plazo. Aquí, hablaré sobre la parte a corto plazo: ideas que son teóricamente implementables incluso hoy.

Las ideas principales son (i) envíos integrados entre L2, y (ii) direcciones específicas de cadena y solicitudes de pago. Su billetera debería poder darle una dirección que (siguiendo el estilo deeste borrador ERC) parece así:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Cuando alguien (o alguna aplicación) te proporciona una dirección en este formato, deberías poder pegarla en el campo “destinatario” de una billetera y hacer clic en “enviar”. La billetera debería procesar automáticamente ese envío de la mejor manera posible:

• Si ya tienes suficientes monedas del tipo necesario en la cadena de destino, envía las monedas directamente
• Si tienes monedas del tipo necesario en otra cadena (o en múltiples otras cadenas), utiliza un protocolo comoERC-7683(efectivamente un DEX entre cadenas) para enviar las monedas
• Si tienes monedas de un tipo diferente en la misma o en otras cadenas, utiliza intercambios descentralizados para convertirlas en el tipo correcto de moneda en la cadena correcta y enviarlas. Esto debe requerir el permiso explícito del usuario: el usuario verá cuánto está pagando y cuánto está recibiendo el destinatario.

Maqueta de una posible interfaz de billetera con soporte de direcciones entre cadenas

Lo anterior es para el “copiar y pegar una dirección (o ENS, por ejemplo, vitalik.eth@optimism.ethcaso de uso de "depositar para que alguien te pague". Si una dapp solicita un depósito (por ejemplo, ver este ejemplo de Polymarket) entonces el flujo ideal es extender la API de web3 y permitir que la dapp haga una solicitud de pago específica de la cadena. Su billetera podría satisfacer esa solicitud de la manera que necesite. Para que la experiencia del usuario funcione bien, también sería necesario estandarizar una solicitud de obtener saldo disponible, y las billeteras deberían pensar detenidamente en qué cadenas almacenan los activos de los usuarios de manera predeterminada para maximizar la seguridad y la facilidad de las transferencias.

Las solicitudes de pago específicas de la cadena también podrían ser incluidas en códigos QR, que las billeteras móviles podrían escanear. En un escenario de pagos al consumidor en persona (u online), el destinatario haría una llamada de API de códigos QR o web3 que diga "Quiero X unidades de token Y en la cadena Z, con ID de referencia o devolución de llamada W", y la billetera estaría libre de satisfacer esa solicitud de la manera que pueda. Otra opción es un protocolo de enlace de reclamo, donde la billetera del usuario genera un código QR o URL que contiene una autorización para reclamar una cierta cantidad de fondos de su contrato en la cadena, y es trabajo del destinatario averiguar cómo mover esos fondos a su propia billetera.

Otro tema relacionado son los pagos de gas. Si recibes activos en un L2 donde aún no tienes ETH y necesitas enviar una transacción en ese L2, la billetera debería poder usar automáticamente un protocolo (por ejemplo, RIP-7755) para pagar el gas en una cadena donde tengas ETH. Si la billetera espera que realices más transacciones en ese L2 en el futuro, también debería usar un DEX para enviar, por ejemplo, unos millones de gas por valor de ETH, para que las transacciones futuras puedan gastar gas allí directamente (ya que es más barato).

Seguridad de la cuenta

Una forma en que conceptualizo el desafío de la seguridad de la cuenta es que una buena billetera debería ser buena simultáneamente en dos áreas: (i) proteger al usuario de que el desarrollador de la billetera sea hackeado o malicioso, y (ii) proteger al usuario de sus propios errores.

La falta de ortografía "mistakles" a la izquierda fue involuntaria. Sin embargo, al verlo, me di cuenta de que es perfectamente apropiado para el contexto, así que decidí mantenerlo.

Mi solución preferida para esto, parasobrediezaños, ha sido recuperación social y billeteras multi-firma, con control de acceso graduado. La cuenta de un usuario tiene dos capas de claves: una clave principal y N guardianes (por ejemplo, N = 5). La clave principal puede realizar operaciones de bajo valor y no financieras. Se requiere la mayoría de los guardianes para realizar (i) operaciones de alto valor, como enviar el valor completo de la cuenta, o (ii) cambiar la clave principal o cualquiera de los guardianes. Si se desea, la clave principal puede estar autorizada para realizar operaciones de alto valor con un bloqueo temporal.

Lo anterior es un diseño básico y se puede aumentar. Claves de sesión y mecanismos de permisos como ERC-7715, puede ayudar a soportar diferentes equilibrios entre conveniencia y seguridad para diferentes aplicaciones. Arquitecturas de guardianes más complicadas, como tener múltiples duraciones de bloqueo temporal en diferentes umbrales, pueden ayudar a maximizar la probabilidad de una recuperación legítima exitosa de la cuenta, al tiempo que se minimiza el riesgo de robo.

¿Quiénes o qué deberían ser los guardianes?

Para un usuario experimentado de criptomonedas que se encuentra dentro de una comunidad de usuarios experimentados de criptomonedas, una opción viable son las claves de tus amigos y familiares. Si les pides a cada uno que te proporcione una dirección nueva, entonces nadie necesita saber quiénes son, de hecho, tus guardianes ni siquiera necesitan saber quiénes son los demás. La posibilidad de que coludan sin que uno de ellos te avise es muy pequeña. Sin embargo, esta opción no está disponible para la mayoría de los nuevos usuarios.

Una segunda opción son los guardianes institucionales: empresas que se especializan en realizar el servicio de solo firmar una transacción si reciben alguna otra confirmación de que la solicitud viene de usted: por ejemplo, un código de confirmación o, para usuarios de alto valor, una videollamada. Las personas han intentado hacer esto durante mucho tiempo, por ejemplo, en Gate.Perfilé CryptoCorp en 2013. Sin embargo, hasta ahora dichas empresas no han tenido mucho éxito.

Una tercera opción es tener varios dispositivos personales (por ejemplo, teléfono, computadora de escritorio, billetera de hardware). Esto puede funcionar, pero también es difícil de configurar y administrar para usuarios inexpertos. También existe el riesgo de que los dispositivos se pierdan o sean robados al mismo tiempo, especialmente si están en el mismo lugar.

Recientemente, hemos comenzado a ver más billeteras basadas en contraseñas. Las contraseñas se pueden respaldar solo en sus dispositivos, lo que las convierte en una solución personal de dispositivo, o respaldarse en la nube, lo que hace que su seguridad dependa de una gate.complicado híbridoen términos de seguridad de contraseña, suposiciones de hardware institucional y confiable. Realísticamente, las contraseñas son una ganancia de seguridad valiosa para los usuarios comunes, pero por sí solas no son lo suficientemente fuertes para proteger los ahorros de toda una vida de un usuario.

Afortunadamente, con ZK-SNARKs, tenemos una cuarta opción: identificación centralizada envuelta en ZK. Este género incluyezk-email, Anon Aadhaar, Cartera Myna, y muchos otros. Básicamente, puedes tomar muchas formas de ID centralizado (corporativo o gubernamental) y convertirlas en una dirección de Ethereum, desde la cual solo puedes enviar transacciones generando una prueba ZK-SNARK de posesión de la identificación centralizada.

Con esta adición, ahora tenemos una amplia gama de opciones, y la identificación centralizada envuelta en ZK es única y fácil de usar para los novatos.

Para que esto funcione, debe implementarse con una interfaz de usuario simplificada e integrada: debería poder especificar simplemente que desea "example@gmail.comComo guardián, debería generar automáticamente la dirección de correo electrónico zk correspondiente en el fondo. Los usuarios avanzados deberían poder ingresar su correo electrónico (junto con quizás un valor de sal para la privacidad, que sería guardado en ese correo electrónico) en una aplicación de terceros de código abierto, y confirmar que la dirección generada es correcta. Lo mismo debería ser cierto para cualquier otro tipo de guardián compatible.

Maqueta de una posible interfaz segura

Tenga en cuenta que hoy en día, un desafío práctico con zk-email específicamente es que depende de firmas DKIM, que utilizan claves que se rotan una vez cada pocos meses, y estas claves no están firmadas por ninguna otra autoridad. Esto significa que zk-email hoy en día tiene algún nivel de requisito de confianza más allá del propio proveedor; esto podría reducirse si zk-email utilizara TLSNotarydentro de hardware confiable para verificar las claves actualizadas, pero no es ideal. Esperemos que los proveedores de correo electrónico comiencen a firmar sus claves DKIM directamente. Hoy en día, recomendaría usar zk-email para un guardián, pero no para la mayoría de tus guardianes: no almacenes fondos en una configuración donde la ruptura de zk-email signifique que pierdes acceso a tus fondos.

Nuevos usuarios y monederos dentro de la aplicación

Los nuevos usuarios no querrán tener que ingresar una gran cantidad de guardianes en su primera experiencia de registro. Por lo tanto, las billeteras deben ofrecerles una opción muy simple. Una ruta natural es un 2-de-3 utilizando zk-email en su dirección de correo electrónico, una clave almacenada localmente en el dispositivo del usuario (que podría ser una contraseña) y una clave de respaldo en poder del proveedor. A medida que el usuario adquiera más experiencia o acumule más activos, en algún momento se le debe solicitar que agregue más guardianes.

Las billeteras integradas en las aplicaciones son inevitables, porque las aplicaciones que intentan atraer a usuarios no criptográficos no desean la confusa experiencia de usuario de pedir a sus usuarios que descarguen dos nuevas aplicaciones (la propia aplicación, más una billetera Ethereum) al mismo tiempo. Sin embargo, un usuario de muchas billeteras de aplicaciones debería poder vincular todas sus billeteras juntas, de modo que solo tengan una 'cosa de control de acceso' de la que preocuparse. La forma más sencilla de hacer esto es un esquema jerárquico, donde hay un proceso de 'vinculación' rápido que permite a un usuario configurar su billetera principal como el guardián de todas sus billeteras en la aplicación. El cliente Farcaster Warpcast ya admite esto:

De forma predeterminada, la recuperación de tu cuenta de Warpcast está controlada por el equipo de Warpcast. Sin embargo, puede "asumir la soberanía" de su cuenta de Farcaster y cambiar la recuperación a su propia dirección.

Protegiendo a los usuarios de estafas y otras amenazas externas

Además de la seguridad de la cuenta, las billeteras de hoy en día hacen mucho para identificar direcciones falsas, phishing, estafas y otras amenazas externas, y tratan de proteger a sus usuarios de tales amenazas. Al mismo tiempo, muchas de las medidas de seguridad siguen siendo bastante primitivas: por ejemplo, requerir un clic para enviar ETH u otros tokens a cualquier dirección nueva, sin importar si estás enviando $100 o $100,000. Aquí, no hay una solución mágica única; es una serie de soluciones lentas y mejoras continuas en diferentes categorías de amenazas. Sin embargo, hay mucho valor en seguir trabajando arduamente para mejorar aquí.

Privacidad

Ahora es el momento de empezar a tomar la privacidad en Ethereum mucho más en serio. La tecnología ZK-SNARK está ahora muy avanzada, tecnologías de privacidad que mitigan los riesgos regulatorios sin depender de puertas traseras, como Piscinas de privacidad, se están volviendo más maduras, y la infraestructura secundaria como Wakuy las mempools ERC-4337 se están volviendo más estables lentamente. Sin embargo, hasta ahora, realizar transferencias privadas en Ethereum ha requerido que los usuarios descarguen y utilicen explícitamente una "billetera de privacidad", como Ferrocarril (or Umbraparadirecciones ocultas. Esto agrega una gran inconveniencia y reduce el número de personas que están dispuestas a hacer transferencias privadas. La solución es que las transferencias privadas deben integrarse directamente en las carteras.

Una implementación simple es la siguiente. Una billetera podría almacenar una parte de los activos de un usuario como un "saldo privado" en un grupo de privacidad. Cuando un usuario realiza una transferencia, se retiraría automáticamente del grupo de privacidad primero. Si un usuario necesita recibir fondos, la billetera podría generar automáticamente una dirección oculta.

Además, una billetera podría generar automáticamente una nueva dirección para cada aplicación en la que participe un usuario (por ejemplo, un protocolo de defi). Los depósitos vendrían del grupo de privacidad y las retiradas irían directamente al grupo de privacidad. Esto permite que la actividad de un usuario en cualquier aplicación esté desvinculada de su actividad en otras aplicaciones.

Una ventaja de esta técnica es que es un camino natural no solo para la transferencia de activos que preservan la privacidad, sino también para la preservación de la identidad. La identidad ya ocurre en la cadena: cualquier aplicación que utilice el gate de prueba de persona (por ejemplo, Gitcoin Grants), cualquier chat con gate de token, el Ethereum Seguir Protocolo, y mucho más son todos identidad onchain. Queremos que este ecosistema también sea respetuoso con la privacidad. Esto significa que la actividad de un usuario en la cadena no debe ser recopilada en un solo lugar: cada elemento debe almacenarse por separado y la billetera del usuario debería ser lo único que tenga una "vista global" que vea todas sus certificaciones al mismo tiempo. Un ecosistema nativamente con muchas cuentas por usuario ayuda a lograr esto, al igual que los protocolos de certificación fuera de la cadena como EAS y Zupass.

Esto representa una visión pragmática para la privacidad de Ethereum en el futuro a medio plazo. Se puede implementar hoy, aunque hay características que se pueden introducir en L1 y L2 para hacer las transferencias preservadoras de la privacidad más eficientes y fiables. Algunos defensores de la privacidad argumentan que lo único aceptable es la privacidad total de todo: encriptar todo el EVM. Yo argumentaría que esto puede ser ideal como resultado a largo plazo, pero requiere una reconsideración mucho más fundamental de los modelos de programación, y actualmente no está al nivel de madurez donde está listo para ser implementado y desplegado en Ethereum. Necesitamos la privacidad por defecto para obtener conjuntos de anonimato lo suficientemente grandes. Sin embargo, centrarse primero en hacer (i) transferencias entre cuentas, y (ii) identidad y casos de uso adyacentes a la identidad como las certificaciones, privados es un primer paso pragmático que es mucho más fácil de implementar, y en el que las carteras pueden comenzar hoy.

Las billeteras de Ethereum también deben convertirse en billeteras de datos

Una consecuencia de cualquier solución de privacidad efectiva, ya sea para pagos o para identidad u otros casos de uso, es que crea la necesidad de que el usuario almacene datos fuera de la cadena. Esto fue evidente en Gate.io, que requería que los usuarios guardaran cada “nota” individual que representaba un depósito de 0.1-100 ETH. Los protocolos de privacidad más modernos a veces guardan los datos encriptados en la cadena, y utilizan una sola clave privada para descifrarlos. Esto es arriesgado, porque si la clave se filtra alguna vez, o si las computadoras cuánticas se vuelven viables, todos los datos se hacen públicos. Las certificaciones fuera de la cadena como EAS y Zupass tienen una necesidad aún más evidente de almacenamiento de datos fuera de la cadena.

Las carteras deben convertirse no solo en software para almacenar permisos de acceso en cadena, sino también en software para almacenar sus datos privados. Esto es algo que el mundo no criptográfico reconoce cada vez más también, por ejemplo, consulte a Tim Berners-Lee.trabajo reciente en almacenes de datos personales. Todos los problemas que necesitamos resolver en torno a garantizar robustamente el control de los permisos de acceso, también necesitamos resolver en torno a garantizar de manera robusta la accesibilidad y la no filtración de datos. Quizás las soluciones podrían superponerse juntas: si tienes N guardianes, utiliza el secreto M-de-N entre esos mismos N guardianes para almacenar tus datos. Los datos son inherentemente más difíciles de asegurar, porque no puedes revocar la parte de alguien, pero deberíamos idear soluciones de custodia descentralizadas que sean tan seguras como podamos.

Acceso seguro a la cadena

Hoy en día, las carteras confían en sus proveedores de RPC para que les informen cualquier información sobre una cadena. Esto es una vulnerabilidad de dos maneras:

1. El proveedor RPC podría intentar robar dinero al proporcionarles información falsa, por ejemplo, sobre los precios del mercado
2. El proveedor de RPC podría extraer información privada sobre qué aplicaciones y otras cuentas está interactuando un usuario

Idealmente, queremos tapar ambos agujeros. Para tapar el primero, necesitamos clientes ligeros estandarizados para L1 y L2, que verifiquen directamente el consenso de la cadena de bloques.Heliosya hace esto para L1, y ha estado haciendo un trabajo preliminar para admitir algunos L2 específicos. Para cubrir adecuadamente todos los L2, lo que necesitamos es un estándar mediante el cual un contrato de configuración que represente un L2 (también utilizado para direcciones específicas de la cadena) pueda declarar una función, tal vez de manera similar aERC-3668contiene la lógica para obtener raíces de estado recientes, y verificar pruebas de estado y recibos contra esas raíces de estado. De esta manera podríamos tener un cliente ligero universal, permitiendo a los monederos verificar de forma segura cualquier estado o eventos en L1 y L2.

Por privacidad, hoy en día la única aproximación realista es ejecutar su propio nodo completo. Sin embargo, ahora que los L2 están entrando en escena, ejecutar un nodo completo de todo se está volviendo cada vez más difícil. El equivalente a un cliente ligero aquí es recuperación de información privada (PIR). PIR implica un servidor que tiene una copia de todos los datos, y un cliente que envía al servidor una solicitud encriptada. El servidor realiza un cálculo sobre todos los datos, lo que devuelve los datos deseados del cliente, encriptados con la clave del cliente, sin revelar al servidor qué parte de los datos accedió el cliente.

Para mantener el servidor honesto, los elementos individuales de la base de datos serían ellos mismos ramas de Merkle, por lo que el cliente podría verificarlos utilizando su cliente ligero.

PIR es muy costoso computacionalmente. Hay varias formas de evitar este problema:

• Fuerza bruta: mejoras en algoritmos o hardware especializado podrían potencialmente hacer que PIR sea lo suficientemente rápido para ejecutarse. Estas técnicas pueden depender de preprocesamiento: los servidores podrían almacenar datos encriptados y mezclados para cada cliente, y los clientes podrían consultar esos datos. El principal desafío en el entorno de Ethereum es adaptar estas técnicas a conjuntos de datos que cambian rápidamente (como lo hace el estado). Esto reduce los costos computacionales en tiempo real, pero podría aumentar los costos computacionales y de almacenamiento totales.
• Reducir el requisito de privacidad: por ejemplo, cada búsqueda solo podría tener 1 millón de "mixins", por lo que el servidor conocería un millón de valores posibles a los que el cliente podría haber accedido, pero no una granularidad más fina.
• Multi-servidor PIR: los algoritmos PIR suelen ser mucho más rápidos si se utilizan varios servidores con una suposición de honestidad de 1-de-N entre esos servidores.
• Anonimato en lugar de confidencialidad: en lugar de ocultar el contenido de la solicitud, la solicitud podría enviarse a través de una mixnet, ocultando al remitente de la solicitud. Sin embargo, hacer esto de manera efectiva inevitablemente aumenta la latencia, empeorando la experiencia del usuario.

Resolver la combinación correcta de técnicas para maximizar la privacidad mientras se mantiene la practicidad en el contexto de Ethereum es un problema de investigación abierto, y agradezco a los criptógrafos que intenten resolverlo.

Carteras de keystore ideales

Aparte de las transferencias y el acceso al estado, otro flujo de trabajo importante que necesita funcionar sin problemas en un contexto cruzado de L2 es cambiar la configuración de validación de una cuenta: ya sea cambiar sus claves (por ejemplo, recuperación), o un cambio más profundo en la lógica completa de la cuenta. Aquí, hay tres niveles de soluciones, en orden creciente de dificultad:

1. Actualizaciones reproducidas: cuando un usuario cambia su configuración, se reproduce un mensaje que autoriza este cambio en cada cadena donde la billetera detecta que un usuario tiene activos. Potencialmente, el formato del mensaje y las reglas de validación pueden hacerse independientes de la cadena, por lo que se puede reproducir automáticamente en tantas cadenas como sea posible.
2. Keystores en L1: la información de configuración reside en L1 y la billetera en L2 la lee con unaL1SLOADoREMOTESTATICCALLDe esta manera, la actualización de la configuración solo necesita hacerse en L1, y la configuración se vuelve efectiva automáticamente.
3. Keystores en L2: la información de configuración reside en L2 y la billetera en L2 la lee con un ZK-SNARK. Esto es lo mismo que (2), excepto que las actualizaciones del keystore pueden ser más baratas, aunque por otro lado las lecturas son más caras.

La solución (3) es particularmente poderosa porque se apila bien con la privacidad. En una “solución de privacidad” normal, un usuario tiene un secreto s, se publica un “valor de hoja” L en la cadena, y un usuario demuestra que L = hash(s, 1) y N = hash(s, 2) para algún secreto (nunca revelado) que controlan. El anulador N se publica, asegurándose de que los gastos futuros de la misma hoja fallen, sin revelar nunca L. Esto depende de que el usuario mantenga s seguro. Una solución de privacidad amigable con la recuperación en lugar de esto diría: s es una ubicación (por ejemplo, dirección y espacio de almacenamiento) en la cadena, y el usuario debe demostrar una consulta de estado: L = hash(sload(s), 1).

Seguridad de Dapp

El eslabón más débil en la seguridad de un usuario suele ser la dapp. La mayor parte del tiempo, un usuario interactúa con una aplicación yendo a un sitio web, que descarga implícitamente el código de la interfaz de usuario en tiempo real desde un servidor y luego lo ejecuta en el navegador. Si el servidor es hackeado, o si el DNS es hackeado, el usuario recibirá una copia falsa de la interfaz, lo que podría engañar al usuario para hacer cosas arbitrarias. Funciones de monedero como simulaciones de transacciones son muy útiles para mitigar los riesgos, pero están lejos de ser perfectas.

Idealmente, trasladaríamos el ecosistema a la versión de contenido en cadena: un usuario accedería a una dapp a través de su nombre ENS, que contendría el hash de IPFS de la interfaz. Se necesitaría una transacción en cadena de un multisig o DAO para actualizar la interfaz. Las carteras mostrarían a los usuarios si están interactuando con una interfaz en cadena más segura, o con una interfaz web2 menos segura. Las carteras también pueden mostrar a los usuarios si están interactuando con una cadena segura (por ejemplo, etapa 1+, múltiples auditorías de seguridad).

Para los usuarios que se preocupan por su privacidad, las carteras también pueden agregar un modo paranoico, que requiere que los usuarios acepten las solicitudes HTTP haciendo clic en ellas, y no solo las operaciones web3:

Maqueta de posible interfaz para el modo paranoico

Un enfoque más avanzado sería ir más allá de HTML + JavaScript y escribir la lógica comercial de las dapps en un lenguaje dedicado, quizás una capa relativamente delgada sobre Solidity o Vyper. Los navegadores podrían generar automáticamente una interfaz de usuario para cualquier funcionalidad necesaria.OKContractya está haciendo esto.

Otra dirección es la información de defensa criptoeconómica: los desarrolladores de dapp, las empresas de seguridad, los desplegadores de cadenas y otros pueden poner una fianza que se pagaría a los usuarios afectados si una dapp fuera hackeada o de otra manera perjudicara a los usuarios al actuar de manera altamente engañosa, según lo determine algún DAO de adjudicación en cadena. La billetera podría mostrar a un usuario una puntuación que se basa en el tamaño de la fianza.

El futuro a largo plazo

Todo lo anterior fue en el contexto de las interfaces convencionales, que implican apuntar y hacer clic en cosas e ingresar cosas en campos de texto. Sin embargo, también estamos en la cúspide de paradigmas que cambian mucho más profundamente:

• AI, que podría llevarnos a alejarnos de un paradigma de hacer clic y escribir a un paradigma de "decir lo que quieres hacer y el bot lo descubre"
• Interfaces cerebro-computadora, tanto enfoques 'leves' como el seguimiento ocular, como técnicas más directas e incluso invasivas (ver: primer paciente de Neuralink este año)
• Clientes que se dedican a la defensa activa: el navegador Braveprotege activamente a los usuarios contra anuncios, rastreadores y muchos otros objetos indeseables. Muchos navegadores, complementos y billeteras de criptomonedas tienen equipos enteros trabajando activamente para proteger a los usuarios contra todo tipo de amenazas de seguridad y privacidad. Este tipo de 'guardianes activos' se volverán aún más poderosos en la próxima década.

Estas tres tendencias juntas conducirán a un replanteamiento mucho más profundo de cómo funcionan las interfaces. A través de la entrada de lenguaje natural, el seguimiento ocular o, eventualmente, una BCI más directa, junto con el conocimiento de su historial (tal vez incluidos los mensajes de texto, siempre que todos los datos se procesen localmente), una "billetera" podría tener una idea clara e intuitiva de lo que desea hacer. La IA podría traducir esa intuición en un "plan de acción" concreto: una serie de interacciones dentro y fuera de la cadena que logren lo que desea. Esto podría reducir en gran medida la necesidad de interfaces de usuario de terceros por completo. Si un usuario interactúa con una aplicación de terceros (u otro usuario), la IA debe pensar de forma adversa en nombre del usuario, identificar cualquier amenaza y sugerir planes de acción para evitarla. Lo ideal sería que existiera un ecosistema abierto de estas IA, producido por diferentes grupos con diferentes sesgos y estructuras de incentivos.

Estas ideas más radicales dependen de una tecnología que hoy es extremadamente inmadura, por lo que hoy no pondría mis activos en una billetera que dependa de ellas. Sin embargo, algo así parece ser claramente el futuro, por lo que vale la pena comenzar a explorar de manera más activa en esa dirección.

Renuncia:

1. Este artículo es una reimpresión de [vitalik]. Si hay objeciones a esta reimpresión, por favor contacte a la Aprendizaje de la puertaequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Aprendizaje de Gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.