Skip to content

Commit 4631a53

Browse files
committed
chore: import translations for fr
1 parent 1e68862 commit 4631a53

File tree

6 files changed

+75
-8
lines changed

6 files changed

+75
-8
lines changed
Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
title: Canaux d'état
3+
description: Une introduction aux canaux d'état et canaux de paiement en tant que solution de mise à l'échelle actuellement utilisée par la communauté Ethereum.
4+
lang: fr
5+
sidebarDepth: 3
6+
---
7+
8+
Les canaux d'État permettent aux participants d'effectuer des transactions hors chaîne en toute sécurité tout en réduisant au minimum l'interaction avec le réseau principal d'Ethereum. Les pairs du canal peuvent effectuer un nombre arbitraire de transactions hors chaîne tout en ne soumettant que deux transactions en chaîne pour ouvrir et fermer le canal. Cela permet un débit de transaction extrêmement élevé et entraîne une réduction des coûts pour les utilisateurs.
9+
10+
## {#how-do-sidechains-work}
11+
12+
Les blockchains publiques, telles qu'Ethereum, sont confrontées à des problèmes d'évolutivité en raison de leur architecture distribuée : les transactions sur la chaîne doivent être exécutées par tous les nœuds. Les nœuds doivent être en mesure de traiter le volume de transactions d'un bloc avec un matériel modeste, ce qui impose une limite au débit des transactions pour que le réseau reste décentralisé.
13+
14+
### {#consensus-algorithms}
15+
16+
Les chaînes sont de simples protocoles de pair à pair qui permettent à deux parties d'effectuer de nombreuses transactions entre elles, puis de ne publier que les résultats finaux sur la blockchain. La chaîne utilise la cryptographie pour démontrer que les données récapitulatives qu'elle génère sont réellement le résultat d'un ensemble valide de transactions intermédiaires. Un [contrat intelligent « multisig »](/developers/docs/smart-contracts/#multisig) garantit que les transactions sont signées par les bonnes parties.
17+
18+
- []()
19+
- []()
20+
-
21+
22+
Avec les canaux, les changements d'état sont exécutés et validés par les parties intéressées, ce qui minimise les calculs sur la couche d'exécution d'Ethereum. Cela réduit la congestion sur Ethereum et augmente la vitesse de traitement des transactions pour les utilisateurs.
23+
24+
#### {#block-parameters}
25+
26+
Chaque canal est géré par un [contrat intelligent multisig](/developers/docs/smart-contracts/#multisig) fonctionnant sur Ethereum. Pour ouvrir un canal, les participants déploient le contrat de canal sur la chaîne et y déposent des fonds.
27+
28+
Pour fermer le canal, les participants soumettent le dernier état convenu du canal sur la chaîne. Ensuite, le contrat intelligent distribue les fonds bloqués en fonction du solde de chaque participant dans l'état final du canal.
29+
30+
Les canaux pair-à-pair sont particulièrement utiles dans les situations où certains participants prédéfinis souhaitent effectuer des transactions à une fréquence élevée sans encourir de frais généraux visibles. Les canaux de la blockchain se divisent en deux catégories : les **canaux de paiement** et les **canaux étatiques**.
31+
32+
### {#evm-compatibility}
33+
34+
La meilleure façon de décrire un canal de paiement est de dire qu'il s'agit d'un « registre à double sens » tenu collectivement par deux utilisateurs. Le solde initial du registre est la somme des dépôts bloqués dans le contrat en chaîne pendant la phase d'ouverture du canal.
35+
36+
Les mises à jour du solde du registre (c'est-à-dire l'état du canal de paiement) nécessitent l'approbation de toutes les parties du canal. Une mise à jour du canal, signée par tous les participants au canal, est considérée comme finalisée, un peu comme une transaction sur Ethereum.
37+
38+
Les canaux de paiement ont été parmi les premières solutions de mise à l'échelle conçues pour minimiser l'activité coûteuse sur la chaîne des interactions simples avec les utilisateurs (par exemple, les transferts d'ETH, les échanges atomiques, les micropaiements). Les participants au canal peuvent effectuer un nombre illimité de transactions instantanées et sans sentiment entre eux, tant que la somme nette de leurs transferts ne dépasse pas les jetons déposés.
39+
40+
En dehors de la prise en charge des paiements hors chaîne, les canaux de paiement ne se sont pas révélés utiles pour gérer la logique générale de transition d'état. Les canaux d'état ont été créés pour résoudre ce problème et rendre les canaux utiles pour la mise à l'échelle du calcul à usage général.
41+
42+
### {#asset-movement}
43+
44+
Les canaux d'état ont encore beaucoup de points communs avec les canaux de paiement. Par exemple, les utilisateurs interagissent en échangeant des messages cryptographiquement signés (transactions), que les autres participants au canal doivent également signer. Si une mise à jour d'état proposée n'est pas signée par tous les participants, elle est considérée comme invalide.
45+
46+
## {#pros-and-cons-of-sidechains}
47+
48+
| | |
49+
| | |
50+
| | |
51+
| | |
52+
| | |
53+
| | |
54+
55+
### {#use-sidechains}
56+
57+
- []()
58+
- []()
59+
- []()
60+
- []()
61+
- []()
62+
63+
## {#further-reading}
64+
65+
-
66+
67+
_ _

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

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -160,6 +160,6 @@ Les timelocks donnent aux utilisateurs un certain temps pour quitter le système
160160

161161
- [L'état des mises à jour des contrats intelligents](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) par Santiago Palladino
162162
- [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
163-
- [Apprendre à mettre à jour un contrat intelligent](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin Docs
164-
- [La méthode proxy pour mettre à jour les contrats en Solidity : Proxy Transparent vs UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) par Naveen Samu
163+
- [ Apprendre à mettre à jour un contrat intelligent](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - OpenZeppelin Docs
164+
- <0>La méthode proxy pour mettre à jour les contrats en Solidity : Proxy Transparent vs UUPS</0> par Naveen Samu
165165
- [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/verifying/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,7 @@ Le processus traditionnel de vérification des contrats peut être complexe. C'e
7070

7171
### Etherscan {#etherscan}
7272

73-
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.
73+
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.
7474

7575
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/).
7676

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ Certaines parties de la feuille de route ne sont pas nécessairement requises po
1313

1414
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.
1515

16-
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.
16+
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.
1717

1818
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**.
1919

public/content/translations/fr/roadmap/index.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,10 +8,10 @@ alt: "Feuille de route d'Ethereum"
88
summaryPoints:
99
buttons:
1010
-
11-
label: Améliorations ultérieures
11+
content: Améliorations ultérieures
1212
toId: what-changes-are-coming
1313
-
14-
label: Améliorations antérieures
14+
content: Améliorations antérieures
1515
href: /history/
1616
variant: outline
1717
---
@@ -112,7 +112,7 @@ La fragmentation est la division de la blockchain Ethereum afin que des sous-ens
112112
- [Danksharding](/roadmap/danksharding) - Le Danksharding rend les rollups de couche 2 bien plus abordables pour les utilisateurs en ajoutant des « blob » de données aux blocs d'Ethereum.
113113
- [Retraits de Staking](/staking/withdrawals) - La mise à niveau Shanghai/Capella a activé les retraits de staking sur Ethereum, permettant aux gens de déverrouiller leurs ETH mis en jeu.
114114
- [Finalité à un seul créneau](/roadmap/single-slot-finality) - Au lieu d'attendre pendant 15 minutes, les blocks pourraient être proposés et finalisés dans le même créneau. Ceci est plus pratique pour les applications et bien plus difficilement attaquable.
115-
- [Séparation Proposeur et Constructeur](/roadmap/pbs) - Découper les tâches de construction et de proposition de blocs entre plusieurs validateurs distincts crée une manière plus équitable, plus résistante à la censure, et plus efficace pour Ethereum d'atteindre le consensus.
115+
- [Séparation Proposeur et Constructeur ](/roadmap/pbs) - Découper les tâches de construction et de proposition de blocs entre plusieurs validateurs distincts crée une manière plus équitable, plus résistante à la censure, et plus efficace pour Ethereum d'atteindre le consensus.
116116
- [Élection secrète du leader](/roadmap/secret-leader-election) - Utilisation astucieuse de la cryptographie pour s'assurer que l'identité du proposeur du bloc courant ne peut pas être rendue publique, le protégeant de certains types d'attaques.
117117
- [Abstraction de compte](/roadmap/account-abstraction) - L'abstraction de compte est une gamme de mises à niveau qui permettent aux contrats de portefeuilles intelligents d'être nativement supportés sur Ethereum, plutôt que de devoir utiliser un intergiciel complexe.
118118
- [Arbres Verkle](/roadmap/verkle-trees) - Les arbres Verkle sont des structures de données qui peuvent être utilisés pour permettre des clients sans état sur Ethereum. Ces clients « sans état » nécessiteront de faibles espaces de stockage mais seront toujours capables de vérifier les nouveaux blocks.

public/content/translations/fr/roadmap/merge/issuance/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ title="Résumé de l'émission d'ETH">
3030

3131
### Émission de la couche d'exécution {#el-issuance-pre-merge}
3232

33-
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.
33+
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.
3434

3535
### Émission de la couche de consensus {#cl-issuance-pre-merge}
3636

0 commit comments

Comments
 (0)