Agradecimientos especiales a Liraz Siri, Yoav Weiss y a los desarrolladores de ImToken, Metamask y OKX por sus comentarios y revisiones.
Una de las capas clave del stack de infraestructura de Ethereum es la billetera, pero a menudo es subestimada por los investigadores y desarrolladores de L1. La billetera es la ventana entre el usuario y el mundo de Ethereum, y los usuarios solo pueden beneficiarse de cualquier atributo descentralizado, resistente a la censura, seguro, privado u otros de Ethereum y sus aplicaciones, siempre que la billetera misma tenga esos atributos.
Recientemente, hemos visto grandes avances en las billeteras de Ethereum en términos de experiencia del usuario, seguridad y funcionalidad. El propósito de este artículo es ofrecer mi perspectiva sobre algunas de las características que debería tener una billetera ideal de Ethereum. No es una lista completa; refleja mis inclinaciones de hacker de la criptografía, que se enfocan en la seguridad y la privacidad, y casi con certeza no es completa en términos de experiencia del usuario. Sin embargo, creo que una lista de deseos no es tan efectiva en la optimización de la experiencia del usuario como el despliegue e iteración simples basados en retroalimentación, por lo que creo que centrarme en propiedades de seguridad y privacidad es lo más valioso.
Experiencia del usuario en transacciones entre L2.
Ahora hay una hoja de ruta cada vez más detallada 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 pueden implementarse hoy.
La idea central es (i) incluir el envío entre L2 de forma nativa, 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 de ERC), como sigue:
Cuando alguien (o alguna aplicación) te proporciona una dirección en este formato, deberías poder pegarla en el campo 'destinatario' de tu billetera y hacer clic en 'enviar'. La billetera debería manejar automáticamente los datos enviados de cualquier manera posible:
Si ya tiene suficientes tokens del tipo requerido en la cadena de destino, envíe los tokens directamente.
Si tiene tokens del tipo requerido en otra cadena (o en múltiples cadenas), envíe los tokens usando protocolos como ERC-7683 (que es un DEX entre cadenas).
Si tiene diferentes tipos de tokens en la misma cadena o en otras cadenas, use un intercambio descentralizado para convertirlos en la moneda del tipo correcto en la cadena correcta y enviarlos. Esto debería requerir el permiso explícito del usuario: el usuario verá cuánto pagó en tarifas y cuánto recibió el destinatario.
Modelo de posible interfaz de billetera con soporte para direcciones entre cadenas.
Lo anterior se aplica al caso de uso 'Copias y pegas 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 ampliar la API de web3 y permitir que la dapp emita solicitudes de pago específicas de la cadena. Luego, tu billetera podrá satisfacer esa solicitud de cualquier manera que necesite. Para que la experiencia del usuario sea buena, también se necesita estandarizar la solicitud getAvailableBalance, y la billetera necesita considerar cuidadosamente en qué cadenas almacenar los activos de los usuarios por defecto, para maximizar la seguridad y la comodidad de las transferencias.
Las solicitudes de pago específicas de la cadena también se pueden poner en un código QR, y las billeteras móviles pueden escanear el código QR. En 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 de web3, indicando 'Quiero X unidades de tokens YZ en la cadena, con una referencia ID o callback W', y la billetera podrá satisfacer esa solicitud de cualquier forma que desee. 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 relevante es el pago de gas. Si recibe activos en un L2 donde aún no tiene ETH y necesita 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 donde tiene ETH. Si la billetera espera que realices más transacciones en el futuro en L2, también debería usar solo DEX para enviar, por ejemplo, ETH por valor de millones de Gas, para que las transacciones futuras puedan gastar Gas directamente allí (ya que es más barato).
Seguridad de cuentas.
Una forma de conceptualizar el desafío de la seguridad de cuentas es que una buena billetera debería desempeñar un papel en ambos aspectos: (i) proteger al usuario de ataques maliciosos o hackeos por parte de los desarrolladores de la billetera, y (ii) proteger al usuario de sus propios errores.
El 'error' a la izquierda es involuntario. Sin embargo, cuando lo vi, me di cuenta de que encajaba perfectamente 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 de múltiples firmas con control de acceso jerárquico. 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 necesitan 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 mediante un bloqueo temporal.
Lo anterior es un diseño básico que se puede ampliar. Las claves de sesión y mecanismos de autorización como ERC-7715 pueden ayudar a respaldar diferentes equilibrios entre conveniencia y seguridad en diversas 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 mientras se minimiza el riesgo de robo.
Lo anterior es un diseño básico que se puede expandir. Claves de sesión y mecanismos de autorización como ERC-7715 pueden ayudar a respaldar diferentes equilibrios entre conveniencia y seguridad en diversas aplicaciones. Estructuras de guardianes más complejas, como tener múltiples períodos de bloqueo temporal bajo diferentes umbrales, pueden ayudar a maximizar las oportunidades de recuperar cuentas legítimas con éxito mientras se minimiza el riesgo de robo.
¿Quién o qué debería ser el guardián?
Para los usuarios experimentados en criptomonedas en la comunidad de criptografía, una opción viable es la clave de sus amigos y familiares. Si pides a cada uno que te dé una nueva dirección, nadie necesita saber quiénes son; de hecho, tus guardianes ni siquiera necesitan saber quiénes son entre sí. Si no te han soplado, es poco probable que se confabulen. Sin embargo, esta opción no está disponible para la mayoría de los nuevos usuarios.
La segunda opción son los guardianes institucionales: empresas que ofrecen servicios de firma de transacciones que solo firman con la otra información de confirmación que reciben, por ejemplo, un código de confirmación, o videollamadas para usuarios de alto valor. La gente ha estado tratando de crear estas durante mucho tiempo, por ejemplo, introduje CryptoCorp en 2013. Sin embargo, hasta ahora, estas empresas no han tenido mucho éxito.
La tercera opción son múltiples dispositivos personales (por ejemplo, teléfono, escritorio, billetera de hardware). Esto puede funcionar, pero también es difícil de configurar y administrar para usuarios sin experiencia. También existe el riesgo de perder o robar dispositivos al mismo tiempo, especialmente si están en el mismo lugar.
Recientemente, hemos comenzado a ver más soluciones basadas en claves maestras. Las claves solo pueden ser respaldadas en su dispositivo, lo que las convierte en una solución personal, y también pueden ser respaldadas en la nube, lo que hace que su seguridad dependa de complejas suposiciones de seguridad criptográfica, institucional y de hardware de confianza. De hecho, las claves son una ganancia de seguridad valiosa para el usuario promedio, pero por sí solas no son suficientes para proteger los ahorros de toda una vida del usuario.
Afortunadamente, con ZK-SNARK, también tenemos una cuarta opción: ID centralizado envuelto en ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, puedes tomar formas centralizadas de ID (de empresas o gobiernos) y convertirlas en direcciones de Ethereum, y solo puedes enviar transacciones generando una prueba de que posees ID centralizado mediante ZK-SNARK.
Con este complemento, ahora tenemos una amplia variedad 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 simplificada e integrada: deberías poder especificar que deseas 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. Debería ser así para cualquier otro tipo de guardián soportado.
Tenga en cuenta que uno de los desafíos prácticos que enfrenta zk-email hoy en día es que depende de la firma DKIM, que usa claves que se rotan cada pocos meses, y estas claves en sí mismas no son firmadas por ninguna otra entidad. Esto significa que el zk-email de hoy tiene un cierto grado de confianza que se extiende más allá del proveedor mismo; 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 puedan comenzar a firmar directamente sus claves DKIM. Hoy, sugiero que un guardián use zk-email, pero no sugiero que la mayoría de los guardianes lo usen: no almacenar fondos en zk-email significa que no puedes usar los fondos en la configuración.
Nuevos usuarios y billeteras dentro de aplicaciones.
Los nuevos usuarios en realidad no quieren ingresar una gran cantidad de guardianes al registrarse por primera vez. Por lo tanto, la billetera debería ofrecerles una opción muy simple. Una opción 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 clave maestra) y una clave de respaldo mantenida por el proveedor, en 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 deberían ser advertidos 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 tengan que descargar simultáneamente dos nuevas aplicaciones (la aplicación en sí y la billetera de Ethereum), lo que genera una experiencia de usuario confusa. Sin embargo, muchos usuarios de billeteras de aplicaciones deberían poder vincular todas sus billeteras, de modo que solo tengan que preocuparse por un 'problema de control de acceso'. La forma más sencilla de hacerlo es adoptar un enfoque jerárquico, en el que haya un rápido proceso de 'vinculación' que permita a los usuarios establecer su billetera principal como guardián de todas las billeteras dentro de la aplicación. El cliente de Farcaster Warpcast ya ha apoyado esto.
Por defecto, la recuperación de tu cuenta de Warpcast está controlada por el equipo de Warpcast. Sin embargo, puedes 'tomar control' de tu cuenta de Farcaster y cambiar la recuperación a tu propia dirección.
Proteger a los usuarios de estafas y otras amenazas externas.
Además de la seguridad de cuentas, las billeteras de hoy también están haciendo mucho trabajo para identificar direcciones falsas, phishing, estafas 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, requerir un clic para enviar ETH o cualquier otro token a cualquier nueva dirección, ya sea que envíes 100 dólares o 100,000 dólares. Aquí no existe una solución única. Se trata de una serie de correcciones y mejoras continuas y lentas para diferentes categorías de amenazas. Sin embargo, continuar esforzándose por mejorar aquí tiene mucho valor.
Privacidad
Ahora es el momento de comenzar a tomar más en serio la privacidad de Ethereum. La tecnología ZK-SNARK ya está muy avanzada, y las tecnologías de privacidad que no dependen de puertas traseras para reducir los riesgos regulatorios (como los fondos de privacidad) están madurando cada vez más, mientras que la infraestructura secundaria 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 aumenta enormemente la incomodidad y reduce la cantidad de personas dispuestas a realizar transferencias privadas. La solución es que las transferencias privadas necesitan ser integradas directamente en la billetera.
Una implementación simple es la siguiente. La billetera puede almacenar una parte de los activos del usuario como 'saldo privado' en un fondo de privacidad. Cuando el usuario realiza una transferencia, se retira automáticamente del fondo 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, protocolo defi). Los depósitos provendrán del fondo de privacidad, y los retiros irán directamente al fondo de privacidad. Esto permite que la actividad del usuario en una aplicación esté desvinculada de su actividad en otras aplicaciones.
Una ventaja de esta tecnología es que no solo es un camino natural para la transferencia de activos que protegen la privacidad, sino que también es un camino natural para la identidad que protege la privacidad. La identidad ya está ocurriendo en la cadena: cualquier aplicación con control de acceso mediante identificación (por ejemplo, Gitcoin Grants), cualquier chat con control de tokens, protocolos que siguen Ethereum, etc., son identidades en la cadena. Queremos que este ecosistema también proteja la privacidad. Esto significa que la actividad del usuario en la cadena no debería ser recopilada en un solo lugar: cada proyecto debería almacenar sus datos por separado, y la billetera del usuario debería ser la única que tenga una 'vista global' que pueda ver todas sus pruebas al mismo tiempo. 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 de la privacidad de Ethereum a medio plazo. Aunque se pueden introducir algunas funcionalidades en L1 y L2 para hacer que la protección de la privacidad en las transferencias sea más eficiente y confiable, esto ya se puede lograr ahora. Algunos defensores de la privacidad creen que lo único aceptable es la privacidad total de todo: encriptar todo el EVM. Creo que esto podría ser el resultado ideal a largo plazo, pero requiere una reconsideración más fundamental del modelo de programación y actualmente no ha alcanzado un nivel de madurez listo para ser desplegado en Ethereum. Realmente necesitamos privacidad por defecto para obtener un conjunto anónimo lo suficientemente grande. Sin embargo, enfocarse primero en (i) transferencias entre cuentas y (ii) identidad y casos de uso relacionados con la identidad (como pruebas privadas) es un primer paso pragmático, más fácil de implementar, y la billetera puede comenzar a usarse ahora mismo.
Las billeteras de Ethereum también necesitan convertirse en billeteras de datos.
Una consecuencia de cualquier solución de privacidad válida es que, ya sea para pagos, identidad u otros casos de uso, generará la necesidad de que los usuarios almacenen datos fuera de la cadena. Esto es evidente en Tornado Cash, que requiere que los usuarios guarden un 'recibo' por cada depósito que representa de 0.1 a 100 ETH. Protocolos de privacidad más modernos a veces almacenan datos encriptados en la cadena y los desencriptan con una sola clave privada. Esto es arriesgado, porque si la clave se filtra, o si la computación cuántica se vuelve viable, los datos se hacen completamente públicos. Protocolos de prueba fuera de la cadena como EAS y Zupass hacen aún 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 a la cadena, sino que también debe convertirse en el software que almacena sus datos privados. El mundo no criptográfico también se está dando cuenta cada vez más de esto, por ejemplo. Consulte 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 necesitamos resolver en torno a garantizar la accesibilidad y la no filtración de los datos. Quizás estas soluciones se puedan superponer: si tiene N guardianes, almacene sus datos utilizando un secreto compartido M de N entre esos N guardianes. Los datos son inherentemente más difíciles de proteger porque no puede revocar la parte de datos de alguien, pero deberíamos proponer soluciones de custodia descentralizadas que sean 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 digan cualquier información sobre la cadena. Esta es una vulnerabilidad con dos aspectos:
Los proveedores de RPC pueden intentar robar dinero proporcionando 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 está interactuando.
Idealmente, queremos cerrar estas dos brechas. Para abordar el primer problema, necesitamos clientes ligeros estandarizados en L1 y L2 que puedan verificar directamente el consenso de la cadena. Helios ya lo ha hecho para L1 y ha estado realizando algunos trabajos preliminares para respaldar algunos L2 específicos. Para cubrir correctamente todos los L2, necesitamos un estándar bajo el cual los contratos de configuración que representan a 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 pruebas para esos estados y los recibos de esas raíces de estado. Así, podríamos tener un cliente ligero universal que permita a la billetera verificar de manera segura cualquier estado o evento en L1 y L2.
Para la privacidad, la única forma real hoy en día es ejecutar tu propio nodo completo. Sin embargo, ahora que los L2 están entrando en la conciencia de la gente, ejecutar un nodo completo para todo se vuelve cada vez más difícil. Lo equivalente a un cliente ligero aquí es la recuperación de información privada (PIR). PIR implica un servidor que mantiene una copia de todos los datos y un cliente que envía solicitudes encriptadas al servidor. El servidor realiza cálculos sobre todos los datos, devuelve los datos necesarios al cliente y los encripta con la clave del cliente, sin revelar al servidor qué datos ha accedido el cliente.
Para mantener la honestidad del servidor, los diferentes proyectos de bases de datos son en sí mismos ramas de Merkle, por lo que el cliente puede verificarlas usando un cliente ligero.
El costo computacional del PIR (Nota de Deep Tide: generalmente se refiere a 'Recuperación de Información Privada', un protocolo o técnica que permite a los usuarios recuperar información de una base de datos sin revelar la información recuperada.) es bastante alto. Hay varias formas de abordar este problema:
Por fuerza bruta: las mejoras en algoritmos o hardware dedicado podrían hacer que el PIR funcione lo suficientemente rápido. Estas tecnologías pueden depender del preprocesamiento: el servidor puede almacenar datos encriptados 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 un país). Esto hace que el costo de cálculo en tiempo real sea menor, pero probablemente aumente el costo total de cálculo y almacenamiento.
Reducir los requisitos de privacidad: por ejemplo, solo puede haber 1 millón de 'mixins' por búsqueda, por lo que el servidor sabrá que el cliente puede acceder a un millón de valores posibles, pero no a ningún nivel de detalle más fino.
PIR de múltiples servidores: si utiliza varios servidores y la suposición de honestidad entre estos servidores es de 1 de N, entonces el algoritmo PIR generalmente será más rápido.
Anónimo en lugar de confidencial: se pueden enviar solicitudes a través de una red de mezcla, ocultando así al remitente de la solicitud, en lugar de ocultar el contenido de la solicitud. Sin embargo, hacerlo de manera efectiva inevitablemente aumentará la latencia, lo que empeorará la experiencia del usuario.
Encontrar la combinación técnica 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 al estado, otro flujo de trabajo importante que necesita funcionar sin problemas en el contexto de L2 es cambiar la configuración de validación de la cuenta: ya sea cambiar su clave (por ejemplo, recuperación) o realizar cambios más profundos en la lógica de la cuenta. Aquí hay tres soluciones, ordenadas por dificultad creciente:
Actualización de repetición: cuando un usuario cambia su configuración, el mensaje que autoriza este cambio se repetirá en cada cadena donde la billetera 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 repetidos automáticamente en tantas cadenas como sea posible.
Almacén de claves en L1: la información de configuración reside en L1, y la billetera en L2 la lee usando L1SLOAD o llamadas estáticas remotas. De este modo, solo se necesita actualizar la configuración en L1 para que se aplique automáticamente.
Almacén de claves en L2: la información de configuración reside en L2, y la billetera en L2 la lee usando ZK-SNARK. Esto es similar a (2), excepto que la actualización del almacén de claves puede ser más barata, pero por otro lado, la lectura es más cara.
La solución (3) es especialmente poderosa porque se adapta bien a la privacidad. En la 'solución de privacidad' normal, el usuario tiene un secreto s, publica un 'valor hoja' L en la cadena, y el usuario prueba que L = hash(s, 1) y N = hash(s, 2) para algún secreto que controlan (que nunca se ha revelado). Un símbolo N inválido se publica, asegurando que los gastos futuros de la misma hoja fallarán sin revelar L, lo que depende de la seguridad del secreto s del usuario. Una solución de privacidad amigable para la recuperación diría: s es una ubicación (por ejemplo, dirección y almacenamiento de ranura) 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 parte del tiempo, el usuario interactúa con la aplicación accediendo a un sitio web, que descarga implícitamente el código de la interfaz del usuario desde el servidor en tiempo real y lo ejecuta en el navegador. Si el servidor es hackeado o el DNS es atacado, el usuario obtendrá una copia falsa de la interfaz, lo que podría engañarlo para que realice operaciones arbitrarias. Las funciones de simulación de transacciones, etc., de la billetera son muy útiles para reducir el riesgo, pero aún están lejos de ser perfectas.
Idealmente, trasladaríamos el ecosistema a un control de versiones de contenido en la cadena: los usuarios accederían a la dapp a través de su nombre ENS, que contendría el hash IPFS de la interfaz. Las actualizaciones de la interfaz requerirían transacciones en la cadena de múltiples firmas o DAO. La billetera mostraría a los usuarios si están interactuando con una interfaz en la cadena más segura o con una interfaz de Web2 menos segura. La billetera también podría mostrar a los usuarios si están interactuando con una cadena segura (por ejemplo, fase 1+, auditoría de seguridad múltiple).
Para los usuarios que valoran la privacidad, la billetera también podría añadir un modo paranoico, que requiera que el usuario haga clic para aceptar solicitudes HTTP, no solo operaciones web3.
Modelo de interfaz del modo paranoico.
Un enfoque más avanzado es ir más allá de HTML + Javascript y escribir la lógica de negocio de la dapp en un lenguaje dedicado (quizás una capa delgada sobre Solidity o Vyper). Luego, el navegador podría generar automáticamente la interfaz de usuario para cualquier función necesaria. OKContract ya está haciendo esto.
Otra dirección es la defensa de información económica criptográfica: desarrolladores de dapp, empresas de seguridad, implementadores de cadenas y otros pueden establecer un bono, que se pagará a los usuarios afectados (determinados) si el dapp es hackeado o causa daño a los usuarios de manera altamente engañosa, por un DAO de arbitraje en la cadena. La billetera puede mostrar a los usuarios un puntaje basado en el tamaño del bono.
Futuro a largo plazo.
Todo lo anterior se ha realizado 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 más profundo de paradigma.
Inteligencia artificial, lo que podría llevarnos de un paradigma de escritura basado en clics a uno de 'di lo que quieres hacer y el robot lo resolverá'.
Interfaces cerebro-máquina, con métodos 'suaves' como el seguimiento ocular y tecnologías más directas e incluso invasivas (ver: el primer paciente de Neuralink de este año).
Defensa activa del cliente: el navegador Brave protege activamente a los usuarios de anuncios, rastreadores y muchos otros objetos dañinos. Muchos navegadores, plugins y billeteras criptográficas cuentan con equipos enteros dedicados a proteger a los usuarios de diversas amenazas de seguridad y privacidad. Estos 'guardianes activos' solo se volverán más poderosos en la próxima década.
Estas tres tendencias juntas llevarán a una re-evaluación más profunda de cómo funcionan las interfaces. Con la entrada en lenguaje natural, el seguimiento ocular o, finalmente, interfaces cerebro-máquina más directas, junto con tu historial (quizás incluyendo mensajes de texto, siempre que todos los datos sean procesados localmente), la 'billetera' podrá entender clara y intuitivamente lo que quieres hacer. Entonces, la inteligencia artificial podrá convertir esta intuición en un 'plan de acción' concreto: una serie de interacciones en la cadena y fuera de la cadena para completar lo que deseas hacer. Esto podría 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 adversarial en nombre del usuario, identificando cualquier amenaza y proponiendo un plan de acción para evitarla. Idealmente, estas inteligencias artificiales deberían tener un ecosistema abierto, generado por diferentes grupos con sesgos y estructuras de incentivos diversos.
Estas ideas más radicales dependen de que la tecnología esté muy inmadura hoy, así que hoy no pondría mis activos en una billetera que dependa de ellas. Sin embargo, parece evidente que cosas similares son una tendencia futura, por lo que vale la pena comenzar a explorar más activamente en esa dirección.
