fix: crowdin syntax errors

Author: wackerow

public/content/translations/fr/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md

@@ -8,7 +8,7 @@ Les voleurs et les saboteurs sont constamment à la recherche d'opportunités po
 
 ## Les prérequis {#prerequisites}
 
-Quelques notions de bases de la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) sont requises. Aussi, cela serait utile d'avoir les notions de compréhension de base des la couche d'incitation [d'Ethereum](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) et de l'algorithme de choix de fourche [, LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper).
+Quelques notions de bases de la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) sont requises. Aussi, cela serait utile d'avoir les notions de compréhension de base des la couche d'incitation [d'Ethereum](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) et de l'algorithme de choix de fourche, [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper).
 
 ## Que veulent les attaquants ? {#what-do-attackers-want}
 

public/content/translations/fr/developers/docs/consensus-mechanisms/pos/index.md

@@ -24,7 +24,7 @@ Alors qu'avec le consensus de preuve de travail, la fréquence des blocs est dé
 
 Ce qui suit fournit une explication de bout en bout de la façon dont une transaction est exécutée avec la preuve d'enjeu Ethereum (PoS).
 
-1. Un utilisateur crée et [signe une](/developers/docs/transactions/) avec sa clé privée. Ceci est généralement géré par un portefeuille ou une bibliothèque telle que l'éther [. s](https://docs.ethers.io/v5/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc mais sous le capuchon l'utilisateur fait une requête à un noeud en utilisant l'API [JSON-RPC](/developers/docs/apis/json-rpc/). L'utilisateur définit la quantité de gaz qu'il est prêt à payer comme un pourboire au validateur pour l'encourager à inclure la transaction dans un bloc. Les [pourboires](/developers/docs/gas/#priority-fee) sont payés au validateur alors que les [frais de base](/developers/docs/gas/#base-fee) sont brûlés.
+1. Un utilisateur crée et signe une [transaction](/developers/docs/transaction/) avec sa clé privée. Ceci est généralement géré par un portefeuille ou une bibliothèque telle que [l'éthers.js](https://docs.ethers.io/v5/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc mais sous le capuchon l'utilisateur fait une requête à un noeud en utilisant l'API [JSON-RPC](/developers/docs/apis/json-rpc/). L'utilisateur définit la quantité de gaz qu'il est prêt à payer comme un pourboire au validateur pour l'encourager à inclure la transaction dans un bloc. Les [pourboires](/developers/docs/gas/#priority-fee) sont payés au validateur alors que les [frais de base](/developers/docs/gas/#base-fee) sont brûlés.
 2. La transaction est soumise à un client d'exécution [Ethereum](/developers/docs/nodes-and-clients/#execution-client) qui vérifie sa validité. Cela signifie s'assurer que l'expéditeur a suffisamment d'ETH pour remplir la transaction et qu'il l'a signée avec la bonne clé.
 3. Si la transaction est valide, le client d'exécution l'ajoute à son mempool local (liste des transactions en attente) et le transmet également à d'autres nœuds sur le réseau d'informations de la couche d'exécution. Quand d'autres nœuds reçoivent la transaction, ils l'ajoutent également à leur mempool local. Les utilisateurs avancés peuvent s'abstenir de diffuser leur transaction et la transmettre à des créateurs de blocs spécialisés tels que [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Cela leur permet d'organiser les transactions dans les blocs à venir pour un profit maximal ([MEV](/developers/docs/mev/#mev-extraction)).
 4. Un des nœuds sur le réseau est le bloc proposant pour le créneau actuel, ayant précédemment été sélectionné pseudo-aléatoirement à l'aide de RANDAO. Ce noeud est responsable de la construction et de la diffusion du prochain bloc à ajouter à la blockchain Ethereum et de la mise à jour de l'état global. Le noeud est composé de trois parties : un client d'exécution, un client de consensus et un client validateur. Le client d'exécution relie les transactions depuis le mempool local à une « charge utile d'exécution » et les exécute localement pour générer un changement d'état. Ces informations sont transmises au client de consensus où la charge utile d'exécution est enveloppée dans un « bloc balise » qui contient également des informations sur les récompenses, les pénalités, les réductions, les attestations, etc. qui permettent au réseau de se mettre d'accord sur la séquence de blocs en tête de la chaîne. La communication entre l'exécution et les clients de consensus est décrite plus en détail dans [Connecting the Consensus and Execution Clients](/developers/docs/networking-layer/#connecting-clients).

public/content/translations/fr/roadmap/future-proofing/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/staking/dvt/index.md

@@ -47,8 +47,8 @@ Sans la Technologie DVT, il est plus facile pour les fournisseurs d'actifs de ne
 Une solution DVT contient les éléments suivants :
 
 - **[Le partage secret de Shamir](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - Validateurs utilisant [des clés BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Les partages individuels de clés BLS (key shares) peuvent être combinés en une seule clé agrégée (signature). Dans la Technologie de validation distribuée (DVT), la clé privée d'un validateur est la combinaison de signatures BLS de chaque opérateur à l'intérieur du cluster.
-- **Seuil du schéma de signature** - Détermine le nombre de partages de clés individuelles requis au sujet des droits de signature. Exemple : 3 sur 4.
-- **Génération de clés distribuées (DKG)** - Processus cryptographique qui génère les partages de clé, puis utilisé à distribuer les partages d'une clé de validateur nouvelle ou déjà existante à l'endroit des nœuds d'un cluster.
+- **[Seuil du schéma de signature](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - Détermine le nombre de partages de clés individuelles requis au sujet des droits de signature. Exemple : 3 sur 4.
+- **[Génération de clés distribuées (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - Processus cryptographique qui génère les partages de clé, puis utilisé à distribuer les partages d'une clé de validateur nouvelle ou déjà existante à l'endroit des nœuds d'un cluster.
 - **[Calcul multipartite (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - L'intégralité de la clé du validateur est générée de manière confidentielle via l'apport d'un calcul multipartite sécurisé. L'intégralité de la clé n'est jamais connue par aucun opérateur individuel : chaque opérateur n'a connaissance que de son propre fragment de clé (leur "part").
 - **Protocole de consensus** - Le protocole de consensus sélectionne un nœud qui deviendra le proposant de bloc. Ils partagent ledit bloc avec les autres nœuds du cluster, qui ajoutent leurs fragments de clé à la signature agrégée. Lorsque suffisamment de fragments de clé ont été agrégés, le bloc est proposé sur Ethereum.