Je viens d’arriver à Mumbai ! J’ai hâte de retrouver des visages familiers et de nouveaux visages, ainsi que tous les merveilleux projets liés à Ethereum et aux technologies ouvertes, sécurisées, privées et décentralisées sur lesquels tout le monde travaille cette semaine.

Finalement, les précompilations et la EVM ne sont pas les bons endroits pour intégrer la plupart des fonctionnalités cryptographiques dans Ethereum. La raison est que les précompilations et la EVM opèrent sur des données qui doivent être incluses d’une manière ou d’une autre dans la chaîne ethereum, ce qui signifie concrètement incluses dans un bloc sous forme de calldata. Cet espace est limité — même avec PeerDAS et les blocs-dans-les-blobs, il existe une limite pratique d’environ 8 Mo/s avant que cela ne devienne inconfortable. Rappelez-vous : ce n’est pas une blockchain. C’est un ordinateur cryptographique mondial. Toute donnée ou calcul qui n’a pas besoin d’être dans le « fil principal » de données/execution ne doit pas être placé dans ce fil principal. La solution correcte est... le maximalisme de l’EIP-8288. Si vous avez un calcul lourd et autonome, effectuez-le et générez un STARK côté client (cela devient de plus en plus rapide, même sur les téléphones), puis transmettez le STARK via le mécanisme d’agrégation récursive de l’EIP-8288. La chaîne ne voit que le fait que le calcul a été effectué et quel en est le résultat ; elle n’a jamais besoin de voir les données ou le calcul réels. Ainsi, chacun peut utiliser n’importe quelle cryptographie qu’il souhaite, la chaîne Ethereum peut rester légère, et nous n’aurons jamais besoin d’ajouter davantage de précompilations.

Fun fact du jour : Le coût de l'exploitation du bitcoin est réparti à peu près à 50/50 entre les dépenses en capital informatiques et l'électricité. En revanche, l'inférence IA est presque entièrement dominée par les dépenses en capital informatiques. https://t.co/PCFKZSuNRw

Wrapped zkAPI + Tor + trafic de couverture supplémentaire + réécriture locale des invites LLM dans un démon compatible OpenAI, et j’ai créé un wrapper « mode paranoïaque » pour mon agent (pi) : Chaque conversation se voit attribuer un circuit Tor distinct, vos demandes sont masquées avec un trafic de couverture aléatoire, zkAPI garantit que vous ne révélez pas votre identité via les paiements, et toutes les invites sont réécrites localement (apportez-votre-propre-modèle-local ; j’utilise qwen3.8-flash-next). https://t.co/MepCFCrLv1 Mon agent est encapsulé dans un sandbox bwrap (j’expérimente également avec MicroVM) et à nouveau encapsulé avec torsocks, de sorte que tout ce qu’il fait passe par Tor. Voici à quoi ressemble ma demande à l’agent pour effectuer une tâche de recherche simple. Il devient assez utilisable ! Bien que vous payiez encore considérablement en latence accrue, surtout au démarrage d’une nouvelle conversation. De plus, Tor n’est pas optimal ici pour la vie privée ; le mécanisme de trafic de couverture est acceptable contre les adversaires passifs, mais beaucoup plus faible si le fournisseur d’LLM collabore avec le gardien et manipule activement les délais. Ce type de tâche nécessite vraiment un mixnet plus spécialisé, probablement en acceptant le compromis d’un multiplicateur de bande passante plus élevé et d’un trafic de couverture constant intégré. En outre, des coûts de gaz beaucoup plus faibles pour les dépôts et retraits zkAPI arriveront prochainement sur le mainnet.

Correction : pour les multisigs, la règle idéale « sécurisée » est que chaque signataire doit changer sa clé après chaque opération. (Cela suppose implicitement que l’ECDSA pourrait devenir faible, mais pas au point qu’une faille quelconque soit littéralement instantanée, auquel cas vous devriez vous inquiéter par exemple d’un frontrunning en mempool.) Vous souhaitez toujours regrouper les signatures hors ligne si possible, pour minimiser le nombre d’heures entre « signature révélée » et « clé non active ». Mais encore une fois : il est très facile de perdre des fonds à cause d’une mise à niveau précipitée mal configurée, donc... ne précipitez rien.

Je ne recommande à personne de se précipiter pour déplacer ses fonds vers de nouveaux wallets aujourd’hui. Mais nous devons prendre au sérieux les risques pour la cryptographie posés par les mathématiques accélérées par l’IA, et minimiser notre exposition non seulement à la cryptographie vulnérable aux ordinateurs quantiques, mais aussi à la cryptographie potentiellement vulnérable à l’IA. Le nouveau domaine de risque principal, malheureusement, est : ML-DSA / FHE / réseaux. (c’est aussi une autre raison, avec le quantique, pour laquelle ECDSA pourrait tomber plus vite que prévu, d’où la recommandation d’« adresse fraîche ») Jusqu’à présent, la plupart des gens pensaient : « les courbes elliptiques cassées, les fonctions de hachage sûres, les réseaux sûrs ». Mais il est très probable que la sécurité concrète des réseaux subisse de sérieux revers au cours des deux prochaines années grâce aux mathématiques accélérées par l’IA. Le modèle de menace de base est le suivant : la factorisation prend naïvement 2^(n/2) unités de temps, mais au fil des décennies, des personnes intelligentes ont trouvé et optimisé les crible de corps de nombres, réduisant cela à 2^O(n^(1/3)), ce qui explique pourquoi les clés et signatures RSA doivent faire ~400 octets (et non 64 octets). Et si des éléments cachés similaires existaient aussi pour les courbes elliptiques et les réseaux, que nous ne sommes tout simplement pas assez intelligents pour découvrir — mais que les bots découvriront bientôt ? C’est une partie majeure de la raison pour laquelle, au cours de la dernière année, la feuille de route allégée d’ethereum a progressé dans la direction « hash uniquement » : pas de réseaux, pas de ML-DSA, pas de Falcon, pas d’engagements basés sur les réseaux dans les preuves ZK, etc. Les signatures dans ethereum allégé sont toutes basées sur le hachage, soit WOTS, soit SPHINCS-. Pour les signatures et les preuves, nous savons déjà comment passer entièrement au hachage. Le défi plus important concerne le *chiffrement à clé publique* — et cela va bien au-delà des blockchains. La communication sécurisée, les protocoles d’anonymisation, beaucoup d’applications nécessitent un chiffrement à clé publique. Malheureusement, il existe des théorèmes mathématiques bien établis montrant pourquoi le chiffrement à clé publique ne peut pas être réalisé uniquement avec des fonctions de hachage. Il faut nécessairement un objet à trappe possédant au moins une forme de « structure » utilisable — soit la théorie des groupes (y compris les isogénies), soit des réseaux, soit basé sur les codes, ou potentiellement dans le futur des choses encore plus nouvelles et étranges (mélange local ?). Mais pour tout ce qui possède une structure, vous devez supposer que l’IA fera au moins quelques progrès pour briser cette structure. Ici, une inférence raisonnable est que si vous voulez rendre quelque chose plausiblement sécurisé à long terme, multipliez les tailles de clés par 10. Pour moi, c’est un monde très plausible et pas du tout extrême à prédire. Si l’IA nous apporte 50 ans de mathématiques en 2 ans, alors ces 50 ans de mathématiques incluront très probablement une amélioration du type « factorisation naïve → GNFS » pour notre capacité à casser les réseaux. Dans ce monde, les réseaux existeront toujours, mais ils devront être significativement plus grands pour garantir le même niveau de sécurité. Et à ces nouvelles tailles plus grandes, les constructions basées sur le hachage surpasseront les constructions basées sur les réseaux en efficacité concrète dans chaque cas d’usage où les constructions basées sur le hachage sont possibles du tout. Théoriquement, bien sûr, il est possible que les fonctions de hachage soient aussi cassées (par exemple, P = NP impliquerait cela). Mais je pense que P = NP est très peu probable. Et intuitivement, il est beaucoup plus probable qu’un objet mathématique n’ait aucune structure exploitable (comme c’est l’intention des fonctions de hachage), que qu’il en ait exactement ~3 formes exploitable (pour les courbes elliptiques : associativité, Schoof, paires) et pas une quatrième forme secrète que nous n’avons pas encore découverte et qui dégrade fortement sa sécurité (pour les courbes elliptiques : ECDLP et sécurité des paires). Même chose pour LWE, SVP, RLWE et toute la famille des problèmes de réseaux. Pour cette raison, nous ne voyons pour l’instant aucune raison de nous inquiéter et de commencer à augmenter la taille en octets des fonctions de hachage (si nous commençons à nous inquiéter davantage, nous augmenterions d’abord le nombre de tours avant d’agir sur la taille en octets). TLDR concret, mes propres vues personnelles : * Hachage > réseaux, dans les situations où le hachage est possible du tout * Pour tout ce qui est basé sur les réseaux, soyez beaucoup plus paranoïaques sur les tailles des paramètres. Rappelez-vous que les blockchains ne représentent qu’une petite partie de l’histoire de la cryptographie ; ce point s’applique bien au-delà des blockchains et concerne par exemple l’accès aux sites web, la messagerie sécurisée, Tor / VPNs... * Pour les protocoles de confidentialité, privilégiez fortement NE PAS mettre des notes chiffrées sur la chaîne. Envoyez-les plutôt hors chaîne via un mécanisme tiers. * Si ce n’est pas difficile pour vous, conserver vos fonds dans des adresses n’ayant pas encore été utilisées pour effectuer une transaction est une bonne idée. Si c’est facile pour vous, faites-le. **Mais soyez prudent avec les migrations ; j’ai personnellement perdu plus d’argent dans des migrations mal gérées que dans toutes les failles combinées**. * Pour les wallets multisig, effectuer les confirmations hors chaîne est préférable à les effectuer sur chaîne, car ainsi les signatures des wallets signataires ne sont pas exposées publiquement ; si ECDSA tombe face à l’IA beaucoup plus vite que prévu, le multisig « dégrade gracieusement » en un 1-sur-1 où le 1 est la personne qui collectait les signatures — un bien meilleur état que « n’importe qui peut prendre l’argent ». https://t.co/oVjwZog2lL

qwen3.8-flash-next client ethereum 100 Go+ de Wikipedia, Gutenberg et articles scientifiques téléchargés localement quoi d'autre ? (Éliminer la nécessité de services de pinning centralisés dans IPFS est définitivement en haut de la liste des priorités)

C'est un triomphe sous-estimé des développeurs de clients Ethereum que PeerDAS fonctionne désormais depuis près d'un an sans pratiquement aucun problème. PeerDAS représentait une tâche complexe : il s'agit du premier exemple à grande échelle d'une blockchain qui atteint un consensus sur la disponibilité des données sans nécessiter qu'aucun nœud télécharge l'intégralité du bloc. Un consensus décentralisé sans réplication. Et pourtant, cela a fonctionné.

Je déteste la tendance récente de personnes qui continuent clairement de croire à plus de 80 % des croyances fondamentales de l’altruisme efficace, mais qui rejettent l’EA et disent « oh, nous ne sommes certainement pas ça, nous sommes [rebranding] » uniquement de manière stratégique, simplement parce qu’elles sentent que critiquer l’EA est maintenant « tendance ». Il est bien plus honorable de dire simplement : « oui, c’était notre éducation intellectuelle, et ces valeurs continuent d’être nos valeurs fondamentales, et voici les points spécifiques sur lesquels nous sommes en désaccord, ainsi que notre argumentation pour expliquer pourquoi nous pensons que ces points précis constituent le sous-ensemble de l’EA qui a produit ce que vous percevez comme le problème de l’ensemble ». Et donc, je vais dire ceci : Oui, l’altruisme efficace a été une part importante de mon éducation intellectuelle, et ses valeurs fondamentales — la bienveillance envers les autres, le cosmopolitisme et la rigueur dans l’allocation efficace des ressources — continuent de me tenir à cœur. Voici également les points spécifiques sur lesquels je suis en désaccord avec ce que je considère être le sous-ensemble de cette manière de penser qui a le plus échoué : https://t.co/iJYPFNaOgg

Un petit exemple de la thèse centrale d/acc (améliorer la technologie passive de défense améliore la sécurité et, en même temps, améliore la liberté et la plupart des autres propriétés de l’organisation sociale qui nous importent) sont les murs insonorisants. Nous avions auparavant une insonorisation beaucoup plus faible, ainsi que des règles de comportement beaucoup plus restrictives, plus de conflits (à l’intérieur des familles et entre elles), des expulsions, etc. Plus tard, nous avons résolu ce problème en concevant et en déployant de meilleurs murs, et désormais, c’est un problème dont nous devons nous soucier beaucoup moins. Quelles sont les « murs insonorisants » du XXIe siècle que nous n’avons pas encore construits ou suffisamment déployés ?