Escrito por: Vitalik Buterin Compilado por: Yangz, Techub News La billetera es una capa crítica en la pila de infraestructura de Ethereum, pero a menudo no es valorada por los principales investigadores y desarrolladores de L1. Las billeteras son la ventana entre los usuarios y el mundo de Ethereum, y los usuarios solo pueden beneficiarse de ellas si la billetera en sí también tiene descentralización, resistencia a la censura, seguridad, privacidad u otras características proporcionadas por Ethereum y sus aplicaciones. En los últimos años, hemos visto a la billetera ecológica Ethereum lograr grandes avances en la mejora de la experiencia, la seguridad y la funcionalidad del usuario. El propósito de este artículo es expresar mi opinión personal sobre algunos de los atributos que debe tener una billetera Ethereum ideal. Esta lista no será exhaustiva, pero refleja mis inclinaciones cypherpunk. Para las billeteras, valoro más la seguridad y la privacidad, porque casi no existe una billetera perfecta en términos de experiencia de usuario. 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, y centrarse en los atributos de seguridad y privacidad es, en mi opinión, lo más valioso. Experiencia del usuario de transacciones entre L2 En la actualidad, la ruta para mejorar la experiencia del usuario entre L2 se ha vuelto cada vez más detallada, incluidas partes a corto y largo plazo. Aquí quiero hablar de la parte a corto plazo, ideas que hoy en día son teóricamente posibles. La idea central de esta parte son las transacciones entre L2 integradas, así como las direcciones y solicitudes de pago específicas de la cadena. La billetera debería proporcionar una dirección como esta:
Cuando alguien (o una aplicación) te proporciona una dirección en este formato, deberías poder pegarla en el campo "para" de tu billetera, luego presionar "enviar" y la billetera la procesará automáticamente:
Si hay suficientes tokens del tipo requerido en la cadena de destino, envíelos directamente;
Si tiene el tipo de token requerido en otra cadena (o cadenas), puede enviar el token usando un protocolo como ERC-7683 (en realidad, un DEX entre cadenas);
Si tiene un tipo diferente de token en la misma cadena u otra cadena, puede usar DEX para convertirlo en el tipo correcto de token en la cadena correcta y enviarlo. Por supuesto, esto también requiere el permiso explícito del usuario, lo que significa que el usuario verá cuánto pagó y cuánto recibió el destinatario.
Lo anterior es un caso de uso para "copiar y pegar una dirección (o ENS, por ejemplo, vitalik.eth@optimism.eth) para que alguien le pague". Si los depósitos se realizan en una DApp (consulte el ejemplo de Polymarket), entonces el flujo ideal sería extender la API Web3 para permitir que la DApp realice solicitudes de pago específicas de la cadena. De esta manera, la billetera del usuario puede satisfacer la solicitud de cualquier manera. Para una buena experiencia de usuario, las solicitudes getAvailableBalance también deben estar estandarizadas, y las billeteras deben considerar en qué cadena se almacenarán los activos de un usuario de forma predeterminada para maximizar la seguridad y la facilidad de las transferencias.
Las solicitudes de pago para una cadena específica también se pueden colocar en un código QR para que las billeteras móviles las escaneen directamente. En un escenario de pago de consumo en persona (u en línea), el beneficiario puede llamar "Quiero X unidades de tokens Y en la cadena Z con una ID de referencia o devolución de llamada W" a través del código QR o API Web3, y la billetera puede Sentir libre de cumplir con esta solicitud en cualquier forma. Otra solución es reclamar un protocolo de enlace, es decir, la billetera del usuario puede generar un código QR o URL, que contiene la autorización para reclamar una cierta cantidad de fondos de su contrato en cadena, y el trabajo del beneficiario es encontrar una manera. para transferir estos fondos Transfiera a su propia billetera.
Otro tema relacionado son los pagos de gasolina. Si recibe un activo en una L2 que aún no posee 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 la cadena. donde posee ETH. Si la billetera anticipa que realizará más transacciones en ese L2 en el futuro, entonces también debería usar el DEX para enviar unos pocos millones de gas en ETH para que las transacciones futuras puedan usar gas directamente (que también es más barato).
Seguridad de la cuenta
Mi comprensión del desafío de seguridad de la cuenta es que una buena billetera debe proteger a los usuarios tanto de piratas informáticos o ataques maliciosos por parte de los desarrolladores de billeteras como de sus propios errores.
Los "errores" tipográficos en el eje vertical son un error de buena fe. Sentí que este error encajaba en el contexto, así que no lo modifiqué.
Durante más de una década, mi solución preferida ha sido la recuperación social y las billeteras multifirma con controles de acceso jerárquicos. Una cuenta de usuario única se configura con dos capas de claves, incluida una clave maestra y N firmantes (por ejemplo, N = 5). Las claves maestras permiten operaciones no financieras y de bajo valor. Pero para realizar operaciones de alto valor, como enviar todos los activos de una cuenta o cambiar la clave maestra o cualquier firmante, se requiere la mayoría de los firmantes. Si lo desea, se puede permitir que la llave maestra realice operaciones de alto valor con bloqueos de tiempo.
Lo anterior es sólo el diseño básico, también podemos ampliarlo. Por ejemplo, las claves de sesión y los mecanismos de permiso como ERC-7715 pueden ayudar a admitir diferentes aplicaciones con diferentes equilibrios entre conveniencia y seguridad. Las arquitecturas de firmantes más complejas, como establecer múltiples duraciones de bloqueo de tiempo en diferentes umbrales, pueden ayudar a maximizar las posibilidades de recuperar exitosamente una cuenta legítima y al mismo tiempo minimizar el riesgo de robo.
¿Quién debería ser elegido como firmante de una billetera multifirma?
Para los usuarios experimentados de criptomonedas, una opción viable son sus amigos y familiares. De hecho, los firmantes de su billetera multifirma ni siquiera necesitan saber quiénes son los demás. Las posibilidades de que colaboren sin su conocimiento son escasas o nulas. Sin embargo, para la mayoría de los usuarios nuevos, esta opción no es viable.
La segunda opción son las agencias, aquellas empresas que se especializan en brindar servicios. Este tipo de firmante solo firmará una transacción después de recibir información de confirmación adicional (como un código de confirmación o una videollamada de un usuario de alto patrimonio). La gente lleva mucho tiempo intentando crear empresas como esta; por ejemplo, describí un perfil de CryptoCorp en 2013. Sin embargo, hasta el momento no hay representantes muy exitosos de este tipo de empresas.
Una tercera opción es utilizar múltiples dispositivos personales (por ejemplo, dispositivos móviles, computadoras de escritorio, billeteras de hardware). Este enfoque puede funcionar, pero también puede resultar difícil de configurar y administrar para usuarios inexpertos. Además, 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 aparecer más billeteras basadas en claves de acceso. Se puede hacer una copia de seguridad de la clave de acceso solo en el dispositivo, lo que la convierte en una solución de persona a dispositivo, o en la nube, lo que hace que su seguridad dependa de una combinación compleja de seguridad de contraseña, autoridad y suposiciones de hardware confiable. En realidad, la clave de acceso es una valiosa ganancia de seguridad para el usuario promedio, pero no es suficiente por sí sola para proteger los ahorros de toda la vida de un usuario.
Afortunadamente, con ZK-SNARK tenemos una cuarta opción, una identificación centralizada procesada por ZK. Este tipo incluye zk-email, Anon Aadhaar, Myna Wallet, etc. Básicamente, toma cualquier forma de identificación centralizada (corporativa o gubernamental) y la convierte en una dirección de Ethereum, y solo generando una prueba ZK-SNARK de propiedad de esa identificación puede enviar transacciones desde esa dirección.
Con esta nueva característica, tenemos una variedad de opciones y las identificaciones centralizadas procesadas por ZK son muy amigables para los principiantes.
Para lograr esto, necesitamos utilizar una interfaz de usuario integrada y optimizada. Los usuarios solo necesitan especificar "example@gmail.com" como firmante, y la billetera generará automáticamente la dirección zk-email Ethereum correspondiente. Además, los usuarios avanzados deberían poder ingresar su correo electrónico (junto con una sal de privacidad que puede guardarse en el 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 firmante admitido.
Cabe señalar que un desafío práctico al que se enfrenta zk-email actualmente es que se basa en firmas DKIM, que utilizan claves que rotan cada pocos meses y no están firmadas por ninguna otra autoridad. Esto significa que se requiere un nivel de confianza más allá del propio proveedor; si zk-email usa TLSNotary en hardware confiable para verificar claves actualizadas, el requisito de confianza se puede reducir, pero esto no es lo ideal. Con suerte, los proveedores de correo electrónico comenzarán a firmar claves DKIM directamente. Además, recomiendo usar zk-email solo en un firmante, no en la mayoría de los firmantes. De esta manera, incluso si zk-email falla, no perderá el acceso a sus fondos.
Nuevos usuarios y billetera en la aplicación
En realidad, los nuevos usuarios no querrán ingresar una gran cantidad de información de firmante de billetera multifirma cuando se registren por primera vez. Por tanto, las carteras deberían ofrecer una opción muy sencilla. Un enfoque natural sería utilizar zk-email para 2 de las 3 firmas, una clave almacenada localmente en el dispositivo del usuario (podría ser una clave de acceso) y una clave de respaldo en poder del proveedor. A medida que los usuarios adquieran experiencia o acumulen activos, en algunos casos se les pedirá que agreguen más firmantes.
La integración de billeteras en las aplicaciones es inevitable porque las aplicaciones que intentan atraer usuarios que no utilizan criptomonedas no querrán crear una mala experiencia de usuario al hacer que los usuarios descarguen dos aplicaciones nuevas (la aplicación en sí y una billetera Ethereum) al mismo tiempo. Los usuarios que utilicen varias carteras también deberían poder conectar todas las carteras para que sólo tengan que preocuparse por los "problemas de control de acceso". El enfoque más simple es utilizar un enfoque en capas, donde los usuarios pueden configurar su billetera principal como firmante para todas las billeteras dentro de la aplicación a través de un rápido proceso de "vinculación". Actualmente, el cliente Farcaster Warpcast admite este método.
De forma predeterminada, la recuperación de las cuentas de Warpcast está controlada por el equipo de Warpcast. Pero los usuarios pueden "tomar control" de una cuenta de Farcaster y cambiarla a su propia dirección.
Proteja a los usuarios del fraude 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 trabajan arduamente para proteger a los usuarios de dichas amenazas. Sin embargo, muchas contramedidas son todavía bastante primitivas. Por ejemplo, enviar ETH u otros tokens a cualquier dirección nueva está a solo un clic de distancia, ya sea que envíes $100 o $100,000. No existe una solución única a este respecto, sino más bien una serie lenta y continua de correcciones y mejoras para diferentes clases de amenazas. Sin embargo, es muy valioso seguir esforzándose por mejorar.
privacidad
La tecnología ZK-SNARK se ha vuelto muy avanzada y las tecnologías de privacidad como Privacy Pools, que pueden reducir los riesgos regulatorios sin depender de puertas traseras, se están volviendo cada vez más maduras. La infraestructura secundaria como Waku y ERC-4337 también se está volviendo más estable. Sin embargo, hasta ahora, realizar transferencias privadas en Ethereum todavía requería que los usuarios descargaran y usaran explícitamente una "billetera privada" como Railway (o Umbra para direcciones ocultas). Esto trae grandes inconvenientes a los usuarios y reduce el número de dichos usuarios. La solución a este problema es integrar dichas transferencias directamente en la billetera.
Un método de implementación simple es que la billetera puede almacenar parte de los activos del usuario como un "saldo privado" en un grupo de privacidad. Cuando un usuario realiza una transferencia, primero se retirará automáticamente del grupo de privacidad. Si el usuario necesita recibir fondos, la billetera genera 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 (como los protocolos DeFi). Los depósitos provienen del grupo de privacidad y los retiros van directamente al grupo de privacidad. De esta manera, la actividad de un usuario en cualquier aplicación es independiente de su actividad en otras aplicaciones.
Una ventaja de esta tecnología es que no sólo logra la privacidad de las transferencias de activos, sino también la privacidad del reconocimiento de identidad. Actualmente, la identificación se implementa en cadena, cualquier aplicación que utilice prueba de personalidad (como Gitcoin Grants), cualquier chat que requiera un token específico y el protocolo Ethereum Follow son identificación en cadena. Esperamos que este ecosistema también pueda ser privado, es decir, las actividades de los usuarios en la cadena no deben recopilarse en un solo lugar, cada proyecto debe almacenarse por separado y la billetera del usuario debe ser lo único con una "vista global". " , podrás ver todas tus pruebas al mismo tiempo. Al igual que con los protocolos de autenticación fuera de cadena como EAS y Zupass, un ecosistema nativo de múltiples cuentas por usuario ayuda a lograr este objetivo.
Esto representa una visión pragmática de la privacidad de Ethereum a medio plazo. Si bien se puede implementar hoy, la introducción de funciones en las etapas L1 y L2 hará que las transacciones que preservan la privacidad sean más eficientes y confiables. Algunos defensores de la privacidad creen que lo único aceptable es que todo sea completamente privado, con todo el EVM cifrado. Pero creo que este es probablemente el resultado deseado a largo plazo y requiere un replanteamiento más fundamental del modelo de programación, y aún no está lo suficientemente maduro como para implementarlo en Ethereum. Necesitamos "privacidad por defecto" para lograr un anonimato suficiente. Sin embargo, centrarse en la privacidad de las transferencias entre cuentas, así como en la identidad y los casos de uso relacionados con la identidad, es un primer paso pragmático que es más fácil de implementar y que puede diseñarse para la billetera en esta etapa.
Las billeteras Ethereum también deben ser billeteras de datos
Cualquier solución de privacidad eficaz, ya sea para pagos, identificación u otros casos de uso, hará que los usuarios necesiten almacenar datos fuera de la cadena. Esto es evidente en Tornado Cash, que requiere que los usuarios guarden cada “nota” que representa un depósito de 0,1 a 100 ETH. Y los protocolos de privacidad más modernos a veces mantienen datos cifrados en cadena y utilizan una única clave privada para descifrarlos. Sin embargo, esto es arriesgado, porque si se filtran las claves o se hacen posibles las computadoras cuánticas, todos los datos serán públicos. Para entonces, la necesidad de almacenamiento de datos fuera de la cadena para la autenticación fuera de la cadena como EAS y Zupass será más obvia.
Las billeteras deben ser un software que no solo almacene los derechos de acceso a la cadena, sino que también almacene datos privados. Esto también se reconoce cada vez más en el mundo sin criptomonedas; consulte la investigación reciente de Tim Berners-Lee sobre el almacenamiento de datos personales. Todos los problemas que debemos resolver no son sólo garantizar eficazmente el control de los derechos de acceso, sino también garantizar la accesibilidad y la no fuga de datos. Tal vez estas dos soluciones se puedan combinar juntas, suponiendo que configure N firmantes multifirma, luego puede usar el intercambio secreto M de N entre estos N firmantes para almacenar los datos. Los datos son intrínsecamente más difíciles de proteger porque no se puede revocar la parte de los datos de otra persona, pero debemos idear soluciones de alojamiento descentralizadas seguras siempre que sea posible.
Acceso seguro a la cadena de bloques
Muchas billeteras confían en que el proveedor de RPC les diga cualquier cosa sobre la cadena. Esto tiene dos errores. En primer lugar, los proveedores de RPC podrían intentar robar fondos proporcionando información falsa (como precios de mercado); en segundo lugar, los proveedores de RPC podrían extraer información privada sobre las aplicaciones y otras cuentas con las que interactúa un usuario.
Idealmente, debemos evitar que se produzcan ambas vulnerabilidades. Para evitar la primera vulnerabilidad, necesitamos clientes ligeros estandarizados L1 y L2 que verifiquen directamente el consenso de blockchain. Helios ya implementa esta funcionalidad para L1 y se ha realizado un trabajo inicial 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 para una dirección de cadena específica) pueda publicar una función (quizás de manera similar a ERC-3668) que contenga la función de obtener el máximo Lógica de raíz estatal reciente y validar certificados y recibos estatales con estas raíces estatales. 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 cuanto a la segunda vulnerabilidad, la única forma viable en este momento es ejecutar su propio nodo completo. Sin embargo, a medida que L2 se vuelve más popular, se vuelve cada vez más difícil ejecutar un nodo completo con todo incluido. Una solución equivalente a este problema es la Recuperación de Información Privada (PIR). PIR implica un servidor que contiene una copia de todos los datos y un cliente que envía solicitudes cifradas 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 que el servidor siga siendo honesto, los elementos individuales de la base de datos deben ser ramas del árbol Merkle, para que los clientes puedan verificarlos utilizando sus propios clientes ligeros.
PIR es computacionalmente costoso, pero hay varias formas de abordar este problema:
Fuerza bruta: es posible que las mejoras en los algoritmos o el hardware especializado puedan hacer que PIR se ejecute lo suficientemente rápido. Estas técnicas pueden depender del preprocesamiento, donde el servidor almacena datos cifrados y mezclados para cada cliente, que pueden consultarse. En el entorno de Ethereum, el principal desafío es cómo adaptar estas tecnologías a conjuntos de datos que cambian rápidamente (como cambios de estado). Esto reducirá los costos de computación en tiempo real, pero probablemente aumentará los costos totales de computación y almacenamiento.
Debilitar los requisitos de privacidad: por ejemplo, solo hay 1 millón de "mixins" por consulta, por lo que el servidor conocerá el millón de valores posibles a los que el cliente puede acceder, pero no la granularidad más fina.
PIR multiservidor: el algoritmo PIR suele ser mucho más rápido si se utilizan varios servidores, suponiendo una honestidad 1 de N entre estos servidores.
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 inevitablemente aumentará la latencia y empeorará la experiencia del usuario.
En el entorno de Ethereum, encontrar una combinación de tecnologías que puedan maximizar la protección de la privacidad manteniendo al mismo tiempo la practicidad es un tema de investigación abierto, y los criptógrafos pueden probarlo.
Cartera ideal para guardar llaves.
Además del transporte y el acceso al estado, otro flujo de trabajo importante que debe ejecutarse sin problemas en entornos L2 es cambiar la configuración de autenticación de una cuenta (ya sea cambiando claves o realizando cambios más profundos en toda la lógica de la cuenta). Aquí están las soluciones de tres niveles, con dificultad creciente:
Reproducir actualizaciones: cuando un usuario cambia una configuración, el mensaje de cambio de autorización se reproduce en cada cadena donde la billetera detecta que el usuario posee activos. Los formatos de mensajes y las reglas de validación pueden ser independientes de la cadena, por lo que pueden reproducirse automáticamente en tantas cadenas como sea posible.
Almacenamiento de claves en L1: la información de configuración se guarda en L1 y la billetera en L2 lee la información de configuración a través de L1SLOAD o REMOTESTATICCALL. De esta manera, sólo necesitarás actualizar la configuración en L1 y automáticamente entrará en vigor.
Almacenamiento de claves en L2: la información de configuración se almacena en L2 y la billetera en L2 lee la información de configuración a través de ZK-SNARK. Esto es lo mismo que en el caso (2), excepto que las actualizaciones de almacenamiento de claves son más baratas y las lecturas son más caras.
La tercera solución es particularmente poderosa porque se combina bien con la privacidad. En la "solución de privacidad" ordinaria, suponiendo que el usuario tiene un secreto s y publica un "valor de hoja" L en la cadena, el usuario demuestra que L = hash(s,1) y N = hash(s,2) son Es algún secreto de control (nunca revelado). N se publica para garantizar que los gastos futuros en el mismo Leaf no fallen y L no se revelará. En una solución de privacidad fácil de recuperar cuentas, s es una ubicación en la cadena (como una dirección y una ranura de almacenamiento) y el usuario debe probar la consulta de estado, es decir, L = hash(sload(s), 1) .
Seguridad de aplicaciones DApp
El eslabón más débil en la seguridad del usuario suele ser la DApp. En la mayoría de los casos, los usuarios interactúan con las aplicaciones visitando un sitio web, que 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, el usuario obtiene una copia falsa de la interfaz que lo engaña para que haga cosas arbitrarias. Las funciones de la billetera, como la simulación comercial, son útiles para reducir el riesgo, pero no son suficientes.
Idealmente, necesitamos mover el ecosistema a una versión de contenido en cadena, donde los usuarios accederán a la DApp a través de su nombre ENS, que contendrá el hash IPFS de la interfaz. Para actualizar la interfaz, se requiere una transacción en cadena desde un ID múltiple 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 bloques segura (por ejemplo, etapa 1+, múltiples auditorías de seguridad).
Para los usuarios preocupados por la privacidad, la billetera también podría ser un poco más difícil y requerir que los usuarios hagan clic para aceptar solicitudes HTTP, no solo operaciones Web3.
Un enfoque más avanzado es ir más allá de HTML + Javascript y escribir la lógica empresarial de la DApp en un lenguaje dedicado, como superponer un lenguaje relativamente liviano sobre Solidity o Vyper. De esta manera, el navegador puede generar automáticamente la interfaz de usuario para cualquier funcionalidad requerida. OKContract ya hace esto. Otra dirección es la defensa de la información económica cifrada, es decir, los desarrolladores de DApp, las empresas de seguridad, los implementadores en cadena y otros pueden configurar un depósito. Si la DApp es pirateada o daña a los usuarios de una manera altamente engañosa, el depósito será posterior al. Si el DAO gobernante en cadena toma una decisión, se pagará a los usuarios afectados. Las billeteras pueden mostrar a los usuarios una calificación basada en el tamaño del margen.
futuro a largo plazo
Todo lo anterior se hace en un contexto tradicional y actualmente estamos al borde de cambios profundos en el modelo:
La inteligencia artificial (IA) puede transformarnos de un modelo de "hacer clic y escribir" a un modelo de "decir y el robot lo descubre".
Interfaz cerebro-computadora: incluye métodos relativamente “suaves” como el seguimiento ocular, así como tecnologías más directas e incluso invasivas (como el primer paciente de Neuralink)
Participación del lado del cliente en defensa proactiva: Brave Browser protege proactivamente a los usuarios de anuncios, rastreadores y muchos otros objetos no deseados. Muchos navegadores, complementos y carteras de criptomonedas cuentan con equipos completos que trabajan activamente para proteger a los usuarios de diversas amenazas a la seguridad y la privacidad. En los próximos diez años, estos "guardianes activos" serán aún más poderosos.
En conjunto, estas tres tendencias provocarán un replanteamiento más profundo de cómo funcionan las billeteras. A través de la entrada de lenguaje natural, el seguimiento ocular o, eventualmente, una identificación biométrica (BCI) más directa, junto con el conocimiento del historial del usuario, la "billetera" puede saber intuitivamente exactamente lo que el usuario quiere hacer. Luego, la IA puede traducir esta intuición en un "plan de acción" específico, como una serie de interacciones dentro y fuera de la cadena, para lograr la intención del usuario. Esto puede reducir en gran medida la necesidad de interfaces de usuario de terceros. Si el usuario interactúa con una aplicación de terceros (u otro usuario), la IA también debe pensar de manera adversa en nombre del usuario, identificando cualquier amenaza y sugiriendo un plan de acción para evitarla. Idealmente, estas IA formarán un ecosistema abierto, generado por diversos grupos con diferentes sesgos y estructuras de incentivos.
Por supuesto, estas ideas más radicales se basan en tecnologías que actualmente son extremadamente inmaduras, por lo que no colocaría mis activos en una billetera que dependa de estas tecnologías. Sin embargo, este tipo de tecnología parece ser la ola del futuro, por lo que vale la pena empezar a explorar más activamente en esta dirección.
