Whenever you optimize a ZK circuit to reduce constraints, you need to be certain that the new version performs the exact same computation as your initial design. While standard testing only validates the specific inputs you anticipate, LLEQ takes a much more comprehensive approach. It delegates the verification to an SMT solver, which logically evaluates every single possible input scenario. For a practical guide on how to execute this workflow, @RaghavMalik15 provides a complete walkthrough.
The team at @aztecnetwork has unveiled a comprehensive post-quantum roadmap that aims for completion by 2030. What makes this timeline particularly interesting is the order of the planned upgrades. They are making it a priority to address the harvest-now-decrypt-later exposure right from the start. Because of this approach, hardened libraries securing private data will be introduced in early 2027, long before any replacements are made to the proof system.
Lorsqu’on envisage la migration du Bitcoin, choisir un schéma de signature post-quantique est en réalité l’étape la moins compliquée. Un récent article sur le post-quantique publié par Coinbase met en lumière un problème bien plus difficile. Les portefeuilles utilisant des schémas à état doivent surveiller attentivement les clés à usage unique qui ont déjà été utilisées. Si un utilisateur restaure une sauvegarde obsolète et réutilise ensuite une clé, un attaquant pourrait alors réussir à forger une signature valide.
Artificial intelligence agents had a massive presence throughout the @token2049 event, where they were showcased handling complex tasks like managing treasuries, executing trades, and drafting contracts. However, amidst all the enthusiasm, a vital conversation was largely overlooked. Hardly anyone addressed the necessity of validating the actual deliverables that these agents produce. Bridging this exact verification shortfall is what our team has been focused on resolving. We look forward to sharing further details with you very shortly.
Au cours d’une journée entière sur place à Singapour, l’équipe de Veridise a eu le plaisir de prendre la parole sur trois scènes bien distinctes. Que ce soit au sommet @solana, lors de @gammaprime ou à Multichain Day, nos échanges ont largement porté sur le ZK, les audits de sécurité et la vérification formelle. Malgré la diversité des lieux, un thème revenait sans cesse. Le public cherchait régulièrement un moyen fiable de vérifier qu’un morceau de code donné fait bien exactement ce que ses spécifications prescrivent.
Si votre feuille de route inclut un audit à venir pour le T4 ou au début de l’année prochaine, @kulm1nski est la personne idéale à consulter concernant le périmètre de votre projet et la planification. Il voyagera à Singapour pour assister à @token2049 du 5 au 9 octobre. Veuillez lui envoyer un DM pour convenir d’un rendez-vous.
Si votre prochaine feuille de route inclut la sécurité et que vous souhaitez en discuter simplement, la semaine prochaine sera l’occasion idéale de prendre contact. @FormallyJon part à Singapour, où il participera à @token2049 et explorera les événements parallèles du 5 au 9 octobre. N’hésitez pas à lui envoyer un message privé pour réserver un créneau de rencontre.
Avec l’introduction des transactions par cadre (Frame Transactions), les comptes auront la possibilité de définir leurs propres lignes directrices d’autorisation spécifiques. Cela signifie que les utilisateurs peuvent mettre en place des règles personnalisées pour des schémas de signature alternatifs, la récupération de compte et des approbations multiples. À la suite de ce changement, la logique opérationnelle qui réside actuellement dans le code de chaque portefeuille sera déplacée directement vers le protocole sous-jacent. Il est important de garder à l’esprit que, lors de cette transition, la surface de défaillance correspondante se déplacera également vers la couche protocolaire.
Avant de partager l’estimation de 63 $ pour une transaction Bitcoin résistante aux attaques quantiques, il est vivement recommandé d’examiner la méthodologie sous-jacente. Comme l’explique clairement @StarkWareLtd, ce montant est un modèle purement théorique et non une facture réelle : aucune véritable transaction n’est donc effectuée. De plus, si les tests de performance ont été réalisés à l’aide de cartes RTX 4090, la projection du coût global repose sur un réseau hypothétique composé de 100 cartes RTX 3090.
Sécuriser une transaction Bitcoin contre les menaces liées à l’informatique quantique est désormais 6 fois plus rapide, grâce au code cryptographique optimisé par l’intelligence artificielle. Bien que la vitesse soit un critère que nous pouvons facilement mesurer, il est impossible d’établir que deux méthodes sont réellement équivalentes sans preuve vérifiable.
La mise à niveau Alpenglow est actuellement testée sur le réseau de test Solana, ce qui permet de réduire de manière impressionnante le temps de finalité, passant de 12,8 secondes à seulement 150 millisecondes. Bien que cette phase garantisse que les validateurs fassent l’objet d’une évaluation approfondie, elle laisse malheureusement certaines intégrations sans vérification. Par conséquent, tout flux de dépôt ou pont qui conserve une confirmation constante calibrée spécifiquement pour 32 slots fonctionne sur l’hypothèse que personne n’a re-dérivé cela.
Dans la toute dernière édition d’Auditor's Take, @FormallyJon examine une classe de vulnérabilité distincte. Le problème principal survient chaque fois qu’une fonction prend des données (calldata) fournies par un appelant et les transmet directement à un appel de bas niveau. Cette configuration permet de déclencher toute action qui est exposée par l’interface de la cible. Cela crée une situation dangereuse, car ce groupe d’opérations précis n’a jamais été conçu intentionnellement par qui que ce soit, et il n’a non plus jamais été audité. Vous pouvez explorer l’analyse complète en visitant le lien ci-dessous.
Bien que la vérification formelle soit très efficace pour signaler qu’une propriété a échoué, elle ne va pas jusqu’à expliquer la raison sous-jacente. Découvrez, avec @ShankaraPailoo2, le processus de traduction d’un contre-exemple simple en une cause racine claire.
Pour une explication étape par étape du fonctionnement, veuillez consulter la démonstration fournie par @RaghavMalik15 ci-dessous. Vous constaterez que Z3 résout avec succès cette obligation de preuve LLZK en moins d’une seconde. En fin de compte, puisque l’antécédent ne peut pas être satisfait, aucune preuve supplémentaire n’est nécessaire.
Une date cible stricte de décembre 2029 a été officiellement établie par Ethereum pour parvenir à la résistance quantique. Fait intéressant, ce calendrier est entièrement piloté par le calendrier de déploiement des mises à jour de protection, plutôt que d’attendre l’apparition effective d’ordinateurs quantiques fonctionnels. Pour atteindre ce jalon, il faudra cinq forks distincts du réseau, chaque phase étant allouée exactement à 7,2 mois. La feuille de route de développement est extrêmement serrée et ne laisse absolument aucune place aux retards. Vous pouvez consulter tous les détails sur https://blog.ethereum.org/2026/09/07/protocol-priorities
Les appels externes constituent la base essentielle du code on-chain, ce qui signifie que leur simple présence ne devrait jamais être considérée comme un signe d’avertissement automatique. Toutefois, il existe exactement 2 situations spécifiques qui indiquent réellement un danger. Le premier problème majeur survient chaque fois qu’une mise à jour de l’état n’a lieu qu’après la fin de l’appel. Le second risque se produit lorsque le contrôle de l’exécution est cédé à un code qui n’a été correctement examiné par personne.
Une fois que vous établissez une équivalence une seule fois, analyser tout autre détail d’un circuit ne relève plus d’un problème ZK. Le processus se transforme alors de manière fluide en une tâche classique de vérification de programme. Ce changement nous permet de réutiliser instantanément des décennies de techniques classiques. Rejoignez @RaghavMalik15 alors qu’il explore cet élément complètement inattendu du LLEQ.
Si vous vous demandez comment 27M$ peuvent sortir d’un système via un simple calcul de récompense, @FormallyJon fournit une analyse claire de la situation. La véritable vulnérabilité provenait d’un défaut sous-jacent dans la logique comptable, qui a conduit à enregistrer deux fois, de manière identique, des tokens distincts. Le système a d’abord reconnu les fonds comme un dépôt que le protocole était tenu de restituer, puis séparément comme une récompense gagnée. Point crucial : ces deux soldes ont été rendus disponibles pour un retrait. Bien qu’une fonction d’exploit de réentrance ait servi de mécanisme de livraison de l’attaque, le bug réel provenait de la comptabilité défectueuse.
Les mises à niveau du réseau sur Mina peuvent contraindre chaque zkApp à mettre à jour sa clé de vérification, une exigence qui fait échouer complètement les configurations de multisig standard lors de son adaptation. Pour relever ce défi, Mina Multisig a mis en place une approche utilisant FROST. Avant que @nori_zk ne publie ce système sur @MinaProtocol, Veridise a effectué une revue approfondie de la solution, et cette évaluation est actuellement documentée sur AuditHub. Le logiciel est désormais entièrement open source, ce qui en fait une excellente ressource pour toute équipe Mina travaillant sur des applications de portefeuille ou des outils d’autoconservation.
L’ensemble de l’idée de se faire auto-conserver a volé en éclats dès lors que les personnes ont été tenues de déposer leurs actifs dans le contrat de dépense pour Rain. Nous avons constaté une perte de 500 000 $ chez Avici, ainsi que 430 000 $ ayant disparu à Tria. Au final, toute affirmation concernant le maintien de la garde devient totalement dénuée de sens si le contrat de routage sur lequel vous vous appuyez comporte une vulnérabilité.