Las billeteras son la ventana entre los usuarios y el mundo de Ethereum, y creo que centrarse en los atributos de seguridad y privacidad es lo más valioso.
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 de usuario para transacciones entre L2
Ahora existe una hoja de ruta cada vez más detallada para mejorar la experiencia del usuario en la L2, con partes a corto y largo plazo. Aquí hablaré de la parte a corto plazo: ideas que aún hoy son teóricamente posibles de implementar.
La idea central es (i) envío integrado entre capas 2 y (ii) solicitudes de pago y direcciones específicas de la cadena. Su billetera debería poder proporcionarle una dirección (siguiendo el estilo de este borrador de ERC) como esta:
Cuando alguien (o alguna aplicación) te proporciona una dirección en este formato, deberías poder pegarla en el campo "Para" 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 el tipo de token deseado en otra cadena (o en varias otras cadenas), envíe el token utilizando un protocolo como ERC-7683 (en realidad, un DEX entre cadenas)
Si tiene diferentes tipos de tokens en la misma cadena u otras cadenas, utilice un intercambio descentralizado para convertirlos en el tipo correcto de moneda en la cadena correcta y enviarlos. Esto debería requerir un permiso explícito del usuario: los usuarios verán cuánto pagaron y cuánto recibió el destinatario.
Modelo de posible interfaz de billetera con soporte de direcciones entre cadenas
Lo anterior es para el caso de uso "copias y pegas la dirección (o ENS, por ejemplo, vitalik.eth @optimism.eth) y alguien te paga". Si una dapp solicita un depósito (por ejemplo, vea este ejemplo de Polymarket), entonces el flujo ideal sería extender la API web3 y permitir que la dapp realice solicitudes de pago específicas de la cadena. Su billetera podrá entonces cumplir con la solicitud de la manera que sea necesaria. Para una buena experiencia de usuario, las solicitudes getAvailableBalance también deben estandarizarse, y las billeteras deben considerar cuidadosamente en qué cadenas se almacenarán los activos de los usuarios de forma predeterminada para maximizar la seguridad y la conveniencia de la transferencia.
Las solicitudes de pago específicas de la cadena también se pueden colocar en códigos QR, que pueden escanearse mediante billeteras móviles. En un escenario de pago del consumidor en persona (o en línea), el destinatario emitirá un código QR o una llamada a la API web3 que dice "Quiero X unidades de token Y Z en la cadena, con una identificación de referencia o devolución de llamada W" y la billetera podrá Siéntase libre de cumplir con esta solicitud de cualquier manera. Otra opción es un protocolo de vinculación de reclamos, donde la billetera del usuario genera un código QR o URL que contiene una autorización de reclamo para obtener una cierta cantidad de fondos de su contrato en cadena, y es trabajo del destinatario descubrir cómo transferir esos fondos a ellos mismos en la billetera.
Otro tema relacionado son los pagos de gasolina. Si recibe un activo en una L2 que aún no tiene ETH y necesita 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 cadena. donde tienes el ETH. Si la billetera quiere que hagas más transacciones en L2 en el futuro, también debería enviar solo usando DEX, por ejemplo. Unos pocos millones de gas en ETH para que las transacciones futuras puedan gastar gas allí directamente (porque es más barato).
Seguridad de la cuenta
Una forma de conceptualizar el desafío de seguridad de la cuenta es que una buena billetera debe hacer dos cosas a la vez: (i) proteger a los usuarios de piratería o ataques maliciosos por parte de los desarrolladores de billeteras, y (ii) proteger a los usuarios de verse afectados por sus propios errores.
El "error" de la izquierda no es intencionado. Sin embargo, cuando lo vi, me di cuenta de que encajaba perfectamente en el contexto, así que decidí conservarlo.
Mi solución preferida para esto, durante más de una década, ha sido la recuperación social y las billeteras multifirma con control de acceso jerárquico. La cuenta de un usuario tiene dos niveles de claves: una clave maestra y N guardianes (por ejemplo, N = 5). Las claves primarias son capaces de realizar operaciones no financieras y de bajo valor. La mayoría de los tutores necesitan realizar (i) operaciones de alto valor, como enviar el valor total de la cuenta, o (ii) cambiar la clave maestra o cualquier tutor. Si lo desea, se puede permitir que las claves primarias realicen operaciones de alto valor mediante bloqueos de tiempo.
Lo anterior es el diseño básico y se puede ampliar. Los mecanismos de permiso, como las claves de sesión y ERC-7715, pueden ayudar a respaldar diferentes equilibrios de conveniencia y seguridad para diferentes aplicaciones. Las arquitecturas guardianas más complejas, como tener múltiples duraciones de bloqueo de tiempo en diferentes umbrales, pueden ayudar a maximizar las posibilidades de recuperar cuentas legítimas con éxito y, al mismo tiempo, minimizar el riesgo de robo.
Lo anterior es el diseño básico y se puede ampliar. Los mecanismos de permiso, como las claves de sesión y ERC-7715, pueden ayudar a respaldar diferentes equilibrios de conveniencia y seguridad para diferentes aplicaciones. Las arquitecturas guardianas más complejas, como tener múltiples duraciones de bloqueo de tiempo en diferentes umbrales, pueden ayudar a maximizar las posibilidades de recuperar con éxito cuentas legítimas y, al mismo tiempo, minimizar el riesgo de robo.
¿Quién o qué debería ser el tutor?
Una opción viable para los usuarios de criptografía experimentados en la comunidad de usuarios de criptografía experimentados son las claves de sus amigos y familiares. Si les pides a todos que te proporcionen una nueva dirección, nadie necesita saber quiénes son; de hecho, tus tutores ni siquiera necesitan saber quiénes son los demás. Si no le avisaron, las posibilidades de que se confabulen son escasas. Sin embargo, para la mayoría de los usuarios nuevos, esta opción no está disponible.
La segunda opción son los tutores institucionales: empresas que se especializan en brindar servicios y que solo firman transacciones cuando reciben una confirmación adicional de su solicitud: ej. Códigos de confirmación o videollamadas para usuarios de alto valor. Por ejemplo, la gente lleva mucho tiempo intentando fabricarlos. Describí a CryptoCorp en 2013. Sin embargo, estas empresas no han tenido mucho éxito hasta el momento.
Una tercera opción son varios dispositivos personales (por ejemplo, teléfono, computadora de escritorio, billetera de hardware). Esto funciona, 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.
Últimamente, hemos comenzado a ver más soluciones basadas en claves maestras. Solo se puede realizar una copia de seguridad de las claves en su dispositivo, lo que lo convierte en una solución para dispositivos personales, o en la nube, lo que hace que su seguridad dependa de una combinación compleja de suposiciones de seguridad criptográfica, autoridad y hardware confiable. De hecho, las claves son una valiosa ganancia de seguridad para el usuario promedio, pero por sí solas no son suficientes para proteger los ahorros de toda la vida de un usuario.
Afortunadamente, con los ZK-SNARK tenemos una cuarta opción: la identificación centralizada del paquete ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, toma una identificación centralizada en una de sus muchas formas (corporativa o gubernamental) y la convierte en una dirección de Ethereum, y solo puede enviar transacciones generando un ZK-SNARK que demuestre que tiene la identificación centralizada.
Con esta incorporación, ahora tenemos una amplia gama de opciones y la exclusiva "facilidad para principiantes" de las identificaciones centralizadas envueltas en ZK.
Para hacer esto, debe implementarse a través de una interfaz de usuario simplificada e integrada: debería poder especificar solo que desea "example@gmail.com" como tutor, y debería generar automáticamente la dirección zk-email Ethereum correspondiente en el capó. Los usuarios avanzados deberían poder ingresar su correo electrónico (y posiblemente la sal de privacidad guardada en ese correo electrónico) en una aplicación de terceros de código abierto y confirmar que la dirección resultante es correcta. Lo mismo debería aplicarse a cualquier otro tipo de tutor admitido.
Tenga en cuenta que un desafío práctico al que se enfrenta zk-email hoy en día es que se basa en firmas DKIM, que utilizan claves que se rotan cada pocos meses y no están firmadas por ninguna otra autoridad. Esto significa que el zk-email actual tiene algún nivel de requisitos de confianza más allá del propio proveedor; esto se puede reducir si zk-email usa TLSNotary dentro del hardware confiable para verificar las claves actualizadas, pero esto no es lo ideal. Con suerte, los proveedores de correo electrónico comenzarán a firmar sus claves DKIM directamente. Hoy recomiendo zk-email para un tutor, pero no para la mayoría de los tutores: no almacene fondos en una configuración donde un zk-email roto significa que no puede usar los fondos.
Nuevos usuarios y billetera en la aplicación
En realidad, los nuevos usuarios no quieren ingresar una gran cantidad de tutores cuando se registran por primera vez. Por lo tanto, la billetera debería brindarles una opción muy simple. Una ruta natural sería hacer un 2 de 3 usando zk-email en su dirección de correo electrónico, una clave almacenada localmente en el dispositivo del usuario (tal vez una clave maestra) y una clave de respaldo en poder del proveedor. A medida que los usuarios adquieren más experiencia o acumulan más activos, en algún momento se les debería solicitar que agreguen más tutores.
La integración de billeteras en aplicaciones es inevitable porque las aplicaciones que intentan atraer a usuarios que no son criptográficos no quieren la experiencia confusa de los usuarios que descargan dos nuevas aplicaciones (la aplicación en sí, más una billetera Ethereum) al mismo tiempo. Sin embargo, los usuarios de muchas billeteras de aplicaciones deberían poder vincular todas sus billeteras para que solo tengan que preocuparse por un "problema de control de acceso". El enfoque más simple es adoptar un esquema en capas, donde existe un proceso rápido de "vinculación" que permite a los usuarios configurar su billetera principal como guardiana de todas las billeteras dentro de la aplicación. El cliente Farcaster Warpcast ya admite esto:
De forma predeterminada, la recuperación de su cuenta Warpcast está controlada por el equipo de Warpcast. Sin embargo, puedes "hacerte cargo" de tu cuenta de Farcaster y cambiar la recuperación a tu propia dirección.
Proteja a los usuarios de estafas y otras amenazas externas
Además de la seguridad de las cuentas, las billeteras actuales hacen mucho para identificar direcciones falsas, phishing, estafas y otras amenazas externas y tratan de proteger a los usuarios de dichas amenazas. Al mismo tiempo, muchas contramedidas son todavía bastante primitivas: por ejemplo, requerir un clic para enviar ETH u otros tokens a cualquier dirección nueva, ya sea que envíe $100 o $100,000. Aquí no existe una única fórmula mágica. Se trata de una serie lenta y continua de correcciones y mejoras para diferentes clases de amenazas. Sin embargo, es muy valioso seguir trabajando en mejoras aquí.
privacidad
Es hora de empezar a tomar más en serio la privacidad en Ethereum. La tecnología ZK-SNARK ahora es muy avanzada, las tecnologías de privacidad que no dependen de puertas traseras para reducir el riesgo regulatorio (como los grupos de privacidad) están cada vez más maduras y la infraestructura secundaria como los mempools Waku y ERC-4337 se están volviendo lentamente más estables. Sin embargo, hasta ahora, realizar transferencias privadas en Ethereum requería que los usuarios descargaran y usaran explícitamente una "billetera privada" como Railway (o Umbra para direcciones ocultas). Esto añade importantes inconvenientes y reduce el número de personas dispuestas a realizar transferencias privadas. La solución es que las transferencias privadas deben integrarse directamente en la billetera.
Una implementación simple es la siguiente. Las billeteras pueden almacenar una parte de los activos de un usuario como un "saldo privado" en un grupo de privacidad. Cuando los usuarios realizan transferencias, saldrán automáticamente del grupo de privacidad primero. Si el usuario necesita recibir fondos, la billetera puede generar automáticamente una dirección oculta.
Además, la billetera puede generar automáticamente una nueva dirección para cada aplicación en la que participa el usuario (por ejemplo, el protocolo defi). Los depósitos provendrán del fondo de privacidad y los retiros irán directamente al fondo de privacidad. Esto permite desvincular la actividad de un usuario en cualquier aplicación de su actividad en otras aplicaciones.
Una ventaja de esta tecnología es que es un camino natural no sólo para las transferencias de activos que preservan la privacidad, sino también para las identidades que preservan la privacidad. La identidad ya ocurre en la cadena: cualquier aplicación que utilice control de prueba de identidad (por ejemplo, Gitcoin Grants), cualquier chat controlado por token, protocolos de seguimiento de Ethereum, etc., es una identidad en la cadena. Queremos que este ecosistema también proteja la privacidad. Esto significa que la actividad en cadena de un usuario no debe recopilarse en un solo lugar: cada proyecto debe almacenarse por separado y la billetera del usuario debe ser lo único con una "vista global" que pueda ver todas sus pruebas al mismo tiempo. . Un ecosistema nativo de múltiples cuentas por usuario ayuda a lograrlo, al igual que los protocolos a prueba fuera de la cadena como EAS y Zupass.
Esto representa una visión pragmática de la privacidad de Ethereum a medio plazo. Si bien se pueden introducir algunas funciones en L1 y L2 para hacer que la transmisión que preserva la privacidad sea más eficiente y confiable, hoy es posible. Algunos defensores de la privacidad creen que lo único aceptable es lograr una privacidad total de todas las cosas: cifrar todo el EVM. Creo que este podría ser el resultado ideal a largo plazo, pero requeriría un replanteamiento más fundamental del modelo de programación y aún no se encuentra en un nivel de madurez listo para implementarse en Ethereum. Necesitamos privacidad predeterminada para obtener un conjunto de anonimato lo suficientemente grande. Sin embargo, centrarse primero en (i) las transferencias entre cuentas y (ii) la identidad y los casos de uso relacionados con la identidad (como las pruebas privadas) son primeros pasos pragmáticos que son más fáciles de implementar y las billeteras pueden comenzar a usarse ahora.
Las billeteras Ethereum también deben ser billeteras de datos
Una consecuencia de cualquier solución de privacidad eficaz, ya sea para pagos, identidad u otros casos de uso, es que crea la necesidad de que los usuarios almacenen sus datos fuera de la cadena. Esto es evidente en Tornado Cash, que requiere que los usuarios guarden "boletos", cada uno de los cuales representa un depósito de 0,1 a 100 ETH. Los protocolos de privacidad más modernos a veces mantienen datos cifrados en cadena y utilizan una única clave privada para descifrarlos. Esto es arriesgado porque si se filtran las claves o si las computadoras cuánticas se vuelven factibles, todos los datos serán públicos. Las pruebas fuera de la cadena, como EAS y Zupass, tienen una necesidad más obvia de almacenamiento de datos fuera de la cadena.
Una billetera debe ser un software que no solo almacene los derechos de acceso a la cadena, sino también sus datos privados. El mundo no criptográfico también lo reconoce cada vez más, por ejemplo. Vea el trabajo reciente de Tim Berners-Lee sobre el almacenamiento de datos personales. Todas las cuestiones que debemos abordar para garantizar de manera sólida el control de acceso, también debemos abordarlas para garantizar de manera sólida que los datos sean accesibles y no se filtren. Quizás estas soluciones puedan acumularse: si tiene N guardianes, utilice el intercambio secreto de M de N entre esos N guardianes para almacenar sus datos. Los datos son intrínsecamente más difíciles de proteger porque no se puede revocar la parte de los datos de alguien, pero deberíamos idear soluciones de alojamiento descentralizadas que sean lo más seguras posible.
Acceso seguro a la cadena
Hoy en día, las billeteras confían en su proveedor de RPC para que les informe cualquier cosa sobre la cadena. Esta es una vulnerabilidad de dos maneras:
Los proveedores de RPC pueden intentar robar dinero proporcionándoles información falsa, por ejemplo. Sobre el precio de mercado.
Los proveedores de RPC pueden extraer información privada sobre las aplicaciones y otras cuentas con las que interactúa el usuario.
Lo ideal sería cerrar ambas lagunas. Para resolver el primer problema, necesitamos clientes ligeros estandarizados para L1 y L2 que puedan verificar directamente el consenso de blockchain. Helios ya hace esto para L1 y ha estado realizando un trabajo preliminar para admitir algunas L2 específicas. Para cubrir adecuadamente toda L2, necesitamos un estándar mediante el cual el contrato de configuración que representa L2 (también usado para direcciones específicas de cadena) pueda declarar una función, posiblemente de manera similar a ERC-3668, que contenga la función de obtener la dirección más cercana. state root y Verifique los estados lógicos de la certificación y los recibos con las raíces de esos estados. De esta manera podemos tener un cliente ligero universal que permite a las billeteras verificar de forma segura cualquier estado o evento en L1 y L2.
En materia de privacidad, el único enfoque realista hoy en día es ejecutar su propio nodo completo. Sin embargo, ahora que L2 está a la vista, ejecutar un nodo completo con todo se vuelve cada vez más difícil. El equivalente del cliente ligero aquí es la Recuperación de Información Privada (PIR). PIR implica un servidor que guarda una copia de todos los datos y un cliente que envía una solicitud cifrada al servidor. El servidor realiza cálculos sobre todos los datos, devolviendo los datos que el cliente necesita, cifrados con la clave del cliente, sin revelar al servidor a qué datos accedió el cliente.
Para mantener el servidor honesto, los proyectos de bases de datos individuales son en sí mismos bifurcaciones de Merkle, por lo que los clientes pueden usar clientes ligeros para verificarlos.
PIR (Nota de Deep Chao: generalmente se refiere a "Recuperación de información privada", un protocolo o tecnología que permite a los usuarios recuperar información de una base de datos sin revelar la información recuperada). La cantidad de cálculo es muy grande. Hay varias formas de solucionar este problema:
Con fuerza bruta: las mejoras en los algoritmos o el hardware especializado podrían hacer que PIR funcione lo suficientemente rápido. Estas técnicas pueden depender del preprocesamiento: el servidor puede almacenar datos cifrados y codificados para cada cliente, y los clientes pueden 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 (al igual que los países). Esto abarata la computación en tiempo real, pero probablemente aumenta los costos totales de computación y almacenamiento.
Debilitar los requisitos de privacidad: por ejemplo, solo puede haber 1 millón de "mixins" por búsqueda, por lo que el servidor sabrá el millón de valores posibles a los que tiene acceso el cliente, pero no una granularidad más fina.
PIR multiservidor: si utiliza varios servidores y se supone que la honestidad entre estos servidores es 1 de N, entonces el algoritmo PIR suele ser más rápido.
Anonimato en lugar de confidencialidad: las solicitudes se pueden enviar a través de una red híbrida, ocultando al remitente de la solicitud en lugar de ocultar el contenido de la solicitud. Sin embargo, hacerlo de forma eficaz inevitablemente aumentará la latencia, empeorando así la experiencia del usuario.
Descubrir la combinación correcta de tecnologías para maximizar la privacidad y al mismo tiempo mantener la practicidad en el entorno Ethereum es una pregunta de investigación abierta, y doy la bienvenida a los criptógrafos a intentar hacerlo.
Cartera de almacenamiento de claves ideal
Además del transporte y el acceso al estado, otro flujo de trabajo importante que debe funcionar sin problemas en contextos L2 es cambiar la configuración de autenticación de la cuenta: ya sea cambiando sus claves (por ejemplo, recuperación) o realizando cambios más profundos en toda la lógica de la cuenta. Aquí hay tres niveles de soluciones, en orden de dificultad creciente:
Reproducir actualizaciones: cuando un usuario cambia su configuración, el mensaje que autoriza este cambio se reproducirá en cada cadena donde la billetera detecte que el usuario posee activos. Potencialmente, los formatos de mensajes y las reglas de validación pueden ser independientes de la cadena y, por lo tanto, reproducirse automáticamente en tantas cadenas como sea posible.
Almacén de claves en L1: la información de configuración se encuentra en L1 y la billetera en L2 la lee mediante L1SLOAD o llamadas estáticas remotas. De esta manera, solo necesita actualizar la configuración en L1 y la configuración entrará en vigencia automáticamente.
Almacén de claves en L2: la información de configuración existe en L2 y la billetera en L2 la lee usando ZK-SNARK. Esto es lo mismo que (2), excepto que las actualizaciones del almacén de claves pueden ser más baratas, pero las lecturas, por otro lado, son más caras.
La solución (3) es particularmente poderosa porque favorece la privacidad. En una "solución de privacidad" normal, un usuario tiene un secreto s, publica un "valor de hoja" L en la cadena y el usuario demuestra que L = hash(s, 1) y N = hash(s, 2) para algunos (s, 2) controlan secretos que nunca han sido revelados). El invalidador N se emite de manera que los gastos futuros de la misma hoja fallarán sin revelar L, lo cual depende de la seguridad del usuario. Una solución de privacidad fácil de recuperar diría: 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 aplicaciones
El eslabón más débil en la seguridad del usuario suele ser el dapp. La mayoría de las veces, los usuarios interactúan con las aplicaciones visitando un sitio web, que implícitamente descarga el código de la interfaz de usuario en tiempo real desde el servidor y luego lo ejecuta en el navegador. Si se piratea el servidor o el DNS, los usuarios obtendrán una copia falsa de la interfaz, lo que podría engañarlos para que realicen acciones arbitrarias. Las funciones de Wallet, como las simulaciones comerciales, son muy útiles para reducir el riesgo, pero están lejos de ser perfectas.
Idealmente, trasladaríamos el ecosistema al control de versiones de contenido en cadena: los usuarios accederían a dapps a través de su nombre de ENS, que contendría el hash IPFS de la interfaz. La actualización de la interfaz requiere una transacción en cadena desde un multifirma o DAO. La billetera mostrará a los usuarios si están interactuando con la interfaz en cadena más segura o con la interfaz Web2 menos segura. Las billeteras también pueden mostrar a los usuarios si están interactuando con una cadena de seguridad (por ejemplo, Etapa 1+, múltiples auditorías de seguridad).
Para los usuarios preocupados por la privacidad, la billetera también puede agregar un modo paranoico que requiere que los usuarios hagan clic para aceptar solicitudes HTTP, no solo operaciones web3:
Posible modelo de interfaz para el modo paranoico.
Un enfoque más avanzado sería ir más allá de HTML + Javascript y escribir la lógica empresarial de la dapp en un lenguaje dedicado (quizás una superposición relativamente delgada en Solidity o Vyper). Luego, el navegador puede generar automáticamente la interfaz de usuario para cualquier funcionalidad deseada. OKContract ya lo está haciendo.
Otra dirección es la defensa de la información criptoeconómica: los desarrolladores de dapp, las empresas de seguridad, los implementadores de cadenas y otros pueden establecer un vínculo que se pagará al destinatario si la dapp es pirateada o daña a los usuarios de una manera altamente engañosa (que están identificados). ) son adjudicados por algún DAO en cadena. La billetera puede mostrar una puntuación al usuario según el tamaño del bono.
futuro a largo plazo
Todo lo anterior está en el contexto de una interfaz tradicional, que implica señalar 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, que puede llevarnos de un paradigma de hacer clic para escribir a un paradigma de "di lo que quieres hacer y el robot lo descubrirá".
Interfaces cerebro-computadora, que van desde métodos "suaves" como el seguimiento ocular hasta técnicas más directas e incluso invasivas (ver: el primer paciente de Neuralink de este año)
Defensa proactiva del lado del cliente: Brave Browser protege proactivamente a los usuarios de anuncios, rastreadores y muchos otros objetos no deseados. En muchos navegadores, complementos y billeteras criptográficas, equipos completos trabajan activamente para proteger a los usuarios de diversas amenazas a la seguridad y la privacidad. Estos “guardianes positivos” no harán más que fortalecerse durante la próxima década.
Juntas, estas tres tendencias conducirán a un replanteamiento más profundo de cómo funcionan las interfaces. A través de la entrada de lenguaje natural, el seguimiento ocular o, eventualmente, una interfaz cerebro-computadora más directa, junto con su historial (quizás incluyendo mensajes de texto, siempre que todos los datos se procesen localmente), la "billetera" puede comprender clara e intuitivamente dónde desea ir. Luego, la IA puede traducir esta intuición en un "plan de acción" concreto: una serie de interacciones dentro y fuera de la cadena para lograr lo que desea. Esto puede reducir en gran medida la necesidad de interfaces de usuario de terceros. Si un usuario interactúa con una aplicación de terceros (u otro usuario), la IA debe pensar de manera adversa en nombre del usuario, identificar cualquier amenaza y sugerir un plan de acción para evitarla. Idealmente, estas IA deberían tener un ecosistema abierto, producido por diversos grupos con diferentes sesgos y estructuras de incentivos.
Estas ideas más radicales dependen de una tecnología que hoy en día es muy inmadura, por lo que no pondría mis activos en una billetera que dependa de ellas hoy. Sin embargo, parece claro que algo así es el camino del futuro, por lo que vale la pena empezar a explorar más activamente en esta dirección.
