Un agradecimiento especial a Liraz Siri, Yoav Weiss y los desarrolladores de ImToken, Metamask y OKX por sus comentarios y reseñas.
Una capa crítica de la pila de infraestructura de Ethereum que los investigadores y desarrolladores centrales de L1 a menudo subestiman es la billetera. Las billeteras son la ventana entre los usuarios y el mundo de Ethereum, y los usuarios solo pueden beneficiarse de cualquier descentralización, resistencia a la censura, seguridad, privacidad u otros atributos ofrecidos por Ethereum y sus aplicaciones si la billetera misma también posee esos atributos.
Recientemente, hemos visto que las billeteras Ethereum han logrado grandes avances en la mejora de la experiencia, la seguridad y la funcionalidad del usuario. El propósito de este artículo es dar mi propia opinión sobre algunas de las características que debería tener una billetera Ethereum ideal. Esta no es una lista completa; refleja mis inclinaciones cypherpunk, se centra en la seguridad y la privacidad y es casi seguro que esté incompleta en términos de experiencia del usuario. Sin embargo, no creo que las listas de deseos sean tan efectivas para optimizar la experiencia del usuario como simplemente implementarlas e iterarlas en función de los comentarios, por lo que creo que centrarse en los atributos de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones entre L2
Ahora hay un mapa cada vez más detallado para mejorar la experiencia del usuario entre L2, que tiene partes a corto y largo plazo. Aquí hablaré de la parte a corto plazo: ideas que teóricamente aún se pueden implementar hoy.
La idea central es (i) enviar entre L2 incorporado, y (ii) direcciones y solicitudes de pago específicas de la cadena. Tu billetera debería poder proporcionarte una dirección (siguiendo el estilo de este borrador ERC) como sigue:
Cuando alguien (o alguna aplicación) te ofrece una dirección en este formato, deberías poder pegarla en el campo "destinatario" de la billetera y luego hacer clic en "enviar". La billetera debería manejar automáticamente los datos que se envían de la mejor manera posible:
Si ya tienes suficientes tokens del tipo requerido en la cadena objetivo, envía los tokens directamente.
Si tienes tokens del tipo requerido en otra cadena (o en múltiples cadenas), usa protocolos como ERC-7683 (que es un DEX entre cadenas) para enviar los tokens.
Si tienes diferentes tipos de tokens en la misma cadena o en otras cadenas, usa un intercambio descentralizado para convertirlos en la moneda correcta del tipo correcto en la cadena y enviarlos. Esto debería requerir el consentimiento explícito del usuario: el usuario verá cuánto ha pagado en tarifas y cuánto ha recibido el destinatario.
Modelo de interfaz de billetera posible con soporte para direcciones entre cadenas
Lo anterior se aplica al caso de uso de "copiar y pegar la dirección (o ENS, por ejemplo, vitalik.eth @ optimism.eth) para que alguien te pague". Si la 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 emita solicitudes de pago específicas de la cadena. Entonces, tu billetera podrá satisfacer esa solicitud de la manera que necesite. Para que la experiencia del usuario sea buena, también es necesario estandarizar la solicitud getAvailableBalance, y la billetera necesita pensar seriamente sobre 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 pueden codificarse en un código QR que las billeteras móviles pueden escanear. En escenarios de pago de consumidores cara a cara (o en línea), el receptor emitirá un código QR o un llamado a la API de web3, indicando "quiero X unidades de token Y Z en la cadena, con referencia ID o callback W", y la billetera podrá satisfacer esa solicitud de cualquier manera. Otra opción es un protocolo de enlace de reclamo, donde la billetera del usuario genera un código QR o URL que permite la autorización de reclamo desde su contrato en cadena para obtener una cierta cantidad de fondos, 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 recibes activos en una L2 donde no tienes ETH, y necesitas enviar una transacción en esa L2, la billetera debería poder usar automáticamente un protocolo (como RIP-7755) para pagar el gas en la cadena donde tienes ETH. Si la billetera quiere que hagas más transacciones en la L2 en el futuro, también debería usar DEX para enviar, por ejemplo, ETH por valor de varios millones de gas, para que las futuras transacciones puedan consumir gas directamente allí (porque es más barato).
Seguridad de la cuenta
Una forma de conceptualizar el desafío de la seguridad de la cuenta es que una buena billetera debería funcionar en dos aspectos: (i) proteger a los usuarios de ataques o ataques maliciosos por parte de desarrolladores de billetera, y (ii) proteger a los usuarios de los efectos de sus propios errores.
El "error" a la izquierda fue involuntario. Sin embargo, cuando lo vi, me di cuenta de que encajaba muy bien en el contexto, así que decidí mantenerlo.
Mi solución preferida para esto, durante más de una década, ha sido la recuperación social y las billeteras multi-firma, con controles de acceso jerárquicos. Las cuentas de los usuarios tienen dos capas de claves: una clave maestra y N guardianes (por ejemplo, N = 5). La clave maestra es capaz de realizar operaciones de bajo valor y no financieras. La mayoría de los guardianes necesitarían ejecutar (i) operaciones de alto valor, como enviar todo el valor de la cuenta, o (ii) cambiar la clave maestra o cualquier guardián. Si es necesario, se puede permitir que la clave maestra ejecute operaciones de alto valor a través de un bloqueo por tiempo.
Lo anterior es el diseño básico, que puede ampliarse. Las claves de sesión y mecanismos de permisos como 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 recuperación exitosa de cuentas legítimas mientras se minimiza el riesgo de robo.
Lo anterior es el diseño básico, que puede ampliarse. Las claves de sesión y mecanismos de permisos como 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 recuperación exitosa de cuentas legítimas mientras se minimiza el riesgo de robo.
¿Quién o qué debería ser el guardián?
Para los usuarios experimentados en criptomonedas dentro de la comunidad de usuarios experimentados, una opción viable es la clave de sus amigos y familiares. Si pides a cada uno que te proporcione una nueva dirección, entonces nadie necesita saber quiénes son; de hecho, tus guardianes ni siquiera necesitan saber quiénes son entre sí. Si no se confabulan, la posibilidad de que se pongan de acuerdo es muy baja. Sin embargo, esta opción no está disponible para la mayoría de los nuevos usuarios.
La segunda opción es guardianes institucionales: empresas que ofrecen servicios de firma de transacciones solo al recibir otra información de confirmación de su solicitud: por ejemplo, un código de confirmación, o una videollamada para usuarios de alto valor. La gente ha estado intentando crear esto durante mucho tiempo, como lo hice yo en 2013 con CryptoCorp. Sin embargo, hasta ahora, estas empresas no han tenido mucho éxito.
La tercera opción es múltiples dispositivos personales (por ejemplo, teléfono, computadora de escritorio, billetera de hardware). Esto puede funcionar, pero también es difícil de configurar y gestionar para los usuarios sin experiencia. También existe el riesgo de que se pierdan o roben los dispositivos al mismo tiempo, especialmente si están en la misma ubicación.
Recientemente, hemos comenzado a ver más basados en llave maestra. Las claves solo se pueden respaldar en tu dispositivo, lo que las convierte en una solución de dispositivo personal, y también pueden respaldarse en la nube, lo que hace que su seguridad dependa de complejas suposiciones de seguridad de contraseña, corporativas y de hardware confiables. De hecho, las claves son un valioso aumento de seguridad para los usuarios comunes, pero por sí solas no son suficientes 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, etc. Básicamente, puedes adoptar varias formas de ID centralizada (de empresas o gobiernos) y convertirla en una dirección de Ethereum, y solo podrás enviar transacciones generando una prueba ZK-SNARK que demuestre que posees la ID centralizada.
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 UI simplificada e integrada: deberías poder especificar simplemente que quieres que "example@gmail.com" sea el guardián, y debería generar automáticamente la dirección zk-email de Ethereum correspondiente bajo el capó. Los usuarios avanzados deberían poder ingresar su correo electrónico (y posiblemente el valor de sal de privacidad almacenado en ese correo electrónico) en una aplicación de terceros de código abierto y confirmar que la dirección generada es correcta. Esto debería ser así para cualquier otro tipo de guardián soportado.
Ten en cuenta que uno de los desafíos prácticos que enfrenta hoy en día zk-email es que depende de firmas DKIM, que utilizan una clave que se rota cada pocos meses, y que esas claves no están firmadas por ninguna otra entidad. Esto significa que el zk-email actual tiene un cierto grado de requisitos de confianza más allá del propio proveedor; si zk-email usa TLSNotary en hardware de confianza para verificar las claves actualizadas, esto podría mitigar la situación, pero no es ideal. Espero que los proveedores de correo electrónico comiencen a firmar directamente sus claves DKIM. Hoy, sugiero que un guardián use zk-email, pero no recomiendo que la mayoría de los guardianes lo hagan: no almacenes fondos en zk-email, ya que perder acceso significa que no podrás usar los fondos.
Nuevos usuarios y billeteras dentro de la aplicación
Los nuevos usuarios realmente no quieren ingresar muchos guardianes en el momento de registrarse por primera vez. Por lo tanto, la billetera debería ofrecerles una opción muy simple. Una forma natural sería usar zk-email en su dirección de correo electrónico, una clave almacenada localmente en el dispositivo del usuario (posiblemente una llave maestra), y una clave de respaldo que tenga el proveedor, utilizando una opción 2-de-3. A medida que los usuarios se vuelvan más experimentados o acumulen más activos, en algún momento debería aparecer un aviso para agregar más guardianes.
La integración de billeteras en aplicaciones es inevitable, ya que las aplicaciones que intentan atraer a usuarios no criptográficos no quieren que los usuarios descarguen dos nuevas aplicaciones (la propia aplicación, además de la billetera de Ethereum), lo que brinda una experiencia de usuario confusa. Sin embargo, muchos usuarios de aplicaciones de billetera deberían ser capaces de vincular todas sus billeteras, para que solo tengan que preocuparse por un "problema de control de acceso". La forma más simple es adoptar un esquema jerárquico, donde hay un proceso de "vinculación" rápido que permite a los usuarios establecer su billetera principal como la guardiana de todas las billeteras dentro de la aplicación. El cliente de Farcaster Warpcast ya lo está respaldando:
Por defecto, la recuperación de tu cuenta de Warpcast está controlada por el equipo de Warpcast. Sin embargo, puedes "tomar el control" de tu cuenta de Farcaster y cambiar la recuperación a tu 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 de las contramedidas siguen siendo bastante primitivas: por ejemplo, se requiere un clic para enviar ETH u otros tokens a cualquier nueva dirección, sin importar si envías $100 o $100,000. No hay una solución única aquí. Se trata de una serie de correcciones y mejoras lentas y continuas para diferentes categorías de amenazas. Sin embargo, seguir esforzándose por mejorar aquí tiene mucho valor.
Privacidad
Ahora es el momento de comenzar a tomar más en serio la privacidad en 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, mientras que la infraestructura de segundo nivel como Waku y los mempools ERC-4337 también se están volviendo más estables. Sin embargo, hasta ahora, realizar transferencias privadas en Ethereum requiere que los usuarios descarguen y usen explícitamente "billeteras de privacidad", como Railway (o Umbra para direcciones invisibles). Esto crea una gran incomodidad y reduce el número de personas dispuestas a realizar transferencias privadas. La solución es que las transferencias privadas deben integrarse directamente en las billeteras.
Una implementación simple es la siguiente. La billetera puede almacenar una parte de los activos del usuario como "saldo privado" en un pool de privacidad. Cuando el usuario realiza una transferencia, se da de baja 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 una nueva dirección para cada aplicación en la que el usuario participe (por ejemplo, protocolos DeFi). Los depósitos provendrán del pool de privacidad, y los retiros irán directamente al pool de privacidad. Esto permite desconectar la actividad del usuario en una aplicación de su actividad en otras aplicaciones.
Una ventaja de esta tecnología es que no solo es una forma natural de transferir activos que protegen la privacidad, sino también una forma natural de proteger la identidad. La identidad ya ocurre en la cadena: cualquier aplicación que use pruebas de identificación controladas (como Gitcoin Grants), cualquier chat controlado por token, protocolos que siguen Ethereum, etc., son identidad en la cadena. Esperamos que este ecosistema también proteja la privacidad. Esto significa que las actividades del usuario en la cadena no deben recopilarse en un solo lugar: cada proyecto debe almacenarse por separado, y la billetera del usuario debería ser lo único que tenga una "vista global" para ver todas sus pruebas a la vez. Un ecosistema nativo donde cada usuario tiene múltiples cuentas ayuda a lograr esto, así como los protocolos de prueba fuera de la cadena como EAS y Zupass.
Esto representa una visión pragmática para la privacidad en Ethereum a medio plazo. Aunque algunas funciones pueden introducirse en L1 y L2 para hacer que la protección de la privacidad en las transferencias sea más eficiente y confiable, ya es posible lograrlo ahora. Algunos defensores de la privacidad creen que lo único aceptable es la privacidad total de todo: encriptar todo el EVM. Creo que esto puede ser el resultado ideal a largo plazo, pero requiere una revisión más fundamental del modelo de programación, y actualmente no se ha alcanzado un nivel de madurez adecuado para desplegarse en Ethereum. Sin embargo, necesitamos privacidad por defecto para obtener un conjunto de anonimato suficientemente grande. Sin embargo, centrar primero en (i) las transferencias entre cuentas, y (ii) la identidad y los casos de uso relacionados con la identidad (como pruebas privadas) es un primer paso pragmático, más fácil de implementar, y que las billeteras ya pueden comenzar a usar.
Las billeteras de Ethereum también necesitan convertirse en billeteras de datos.
Una consecuencia de cualquier solución de privacidad efectiva es que, ya sea para pagos, identidad u otros casos de uso, se genera la necesidad de que los usuarios almacenen datos fuera de la cadena. Esto es evidente en Tornado Cash, que requiere que los usuarios mantengan un "recibo" para cada depósito que representa entre 0.1 y 100 ETH. Protocolos de privacidad más modernos a veces almacenan datos cifrados en la cadena y los descifran usando una única clave privada. Esto es riesgoso porque si la clave se filtra, o si las computadoras cuánticas se vuelven viables, los datos se harían públicos. Pruebas fuera de la cadena como EAS y Zupass hacen más evidente la necesidad de almacenamiento de datos fuera de la cadena.
La billetera no solo necesita convertirse en el software que almacena el acceso en la cadena, sino que también necesita convertirse en el software que almacena tus datos privados. El mundo no criptográfico también está reconociendo cada vez más esto; por ejemplo, consulta el trabajo reciente de Tim Berners-Lee sobre el almacenamiento de datos personales. Todos los problemas que necesitamos resolver en torno a un control robusto de acceso también deben abordarse en torno a garantizar robustamente la accesibilidad de los datos y evitar filtraciones. Quizás estas soluciones puedan superponerse: si tienes N guardianes, usa M-de-N para compartir secretos entre esos N guardianes para almacenar tus datos. La protección de los datos es intrínsecamente más difícil porque no puedes revocar la parte de datos de alguien, pero deberíamos proponer soluciones de almacenamiento descentralizado lo más seguras posible.
Acceso seguro a la cadena
Hoy en día, las billeteras confían en que sus proveedores de RPC les informen sobre cualquier información de la cadena. Esta es una vulnerabilidad con dos aspectos:
Los proveedores de RPC pueden intentar robar dinero brindándoles información falsa, por ejemplo, sobre precios de mercado.
Los proveedores de RPC pueden extraer información privada sobre las aplicaciones y otras cuentas con las que el usuario interactúa.
Idealmente, queremos cerrar estas dos vulnerabilidades. Para abordar el primer problema, necesitamos clientes ligeros estandarizados para L1 y L2 que puedan verificar directamente el consenso de la cadena. Helios ya ha hecho esto para L1 y ha estado realizando algunos trabajos preliminares para admitir algunas L2 específicas. Para cubrir correctamente todas las L2, necesitamos un estándar a través del cual los contratos de configuración que representan L2 (también utilizados para direcciones específicas de la cadena) puedan declarar una función, posiblemente de manera similar a ERC-3668, que incluya la lógica para obtener la raíz de estado más reciente y verificar la prueba de estado y recibos para esas raíces de estado. Así, podemos tener un cliente ligero universal que permita a las billeteras verificar de manera segura cualquier estado o evento en L1 y L2.
Para la privacidad, la única forma práctica hoy en día es ejecutar tu propio nodo completo. Sin embargo, ahora que las L2 están entrando en la conciencia de las personas, se vuelve cada vez más difícil ejecutar un nodo completo que lo tenga todo. Lo que es comparable a un cliente ligero aquí es la recuperación de información privada (PIR). El PIR implica servidores que mantienen copias de todos los datos y clientes que envían solicitudes cifradas al servidor. El servidor realiza cálculos sobre todos los datos, devuelve los datos requeridos al cliente y los cifra con la clave del cliente, sin revelar al servidor qué datos ha accedido el cliente.
Para mantener la honestidad de los servidores, cada uno de los proyectos de base de datos es en sí mismo una rama de Merkle, por lo que el cliente puede usar un cliente ligero para verificarlos.
La carga computacional de PIR (Nota de Dap: típicamente se refiere a "Recuperación de Información Privada", que es un protocolo o técnica que permite a los usuarios recuperar información de bases de datos sin revelar la información recuperada) es muy alta. Hay varias formas de abordar este problema:
Con fuerza bruta: las mejoras en algoritmos o hardware dedicado pueden permitir que el PIR funcione lo suficientemente rápido. Estas tecnologías pueden depender de un preprocesamiento: el servidor puede almacenar datos cifrados y desordenados para cada cliente, y el cliente puede consultar esos datos. El principal desafío en el entorno de Ethereum es adaptar estas tecnologías a conjuntos de datos que cambian rápidamente (como lo hace un país). Esto hace que el costo de cálculo en tiempo real sea más bajo, pero probablemente hará que el costo total de cálculo y almacenamiento sea más alto.
Desgaste de los requisitos de privacidad: por ejemplo, puede haber un máximo de 1 millón de "mixins" por búsqueda, por lo que el servidor sabrá un millón de posibles valores a los que puede acceder el cliente, pero no sabrá ningún nivel de granularidad más fino.
PIR de múltiples servidores: si usas varios servidores, y la suposición de honestidad entre esos servidores es 1-de-N, entonces el algoritmo de PIR generalmente será más rápido.
Anónimo en lugar de confidencial: las solicitudes pueden enviarse a través de redes de mezcla, ocultando al remitente de la solicitud, en lugar de ocultar el contenido de la solicitud. Sin embargo, hacerlo efectivamente inevitablemente aumentará la latencia, lo que empeorará la experiencia del usuario.
Encontrar la combinación de tecnologías correcta en el entorno de Ethereum para maximizar la privacidad mientras se mantiene la utilidad es un problema de investigación abierto, y agradezco a los criptógrafos que intenten hacerlo.
Billetera de almacén de claves ideal
Además de la transferencia y el acceso a estado, otro flujo de trabajo importante que necesita funcionar sin problemas en el contexto entre L2 es cambiar la configuración de validación de la cuenta: ya sea cambiando su clave (por ejemplo, recuperación) o realizando cambios más profundos en la lógica de la cuenta. Aquí hay tres soluciones en capas, ordenadas de menor a mayor dificultad:
Actualizaciones de repetición: cuando los usuarios cambian su configuración, los mensajes que autorizan este cambio serán reproducidos en cada cadena donde el wallet detecte que el usuario tiene activos. Es posible que el formato de mensaje y las reglas de verificación puedan ser independientes de la cadena, por lo que podrían ser reproducidos automáticamente en tantas cadenas como sea posible.
Almacén de claves en L1: la información de configuración reside en L1, y las billeteras en L2 usan L1S LOAD para leerla o llamadas estáticas remotas. De este modo, solo se necesita actualizar la configuración en L1, y esta se aplicará automáticamente.
Almacén de claves en L2: la información de configuración reside en L2, y las billeteras en L2 la leen usando ZK-SNARK. Esto es similar a (2), excepto que actualizar el almacén de claves puede ser más barato, pero por otro lado, leerlo es más caro.
La solución (3) es especialmente poderosa porque se adapta bien a la privacidad. En las "soluciones de privacidad" normales, los usuarios poseen secretos s, publican "valores hoja" L en la cadena, y los usuarios prueban que L = hash(s, 1) y N = hash(s, 2) para algunos secretos que controlan (nunca revelados). Un símbolo inválido N es publicado, de forma que asegurar el gasto futuro de la misma hoja fallará sin revelar L y depende de la seguridad del secreto s del usuario. Una solución de privacidad amigable con la recuperación diría que s es una ubicación (por ejemplo, dirección y ranura de almacenamiento) en la cadena, y el usuario debe probar la consulta de estado: L = hash(sload(s), 1).
Seguridad de Dapp
El eslabón más débil en la seguridad del usuario suele ser la dapp. La mayoría de las veces, los usuarios interactúan con las aplicaciones accediendo a un sitio web que descarga implícitamente el código de la interfaz de usuario en tiempo real desde el servidor y luego se ejecuta en el navegador. Si el servidor es hackeado, o si el DNS es hackeado, el usuario obtendrá una copia falsa de la interfaz, que podría engañar al usuario para que realice cualquier acción. Funciones de billetera como simulación de transacciones ayudan a reducir riesgos, pero aún están lejos de ser perfectas.
Idealmente, trasladaríamos el ecosistema a un control de versiones de contenido en cadena: los usuarios accederían a la dapp a través de su nombre ENS, que contendría el valor hash IPFS de la interfaz. Actualizar la interfaz requeriría transacciones en cadena de múltiples firmas o DAO. La billetera mostraría a los usuarios si están interactuando con una interfaz en cadena más segura o con una interfaz Web2 de menor seguridad. La billetera también podría mostrar a los usuarios si están interactuando con una cadena segura (por ejemplo, etapa 1+, revisiones de seguridad múltiples).
Para los usuarios preocupados por la privacidad, la billetera también podría agregar un modo paranoico, que exige que el usuario haga clic para aceptar solicitudes HTTP, y no solo operaciones web3:
Modelo de posible interfaz en modo paranoico
Un enfoque más avanzado es ir más allá de HTML + Javascript y escribir la lógica de negocios de la dapp en un lenguaje dedicado (posiblemente una capa de cobertura relativamente delgada sobre Solidity o Vyper). Luego, el navegador puede generar automáticamente la UI para cualquier funcionalidad requerida. OKContract ya está haciendo esto.
Otra dirección es la defensa de información económica criptográfica: los desarrolladores de dapp, empresas de seguridad, desplegadores de cadenas y otros pueden establecer un bono que se pagará a los usuarios afectados (determinados por algún DAO de arbitraje en cadena) si la dapp es hackeada o causa daño a los usuarios de manera altamente engañosa. La billetera puede mostrar a los usuarios una puntuación basada en el tamaño del bono.
Un futuro más lejano
Todo lo anterior se ha hecho en el contexto de interfaces tradicionales, que implican apuntar y hacer clic en cosas y escribir cosas en campos de texto. Sin embargo, también estamos en la cúspide de un cambio de paradigma más profundo:
Inteligencia artificial, lo que podría llevarnos a un cambio del paradigma de escribir haciendo clic al paradigma de "diga lo que quiere hacer y el robot se encargará".
Interfaces cerebro-computadora, que incluyen tanto métodos "suaves" como el seguimiento ocular como técnicas más directas e incluso invasivas (considere: el primer paciente de Neuralink de este año).
Defensa proactiva del cliente: el navegador Brave protege proactivamente a los usuarios de anuncios, rastreadores y muchos otros objetos dañinos. Muchos navegadores, complementos y billeteras criptográficas tienen equipos enteros dedicados activamente a proteger a los usuarios de diversas amenazas a la seguridad y la privacidad. Estos "guardianes activos" solo se volverán más poderosos en la próxima década.
Estas tres tendencias juntas conducirán a una reflexión más profunda sobre cómo funcionan las interfaces. Con entradas de lenguaje natural, seguimiento ocular o, en última instancia, interfaces cerebro-computadora más directas, junto con tu historial (quizás incluyendo mensajes de texto, siempre que todos los datos se procesen localmente), la "billetera" podrá saber de manera clara e intuitiva qué deseas hacer. Luego, la inteligencia artificial puede convertir esta intuición en un "plan de acción" concreto: una serie de interacciones en cadena y fuera de cadena para lograr lo que deseas. Esto puede reducir drásticamente la necesidad de interfaces de usuario de terceros. Si el usuario realmente interactúa con aplicaciones de terceros (o con otros usuarios), la inteligencia artificial debería pensar de manera adversativa en nombre del usuario, identificando cualquier amenaza y proponiendo un plan de acción para evitar las amenazas. Idealmente, estas inteligencias artificiales deberían tener un ecosistema abierto, generado por grupos con diferentes sesgos y estructuras de incentivos.
Estas ideas más radicales dependen de tecnologías que hoy son muy inmaduras, así que hoy no pondría mis activos en una billetera que dependa de ellas. Sin embargo, cosas similares parecen ser claramente la tendencia futura, por lo que vale la pena comenzar a explorar más activamente en esta dirección.
