Ethereum
Un contrat qui continue d'exécuter après un appel échoué ne dispose aujourd'hui d'aucun moyen fiable pour déterminer si l'appelé a annulé intentionnellement ou a simplement manqué de gaz, selon le choix de l'expéditeur. Cette lacune est à la racine du griefing par manque de gaz, et une nouvelle proposition en cours de rédaction tente de la résoudre au niveau de l'EVM. EIP-8456, ouverte à la discussion sur Ethereum Magicians lundi, ajoute une instruction appelée CALLSTATUS, provisoirement à l'opcode 0xA5 pour 2 gaz. Elle pousse l'état de terminaison du dernier appel ou création dans le cadre actuel sous forme de trois bits. Le bit 0 signifie un revert, le bit 1 signifie une interruption exceptionnelle telle qu'une absence de gaz, et le bit 2 signifie qu'un élément dans un cadre inférieur s'est arrêté. L'auteur souligne que la seule preuve actuelle repose sur l'arithmétique de gasleft() après l'appel, et que chaque fork de réajustement a rompu ces seuils. Le gaz bidimensionnel proposé par l'EIP-8037 affaiblirait encore davantage cette arithmétique, car son réservoir n'est pas visible via l'opcode GAS. Pourquoi alors un troisième bit ? La plupart des appels réels passent par des intermédiaires tels que des proxies, le wrapper functionCall d'OpenZeppelin, Multicall3 ou les vérificateurs de signature ERC-1271. Si seul le résultat du call direct était rapporté, un wrapper qui attrape une interruption due à un manque de gaz et effectue un revert avec une raison apparaîtrait comme un revert intentionnel. Le projet conserve un drapeau persistant qui remonte chaque cadre, afin qu'un expéditeur ne contrôlant que le gaz ne puisse jamais faire en sorte qu'un appelant lise un revert simple. Il rapporte les résultats plutôt que les causes, et un appelé peut toujours provoquer intentionnellement une interruption avec INVALID. Il ne protège que le code écrit après son déploiement, car les contrats déjà déployés ne le liront pas. Aucun examen externe n'a encore été effectué, le numéro d'opcode est toujours ouvert, et un prototype ainsi que des tests pour les 58 cas listés sont encore en attente. Lien - https://t.co/KnByUBgWrY
La plupart des wallets Ethereum affichent toujours votre historique financier complet à toute personne ayant votre adresse, et la Fondation Ethereum considère désormais cela comme une faille de sécurité, et non comme un avantage de confidentialité supplémentaire. Lundi, la Fondation a indiqué que les attaques et exploitations de la semaine passée leur avaient rendu un point plus clair : la confidentialité et la sécurité ne peuvent pas être traitées comme des objectifs séparés. Leur position est que vous pouvez vous inquiéter moins d’un attaquant utilisant votre historique onchain contre vous lorsque la confidentialité est la norme par défaut. Le post citait une mise à jour sur Kohaku, le projet d’outils de confidentialité de la Fondation. Le dépôt JavaScript le divise en packages que les équipes de wallet peuvent intégrer un par un. Il existe des bibliothèques pour Privacy Pools et Tornado Cash, ainsi qu’une bibliothèque Railgun que le README marque actuellement comme en maintenance. Un package de plugins définit une interface standard pour les protocoles de pool masqués, permettant à un wallet de communiquer avec tous de la même manière. Un package provider abstractise ethers, viem, Helios et Colibri. Le dépôt inclut également un compte ERC-4337 post-quantique. Les crates Rust sont hébergés dans un dépôt sœur séparé. J’aime que cela soit présenté comme un SDK plutôt qu’un autre wallet de confidentialité demandant aux utilisateurs de déplacer leurs fonds. L’idée est que les wallets existants intègrent des flux masqués sans que chaque équipe doive réimplémenter trois protocoles. Le README est franc sur l’état actuel des choses. Certaines parties sont marquées comme non prêtes pour la production, et les packages contiennent du code non audité. Jordan Enev d'Ambire a déclaré vendredi dernier que l’équipe a passé des mois à tester les intégrations, et aucune date de lancement publique n’a été annoncée. Vitalik et Nicolas Consigny sont prévus pour démontrer Kohaku avec Ambire sur le mainnet Ethereum mardi prochain lors de @EFDevcon, selon la liste des sessions. Voici le dépôt - https://t.co/egNbLgAo0J
Votre terminal peut désormais vous répondre à voix haute, et le plus drôle, c’est qu’il le fait sans appeler aucune API cloud. Samedi, Ollama a publié la version 0.40.11 avec la synthèse vocale sur macOS. Le premier modèle vocal est Phonon, une famille de petits modèles TTS développés par Gradium. Vous le téléchargez avec `ollama pull phonon` et vous l’exécutez comme n’importe quel autre modèle. La fonctionnalité qui intéressera réellement les développeurs, c’est l’API. Phonon fonctionne avec le point de terminaison `/v1/audio/speech` compatible OpenAI sur localhost. Si votre code utilise déjà le SDK OpenAI pour la voix, la documentation indique que vous n’avez besoin que d’une nouvelle URL de base. La réponse est diffusée en continu pendant la génération de l’audio, ce qui permet de commencer la lecture avant que tout le texte ne soit terminé. Vous pouvez même rediriger directement la réponse d’un modèle de discussion vers Phonon, qui commence à parler dès la première phrase. La sortie est en 24 kHz mono, au format WAV par défaut ou en PCM brut 16 bits si vous le demandez. La documentation mentionne certaines limites faciles à dépasser. Chaque requête peut contenir jusqu’à 4 096 caractères, bien qu’`ollama run` découpe automatiquement les textes plus longs. Les prix, symboles, adresses e-mail et URLs sont prononcés lettre par lettre, tandis que les dates numériques sont lues telles quelles ; la documentation recommande donc d’écrire les dates en toutes lettres. Les options non prises en charge, comme la vitesse ou les instructions, déclenchent une erreur 400 au lieu d’être silencieusement ignorées. La licence mérite une lecture attentive avant de déployer quoi que ce soit. Le modèle anglais par défaut de Phonon est sous licence Apache 2.0. Les variantes en français, allemand, espagnol, portugais et multilingues (40 Mo) sont sous licence CC BY-NC 4.0, ce qui exclut toute utilisation commerciale. Ollama indique également que sur un MacBook Pro M5 Max, il fonctionne 35 % plus rapidement que le runtime propre à Gradium — ce qui constitue leur propre benchmark et non une évaluation indépendante. Pour l’instant, la synthèse vocale est uniquement disponible sur Apple Silicon, avec une prise en charge pour Windows et Linux prévue prochainement.
Un L2 Ethereum qui accepte des signatures nulles semble être un bug de sécurité, mais BB84 le fait volontairement pour éviter les attaques quantiques. Le week-end dernier, son fondateur, qui poste sous le nom de Hadamard, a publié la conception sur Ethereum Research et a demandé des retours critiques. BB84 est un rollup OP Stack sur mainnet, en ligne depuis le 30 septembre, où les transactions L2 ne comportent aucune ECDSA du tout. Chaque compte est le dernier maillon d'une chaîne de hachage keccak-256 construite à partir d'un secret, avec 1 000 étapes par défaut. Pour dépenser, votre wallet révèle la valeur précédente dans la chaîne, que n'importe qui peut vérifier en effectuant un seul hachage. À l'intérieur du L2, la seule hypothèse restante est la résistance à l’antécédent de keccak-256, que l’algorithme de Grover réduit à environ 2^128 opérations. Révéler un secret le rend public, donc le protocole ajoute une étape de commit et de révélation pour lier chaque antécédent à une transaction unique au préalable. Deux nouveaux types de transactions dans op-geth gèrent cela, et la vérification de l'expéditeur remplace ecrecover. L'autorisation est consommée même si l'appel échoue, et si un wallet manque l'étape de renouvellement sur le dernier maillon, cette adresse est morte. Le post inclut une faille de front-running que l'équipe a découverte pendant son écriture. Les commits ne portent aucune signature, donc un nouveau commit pouvait remplacer un commit en attente, et un attaquant pouvait relier un secret révélé à son propre paiement. Une règle entrée en vigueur le 21 octobre fait gagner le premier commit. Les limites sont clairement énoncées. Les dépôts et retraits L1 utilisent toujours ECDSA. Il n'y a pas encore de preuves de faute, et selon le post lui-même, la chaîne n'atteindrait même pas le Stage 0 de L2BEAT. Le séquenceur est géré par l'équipe, et les adresses sur 160 bits offrent environ 2^80 de résistance quantique aux secondes antécédents. Le post demande également si les comptes en chaîne de hachage pourraient devenir un mode de validation EIP-7702 ou une abstraction native de compte sur les L2 généraux.
OpenZeppelin a rendu Chainlink le choix par défaut pour les opérations interchaînes et la conformité dans ses outils de jetons, et si vous cochez la case de conformité, la licence de votre jeton change. Il y a une semaine, OpenZeppelin a annoncé un partenariat stratégique avec Chainlink. CCIP et ACE, le protocole interchaîne de Chainlink et son moteur de conformité automatisé, sont désormais intégrés au Contracts Wizard, l'outil d'IA d'OpenZeppelin et sa documentation. Les générateurs ERC20, Stablecoin et RWA offrent tous les deux options. Le choix de l'option CCIP expose les appels de création et de brûlage nécessaires au pool de brûlage et de création de Chainlink, derrière les autorisations propres au jeton. Il désigne également un administrateur pour l'enregistrement CCIP. Cette partie conserve la licence que vous avez choisie, car aucun code Chainlink n'est inclus. L'option ACE est différente. Elle redirige les transferts, les créations et les brûlages vers un moteur de politique que vous déploiez et configurez. La documentation d'OpenZeppelin indique que les jetons utilisant ACE relèvent de la licence BUSL-1.1, et leur utilisation en production doit satisfaire à la licence ACE et à ses autorisations d'utilisation supplémentaires. Pendant des années, un jeton généré par OpenZeppelin portait la licence que vous aviez choisie, généralement MIT. Une simple case à cocher change désormais cela, et un développeur junior pressé pourrait ne jamais s'en rendre compte. Le générateur n'enregistre pas votre pool, ne définit pas les autorisations ni ne rédige vos politiques. L'attachement d'un moteur de politique ne configure aucune politique, et vous restez responsable de respecter les règles qui vous concernent. L'annonce mentionne également un chemin de migration depuis OpenZeppelin Defender vers l'environnement d'exécution de Chainlink. Rien de tout cela n'est caché, et pour une équipe RWA déjà orientée vers Chainlink, cela permet d'économiser un réel travail d'intégration. Je souhaite simplement que les développeurs choisissent cette option intentionnellement, et non parce que le wizard l'a placée là.
Smart contract maxis, Votre compilateur Solidity a peut-être silencieusement supprimé un stockage dont vous aviez besoin, sans que vous le voyiez jamais dans votre code source. Solidity 0.8.38 est sortie jeudi dernier. Elle corrige un bug dans l’optimiseur Yul présent dans toutes les versions de 0.8.19 à 0.8.37. L’optimiseur garde une trace de ce qui se trouve en mémoire et en stockage. Il utilise ces informations pour remplacer un chargement par une valeur qu’il connaît déjà, et pour ignorer un stockage qui écrit une donnée déjà présente. Pour déterminer si deux adresses peuvent se chevaucher, il décrit chaque adresse comme une variable de base plus un décalage. Même base, décalage différent : elles doivent donc se trouver dans des emplacements différents. Ces descriptions étaient mises en cache. Puis quelqu’un réaffecte la variable de base. L’optimiseur ne le détecte pas toujours. Il compare maintenant une adresse construite à partir de l’ancienne valeur avec une autre construite à partir de la nouvelle valeur, comme si elles partageaient la même base. Il conclut qu’elles sont différentes, mais à l’exécution, elles pointent vers le même emplacement. Le résultat est une note périmée. Un chargement ultérieur peut renvoyer une ancienne valeur. Un stockage dont vous aviez besoin peut être supprimé. Un keccak256 sur cet emplacement peut hacher des données obsolètes. Seul le code compilé avec l’optimiseur activé est concerné. Avec via-IR, tout code peut être affecté, même sans assembly inline. Avec le pipeline legacy par défaut, uniquement certains fragments d’assembly inline et les fonctions auxiliaires générées par le compilateur. Les builds non optimisés sont sûrs. L’équipe classe ce bug comme de faible gravité, et ils ont fait quelque chose que je souhaite à chaque équipe de compilateur : Ils ont recompilé tous les contrats vérifiés dans la base de données Sourcify avec et sans la correction, et le bytecode était identique pour tous. Ainsi, ce bug est rare. Rare ne signifie pas inexistant, surtout si votre code est récent et non encore déployé. Ce bug a été découvert via le programme de récompense de l’Ethereum Foundation, et un second rapport a montré qu’il peut être déclenché avec du Solidity pur, sans assembly.
L'impulsion masculine d'être un maximaliste ETH. 🥳
Ethereum est Ethereum et le restera pour toujours. Lors du prochain fork, la communauté Ethereum découvrira la véritable magie du protocole.