No recomiendo que nadie se apresure a mover sus fondos a nuevos monederos hoy. Pero debemos tomar en serio los riesgos para la criptografía provenientes de las matemáticas aceleradas por IA, y minimizar nuestra exposición no solo a la criptografía vulnerable a cuántica, sino también a la criptografía potencialmente vulnerable a IA. El nuevo área central de riesgo desde este punto de vista es, desafortunadamente, ML-DSA / FHE / retículos. (y también es otra razón, junto con la cuántica, por la que ECDSA podría caer incluso más rápido de lo esperado, de ahí la recomendación de "dirección nueva") Hasta ahora, la mayoría de las personas han pensado en términos de "curvas elípticas rotas, hashes seguros, retículos seguros". Pero existe una buena posibilidad de que la seguridad concreta de los retículos sufra fuertes impactos durante los próximos dos años de matemáticas impulsadas por IA. El modelo de amenaza básico es: la factorización es algo que toma, ingenuamente, 2^(n/2) tiempo, pero durante décadas personas inteligentes han encontrado y optimizado tamices de campos numéricos, reduciéndolo a 2^O(n^(1/3)), por eso las claves y firmas RSA necesitan ser ~400 bytes (y no 64 bytes). ¿Y si hay esqueletos en el armario así, tanto para curvas elípticas como para retículos, que simplemente no somos lo suficientemente inteligentes como para descubrirlos —pero los bots lo harán pronto? Esta es una parte fundamental de la razón por la que, durante el último año, la hoja de ruta ligera de ethereum ha avanzado en la dirección "solo hashes": sin retículos, sin ML-DSA, sin Falcon, sin compromisos basados en retículos dentro de pruebas ZK, etc. Las firmas en ethereum ligero son todas basadas en hashes, ya sea WOTS o SPHINCS-. Para firmas y pruebas, ya sabemos cómo ir solo con hashes. El mayor desafío es para el *cifrado de clave pública* —y esto va mucho más allá de las blockchains. La comunicación segura, los protocolos de anonimato, muchas cosas necesitan cifrado de clave pública. Y desafortunadamente existen teoremas matemáticos bien establecidos que muestran por qué el cifrado de clave pública no puede lograrse solo con hashes. Debes tener algún tipo de objeto "trampa" que tenga al menos una forma de "estructura" utilizable —ya sea teoría de grupos (incluyendo isogenias), retículos, basado en códigos o potencialmente en el futuro incluso cosas más novedosas y extrañas (mezcla local?). Pero para cualquier cosa que tenga estructura, debes asumir que la IA logrará al menos algún progreso en romper esa estructura. Aquí, una inferencia razonable es que si quieres hacer algo plausiblemente seguro a largo plazo, multiplica los tamaños de clave por 10. Para mí, ese es un mundo muy plausible y algo nada extremo de predecir. Si la IA nos traerá 50 años de matemáticas en 2 años, entonces esos 50 años de matemáticas muy probablemente incluyan una mejora del nivel "factorización ingenua -> GNFS" en nuestra capacidad para romper retículos. En ese mundo, los retículos seguirán existiendo, pero deberán ser significativamente más grandes para garantizar el mismo nivel de seguridad. Y a esos nuevos tamaños más grandes, las construcciones basadas en hashes superarán a las basadas en retículos en eficiencia concreta en cada caso de uso donde las construcciones basadas en hashes son posibles en absoluto. Teóricamente, por supuesto es posible que los hashes también se rompan (por ejemplo, P = NP implicaría eso). Pero creo que P = NP es muy poco probable. E intuitivamente, es mucho más probable que un objeto matemático tenga exactamente ninguna estructura explotable (como se pretende que tengan los hashes), que que un objeto matemático tenga exactamente ~3 formas de estructura explotable (para curvas elípticas: asociatividad, Schoof, emparejamientos) y no alguna cuarta forma secreta de estructura que aún no hemos descubierto y que degrade enormemente su seguridad (para curvas elípticas, ECDLP y seguridad de emparejamientos). Similar para LWE, SVP, RLWE y el zoo de problemas de retículos. Por esta razón, aún no vemos ninguna razón para preocuparnos y comenzar a aumentar el tamaño en bytes de los hashes (si comenzamos a preocuparnos más, aumentaríamos primero el número de rondas antes de hacer algo al tamaño en bytes). TLDR concreto, mis propias opiniones personales: * Basado en hashes > basado en retículos, en aquellas situaciones donde el basado en hashes es posible en absoluto * Para cualquier cosa basada en retículos, sé mucho más paranoico con los tamaños de parámetros. Recuerda que las blockchains son solo una pequeña parte de la historia criptográfica; este punto va mucho más allá de las blockchains y se aplica a, por ejemplo, acceso a sitios web, mensajería segura, Tor / VPNs... * Para protocolos de privacidad, favorece fuertemente NO poner notas cifradas en la cadena. En su lugar, envíalas fuera de cadena mediante algún mecanismo de terceros. * Si no es difícil para ti, mantener tus fondos en direcciones que aún no se han utilizado para realizar una transacción es una buena idea. Si es fácil para ti, hazlo. **Pero ten cuidado con las migraciones; personalmente he perdido más dinero en migraciones fallidas que en todos los hackeos combinados**. * Para monederos multisig, hacer confirmaciones fuera de cadena es mejor que en cadena, porque así las firmas de las carteras firmantes no se exponen al público; por lo tanto, si ECDSA cae ante IA mucho más rápido de lo esperado, al menos el multisig "degrada elegantemente" a un 1-de-1 donde el 1 es quien esté recolectando las firmas —un lugar mucho mejor que "cualquiera puede tomar el dinero". https://t.co/oVjwZog2lL