fix regressions

Author: corwintines

public/content/translations/fr/developers/docs/scaling/state-channels/index.md

@@ -161,5 +161,5 @@ Les timelocks donnent aux utilisateurs un certain temps pour quitter le système
 - [L'état des mises à jour des contrats intelligents](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) par Santiago Palladino
 - [Plusieurs façons de mettre à jour un contrat intelligent Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Blog Crypto Market Pool
 - [ Apprendre à mettre à jour un contrat intelligent](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin Docs
-- <0>La méthode proxy pour mettre à jour les contrats en Solidity : Proxy Transparent vs UUPS</0> par Naveen Samu
+- [La méthode proxy pour mettre à jour les contrats en Solidity : Proxy Transparent vs UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) par Naveen Samu
 - [Comment les mises à jour en diamant fonctionnent ?](https://dev.to/mudgen/how-diamond-upgrades-work-417j) par Nick Mudge

public/content/translations/fr/developers/docs/smart-contracts/upgrading/index.md

@@ -70,7 +70,7 @@ Le processus traditionnel de vérification des contrats peut être complexe. C'e
 
 ### Etherscan {#etherscan}
 
-Bien que principalement connu comme un [explorateur de la blockchain Ethereum](/developers/docs/data-and-analytics/block-explorers/), Etherscan propose également un [service de vérification de source code ](https://etherscan.io/verifyContract) pour les développeurs et les utilisateurs de contrats intelligents.
+Bien que principalement connu comme un [explorateur de la blockchain Ethereum](/developers/docs/data-and-analytics/block-explorers/), Etherscan propose également un [service de vérification de source code](https://etherscan.io/verifyContract) pour les développeurs et les utilisateurs de contrats intelligents.
 
 Etherscan vous permet de recompiler le bytecode du contrat à partir de la charge utile des données originales (code source, adresse de la bibliothèque, paramètres du compilateur, adresse du contrat, etc.) Si le bytecode recompilé est identifié comme étant identique au bytecode (et les paramètres du constructeur) du contrat en chaîne, alors [le contrat est vérifié](https://info.etherscan.com/types-of-contract-verification/).
 

public/content/translations/fr/developers/docs/smart-contracts/verifying/index.md

@@ -13,7 +13,7 @@ Certaines parties de la feuille de route ne sont pas nécessairement requises po
 
 Une partie de la sécurisation de la [cryptographie](/glossary/#cryptography) actuelle d'Ethereum sera compromise lorsque le calcul quantique deviendra une réalité. Bien que les ordinateurs quantiques soient probablement à des décennies de constituer une véritable menace pour la cryptographie moderne, Ethereum est construit pour être sécurisé pour les siècles à venir. Cela signifie rendre [Ethereum quantique résistant](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) dès que possible.
 
-Le défi auquel sont confrontés les développeurs d'Ethereum est que le protocole actuel de [preuve d'enjeu ](/glossary/#pos)repose sur un système de signature très efficace connu sous le nom de BLS pour regrouper les votes sur les [blocs](/glossary/#block) valides. Ce schéma de signature est rompu par les ordinateurs quantiques, mais les alternatives de résistance quantique ne sont pas aussi efficaces.
+Le défi auquel sont confrontés les développeurs d'Ethereum est que le protocole actuel de [preuve d'enjeu](/glossary/#pos)repose sur un système de signature très efficace connu sous le nom de BLS pour regrouper les votes sur les [blocs](/glossary/#block) valides. Ce schéma de signature est rompu par les ordinateurs quantiques, mais les alternatives de résistance quantique ne sont pas aussi efficaces.
 
 Les [schémas d'engagement « KZG»](/roadmap/danksharding/#what-is-kzg) utilisés à plusieurs endroits à travers Ethereum pour générer des secrets cryptographiques sont connus pour être vulnérables. Actuellement, cela est contourné en utilisant des « configurations de confiance » où de nombreux utilisateurs génèrent un aléa qui ne peut pas être inversé par un ordinateur quantique. Cependant, la solution idéale serait simplement d'intégrer la cryptographie quantique sûre. Il y a deux approches principales qui pourraient devenir des remplacements efficaces pour le schéma BLS : la signature [basée sur le STARK](https://hackmd.io/@vbuterin/stark_aggregation) et la signature [basée sur le treillis](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **Ils sont encore en cours de recherche et de prototype**.
 

public/content/translations/fr/roadmap/future-proofing/index.md

@@ -30,7 +30,7 @@ title="Résumé de l'émission d'ETH">
 
 ### Émission de la couche d'exécution {#el-issuance-pre-merge}
 
-En preuve de travail, les mineurs n'interagissaient qu'avec la couche d'exécution et étaient récompensés par des récompenses de bloc, si et seulement s'ils étaient les premiers mineurs à résoudre le nouveau bloc. Depuis [la mise à jour Constantinople ](/history/#constantinople) en 2019, cette récompense était de 2 ETH par bloc. Les mineurs étaient également récompensés pour la publication de blocs [oncle](/glossary/#ommer), qui étaient des blocs valides mais qui n'avaient pas abouti à la chaîne la plus longue/canonique. Ces récompenses étaient plafonnées à 1,75 ETH par bloc oncle et _s'ajoutaient à_ la récompense émise à partir du bloc canonique. Le processus de minage était une activité économiquement intensive, qui nécessitait historiquement des niveaux élevés d'émission d'ETH pour être soutenu.
+En preuve de travail, les mineurs n'interagissaient qu'avec la couche d'exécution et étaient récompensés par des récompenses de bloc, si et seulement s'ils étaient les premiers mineurs à résoudre le nouveau bloc. Depuis [la mise à jour Constantinople](/history/#constantinople) en 2019, cette récompense était de 2 ETH par bloc. Les mineurs étaient également récompensés pour la publication de blocs [oncle](/glossary/#ommer), qui étaient des blocs valides mais qui n'avaient pas abouti à la chaîne la plus longue/canonique. Ces récompenses étaient plafonnées à 1,75 ETH par bloc oncle et _s'ajoutaient à_ la récompense émise à partir du bloc canonique. Le processus de minage était une activité économiquement intensive, qui nécessitait historiquement des niveaux élevés d'émission d'ETH pour être soutenu.
 
 ### Émission de la couche de consensus {#cl-issuance-pre-merge}