`nonce``
+Exemple : ``nonce``
`` - _Balise ouvrante, qui contient un extrait de code_
@@ -150,17 +156,17 @@ nonce - _Texte non traduisible_
`` - _Balise fermante_
-
+
Le texte source contient aussi des balises raccourcies. Elles contiennent uniquement des chiffres et leur fonction n'est donc pas directement identifiable. Vous pouvez survoler ces balises pour voir exactement ce à quoi elles servent.
-Dans l'exemple ci-dessous, vous pouvez voir que survoler la balise `<0>` nous permet de savoir qu'elle désigne en fait une balise `` et qu'elle contient un extrait de code. Le contenu de ces balises ne doit donc pas être traduit.
+Dans l'exemple ci-dessous, vous pouvez voir que le survol de la balise `<0>` montre qu'elle représente `` et contient un extrait de code. Par conséquent, le contenu à l'intérieur de ces balises ne doit pas être traduit.
-
+
-## Formes courtes et formes complètes/abréviations {#short-vs-full-forms}
+## Formes courtes ou complètes/abréviations {#short-vs-full-forms}
-De nombreuses abréviations sont utilisées sur le site, comme dApps, NFT, DAO, DeFi, etc. Ces abréviations sont couramment utilisées en anglais et les visiteurs du site web les connaissent généralement.
+De nombreuses abréviations sont utilisées sur le site, par exemple dapps, NFT, DAO, DeFi, etc. Ces abréviations sont couramment utilisées en anglais et les visiteurs du site web les connaissent généralement.
Étant donné qu'elles n'ont souvent pas de traduction établie dans les autres langues, la meilleure façon d'adapter ces termes (ainsi que les termes qui gravitent autour) est de fournir une traduction descriptive de leur forme complète, puis d'ajouter l'abréviation entre parenthèses.
@@ -168,7 +174,7 @@ Ne traduisez pas ces abréviations, car la plupart des gens ne les connaissent p
Exemple de la manière de traduire « dApps » :
-- Applications décentralisées (dApps) → _Forme complète traduite (abréviation anglaise entre parenthèses)_
+- Applications décentralisées (dapps) → _Forme complète traduite (abréviation anglaise entre parenthèses)_
## Termes sans traduction établie {#terms-without-established-translations}
@@ -180,17 +186,17 @@ Lorsque vous traduisez ces termes, soyez créatifs, utilisez des traductions des
**Le fait de traduire ces termes, plutôt que de les laisser en anglais, permettra à cette nouvelle terminologie de se généraliser à l'avenir, à mesure que de plus en plus de personnes utiliseront Ethereum et les technologies associées. Si nous voulons faire connaître ce domaine à plus de personnes à travers le monde, nous devons fournir une terminologie compréhensible dans un maximum de langues, quitte à la créer nous-mêmes.**
-## Boutons & boutons d'appel à l'action {#buttons-and-ctas}
+## Boutons et CTA {#buttons-and-ctas}
Le site contient de nombreux boutons, qui doivent être traduits différemment des autres contenus.
Vous pouvez repérer un bouton et son contenu en visualisant les captures d'écran contextuelles, fournies avec la plupart des textes sources, ou bien en regardant le contexte de l'éditeur, qui inclura le terme « button » (bouton).
-Les traductions des boutons doivent être aussi courtes que possible pour éviter les problèmes de mise en forme. En outre, la traduction des boutons doit être impérative, c'est-à-dire exprimer un ordre ou une demande.
+Les traductions des boutons doivent être aussi courtes que possible pour éviter les problèmes de mise en forme. En outre, la traduction des boutons doit être impérative, c'est-à-dire présenter un ordre ou une demande.
-
+
-## Traduire de façon inclusive {#translating-for-inclusivity}
+## Traduction inclusive {#translating-for-inclusivity}
Les visiteurs d'ethereum.org viennent de partout dans le monde et d'horizons différents. Le langage du site web devrait donc être neutre, accueillant pour tout le monde et inclusif.
@@ -200,7 +206,7 @@ Une autre forme d'inclusivité consiste à faire en sorte que la traduction s'ad
Enfin, le langage doit être adapté à tous les publics et tous les âges.
-## Traductions spécifiques dans une langue {#language-specific-translations}
+## Traductions spécifiques à la langue {#language-specific-translations}
Lors de la traduction, plutôt que de calquer simplement la source, il est important de suivre les règles de grammaire, les conventions et le formatage en vigueur dans votre langue. Le texte source suit les règles et conventions de la grammaire anglaise, qui ne sont pas applicables dans beaucoup d'autres langues.
@@ -208,7 +214,7 @@ Vous devez donc avoir les règles de votre langue en tête afin de traduire corr
Voici quelques exemples de ce à quoi vous devrez faire attention :
-### Ponctuation, mise en forme {#punctuation-and-formatting}
+### Ponctuation et formatage {#punctuation-and-formatting}
**Majuscules**
@@ -216,12 +222,12 @@ Voici quelques exemples de ce à quoi vous devrez faire attention :
- En anglais, il est courant de mettre en majuscule sur la première lettre de tous les mots contenus dans les titres, les noms, les mois, les jours, le nom des langues, les jours fériés, etc. Dans de nombreuses autres langues, c'est grammaticalement incorrect, car les règles sont différentes.
- Certaines langues ont aussi des règles sur la mise en majuscule des pronoms personnels, des noms communs et de certains adjectifs, qui ne portent pas de majuscule en anglais.
-**Espaces**
+**Espacement**
- Les règles orthographiques définissent l'utilisation des espaces pour chaque langue. Ces règles sont souvent très spécifiques, et parce que les espaces sont utilisés partout, ils sont parmi les éléments les plus mal traduits.
- Voici quelques différences d'espacement fréquentes entre l'anglais et d'autres langues :
- - Espace avant les unités de mesure et les devises (ex. USD, EUR, kB, MB)
- - Espace avant le signe de degré (ex. °C, ℉)
+ - Espace avant les unités de mesure et les devises (par ex., USD, EUR, kB, MB)
+ - Espace avant les signes de degré (par ex., °C, ℉)
- Espace avant certains signes de ponctuation, notamment l'ellipse (…)
- Espace avant et après les barres obliques (/)
@@ -229,7 +235,7 @@ Voici quelques exemples de ce à quoi vous devrez faire attention :
- Chaque langue possède un ensemble de règles diverses et variées pour la rédaction des listes. Elles peuvent différer considérablement de l'anglais.
- Dans certaines langues, le premier mot de chaque nouvelle ligne doit avoir sa première lettre en majuscule, tandis que dans d'autres langues, les nouvelles lignes doivent commencer par une lettre minuscule. Plusieurs langues ont aussi différentes règles sur la présence de majuscule en début de ligne, en fonction de la longueur de celle-ci.
-- Il en va de même pour la ponctuation en fin de ligne. Cela peut être un point (**.**), une virgule (**,**) ou un point-virgule (**;**), en fonction de la langue.
+- Il en va de même pour la ponctuation en fin de ligne. La ponctuation finale dans les listes peut être un point (.), une virgule (,) ou un point-virgule (;), selon la langue.
**Guillemets**
@@ -256,7 +262,7 @@ Voici quelques exemples de ce à quoi vous devrez faire attention :
- Anglais – **1,000.50**
- Espagnol – **1.000,50**
- Français – **1 000,50**
-- Une autre chose à prendre en considération lors de la traduction de nombres est le signe pourcentage. Il peut être écrit de différentes manières : **100%**, **100 %** ou encore **%100**.
+- Une autre chose à prendre en considération lors de la traduction de nombres est le signe pourcentage. Il peut être écrit de différentes manières : **100%**, **100 %** ou **%100**.
- Enfin, les nombres négatifs peuvent aussi s'afficher différemment en fonction de la langue : -100, 100-, (100) ou [100].
**Dates**
diff --git a/public/content/translations/fr/dao/index.md b/public/content/translations/fr/dao/index.md
index 962e8abd025..784018ed161 100644
--- a/public/content/translations/fr/dao/index.md
+++ b/public/content/translations/fr/dao/index.md
@@ -1,16 +1,16 @@
---
title: Qu'est-ce qu'une DAO ?
-metaTitle: Qu'est-ce qu'une DAO ? | Organisation autonome et décentralisée
-description: Un aperçu des DAO sur Ethereum
+metaTitle: "Qu'est-ce qu'une DAO ? | Organisation autonome et décentralisée"
+description: "Un aperçu des DAO sur Ethereum"
lang: fr
template: use-cases
emoji: ":handshake:"
sidebarDepth: 2
image: /images/use-cases/dao-2.png
-alt: Une représentation d'une DAO qui vote une proposition.
-summaryPoint1: Des communautés appartenant à leurs membres sans pouvoir centralisé.
-summaryPoint2: Un moyen sûr de collaborer avec des étrangers sur Internet.
-summaryPoint3: Un endroit sûr pour engager des fonds pour une cause précise.
+alt: "Une représentation d'une DAO qui vote une proposition."
+summaryPoint1: "Des communautés appartenant à leurs membres sans pouvoir centralisé."
+summaryPoint2: "Un moyen sûr de collaborer avec des étrangers sur Internet."
+summaryPoint3: "Un endroit sûr pour engager des fonds pour une cause précise."
---
## Que sont les DAO ? {#what-are-daos}
@@ -19,7 +19,7 @@ Une DAO est une organisation collectivement détenue et qui travaille à une mis
Les DAO nous permettent de travailler avec des personnes partageant le même état d'esprit et dans le monde entier, sans pour autant faire confiance à un dirigeant bienveillant pour gérer les fonds ou les opérations. Il n'y a pas de Directeur Général qui puisse dépenser des fonds sur un caprice ou un Chef de la direction financière capable de manipuler les registres. Au lieu de cela, les règles basées sur la blockchain ont été intégrées dans le code et définissent comment fonctionne l'organisation et comment les fonds sont dépensés.
-Elles possèdent une trésorerie intégrée à laquelle personne ne peut accéder sans l'accord du groupe. Les décisions sont régies par des propositions et des votes pour s'assurer que tout le monde au sein de l'organisation puisse s'exprimer et que tout se passe de manière transparente [onchain](/glossary/#onchain).
+Elles possèdent une trésorerie intégrée à laquelle personne ne peut accéder sans l'accord du groupe. Les décisions sont régies par des propositions et des votes pour s'assurer que tout le monde au sein de l'organisation a une voix, et que tout se passe de manière transparente [en chaîne](/glossary/#onchain).
## Pourquoi avons-nous besoin des DAO ? {#why-dao}
@@ -29,19 +29,19 @@ Cela ouvre énormément de nouvelles possibilités de collaboration et de coordi
### Une comparaison {#dao-comparison}
-| DAO | Organisation traditionnelle |
-| --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
-| Habituellement fixe, et pleinement démocratisée. | Généralement hiérarchique. |
-| Vote requis par les membres pour que tout changement soit mis en œuvre. | Selon la structure, des changements peuvent être demandés par une seule personne et le vote peut être biaisé. |
-| Votes comptabilisés et résultats mis en œuvre automatiquement sans intermédiaire de confiance. | Si les votes sont proposés, ils sont calculés en interne et les résultats des votes doivent être traités manuellement. |
+| DAO | Organisation traditionnelle |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| Habituellement fixe, et pleinement démocratisée. | Généralement hiérarchique. |
+| Vote requis par les membres pour que tout changement soit mis en œuvre. | Selon la structure, des changements peuvent être demandés par une seule personne et le vote peut être biaisé. |
+| Votes comptabilisés et résultats mis en œuvre automatiquement sans intermédiaire de confiance. | Si les votes sont proposés, ils sont calculés en interne et les résultats des votes doivent être traités manuellement. |
| Les services offerts sont gérés automatiquement de manière décentralisée (par exemple la distribution de fonds philanthropiques). | Nécessite une manipulation humaine ou une automatisation centralisée sujette à la manipulation. |
-| Toutes les activités sont transparentes et entièrement publiques. | L'activité est généralement privée et limitée au public. |
+| Toutes les activités sont transparentes et entièrement publiques. | L'activité est généralement privée et limitée au public. |
### Exemples de DAO {#dao-examples}
Pour aider votre compréhension, voici quelques exemples de la façon dont vous pourriez utiliser une DAO :
-- **Un organisme caritatif** – vous pouvez accepter les dons de n'importe qui dans le monde entier et voter pour les causes à financer.
+- **Un organisme de bienfaisance** – vous pouvez accepter les dons de n'importe qui dans le monde entier et voter pour les causes à financer.
- **Propriété collective** – vous pouvez acheter des actifs physiques ou numériques et les membres peuvent voter sur la façon de les utiliser.
- **Entreprises et subventions** – vous pouvez créer un fonds de capital-risque qui regroupe le capital d'investissement et vote sur les entreprises à soutenir. L'argent perçu pourra plus tard être redistribué entre les membres de la DAO.
@@ -49,11 +49,11 @@ Pour aider votre compréhension, voici quelques exemples de la façon dont vous
## Comment fonctionnent les DAO ? {#how-daos-work}
-La colonne vertébrale d'une DAO est [son contrat intelligent](/glossary/#smart-contract), qui définit les règles de l'organisation et détient la trésorerie du groupe. Une fois que le contrat est en vigueur sur Ethereum, personne ne peut modifier les règles autrement que par un vote. Si quelqu'un essaie de faire quelque chose qui n'est pas couvert par les règles et la logique dans le code, il échouera. Et, comme la trésorerie est également définie par le contrat intelligent, personne ne peut dépenser l'argent sans l'approbation du groupe. Cela signifie que les DAO n'ont pas besoin d'une autorité centrale. Au lieu de cela, le groupe prend des décisions collectives et les paiements sont autorisés automatiquement lorsque les votes sont passés.
+La colonne vertébrale d'une DAO est son [contrat intelligent](/glossary/#smart-contract), qui définit les règles de l'organisation et détient la trésorerie du groupe. Une fois que le contrat est en vigueur sur Ethereum, personne ne peut modifier les règles autrement que par un vote. Si quelqu'un essaie de faire quelque chose qui n'est pas couvert par les règles et la logique dans le code, il échouera. Et, comme la trésorerie est également définie par le contrat intelligent, personne ne peut dépenser l'argent sans l'approbation du groupe. Cela signifie que les DAO n'ont pas besoin d'une autorité centrale. Au lieu de cela, le groupe prend des décisions collectives et les paiements sont autorisés automatiquement lorsque les votes sont passés.
Ceci est possible parce que les contrats intelligents sont étanches à toute intrusion dès qu'ils sont mis en service sur Ethereum. Vous ne pouvez pas simplement modifier le code (les règles DAO) sans que les gens le remarquent puisque tout est public.
-## Ethereum et DAO {#ethereum-and-daos}
+## Ethereum et les DAO {#ethereum-and-daos}
Ethereum est une base parfaite pour les DAOs pour plusieurs raisons :
@@ -62,7 +62,7 @@ Ethereum est une base parfaite pour les DAOs pour plusieurs raisons :
- Les contrats intelligents peuvent envoyer/recevoir des fonds. Sans cela, vous aurez besoin d'un intermédiaire de confiance pour gérer les fonds de groupe.
- La communauté Ethereum s'est révélée plus coopérative que compétitive, permettant ainsi l'émergence de pratiques exemplaires dotés d'une grande vitesse de développement.
-## Gouvernance de DAO {#dao-governance}
+## Gouvernance des DAO {#dao-governance}
Il existe de nombreuses considérations à prendre en compte au moment de gouverner une DAO, comme le fonctionnement du vote et des propositions.
@@ -70,9 +70,7 @@ Il existe de nombreuses considérations à prendre en compte au moment de gouver
La délégation est la version DAO de la démocratie représentative. Les détenteurs de jetons délèguent des votes aux utilisateurs qui se désignent et s'engagent à gérer le protocole et à rester informés.
-#### Un exemple célèbre {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) – Les détenteurs d'ENS peuvent déléguer leurs votes à des membres de la communauté engagés pour les représenter.
+#### Un exemple célèbre {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – Les détenteurs d'ENS peuvent déléguer leurs votes à des membres engagés de la communauté pour les représenter.
### Gouvernance automatique des transactions {#governance-example}
@@ -80,35 +78,35 @@ Dans de nombreuse DAO, les transactions seront automatiquement exécutées si le
#### Un exemple célèbre {#governance-example}
-[Nouns](https://nouns.wtf) – Dans Nouns DAO, une transaction est automatiquement exécutée si un quorum de votes est atteint et qu'une majorité vote par l'affirmative, tant qu'elle ne fait pas l'objet d'un véto de la part des fondateurs.
+[Nouns](https://nouns.wtf) – Dans la DAO Nouns, une transaction est automatiquement exécutée si un quorum de votes est atteint et qu'une majorité vote par l'affirmative, tant qu'elle ne fait pas l'objet d'un veto de la part des fondateurs.
-### Gouvernance Multisig {#governance-example}
+### Gouvernance multisig {#governance-example}
-Tandis que les DAO peuvent avoir des milliers de membres votants, les fonds peuvent se trouver dans un [portefeuille](/glossary/#wallet) partagé par 5 à 20 membres actifs de la communauté qui sont dignes de confiance et généralement doxxés (identités publiques connues de la communauté). Après un vote, les signataires [multisig](/glossary/#multisig) exécutent la volonté de la communauté.
+Bien que les DAO puissent avoir des milliers de membres votants, les fonds peuvent se trouver dans un [portefeuille](/glossary/#wallet) partagé par 5 à 20 membres actifs de la communauté qui sont dignes de confiance et généralement doxxés (dont les identités publiques sont connues de la communauté). Après un vote, les signataires [multisig](/glossary/#multisig) exécutent la volonté de la communauté.
-## Les lois des DAO {#dao-laws}
+## Lois sur les DAO {#dao-laws}
En 1977, le Wyoming a créé la LLC, qui protège les entrepreneurs et limite leur responsabilité. Plus récemment, ils ont été les pionniers de la loi pour les DAO qui établit un statut juridique pour les DAO. Actuellement, le Wyoming, le Vermont et les Îles Vierges ont des lois portant sur les DAO sous une forme ou une autre.
### Un exemple célèbre {#law-example}
-[CityDAO](https://citizen.citydao.io/) - CityDAO s'est servi de la loi DAO du Wyoming pour acheter 40 acres de terrain près du parc national de Yellowstone.
+[CityDAO](https://citizen.citydao.io/) – CityDAO a utilisé la loi sur les DAO du Wyoming pour acheter 40 acres de terrain près du parc national de Yellowstone.
-## Adhésion à la DAO {#dao-membership}
+## Adhésion à une DAO {#dao-membership}
Il existe différents modèles pour adhérer à une DAO. L'adhésion peut déterminer comment fonctionne le vote et d'autres éléments clés de la DAO.
-### Adhésion basée sur des jetons {#token-based-membership}
+### Adhésion basée sur les jetons {#token-based-membership}
-Habituellement cela se fait totalement [sans permission](/glossary/#permissionless), seulement en fonction du jeton utilisé. La plupart de ces jetons de gouvernance peuvent être échangés sans permission sur un [échange décentralisé](/glossary/#dex). D’autres doivent être gagnés en fournissant des liquidités ou une autre « preuve de travail ». Quoi qu’il en soit, il suffit de détenir le jeton pour avoir accès au vote.
+Généralement entièrement [sans permission](/glossary/#permissionless), en fonction du jeton utilisé. La plupart de ces jetons de gouvernance peuvent être échangés sans permission sur un [échange décentralisé](/glossary/#dex). D’autres doivent être gagnés en fournissant des liquidités ou une autre « preuve de travail ». Quoi qu’il en soit, il suffit de détenir le jeton pour avoir accès au vote.
_Généralement, cela est utilisé pour régir des protocoles décentralisés et/ou des jetons eux-mêmes._
#### Un exemple célèbre {#token-example}
-[MakerDAO](https://makerdao.com) – Le jeton MKR de MakerDAO est largement disponible sur les échanges décentralisés et tout le monde peut acheter un droit de vote sur le futur du protocole Maker.
+[MakerDAO](https://makerdao.com) – Le jeton MKR de MakerDAO est largement disponible sur les échanges décentralisés et n'importe qui peut en acheter pour avoir un droit de vote sur l'avenir du protocole Maker.
-### Adhésion basée sur les actions {#share-based-membership}
+### Adhésion par actions {#share-based-membership}
Les DAO basées sur le partage sont davantage soumises à l'autorisation, mais demeurent assez ouvertes. Tous les membres potentiels peuvent soumettre une proposition pour rejoindre la DAO, offrant habituellement une contribution d'une certaine valeur sous la forme de jetons ou de travail. Les actions représentent le droit de vote direct et la propriété. Les membres peuvent sortir à tout moment avec leur part proportionnelle de la trésorerie.
@@ -116,51 +114,53 @@ _Habituellement utilisé pour des organisations plus proches et axées sur l'asp
#### Un exemple célèbre {#share-example}
-[MolochDAO](http://molochdao.com/) – MolochDAO se concentre sur le financement de projets Ethereum. Ils requièrent une proposition d’adhésion afin que le groupe puisse évaluer si vous avez l’expertise et le capital nécessaires pour émettre des jugements éclairés sur les bénéficiaires potentiels. Vous ne pouvez pas vous contenter d'acheter l'accès à la DAO sur le marché ouvert.
+[MolochDAO](http://molochdao.com/) – MolochDAO se concentre sur le financement des projets Ethereum. Ils requièrent une proposition d’adhésion afin que le groupe puisse évaluer si vous avez l’expertise et le capital nécessaires pour émettre des jugements éclairés sur les bénéficiaires potentiels. Vous ne pouvez pas vous contenter d'acheter l'accès à la DAO sur le marché ouvert.
### Adhésion basée sur la réputation {#reputation-based-membership}
Ici, la réputation représente une preuve de participation et accorde le droit de vote dans la DAO. Contrairement à une adhésion basée sur des jetons ou sur les actions, les DAO basées sur la réputation ne transfèrent pas la propriété aux contributeurs. En effet, la réputation ne peut pas être achetée, transférée ou déléguée ; les membres de la DAO doivent mériter leur réputation par la participation. Le vote sur la chaîne est sans permission, les membres potentiels peuvent librement soumettre des propositions pour rejoindre la DAO et demander à obtenir une réputation et des jetons en guise de récompense en échange de leurs contributions.
-_Habituellement utilisée pour le développement décentralisé et la gouvernance de protocoles et de [DApps](/glossary/#dapp), cette méthode est également adaptée à divers autres types d'organisations, comme les organismes caritatifs, les collectifs de travailleurs, les clubs d'investissement, etc._
+_Généralement utilisée pour le développement décentralisé et la gouvernance des protocoles et des [dapps](/glossary/#dapp), cette méthode convient également à divers types d'organisations, comme les organismes de bienfaisance, les collectifs de travailleurs, les clubs d'investissement, etc._
#### Un exemple célèbre {#reputation-example}
-[DXdao](https://DXdao.eth.limo) - DXdao est une construction collective mondiale souveraine et régit des protocoles et applications décentralisés depuis 2019. DXdao tire parti d'une gouvernance basé sur la réputation et du [consensus holographique](/glossary/#holographic-consensus) pour coordonner et gérer les fonds, ce qui signifie que personne ne pourrait faire en sorte d'influencer son futur ou sa gouvernance.
+[DXdao](https://DXdao.eth.limo) – DXdao était un collectif souverain mondial qui créait et gouvernait des protocoles et des applications décentralisés depuis 2019. Elle a tiré parti de la gouvernance basée sur la réputation et du [consensus holographique](/glossary/#holographic-consensus) pour coordonner et gérer les fonds, ce qui signifie que personne ne pouvait acheter son influence sur son avenir ou sa gouvernance.
-## Rejoindre/démarrer une DAO {#join-start-a-dao}
+## Rejoindre / créer une DAO {#join-start-a-dao}
-### Rejoindre une organisation autonome décentralisée (DAO) {#join-a-dao}
+### Rejoindre une DAO {#join-a-dao}
- [DAO de la communauté Ethereum](/community/get-involved/#decentralized-autonomous-organizations-daos)
-- [Liste des DAO de DAOHauss](https://app.daohaus.club/explore)
-- [Liste des DAO Tally.xyz](https://www.tally.xyz)
+- [Liste de DAO de DAOHaus](https://app.daohaus.club/explore)
+- [Liste de DAO de Tally.xyz](https://www.tally.xyz/explore)
+- [Liste de DAO de DeGov.AI](https://apps.degov.ai/)
-### Démarrer une DAO {#start-a-dao}
+### Créer une DAO {#start-a-dao}
-- [Invoquer une DAO avec DAOHaus](https://app.daohaus.club/summon)
-- [Lancer une Governor DAO avec Tally](https://www.tally.xyz/add-a-dao)
+- [Créer une DAO avec DAOHaus](https://app.daohaus.club/summon)
+- [Créer une Governor DAO avec Tally](https://www.tally.xyz/get-started)
- [Créer une DAO propulsée par Aragon](https://aragon.org/product)
- [Lancer une colonie](https://colony.io/)
- [Créer une DAO avec le consensus holographique de DAOstack](https://alchemy.daostack.io/daos/create)
+- [Lancer une DAO avec le DeGov Launcher](https://docs.degov.ai/integration/deploy)
-## Complément d'information {#further-reading}
+## En savoir plus {#further-reading}
-### Articles DAO {#dao-articles}
+### Articles sur les DAO {#dao-articles}
- [Qu'est-ce qu'une DAO ?](https://aragon.org/dao) – [Aragon](https://aragon.org/)
-- [La maison des DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
-- [Qu'est-ce qu'une DAO et à quoi sert-elle ?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
-- [Comment démarrer une communauté numérique DAO](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
+- [House of DAOs](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/)
+- [Qu'est-ce qu'une DAO et à quoi ça sert ?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/)
+- [Comment démarrer une communauté numérique alimentée par une DAO](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/)
- [Qu'est-ce qu'une DAO ?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com)
-- [Qu'est-ce que le Consensus holographique ?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
-- [Les DAO ne sont pas des entreprises : là où la décentralisation dans les organisations autonomes compte, par Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html)
-- [DAO, DAC, DA et plus : un guide terminologique incomplet](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [Blog Ethereum](https://blog.ethereum.org)
+- [Qu'est-ce que le consensus holographique ?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) - [DAOstack](https://daostack.io/)
+- [Les DAO ne sont pas des entreprises : où la décentralisation dans les organisations autonomes est importante, par Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html)
+- [DAO, DAC, DA et plus encore : un guide terminologique incomplet](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) - [Blog Ethereum](https://blog.ethereum.org)
### Vidéos {#videos}
-- [Qu'est-ce qu'une DAO en cryptomonnaie ?](https://youtu.be/KHm0uUPqmVE)
-- [Une DAO peut-elle bâtir une ville ?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
+- [Qu'est-ce qu'une DAO en crypto ?](https://youtu.be/KHm0uUPqmVE)
+- [Une DAO peut-elle construire une ville ?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/)
- Explorer la DeFi
+ Explorer les applications DeFi
## Et si on commençait avec Bitcoin... {#bitcoin}
Bitcoin à bien des égards a été la première application de la DeFi. Bitcoin vous permet de posséder et de contrôler la valeur et de l'envoyer partout dans le monde. Il le fait en fournissant un moyen à un grand nombre de personnes, qui ne se font pas confiance les unes aux autres, de se mettre d'accord sur un grand livre de comptes sans avoir besoin d'un intermédiaire de confiance. Le Bitcoin est ouvert à tout le monde et personne n'a l'autorité nécessaire pour modifier ses règles. Les règles du Bitcoin, comme sa rareté et son ouverture, sont inscrites dans la technologie. Ce n'est pas comme la finance traditionnelle où les gouvernements peuvent imprimer de l'argent qui déprécie vos épargnes et où les entreprises peuvent fermer les marchés.
-L'Ethereum s'appuie sur cela. Comme le Bitcoin, les règles ne peuvent pas changer et tout le monde y a accès. Mais cela rend aussi cet argent numérique programmable, en utilisant des [contrats intelligents](/glossary/#smart-contract), vous pouvez donc aller au-delà du stockage et de la valeur d'envoi.
+L'Ethereum s'appuie sur cela. Comme le Bitcoin, les règles ne peuvent pas changer et tout le monde y a accès. Mais cela rend également cette monnaie numérique programmable à l'aide de [contrats intelligents](/glossary/#smart-contract), ce qui permet d'aller au-delà du simple stockage et envoi de valeur.
+
Explorez nos suggestions pour les applications de la DeFi pour essayer si vous êtes nouveau sur Ethereum.
- Explorer la DeFi
+ Explorer les applications DeFi
@@ -78,37 +78,37 @@ Cela semble étrange... « pourquoi je voudrais programmer mon argent » ? Cepen
Il existe une alternative décentralisée à la plupart des services financiers. Mais Ethereum crée également des opportunités de création de produits financiers totalement nouveaux. Cette liste ne cesse de croître.
-- [Envoyer de l'argent partout dans le monde](#send-money)
-- [Diffuser de l'argent dans le monde entier](#stream-money)
-- [Accéder aux devises stables](#stablecoins)
+- [Envoyer de l'argent dans le monde entier](#send-money)
+- [Transférer de l'argent en continu dans le monde entier](#stream-money)
+- [Accéder à des monnaies stables](#stablecoins)
- [Emprunter des fonds avec garantie](#lending)
- [Emprunter sans garantie](#flash-loans)
-- [Démarrer des économies de cryptomonnaies](#saving)
+- [Commencer à épargner en cryptomonnaies](#saving)
- [Échanger des jetons](#swaps)
-- [Développer votre portefeuille](#investing)
+- [Faire fructifier votre portefeuille](#investing)
- [Financer vos idées](#crowdfunding)
-- [Acheter une assurance](#insurance)
+- [Souscrire une assurance](#insurance)
- [Gérer votre portefeuille](#aggregators)
- Voir les applications de paiement
+ Voir les dapps de paiement
#### Diffuser de l'argent partout dans le monde... {#stream-money}
Vous pouvez également diffuser de l'argent sur Ethereum. Cela vous permet de payer à quelqu'un son salaire en une seconde, lui donnant accès, ainsi, à son argent chaque fois qu'il en a besoin. Ou louer quelque chose presque instantanément comme un casier de stockage ou scooter électrique par exemple.
-Et si vous ne voulez pas envoyer ou diffuser des [ETH](/glossary/#ether) en raison de sa volatilité, il existe des devises alternatives sur Ethereum : les [stablecoins](/glossary/#stablecoin).
+Et si vous ne voulez pas envoyer ou streamer de l'[ETH](/glossary/#ether) en raison des fluctuations de sa valeur, il existe des monnaies alternatives sur Ethereum : les [stablecoins](/glossary/#stablecoin).
- Voir les dapp d'emprunt
+ Voir les dapps d'emprunt
Il y a de nombreux avantages à utiliser un prêteur décentralisé...
-#### Emprunter avec confidentialité {#borrowing-privacy}
+#### Emprunter en toute confidentialité {#borrowing-privacy}
Aujourd'hui, le prêt et l'emprunt d'argent tournent autour des personnes impliquées. Les banques doivent savoir si vous êtes susceptible de rembourser un prêt avant de le prêter.
-Les prêts décentralisés fonctionnent sans que l’une ou l’autre des parties n’ait à s’identifier. Au lieu de cela, l'emprunteur doit placer une garantie que le prêteur recevra automatiquement si leur prêt n'est pas remboursé. Certains prêteurs acceptent même les [NFT](/glossary/#nft) comme garanties. Les NFT sont un acte de propriété unique, comme une peinture par exemple. [Plus de détails sur les NFT](/nft/)
+Les prêts décentralisés fonctionnent sans que l’une ou l’autre des parties n’ait à s’identifier. Au lieu de cela, l'emprunteur doit placer une garantie que le prêteur recevra automatiquement si leur prêt n'est pas remboursé. Certains prêteurs acceptent même les [NFT](/glossary/#nft) comme garantie. Les NFT sont un acte de propriété unique, comme une peinture par exemple. [En savoir plus sur les NFT](/nft/)
Cela vous permet d'emprunter de l'argent sans chèques d'acompte et sans remise d'informations privées.
#### Accès aux fonds mondiaux {#access-global-funds}
-Lorsque vous utilisez un prêteur décentralisé, vous avez accès aux fonds déposés du monde entier, pas seulement les fonds détenus par la banque ou l'institution que vous avez choisie. Cela rend les prêts plus accessibles et améliore les taux d'intérêt.
+Lorsque vous utilisez un prêteur décentralisé, vous avez accès aux fonds déposés du monde entier, pas seulement les fonds détenus par la banque ou l'institution que vous avez choisie. Cela rend les prêts plus accessibles et améliore les taux d’intérêt.
-#### Efficacité fiscale {#tax-efficiencies}
+#### Optimisations fiscales {#tax-efficiencies}
-L’emprunt peut vous donner accès aux fonds dont vous avez besoin sans devoir vendre votre ETH (un événement imposable). Au lieu de cela, vous pouvez utiliser ETH comme garantie pour un prêt stablecoin. Cela vous donne le flux de trésorerie dont vous avez besoin et vous permet de garder votre ETH. Les Stablecoins sont des jetons qui sont beaucoup plus intéressant quand vous avez besoin d'argent car ils ne fluctuent pas en valeur comme ETH. [Plus d'infos sur les stablecoins](#stablecoins)
+L’emprunt peut vous donner accès aux fonds dont vous avez besoin sans devoir vendre votre ETH (un événement imposable). Au lieu de cela, vous pouvez utiliser ETH comme garantie pour un prêt stablecoin. Cela vous donne le flux de trésorerie dont vous avez besoin et vous permet de garder votre ETH. Les Stablecoins sont des jetons qui sont beaucoup plus intéressant quand vous avez besoin d'argent car ils ne fluctuent pas en valeur comme ETH. [En savoir plus sur les stablecoins](#stablecoins)
-#### Prêts Flash {#flash-loans}
+#### Prêts instantanés {#flash-loans}
Les prêts Flash sont une forme plus expérimentale de prêt décentralisé qui vous permet d'emprunter sans garantie ou sans fournir de renseignements personnels.
@@ -173,12 +173,12 @@ Si l'échange B chutait soudainement et que l'utilisateur n'était pas en mesure
Pour pouvoir faire ce qui précède dans le monde de la finance traditionnelle, vous auriez besoin d'une somme d'argent énorme. Ces stratégies pour gagner de l'argent ne sont accessibles qu'à ceux qui possèdent déjà une certaine richesse. Les prêts Flash sont un exemple d'avenir où avoir de l'argent n'est pas nécessairement une condition préalable pour gagner de l'argent.
- Plus d'infos sur les prêts Flash
+ En savoir plus sur les prêts instantanés
- Voir les dApps de prêt
+ Voir les dapps de prêt
-#### Loteries sans risque {#no-loss-lotteries}
+#### Loteries sans perte {#no-loss-lotteries}
Les Loteries sans risque comme PoolTogether sont un moyen amusant et innovant d'épargner de l'argent.
@@ -218,36 +218,36 @@ Il existe des milliers de jetons sur Ethereum. Les échanges décentralisés (DE
Par exemple, si vous voulez vous lancer dans une loterie sans risque (décrite au dessus), vous aurez besoin de jeton comme les Dai ou USDC. Les DEXs vous permettent d'échanger vos ETH avec des tokens, et de les reconvertir en ETH lorsque vous avez terminé.
- Voir échanger des jetons
+ Voir les plateformes d'échange de jetons
- Voir Applications décentralisées (dapps)
+ Voir les dapps de trading
- Voir les applications d'investissement dapps
+ Voir les dapps d'investissement
- Voir les dapps de crowdfunding
+ Voir les dapps de financement participatif
-#### Financements quadratiques {#quadratic-funding}
+#### Financement quadratique {#quadratic-funding}
-Ethereum est un logiciel open source, une grand partie du travail à été financée par la communauté. Cela a conduit à la croissance d'un nouveau modèle de collecte de fond : le financement quadratique. Ce modèle a le potentiel d'améliorer la façon dont nous finançons tous les types de biens publics à l'avenir.
+Ethereum est un logiciel open source, une grand partie du travail à été financée par la communauté. Cela a conduit à la croissance d'un nouveau modèle de collecte de fond : le financement quadratique. Ce modèle a le potentiel d'améliorer la façon dont nous finançons tous les types de bien publics à l'avenir.
Le financement quadratique veille à ce que les projets qui reçoivent le plus de financement soient ceux dont la demande est la plus unique. En d'autres termes, des projets qui visent à améliorer la vie du plus grand nombre de personnes. Voici comment ça marche :
@@ -282,10 +282,10 @@ Cela veut dire qu'un projet A avec ses 100 donneurs de 1 dollar pourrait finir a
L'assurance décentralisée vise à rendre l'assurance moins chère, plus rapide à rembourser et plus transparente. Avec davantage d'automatisation, la protection est plus abordable et les paiements sont beaucoup plus rapides. Les données utilisées pour décider de votre réclamation sont complètement transparentes.
-Les produits Ethereum, comme n'importe quel logiciel, peuvent souffrir de bugs et d'exploits. Actuellement, de nombreux produits d'assurance dans l'espace sont axés sur la protection de leurs utilisateurs contre la perte de fonds. Cependant, il y a des projets qui commencent à construire une couverture pour tous les événements de la vie. Un bon exemple de ceci est la couverture Etherisc's Crop qui vise à [protéger les petits agriculteurs kényans contre les sécheresses et les inondations](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). Les assurances décentralisées peuvent offrir une couverture moins chère aux agriculteurs qui n'ont souvent pas les moyens d'accéder aux assurances traditionnelles.
+Les produits Ethereum, comme n'importe quel logiciel, peuvent souffrir de bugs et d'exploits. Actuellement, de nombreux produits d'assurance dans l'espace sont axés sur la protection de leurs utilisateurs contre la perte de fonds. Cependant, il y a des projets qui commencent à construire une couverture pour tous les événements de la vie. Un bon exemple est l'assurance récolte d'Etherisc qui vise à [protéger les petits agriculteurs du Kenya contre les sécheresses et les inondations](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). Les assurances décentralisées peuvent offrir une couverture moins chère aux agriculteurs qui n'ont souvent pas les moyens d'accéder aux assurances traditionnelles.
- Voir les assurances Dapps
+ Voir les dapps d'assurance
- Voir les dApps de portefeuille
+ Voir les dapps de portefeuille
- En savoir plus sur la fabrication de dapps
+ En savoir plus sur la création de dapps
-## Complément d'information {#further-reading}
+## En savoir plus {#further-reading}
### Données DeFi {#defi-data}
- [DeFi Prime](https://defiprime.com/)
- [DeFi Llama](https://defillama.com/)
-### Articles DeFi {#defi-articles}
+### Articles sur la DeFi {#defi-articles}
-- [Un guide de la DeFi pour débutants](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) - _Sid Coelho-Prabhu, 6 janvier 2020_
+- [Un guide du débutant sur la DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 janvier 2020_
+- [Directives d'évaluation des risques de la DeFi de l'EEA](https://entethalliance.org/specs/defi-risks/) – Un aperçu soutenu par l'industrie sur la manière d'identifier et d'évaluer les risques clés dans les protocoles DeFi.
### Vidéos {#videos}
-- [Finematics - decentralized finance education](https://finematics.com/) _vidéos de DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _Les bases de la DeFi : Tout ce que vous avez besoin de savoir pour commencer dans cet espace parfois déroutant_
-- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Qu'est-ce que DeFi?_
+- [Finematics - éducation sur la finance décentralisée](https://finematics.com/) – _Vidéos sur la DeFi_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _Les bases de la DeFi : tout ce que vous devez savoir pour commencer dans cet espace parfois déroutant._
+- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Qu'est-ce que la DeFi ?_
### Communautés {#communities}
-- [Serveur Discord DeFi Llama](https://discord.defillama.com/)
-- [Serveur Discord DeFi Pulse](https://discord.gg/Gx4TCTk)
+- [Serveur Discord de DeFi Llama](https://discord.defillama.com/)
+- [Serveur Discord de DeFi Pulse](https://discord.gg/Gx4TCTk)
+> clef newaccount --keystore
-Please enter a password for the new account to be created:
->
+Veuillez saisir un mot de passe pour le nouveau compte à créer :
+>
------------
INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
@@ -92,15 +93,15 @@ Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
[Documentation Geth](https://geth.ethereum.org/docs)
-Il est possible de dériver de nouvelles clés publiques à partir de votre clé privée, mais pas l'inverse. Il est impératif de conserver vos clés privées en sécurité. Comme leur nom l'indique, elles sont **PRIVÉES**.
+Il est possible de dériver de nouvelles clés publiques à partir de votre clé privée, mais pas l'inverse. Il est essentiel de conserver vos clés privées en lieu sûr et, comme leur nom l'indique, de les garder **PRIVÉES**.
-Vous avez besoin d'une clé privée pour signer les messages et les transactions produisant une signature. Les autres peuvent alors prendre la signature pour dériver votre clé publique, prouvant l'auteur du message. Dans votre application, vous pouvez utiliser une bibliothèque JavaScript pour envoyer des transactions au réseau.
+Vous avez besoin d'une clé privée pour signer des messages et des transactions qui génèrent une signature. Les autres peuvent alors prendre la signature pour dériver votre clé publique, prouvant l'auteur du message. Dans votre application, vous pouvez utiliser une bibliothèque JavaScript pour envoyer des transactions au réseau.
-## Les comptes de contrats {#contract-accounts}
+## Comptes de contrat {#contract-accounts}
Les comptes de contrats possèdent également une adresse hexadécimale de 42 caractères :
-Exemple :
+Exemple :
`0x06012c8cf97bead5deae237070f9587f8e7a266d`
@@ -116,7 +117,7 @@ Il existe également un autre type de clé dans Ethereum, qui a été mis en pla
Un compte n'est pas un portefeuille. Un portefeuille est une interface ou une application qui vous permet d'interagir avec votre compte Ethereum, qu'il s'agisse d'un compte externe ou d'un compte de contrat.
-## Démonstration visuelle {#a-visual-demo}
+## Une démo visuelle {#a-visual-demo}
Regardez Austin vous guider à travers les fonctions de hachage et les paires de clés.
@@ -124,9 +125,9 @@ Regardez Austin vous guider à travers les fonctions de hachage et les paires de
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-Aucune
+Aucun
**Retours**
-Les données précises renvoyées varient entre les différentes implémentations de clients. Tous les clients renvoient `False` lorsque le nœud n'est pas en synchronisation, et tous les clients renvoient les champs suivants.
+Les données précises renvoyées varient entre les différentes implémentations de clients. Tous les clients retournent `False` lorsque le nœud n'est pas en cours de synchronisation, et tous les clients retournent les champs suivants.
-`Objet|Booléen`, un objet avec des données sur l'état de la synchronisation ou `FALSE`, s'il n'y a pas de synchronisation :
+`Objet|Booléen`, un objet avec des données d'état de synchronisation ou `FALSE` lorsque la synchronisation n'a pas lieu :
-- `startingBlock`: `QUANTITY` - Le bloc où l'importation a commencé (ne sera remis à zéro que lorsque la synchronisation aura atteint sa tête)
-- `currentBlock`: `QUANTITY` - Le bloc actuel, identique à eth_blockNumber
-- `highestBlock`: `QUANTITY` - Le bloc estimé le plus élevé
+- `startingBlock` : `QUANTITÉ` - le bloc où l'importation a commencé (ne sera réinitialisé qu'une fois que la synchronisation aura atteint sa tête)
+- `currentBlock` : `QUANTITÉ` - le bloc actuel, identique à eth_blockNumber
+- `highestBlock` : `QUANTITÉ` - le plus haut bloc estimé
Cependant, chaque client peut également fournir des données supplémentaires. Par exemple, Geth renvoie les informations suivantes :
@@ -359,7 +364,7 @@ Alors que Besu renvoie :
Reportez-vous à la documentation de votre client spécifique pour plus de détails.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -386,17 +391,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
Renvoie l'adresse coinbase du client.
-> **Note :** Cette méthode est obsolète depuis la version **v1.14.0** et n'est plus prise en charge. Essayer d’utiliser cette méthode entraînera une erreur « Méthode non prise en charge ».
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
+> **Remarque :** Cette méthode est obsolète depuis la **v1.14.0** et n'est plus prise en charge. Essayer d’utiliser cette méthode entraînera une erreur « Méthode non prise en charge ».
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`DATA`, 20 octets - l'adresse actuelle de coinbase.
+`DONNÉES`, 20 octets - l'adresse coinbase actuelle.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -413,15 +422,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6
Retourne la chaîne ID utilisée pour la signature d'opérations protégées par la rediffusion.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`chainId`, valeur hexadécimale comme une chaîne représentant le nombre entier de l'id de la chaîne courante.
+`chainId`, valeur hexadécimale sous forme de chaîne représentant l'entier de l'ID de la chaîne actuelle.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -436,17 +449,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
### eth_mining {#eth_mining}
-Retourne `true` si le client est en train de miner activement de nouveaux blocs. Cela ne peut renvoyer que `vrai` pour les réseaux en preuve de travail et peut ne pas être disponible dans certains clients depuis [La Fusion](/roadmap/merge/).
+Retourne `true` si le client mine activement de nouveaux blocs. Cela ne peut renvoyer `true` que pour les réseaux à preuve de travail et peut ne pas être disponible dans certains clients depuis [La Fusion](/roadmap/merge/).
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`Boolean` - renvoie `true` du client en train de miner, sinon `false`.
+`Booléen` - renvoie `true` si le client mine, sinon `false`.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -461,17 +478,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
### eth_hashrate {#eth_hashrate}
-Retourne le nombre de hachages par seconde avec lesquels le nœud est miné. Cela ne peut renvoyer que `vrai` pour les réseaux en preuve de travail et peut ne pas être disponible dans certains clients depuis [La Fusion](/roadmap/merge/).
+Retourne le nombre de hachages par seconde avec lesquels le nœud est miné. Cela ne peut renvoyer `true` que pour les réseaux à preuve de travail et peut ne pas être disponible dans certains clients depuis [La Fusion](/roadmap/merge/).
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre de hachages par seconde.
+`QUANTITÉ` - nombre de hachages par seconde.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -488,15 +509,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7
Retourne une estimation du prix actuel de gaz en wei. Par exemple, le client Besu examine les 100 derniers blocs et renvoie le prix médian du gaz en unité par défaut.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`QUANTITY` - entier du prix actuel du gaz en wei.
+`QUANTITÉ` - entier du prix actuel du gaz en wei.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -513,15 +538,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7
Renvoie une liste d'adresses appartenant au client.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`Array of DATA`, 20 octets - adresses appartenant au client.
+`Tableau de DONNÉES`, 20 Octets - adresses appartenant au client.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -538,15 +567,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
Renvoie le numéro du bloc le plus récent.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-Aucune
+Aucun
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du numéro de bloc actuel sur lequel se trouve le client.
+`QUANTITÉ` - entier du numéro de bloc actuel sur lequel se trouve le client.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -561,22 +594,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id
### eth_getBalance {#eth_getbalance}
-Renvoie le solde du compte de l'adresse donnée.
+Renvoie le solde du compte à une adresse donnée.
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-1. `DATA`, 20 octets - adresse pour vérifier le solde.
-2. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+1. `DONNÉES`, 20 octets - adresse pour vérifier le solde.
+2. `QUANTITÉ|TAG` - numéro de bloc entier, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"`, ou `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du solde actuel en wei.
+`QUANTITÉ` - entier du solde actuel en wei.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -593,30 +630,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407
Renvoie la valeur d'une position de stockage à une adresse donnée.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 20 octets - adresse du stockage.
-2. `QUANTITY` - nombre entier de la position dans le stockage.
-3. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+1. `DONNÉES`, 20 octets - adresse du stockage.
+2. `QUANTITÉ` - entier de la position dans le stockage.
+3. `QUANTITÉ|TAG` - numéro de bloc entier, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"`, `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
-**Valeur de retour**
+**Retours**
-`DATA` - la valeur à cette position de stockage.
+`DONNÉES` - la valeur à cette position de stockage.
-**Exemple** Le calcul de la position correcte dépend du stockage à récupérer. Considérons le contrat suivant déployé à `0x295a70b2de5e3953354a6a8344e616ed314d7251` par l'adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
+**Exemple**
+Le calcul de la position correcte dépend du stockage à récupérer. Considérez le contrat suivant déployé à l'adresse `0x295a70b2de5e3953354a6a8344e616ed314d7251` par l'adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
```
contract Storage {
uint pos0;
- mapping(address => uint) pos1;
- function Storage() {
+ mapping(adresse => uint) pos1;
+ constructor() {
pos0 = 1234;
pos1[msg.sender] = 5678;
}
}
```
-La récupération de la valeur pos0 est simple :
+Récupérer la valeur de pos0 est simple :
```js
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
@@ -658,12 +700,16 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
### eth_getTransactionCount {#eth_gettransactioncount}
-Renvoie le nombre de transactions _envoyées_ à partir d'une adresse.
+Renvoie le nombre de transactions _envoyées_ depuis une adresse.
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-1. `DATA`, 20 octets - adresse.
-2. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+1. `DONNÉES`, 20 octets - adresse.
+2. `QUANTITÉ|TAG` - numéro de bloc entier, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -672,11 +718,11 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du nombre de transactions envoyées depuis cette adresse.
+`QUANTITÉ` - entier du nombre de transactions envoyées depuis cette adresse.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -693,19 +739,23 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params
Renvoie le nombre de transactions dans un bloc à partir d'un bloc correspondant au hachage de bloc donné.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 32 octets - hachage d'un bloc
+1. `DONNÉES`, 32 octets - hachage d'un bloc
```js
params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du nombre de transactions dans ce bloc.
+`QUANTITÉ` - entier du nombre de transactions dans ce bloc.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -722,9 +772,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa
Renvoie le nombre de transactions dans un bloc correspondant au numéro de bloc donné.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITÉ|TAG` - entier d'un numéro de bloc, ou la chaîne `\"earliest\"`, `\"latest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, comme dans le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter).
```js
params: [
@@ -732,11 +786,11 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du nombre de transactions dans ce bloc.
+`QUANTITÉ` - entier du nombre de transactions dans ce bloc.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -753,19 +807,23 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu
Renvoie le nombre d'oncles dans un bloc à partir d'un bloc correspondant au hachage de bloc donné.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 32 octets - hachage d'un bloc
+1. `DONNÉES`, 32 octets - hachage d'un bloc
```js
params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du nombre d'oncles dans ce bloc.
+`QUANTITÉ` - entier du nombre d'oncles dans ce bloc.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -782,9 +840,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p
Renvoie le nombre d'oncles dans un bloc à partir d'un bloc correspondant au numéro de bloc donné.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+1. `QUANTITÉ|TAG` - entier d'un numéro de bloc, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -792,11 +854,11 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`QUANTITY` - nombre entier du nombre d'oncles dans ce bloc.
+`QUANTITÉ` - entier du nombre d'oncles dans ce bloc.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -813,10 +875,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber",
Renvoie le code à une adresse donnée.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 20 octets - adresse
-2. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+1. `DONNÉES`, 20 octets - adresse
+2. `QUANTITÉ|TAG` - numéro de bloc entier, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -825,11 +891,11 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`DATA` - le code issu de l'adresse donnée.
+`DONNÉES` - le code de l'adresse donnée.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -844,22 +910,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA
### eth_sign {#eth_sign}
-La méthode du signe calcule une signature spécifique à Ethereum avec : `sign(keccak256("\x19Message signé Ethereum :\n" + len(message) + message)))`.
+La méthode de signature calcule une signature spécifique à Ethereum avec : `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
-En ajoutant un préfixe au message, la signature calculée peut être reconnue comme une signature spécifique à Ethereum. Cela empêche l'utilisation abusive où une DApp malveillante peut signer des données arbitraires (par exemple une transaction) et utiliser la signature pour usurper l'identité de la victime.
+En ajoutant un préfixe au message, la signature calculée peut être reconnue comme une signature spécifique à Ethereum. Cela empêche une utilisation abusive où une dapp malveillante peut signer des données arbitraires (par exemple, une transaction) et utiliser la signature pour usurper l'identité de la victime.
Remarque : l'adresse avec laquelle signer doit être déverrouillée.
**Paramètres**
-1. `DATA`, 20 octets - adresse
-2. `DATA`, N octets - message à signer
+1. `DONNÉES`, 20 octets - adresse
+2. `DONNÉES`, N octets - message à signer
-**Valeur de retour**
+**Retours**
-`DATA` : Signature
+`DONNÉES` : Signature
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -874,26 +940,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37
### eth_signTransaction {#eth_signtransaction}
-Signale une transaction qui peut être soumise au réseau plus tard en utilisant [eth_sendRawTransaction](#eth_sendrawtransaction).
+Signe une transaction qui pourra être soumise ultérieurement au réseau en utilisant [eth_sendRawTransaction](#eth_sendrawtransaction).
**Paramètres**
-1. `Object` - L'objet de la transaction
+1. `Objet` - L'objet de la transaction
-- `type`:
-- `from`: `DATA`, 20 octets - L'adresse à partir de laquelle la transaction est envoyée.
-- `to`: `DATA`, 20 octets - (optionnel lors de la création d'un nouveau contrat) L'adresse vers laquelle la transaction est orientée.
-- `gaz` : `QUANTITY` - (facultatif, par défaut : 90 000) Nombre entier du gaz fourni pour l'exécution de la transaction. Il retournera du gaz inutilisé.
-- `gasPrice` : `QUANTITY` - (facultatif, par défaut : To-Be-Determined) Nombre entier du prix du gaz utilisé pour chaque gaz payé, à Wei.
-- `value`: `QUANTITY` - (facultatif) Nombre entier de la valeur envoyée avec cette transaction, dans Wei.
-- `data` : `DATA` - Le code compilé d'un contrat OU le hachage de la signature de la méthode invoquée et des paramètres encodés.
-- `nonce` : `QUANTITY` - (facultatif) Entier d'un nonce. Cela permet d'écraser vos propres transactions en attente qui utilisent le même nonce.
+- `type` :
+- `from` : `DONNÉES`, 20 octets - L'adresse depuis laquelle la transaction est envoyée.
+- `to` : `DONNÉES`, 20 octets - (facultatif lors de la création d'un nouveau contrat) L'adresse à laquelle la transaction est destinée.
+- `gas` : `QUANTITÉ` - (facultatif, par défaut : 90000) Entier du gaz fourni pour l'exécution de la transaction. Il retournera du gaz inutilisé.
+- `gasPrice` : `QUANTITÉ` - (facultatif, par défaut : à déterminer) Entier du gasPrice utilisé pour chaque gaz payé, en Wei.
+- `value` : `QUANTITÉ` - (facultatif) Entier de la valeur envoyée avec cette transaction, en Wei.
+- `data` : `DONNÉES` - Le code compilé d'un contrat OU le hachage de la signature de la méthode invoquée et des paramètres encodés.
+- `nonce` : `QUANTITÉ` - (facultatif) Entier d'un nonce. Cela permet d'écraser vos propres transactions en attente qui utilisent le même nonce.
-**Valeur de retour**
+**Retours**
-`DATA`, L'objet de transaction encodé en RLP signé par le compte spécifié.
+`DONNÉES`, l'objet de transaction encodé en RLP signé par le compte spécifié.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -908,19 +974,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","
### eth_sendTransaction {#eth_sendtransaction}
-Crée une nouvelle transaction d'appel ou une création de contrat, si le champ de données contient du code, et la signe en utilisant le compte spécifié dans `from`.
+Crée une nouvelle transaction d'appel de message ou une création de contrat, si le champ de données contient du code, et la signe en utilisant le compte spécifié dans `from`.
**Paramètres**
-1. `Object` - L'objet de la transaction
+1. `Objet` - L'objet de la transaction
-- `from`: `DATA`, 20 octets - L'adresse à partir de laquelle la transaction est envoyée.
-- `to`: `DATA`, 20 octets - (optionnel lors de la création d'un nouveau contrat) L'adresse vers laquelle la transaction est orientée.
-- `gaz` : `QUANTITY` - (facultatif, par défaut : 90 000) Nombre entier du gaz fourni pour l'exécution de la transaction. Il retournera du gaz inutilisé.
-- `gasPrice` : `QUANTITY` - (facultatif, par défaut : To-Be-Determined) Nombre entier du prix du gaz utilisé pour chaque gaz payé.
-- `value` : `QUANTITY` - (facultatif) Nombre entier de la valeur envoyée avec cette transaction.
-- `input` : `DATA` - Le code compilé d'un contrat OU le hachage de la signature de la méthode invoquée et des paramètres encodés.
-- `nonce` : `QUANTITY` - (facultatif) Entier d'un nonce. Cela permet d'écraser vos propres transactions en attente qui utilisent le même nonce.
+- `from` : `DONNÉES`, 20 octets - L'adresse depuis laquelle la transaction est envoyée.
+- `to` : `DONNÉES`, 20 octets - (facultatif lors de la création d'un nouveau contrat) L'adresse à laquelle la transaction est destinée.
+- `gas` : `QUANTITÉ` - (facultatif, par défaut : 90000) Entier du gaz fourni pour l'exécution de la transaction. Il retournera du gaz inutilisé.
+- `gasPrice` : `QUANTITÉ` - (facultatif, par défaut : à déterminer) Entier du gasPrice utilisé pour chaque gaz payé.
+- `value` : `QUANTITÉ` - (facultatif) Entier de la valeur envoyée avec cette transaction.
+- `input` : `DONNÉES` - Le code compilé d'un contrat OU le hachage de la signature de la méthode invoquée et des paramètres encodés.
+- `nonce` : `QUANTITÉ` - (facultatif) Entier d'un nonce. Cela permet d'écraser vos propres transactions en attente qui utilisent le même nonce.
```js
params: [
@@ -936,13 +1002,13 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`DATA`, 32 octets - le hachage de la transaction, ou le hachage zéro si la transaction n'est pas encore disponible.
+`DONNÉES`, 32 octets - le hachage de la transaction, ou le hachage zéro si la transaction n'est pas encore disponible.
-Utilisez [eth_getTransactionReceipt](#eth_gettransactionreceipt) pour obtenir l'adresse du contrat, après que la transaction a été proposée dans un block, lorsque vous avez créé un contrat.
+Utilisez [eth_getTransactionReceipt](#eth_gettransactionreceipt) pour obtenir l'adresse du contrat, une fois que la transaction a été proposée dans un bloc, lorsque vous avez créé un contrat.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -961,7 +1027,7 @@ Crée une nouvelle transaction d'appel de message ou une création de contrat po
**Paramètres**
-1. `DATA`, Les données de transaction signées.
+1. `DONNÉES`, les données de transaction signées.
```js
params: [
@@ -969,13 +1035,13 @@ params: [
]
```
-**Valeur de retour**
+**Retours**
-`DATA`, 32 octets - le hachage de la transaction, ou le hachage zéro si la transaction n'est pas encore disponible.
+`DONNÉES`, 32 octets - le hachage de la transaction, ou le hachage zéro si la transaction n'est pas encore disponible.
-Utilisez [eth_getTransactionReceipt](#eth_gettransactionreceipt) pour obtenir l'adresse du contrat, après que la transaction a été proposée dans un block, lorsque vous avez créé un contrat.
+Utilisez [eth_getTransactionReceipt](#eth_gettransactionreceipt) pour obtenir l'adresse du contrat, une fois que la transaction a été proposée dans un bloc, lorsque vous avez créé un contrat.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -990,26 +1056,30 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
### eth_call {#eth_call}
-Exécute un nouvel appel de message immédiatement sans créer de transaction sur la chaîne de blocs. Souvent utilisé pour exécuter des fonctions de contrat intelligent en lecture seule, par exemple le `balanceOf` pour un contrat ERC-20.
+Exécute un nouvel appel de message immédiatement sans créer de transaction sur la chaîne de blocs. Souvent utilisé pour exécuter des fonctions de contrat intelligent en lecture seule, par exemple `balanceOf` pour un contrat ERC-20.
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-1. `Object` - L'objet d'appel de transaction
+1. `Objet` - L'objet d'appel de transaction
-- `from` : `DATA`, 20 octets - (optionnel) - L'adresse à partir de laquelle la transaction est envoyée.
-- `to` : `DATA`, 20 octets - L'adresse à laquelle la transaction est orientée.
-- `gaz`: `QUANTITY` - (facultatif) Nombre entier du gaz fourni pour l'exécution de la transaction. eth_call consomme zéro gaz, mais ce paramètre peut être nécessaire pour certaines exécutions.
-- `gasPrice` : `QUANTITY` - (facultatif) Nombre entier du prix du gaz utilisé pour chaque gaz payé
-- `value` : `QUANTITY` - (facultatif) Nombre entier de la valeur envoyée avec cette transaction
-- `input` : `DATA` - Hachage (facultatif) de la signature de la méthode et des paramètres encodés. Pour plus de détails, voir [le contrat Ethereum ABI dans la documentation de Solidity](https://docs.soliditylang.org/en/latest/abi-spec.html).
+- `from` : `DONNÉES`, 20 octets - (facultatif) L'adresse depuis laquelle la transaction est envoyée.
+- `to` : `DONNÉES`, 20 octets - L'adresse à laquelle la transaction est destinée.
+- `gas` : `QUANTITÉ` - (facultatif) Entier du gaz fourni pour l'exécution de la transaction. eth_call consomme zéro gaz, mais ce paramètre peut être nécessaire pour certaines exécutions.
+- `gasPrice` : `QUANTITÉ` - (facultatif) Entier du gasPrice utilisé pour chaque gaz payé
+- `value` : `QUANTITÉ` - (facultatif) Entier de la valeur envoyée avec cette transaction
+- `input` : `DONNÉES` - (facultatif) Hachage de la signature de la méthode et des paramètres encodés. Pour plus de détails, voir l'[ABI du contrat Ethereum dans la documentation de Solidity](https://docs.soliditylang.org/en/latest/abi-spec.html).
-2. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITÉ|TAG` - numéro de bloc entier, ou la chaîne `\"latest\"`, `\"earliest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, voir le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter)
-**Valeur de retour**
+**Retours**
-`DATA` - la valeur de retour du contrat exécuté.
+`DONNÉES` - la valeur de retour du contrat exécuté.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1026,15 +1096,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}]
Génère et retourne une estimation de la quantité de gaz nécessaire à la réalisation de la transaction. La transaction ne sera pas ajoutée à la blockchain. Notez que l'estimation peut être beaucoup plus grande que la quantité de gaz réellement utilisée par la transaction, pour diverses raisons, y compris la mécanique EVM et la performance des nœuds.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-Voir les paramètres de [eth_call](#eth_call) , hormis le fait que toutes les propriétés sont facultatives. Si aucune limite de gaz n'est spécifiée, geth utilise la limite de gaz du bloc en attente comme une limite supérieure. En conséquence, l'estimation retournée pourrait ne pas suffire à exécuter l'appel/la transaction lorsque la quantité de gaz est supérieure à la limite de gaz bloc en attente.
+Voir les paramètres de [eth_call](#eth_call), sauf que toutes les propriétés sont facultatives. Si aucune limite de gaz n'est spécifiée, geth utilise la limite de gaz du bloc en attente comme une limite supérieure. Par conséquent, l'estimation retournée peut ne pas être suffisante pour exécuter l'appel/la transaction lorsque la quantité de gaz est supérieure à la limite de gaz du bloc en attente.
-**Valeur de retour**
+**Retours**
-`QUANTITY` - la quantité de gaz utilisée.
+`QUANTITÉ` - la quantité de gaz utilisée.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1051,10 +1125,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see
Retourne des informations à propos d'un bloc par hachage.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 32 octets - Hachage d'un bloc.
-2. `Boolean` - Si `true` il retourne les objets de transaction complets, si `false` seulement les hachages des transactions.
+1. `DONNÉES`, 32 octets - Hachage d'un bloc.
+2. `Booléen` - Si `true`, il renvoie les objets de transaction complets, si `false`, seulement les hachages des transactions.
```js
params: [
@@ -1063,41 +1141,40 @@ params: [
]
```
-**Valeur de retour**
-
-`Object` - Un objet bloc, ou `null` quand aucun bloc n'a été trouvé :
-
-- `number` : `QUANTITY` - le numéro du bloc. `null` quand son bloc est en attente.
-- `hash` : `DATA`, 32 octets - hachage du bloc. `null` quand son bloc est en attente.
-- `parentHash` : `DATA`, 32 octets - hachage du bloc parent.
-- `nonce` : `DATA`, 8 octets - hachage de la preuve de travail générée. `null` quand son bloc est en attente.
-- `sha3Uncles` : `DATA`, 32 octets - SHA3 des oncles données dans le bloc.
-- `logsBloom` : `DATA`, 256 octets - le filtre bloom pour les logs du bloc. `null` quand son bloc est en attente.
-- `transactionsRoot` : `DATA`, 32 octets - la racine de la tentative de transaction du bloc.
-- `stateRoot` : `DATA`, 32 octets - la racine de l'état final du bloc.
-- `receiptsRoot` : `DATA`, 32 octets - la racine de la tentative de réception du bloc.
-- `miner` : `DATA`, 20 octets - l'adresse du bénéficiaire auquel les récompenses minières ont été données.
-- `difficulty` : `QUANTITY` - entier de la difficulté pour ce bloc.
-- `totalDifficulty` : `QUANTITY` - entier de la difficulté globale de la chaîne jusqu'à ce bloc.
-- `extraData` : `DATA` - le champ « données supplémentaires » de ce bloc.
-- `size` : `QUANTITY` - entier de la taille de ce bloc en octets.
-- `gasLimit` : `QUANTITY` - le gaz maximum autorisé dans ce bloc.
-- `gasUsed`: `QUANTITY` - le total utilisé par toutes les transactions de ce bloc.
-- `timestamp`: `QUANTITY` - l'horodatage unix pour le moment où le bloc a été assemblé.
-- `transactions`: `Array` - Tableau d'objets de transaction, ou hachage de transaction 32 octets dépendant du dernier paramètre donné.
-- `uncles`: `Array` - Tableau de hachages d'oncle.
-
-**Exemple**
+**Retours**
-```js
-// Request
+`Objet` - un objet de bloc, ou `null` si aucun bloc n'a été trouvé :
+
+- `number` : `QUANTITÉ` - le numéro du bloc. `null` quand il s'agit d'un bloc en attente.
+- `hash` : `DONNÉES`, 32 octets - hachage du bloc. `null` quand il s'agit d'un bloc en attente.
+- `parentHash` : `DONNÉES`, 32 octets - hachage du bloc parent.
+- `nonce` : `DONNÉES`, 8 octets - hachage de la preuve de travail générée. `null` lorsqu'il s'agit d'un bloc en attente, `0x0` pour les blocs à preuve d'enjeu (depuis La Fusion)
+- `sha3Uncles` : `DONNÉES`, 32 octets - SHA3 des données des oncles dans le bloc.
+- `logsBloom` : `DONNÉES`, 256 octets - le filtre de bloom pour les journaux du bloc. `null` quand il s'agit d'un bloc en attente.
+- `transactionsRoot` : `DONNÉES`, 32 octets - la racine du trie de transactions du bloc.
+- `stateRoot` : `DONNÉES`, 32 octets - la racine du trie d'état final du bloc.
+- `receiptsRoot` : `DONNÉES`, 32 octets - la racine du trie de reçus du bloc.
+- `miner` : `DONNÉES`, 20 octets - l'adresse du bénéficiaire à qui les récompenses de bloc ont été données.
+- `difficulty` : `QUANTITÉ` - entier de la difficulté pour ce bloc.
+- `totalDifficulty` : `QUANTITÉ` - entier de la difficulté totale de la chaîne jusqu'à ce bloc.
+- `extraData` : `DONNÉES` - le champ « données supplémentaires » de ce bloc.
+- `size` : `QUANTITÉ` - entier de la taille de ce bloc en octets.
+- `gasLimit` : `QUANTITÉ` - le gaz maximum autorisé dans ce bloc.
+- `gasUsed` : `QUANTITÉ` - le gaz total utilisé par toutes les transactions dans ce bloc.
+- `timestamp` : `QUANTITÉ` - l'horodatage unix du moment où le bloc a été assemblé.
+- `transactions` : `Tableau` - Tableau d'objets de transaction, ou hachages de transaction de 32 octets en fonction du dernier paramètre donné.
+- `uncles` : `Tableau` - Tableau de hachages d'oncles.
+
+\*\*Exemple \*\*
+
+```js
+// Requête
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
+// Résultat
{
-{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
"difficulty": "0x4ea3f27bc",
"extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
"gasLimit": "0x1388",
@@ -1120,7 +1197,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
"transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
"uncles": [
]
-}
+ }
}
```
@@ -1128,10 +1205,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
Renvoie des informations sur un bloc par numéro de bloc.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `QUANTITY|TAG` - nombre entier d'un numéro de bloc, ou la chaîne `« latest »`, `« earliest »`, `« pending »`, `« safe »`, ou `« finalized »`, voir le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block).
-2. `Boolean` - Si `true` il retourne les objets de transaction complètes, si `false` seulement les hachages des transactions.
+1. `QUANTITÉ|TAG` - entier d'un numéro de bloc, ou la chaîne `\"earliest\"`, `\"latest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, comme dans le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter).
+2. `Booléen` - Si `true`, il renvoie les objets de transaction complets, si `false`, seulement les hachages des transactions.
```js
params: [
@@ -1140,9 +1221,10 @@ params: [
]
```
-**Retourne** Voir [eth_getBlockByHash](#eth_getblockbyhash)
+**Retours**
+Voir [eth_getBlockByHash](#eth_getblockbyhash)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1155,34 +1237,38 @@ Résultat voir [eth_getBlockByHash](#eth_getblockbyhash)
Retourne les informations sur une transaction demandée par le hachage de la transaction.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 32 octets - hachage d'une transaction
+1. `DONNÉES`, 32 octets - hachage d'une transaction
```js
params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
```
-**Valeur de retour**
+**Retours**
-`Object` - Un objet de transaction, ou `null` quand aucune transaction n'a été trouvée :
+`Objet` - un objet de transaction, ou `null` si aucune transaction n'a été trouvée :
-- `blockHash`: `DATA`, 32 octets - hachage du bloc dans lequel se trouvait cette transaction. `null` lors de son attente.
-- `blockNumber`: `QUANTITY` - numéro de bloc où se trouvait cette transaction. `null` lors de son attente.
-- `from`: `DATA`, 20 octets - adresse de l'expéditeur.
-- `gas`: `QUANTITY` - gaz fourni par l'expéditeur.
-- `gasPrice`: `QUANTITY` - prix du gaz fourni par l'expéditeur en Wei.
-- `hash`: `DATA`, 32 octets - hachage de la transaction.
-- `input`: `DATA` - les données envoyées avec la transaction.
-- `nonce`: `QUANTITY` - le nombre de transactions effectuées par l'expéditeur avant celle-ci.
-- `to`: `DATA`, 20 octets - adresse du destinataire. `null` lors d'une transaction de création de contrat.
-- `transactionIndex`: `QUANTITY` - nombre entier de la position de l'indice des transactions dans le bloc. `null` lors de son attente.
-- `valeur`: `QUANTITY` - valeur transférée dans Wei.
-- `v`: `QUANTITY` - Identifiant de récupération ECDSA
-- `r`: `QUANTITY` - Signature ECDSA r
-- `s`: `QUANTITY` - Signature ECDSA s
+- `blockHash` : `DONNÉES`, 32 octets - hachage du bloc dans lequel se trouvait cette transaction. `null` lorsqu'elle est en attente.
+- `blockNumber` : `QUANTITÉ` - numéro de bloc où se trouvait cette transaction. `null` lorsqu'elle est en attente.
+- `from` : `DONNÉES`, 20 octets - adresse de l'expéditeur.
+- `gas` : `QUANTITÉ` - gaz fourni par l'expéditeur.
+- `gasPrice` : `QUANTITÉ` - prix du gaz fourni par l'expéditeur en Wei.
+- `hash` : `DONNÉES`, 32 octets - hachage de la transaction.
+- `input` : `DONNÉES` - les données envoyées avec la transaction.
+- `nonce` : `QUANTITÉ` - le nombre de transactions effectuées par l'expéditeur avant celle-ci.
+- `to` : `DONNÉES`, 20 octets - adresse du destinataire. `null` lorsqu'il s'agit d'une transaction de création de contrat.
+- `transactionIndex` : `QUANTITÉ` - entier de la position de l'index des transactions dans le bloc. `null` lorsqu'elle est en attente.
+- `value` : `QUANTITÉ` - valeur transférée en Wei.
+- `v` : `QUANTITÉ` - ID de récupération ECDSA
+- `r` : `QUANTITÉ` - signature ECDSA r
+- `s` : `QUANTITÉ` - signature ECDSA s
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1214,10 +1300,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param
Retourne des informations sur une transaction par hachage de bloc et la position de l'indice de transaction.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `DATA`, 32 octets - hachage d'un bloc.
-2. `QUANTITY` - nombre entier de la position de l'indice de transaction.
+1. `DONNÉES`, 32 octets - hachage d'un bloc.
+2. `QUANTITÉ` - entier de la position de l'index de transaction.
```js
params: [
@@ -1226,9 +1316,10 @@ params: [
]
```
-**Retourne** Voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Retours**
+Voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1241,10 +1332,14 @@ Résultat voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
Retourne des informations sur une transaction par numéro de bloc et la position de l'indice de transaction.
+
+ Essayer le point de terminaison dans le terrain de jeu
+
+
**Paramètres**
-1. `QUANTITY|TAG` - un numéro de bloc, ou la chaîne `« earliest »`, `« latest »`, `« pending »`, `« safe »`, ou `« finalized »`, comme dans le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - position de l'indice de transaction.
+1. `QUANTITÉ|TAG` - un numéro de bloc, ou la chaîne `\"earliest\"`, `\"latest\"`, `\"pending\"`, `\"safe\"` ou `\"finalized\"`, comme dans le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITÉ` - position de l'indice de transaction.
```js
params: [
@@ -1253,12 +1348,13 @@ params: [
]
```
-**Retourne** Voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Retours**
+Voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
-**Exemple**
+\*\*Exemple \*\*
```js
-// Request
+// Requête
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
```
@@ -1268,38 +1364,39 @@ Résultat voir [eth_getTransactionByHash](#eth_gettransactionbyhash)
Retourne la réception d'une transaction par hachage de la transaction.
-**Remarque** que le reçu n'est pas disponible pour les transactions en attente.
+**Remarque** Ce reçu n'est pas disponible pour les transactions en attente.
**Paramètres**
-1. `DATA`, 32 octets - hachage d'une transaction
+1. `DONNÉES`, 32 octets - hachage d'une transaction
```js
params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
```
-**Renvoie** `Object` - Un objet de réception de transaction, ou `null` quand aucun reçu n'a été trouvé :
+**Retours**
+`Objet` - Un objet de reçu de transaction, ou `null` si aucun reçu n'a été trouvé :
-- `transactionHash`: `DATA`, 32 octets - hachage de la transaction.
-- `transactionIndex`: `QUANTITY` - nombre entier de la position de l'indice des transactions dans le bloc.
-- `blockHash`: `DATA`, 32 octets - hachage du bloc dans lequel se trouvait cette transaction.
-- `blockNumber`: `QUANTITY` - numéro de bloc où se trouvait cette transaction.
-- `from`: `DATA`, 20 octets - adresse de l'expéditeur.
-- `to`: `DATA`, 20 octets - adresse du destinataire. null lors d'une transaction de création de contrat.
-- `cumulativeGasUsed` : `QUANTITY` - Le montant total de gaz utilisé lorsque cette transaction a été exécutée dans le bloc.
-- `effectiveGasPrice` : `QUANTITY` - La somme des frais de base et du pourboire payés par unité de gaz.
-- `gasUsed`: `QUANTITY` - La quantité de gaz utilisée par cette transaction spécifique seule.
-- `contractAddress`: `DATA`, 20 octets - L'adresse du contrat a été créée, si la transaction était une création de contrat, sinon `null`.
-- `logs`: `Tableau` - Tableau d'objets de log, que cette transaction a générés.
-- `logsBloom`: `DATA`, 256 octets - Filtre Bloom pour les clients légers pour récupérer rapidement les logs associés.
-- `type`: `QUANTITY` - nombre entier du type de transaction, `0x00` pour les transactions héritées, `0x01` pour les types de listes d'accès, `0x02` pour les frais dynamiques.
+- `transactionHash ` : `DONNÉES`, 32 octets - hachage de la transaction.
+- `transactionIndex` : `QUANTITÉ` - entier de la position de l'index des transactions dans le bloc.
+- `blockHash` : `DONNÉES`, 32 octets - hachage du bloc dans lequel se trouvait cette transaction.
+- `blockNumber` : `QUANTITÉ` - numéro de bloc où se trouvait cette transaction.
+- `from` : `DONNÉES`, 20 octets - adresse de l'expéditeur.
+- `to` : `DONNÉES`, 20 octets - adresse du destinataire. null lors d'une transaction de création de contrat.
+- `cumulativeGasUsed` : `QUANTITÉ ` - Le montant total de gaz utilisé lorsque cette transaction a été exécutée dans le bloc.
+- `effectiveGasPrice` : `QUANTITÉ` - La somme des frais de base et du pourboire payés par unité de gaz.
+- `gasUsed ` : `QUANTITÉ ` - La quantité de gaz utilisée par cette transaction spécifique seule.
+- `contractAddress ` : `DONNÉES`, 20 octets - L'adresse du contrat créée, si la transaction était une création de contrat, sinon `null`.
+- `logs` : `Tableau` - Tableau d'objets de journal que cette transaction a générés.
+- `logsBloom` : `DONNÉES`, 256 octets - Filtre de Bloom pour que les clients légers puissent récupérer rapidement les journaux associés.
+- `type` : `QUANTITÉ` - entier du type de transaction, `0x0` pour les transactions héritées, `0x1` pour les types de listes d'accès, `0x2` pour les frais dynamiques.
-Il renvoie aussi _soit_ :
+Il renvoie également _soit_ :
-- `root` : `DATA` 32 octets de stateroot post-transaction (avant Byzantium)
-- `status`: `QUANTITY` soit `1` (succès) ou `0` (échec)
+- `root` : `DONNÉES` 32 octets de la racine de l'état post-transaction (avant Byzance)
+- `status` : `QUANTITÉ` soit `1` (succès), soit `0` (échec)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1333,12 +1430,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-Retourne des informations à propos d'un oncle d'un bloc par hachage et position de l'indice.
+Renvoie des informations sur un oncle d'un bloc par hachage et position de l'index de l'oncle.
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-1. `DATA`, 32 octets - Le hachage d'un bloc.
-2. `QUANTITY` - La position de l'oncle dans l'indice.
+1. `DONNÉES`, 32 octets - Le hachage d'un bloc.
+2. `QUANTITÉ` - La position de l'indice de l'oncle.
```js
params: [
@@ -1347,9 +1448,10 @@ params: [
]
```
-**Retourne** Voir [eth_getBlockByHash](#eth_getblockbyhash)
+**Retours**
+Voir [eth_getBlockByHash](#eth_getblockbyhash)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1358,16 +1460,20 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex"
Résultat voir [eth_getBlockByHash](#eth_getblockbyhash)
-**Remarque** : Un oncle ne contient pas de transactions individuelles.
+**Remarque** : un oncle ne contient pas de transactions individuelles.
### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-Renvoie des informations à propos d'un oncle d'un bloc par nombre et par position de l'indice.
+Renvoie des informations sur un oncle d'un bloc par numéro et position de l'index de l'oncle.
+
+
+ Essayer le point de terminaison dans le terrain de jeu
+
**Paramètres**
-1. `QUANTITY|TAG` - un numéro de bloc, ou la chaîne `« earliest »`, `« latest »`, `« pending »`, `« safe »`, ou `« finalized »`, comme dans le [paramètre de bloc par défaut](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - la position de l'oncle dans l'indice.
+1. `QUANTITÉ|TAG` - un numéro de bloc, ou la chaîne `\"earliest\"`, `\"latest\"`, `\"pending\"`, `\"safe\"`, `\"finalized\"`, comme dans le [paramètre de bloc](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITÉ` - la position de l'indice de l'oncle.
```js
params: [
@@ -1376,11 +1482,12 @@ params: [
]
```
-**Retourne** Voir [eth_getBlockByHash](#eth_getblockbyhash)
+**Retours**
+Voir [eth_getBlockByHash](#eth_getblockbyhash)
-**Remarque** : Un oncle ne contient pas de transactions individuelles.
+**Remarque** : un oncle ne contient pas de transactions individuelles.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1391,23 +1498,25 @@ Résultat voir [eth_getBlockByHash](#eth_getblockbyhash)
### eth_newFilter {#eth_newfilter}
-Crée un objet filtre, basé sur les options de filtre, pour avertir lorsque l'état change (logs). Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
+Crée un objet filtre, basé sur les options de filtre, pour avertir lorsque l'état change (logs).
+Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
-**Une note sur la spécification des filtres de sujet :** Les sujets sont dépendants de l'ordre. Une transaction avec un journal avec des sujets [A, B] sera mise en correspondance par les filtres de discussion suivants :
+**Remarque sur la spécification des filtres de sujets :**
+Les sujets dépendent de l'ordre. Une transaction avec un journal avec des sujets [A, B] sera mise en correspondance par les filtres de discussion suivants :
-- `[]` « n'importe quoi »
-- `[A]`: « A en première position (et n'importe quoi après) »
-- `[null, B]` « tout ce qui est en première position ET B en seconde position (et tout ce qui est après) »
-- `[A, B]` « A en première position ET B en deuxième position (et tout ce qui suivra) »
-- `[[A, B], [A, B]]` « (A OU B) en première position ET (A OU B) en deuxième position (et n'importe quoi après) »
+- `[]` « n'importe quoi »
+- `[A]` « A en première position (et n'importe quoi après) »
+- `[null, B]` « n'importe quoi en première position ET B en deuxième position (et n'importe quoi après) »
+- `[A, B]` « A en première position ET B en deuxième position (et n'importe quoi après) »
+- `[[A, B], [A, B]]` « (A OU B) en première position ET (A OU B) en deuxième position (et n'importe quoi après) »
- **Paramètres**
-1. `Object` - Les options de filtre :
+1. `Objet` - Les options de filtre :
-- `fromBlock`: `QUANTITY|TAG` - (optionnel, par défaut : `« latest »`) nombre entier de blocs, ou `« latest »` pour le dernier bloc proposé, `« safe »` pour le dernier bloc sécurisé, `« finalized »` pour le dernier bloc finalisé, ou `« pending »`, `« earliest »` pour les transactions ne faisant pas encore partie d'un bloc.
-- `toBlock`: `QUANTITY|TAG` - (optionnel, par défaut : `« latest »`) nombre entier de blocs, ou `« latest »` pour le dernier bloc proposé, `« safe »` pour le dernier bloc sécurisé, `« finalized »` pour le dernier bloc finalisé, ou `« pending »`, `« earliest »` pour les transactions ne faisant pas encore partie d'un bloc.
-- `address`: `DATA|Array`, 20 octets - (facultatif) adresse contractuelle ou une liste d'adresses d'où les logs doivent provenir.
-- `topics`: `Array of DATA`, - (facultatif) tableau de 32 bytes `DATA` topics. Les sujets dépendent de l'ordre. Chaque sujet peut également être un tableau de DATA avec des options "ou".
+- `fromBlock` : `QUANTITÉ|TAG` - (facultatif, par défaut : `\"latest\"`) Numéro de bloc entier, ou `\"latest\"` pour le dernier bloc proposé, `\"safe\"` pour le dernier bloc sûr, `\"finalized\"` pour le dernier bloc finalisé, ou `\"pending\"`, `\"earliest\"` pour les transactions qui ne sont pas encore dans un bloc.
+- `toBlock` : `QUANTITÉ|TAG` - (facultatif, par défaut : `\"latest\"`) Numéro de bloc entier, ou `\"latest\"` pour le dernier bloc proposé, `\"safe\"` pour le dernier bloc sûr, `\"finalized\"` pour le dernier bloc finalisé, ou `\"pending\"`, `\"earliest\"` pour les transactions qui ne sont pas encore dans un bloc.
+- `address` : `DONNÉES|Tableau`, 20 octets - (facultatif) Adresse de contrat ou liste d'adresses d'où les journaux doivent provenir.
+- `topics` : `Tableau de DONNÉES`, - (facultatif) Tableau de sujets `DONNÉES` de 32 octets. Les sujets dépendent de l'ordre. Chaque sujet peut également être un tableau de DATA avec des options « ou ».
```js
params: [
@@ -1427,9 +1536,10 @@ params: [
]
```
-**Renvoie** `QUANTITY` - Un id de filtre.
+**Retours**
+`QUANTITÉ` - Un ID de filtre.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1444,13 +1554,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic
### eth_newBlockFilter {#eth_newblockfilter}
-Crée un filtre dans le nœud, pour avertir lorsqu'un nouveau bloc arrive. Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
+Crée un filtre dans le nœud, pour avertir lorsqu'un nouveau bloc arrive.
+Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
-**Paramètres :** Aucun
+**Paramètres**
+Aucun
-**Renvoie** `QUANTITY` - Un id de filtre.
+**Retours**
+`QUANTITÉ` - Un ID de filtre.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1465,13 +1578,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],
### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-Crée un filtre dans le nœud, pour notifier quand de nouvelles transactions en attente arrivent. Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
+Crée un filtre dans le nœud, pour notifier quand de nouvelles transactions en attente arrivent.
+Pour vérifier si l'état a changé, appelez [eth_getFilterChanges](#eth_getfilterchanges).
-**Paramètres :** Aucun
+**Paramètres**
+Aucun
-**Renvoie** `QUANTITY` - Un id de filtre.
+**Retours**
+`QUANTITÉ` - Un ID de filtre.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1486,11 +1602,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter"
### eth_uninstallFilter {#eth_uninstallfilter}
-Désinstalle un filtre avec un identifiant donné. Doit toujours être appelé lorsque la montre n'est plus nécessaire. De plus, filtre le délai d'attente quand ils ne sont pas demandés avec [eth_getFilterChanges](#eth_getfilterchanges) pour une période de temps.
+Désinstalle un filtre avec un identifiant donné. Doit toujours être appelé lorsque la montre n'est plus nécessaire.
+De plus, les filtres expirent lorsqu'ils ne sont pas demandés avec [eth_getFilterChanges](#eth_getfilterchanges) pendant un certain temps.
**Paramètres**
-1. `QUANTITY` - L'identifiant du filtre.
+1. `QUANTITÉ` - L'ID du filtre.
```js
params: [
@@ -1498,9 +1615,10 @@ params: [
]
```
-**Retourne** `Boolean` - `true` si le filtre a été désinstallé avec succès, sinon `false`.
+**Retours**
+`Booléen` - `true` si le filtre a été désinstallé avec succès, sinon `false`.
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
@@ -1519,7 +1637,7 @@ Méthode de vote pour un filtre, qui retourne un tableau de logs qui s'est produ
**Paramètres**
-1. `QUANTITY` - L'identifiant du filtre.
+1. `QUANTITÉ` - l'ID du filtre.
```js
params: [
@@ -1527,26 +1645,30 @@ params: [
]
```
-**Retourne** `Array` - Tableau d'objets de log, ou un tableau vide si rien n'a changé depuis le dernier sondage.
+**Retours**
+`Tableau` - Tableau d'objets de journal, ou un tableau vide si rien n'a changé depuis le dernier sondage.
+
+- Pour les filtres créés avec `eth_newBlockFilter`, le retour est un hachage de bloc (`DONNÉES`, 32 octets), par exemple, `[\"0x3454645634534...\"]`.
+
+- Pour les filtres créés avec `eth_newPendingTransactionFilter`, le retour est un hachage de transaction (`DONNÉES`, 32 octets), par exemple `[\"0x6345343454645...\"]`.
+
+- Pour les filtres créés avec `eth_newFilter`, les journaux sont des objets avec les paramètres suivants :
+ - `removed` : `TAG` - `true` lorsque le journal a été supprimé, en raison d'une réorganisation de la chaîne. `false` s'il s'agit d'un journal valide.
+ - `logIndex` : `QUANTITÉ` - entier de la position de l'index du journal dans le bloc. `null` lorsqu'il s'agit d'un journal en attente.
+ - `transactionIndex` : `QUANTITÉ` - entier de la position de l'index des transactions à partir de laquelle le journal a été créé. `null` lorsqu'il s'agit d'un journal en attente.
+ - `transactionHash` : `DONNÉES`, 32 octets - hachage des transactions à partir desquelles ce journal a été créé. `null` lorsqu'il s'agit d'un journal en attente.
+ - `blockHash` : `DONNÉES`, 32 octets - hachage du bloc dans lequel se trouvait ce journal. `null` lorsqu'elle est en attente. `null` lorsqu'il s'agit d'un journal en attente.
+ - `blockNumber` : `QUANTITÉ` - le numéro de bloc où se trouvait ce journal. `null` lorsqu'elle est en attente. `null` lorsqu'il s'agit d'un journal en attente.
+ - `address` : `DONNÉES`, 20 octets - adresse d'où provient ce journal.
+ - `data` : `DONNÉES` - données de journal non indexées de longueur variable. (En _Solidity_ : zéro ou plusieurs arguments de journal non indexés de 32 octets.)
+ - `topics` : `Tableau de DONNÉES` - Tableau de 0 à 4 `DONNÉES` de 32 octets d'arguments de journal indexés. (En _Solidity_ : le premier sujet est le _hachage_ de la signature de l'événement (par ex., `Deposit(address,bytes32,uint256)`), sauf si vous avez déclaré l'événement avec le spécificateur `anonymous`.)
-- Pour les filtres créés avec `eth_newBlockFilter` le retour constitue des hachages de blocs (`DATA`, 32 octets), par exemple `["0x3454645634534..."]`.
-- Pour les filtres créés avec `eth_newPendingTransactionFilter` le retour constitue des hachages de transaction (`DATA`, 32 octets), par exemple `["0x6345343454645..."]`.
-- Pour les filtres créés avec `eth_newFilter`, les logs sont des objets avec les paramètres suivants :
- - `removed` : `TAG` - `true` lorsque le journal a été supprimé, en raison d'une réorganisation de chaîne. `false` si c'est un journal valide.
- - `logIndex`: `QUANTITY` - nombre entier de la position de l'indice des logs dans le bloc. `null` lors de son log en attente.
- - `transactionIndex` : `QUANTITY` - nombre entier à partir duquel le log de position de l'indice des transactions a été créé. `null` lors de son log en attente.
- - `transactionHash` : `DATA`, 32 octets - hachage des transactions à partir desquelles ce log a été créé. `null` lors de son log en attente.
- - `blockHash` : `DATA`, 32 octets - hachage du bloc dans lequel se trouvait ce log. `null` lors de son attente. `null` lors de son log en attente.
- - `blockNumber` : `QUANTITY` - le numéro de bloc où se trouvait ce log. `null` lors de son attente. `null` lors de son log en attente.
- - `address`: `DATA`, 20 octets - adresse à partir de laquelle ce journal est originaire.
- - `data`: `DATA` - contient zéro ou plus de 32 octets d'arguments non indexés du log.
- - `topics`: `Array of DATA` - Tableau de 0 à 4 32 octets `DATA` d'arguments de log indexés. (Dans _Solidity_: Le premier sujet est le _hash_ de la signature de l'événement (par ex. `Déposit(adresse,octets32,uint256)`), sauf que vous avez déclaré l'événement avec le `spécificateur anonyme`.)
-- **Exemple**
+- \*\*Exemple \*\*
```js
-// Request
+// Requête
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
+// Résultat
{
"id":1,
"jsonrpc":"2.0",
@@ -1571,7 +1693,7 @@ Retourne un tableau de tous les logs correspondant au filtre avec l'identifiant
**Paramètres**
-1. `QUANTITY` - L'identifiant du filtre.
+1. `QUANTITÉ` - L'ID du filtre.
```js
params: [
@@ -1579,16 +1701,17 @@ params: [
]
```
-**Retourne** Voir [eth_getFilterChanges](#eth_getfilterchanges)
+**Retours**
+Voir [eth_getFilterChanges](#eth_getfilterchanges)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
```
-Résultats voir [eth_getFilterChanges](#eth_getfilterchanges)
+Résultat voir [eth_getFilterChanges](#eth_getfilterchanges)
### eth_getLogs {#eth_getlogs}
@@ -1596,13 +1719,13 @@ Retourne un tableau de tous les logs correspondant à un objet filtre donné.
**Paramètres**
-1. `Object` - Les options de filtre :
+1. `Objet` - Les options de filtre :
-- `fromBlock`: `QUANTITY|TAG` - (optionnel, par défaut : `« latest »`) nombre entier de blocs, ou `« latest »` pour le dernier bloc proposé, `« safe »` pour le dernier bloc sécurisé, `« finalized »` pour le dernier bloc finalisé, ou `« pending »`, `« earliest »` pour les transactions ne faisant pas encore partie d'un bloc.
-- `toBlock`: `QUANTITY|TAG` - (optionnel, par défaut : `« latest »`) nombre entier de blocs, ou `« latest »` pour le dernier bloc proposé, `« safe »` pour le dernier bloc sécurisé, `« finalized »` pour le dernier bloc finalisé, ou `« pending »`, `« earliest »` pour les transactions ne faisant pas encore partie d'un bloc.
-- `address`: `DATA|Array`, 20 octets - (facultatif) adresse contractuelle ou une liste d'adresses d'où les logs doivent provenir.
-- `topics`: `Array of DATA`, - (facultatif) tableau de 32 bytes `DATA` topics. Les sujets dépendent de l'ordre. Chaque sujet peut également être un tableau de DATA avec des options "ou".
-- `blockhash`: `DATA`, 32 octets - (facultatif, **futur**) À l'ajout de EIP-234, `blockHash` sera une nouvelle option de filtre qui restreint les logs retournés au bloc unique avec le hachage de 32 octets `blockHash`. Utiliser `blockHash` est équivalent à `fromBlock` = `toBlock` = le numéro de bloc avec le hachage `blockHash`. Si `blockHash` est présent dans les critères de filtre, alors ni `fromBlock` ni `toBlock` ne sont autorisés.
+- `fromBlock` : `QUANTITÉ|TAG` - (facultatif, par défaut : `\"latest\"`) Numéro de bloc entier, ou `\"latest\"` pour le dernier bloc proposé, `\"safe\"` pour le dernier bloc sûr, `\"finalized\"` pour le dernier bloc finalisé, ou `\"pending\"`, `\"earliest\"` pour les transactions qui ne sont pas encore dans un bloc.
+- `toBlock` : `QUANTITÉ|TAG` - (facultatif, par défaut : `\"latest\"`) Numéro de bloc entier, ou `\"latest\"` pour le dernier bloc proposé, `\"safe\"` pour le dernier bloc sûr, `\"finalized\"` pour le dernier bloc finalisé, ou `\"pending\"`, `\"earliest\"` pour les transactions qui ne sont pas encore dans un bloc.
+- `address` : `DONNÉES|Tableau`, 20 octets - (facultatif) Adresse de contrat ou liste d'adresses d'où les journaux doivent provenir.
+- `topics` : `Tableau de DONNÉES`, - (facultatif) Tableau de sujets `DONNÉES` de 32 octets. Les sujets dépendent de l'ordre. Chaque sujet peut également être un tableau de DATA avec des options « ou ».
+- `blockHash` : `DONNÉES`, 32 octets - (facultatif, **futur**) Avec l'ajout de l'EIP-234, `blockHash` sera une nouvelle option de filtre qui restreint les journaux retournés au seul bloc avec le hachage de 32 octets `blockHash`. L'utilisation de `blockHash` est équivalente à `fromBlock` = `toBlock` = le numéro de bloc avec le hachage `blockHash`. Si `blockHash` est présent dans les critères de filtre, ni `fromBlock` ni `toBlock` ne sont autorisés.
```js
params: [
@@ -1614,24 +1737,25 @@ params: [
]
```
-**Retourne** Voir [eth_getFilterChanges](#eth_getfilterchanges)
+**Retours**
+Voir [eth_getFilterChanges](#eth_getfilterchanges)
-**Exemple**
+\*\*Exemple \*\*
```js
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
```
-Résultats voir [eth_getFilterChanges](#eth_getfilterchanges)
+Résultat voir [eth_getFilterChanges](#eth_getfilterchanges)
## Exemple d'utilisation {#usage-example}
-### Déploiement d'un contrat en utilisant JSON_RPC {#deploying-contract}
+### Déploiement d'un contrat à l'aide de JSON-RPC {#deploying-contract}
-Cette section comprend une démonstration de la façon de déployer un contrat en utilisant uniquement l'interface RPC. Il existe des voies alternatives pour le déploiement de contrats où cette complexité est abstraite, par exemple, en utilisant des bibliothèques construites au dessus de l'interface RPC comme [web3.js](https://web3js.readthedocs.io/) et [web3.py](https://github.com/ethereum/web3.py). Ces abstractions sont généralement plus faciles à comprendre et moins sujettes aux erreurs, mais il est toujours utile de comprendre ce qui se passe sous le capot.
+Cette section comprend une démonstration de la façon de déployer un contrat en utilisant uniquement l'interface RPC. Il existe d'autres moyens de déployer des contrats où cette complexité est abstraite, par exemple, en utilisant des bibliothèques construites sur l'interface RPC telles que [web3.js](https://web3js.readthedocs.io/) et [web3.py](https://github.com/ethereum/web3.py). Ces abstractions sont généralement plus faciles à comprendre et moins sujettes aux erreurs, mais il est toujours utile de comprendre ce qui se passe sous le capot.
-Ce qui suit est un contrat intelligent simple appelé `Multiply7` qui sera déployé à l'aide de l'interface JSON-RPC sur un nœud Ethereum. Ce tutoriel suppose que le lecteur exécute déjà un nœud Geth. Plus d'informations sur les nœuds et les clients sont disponibles [ici](/developers/docs/nodes-and-clients/run-a-node). Veuillez vous référer à la documentation de [client](/developers/docs/nodes-and-clients/) individuelle pour voir comment démarrer le JSON-RPC HTTP pour les clients non-Geth. La plupart des clients servent par défaut sur `localhost:8545`.
+Ce qui suit est un contrat intelligent simple appelé `Multiply7` qui sera déployé à l'aide de l'interface JSON-RPC sur un nœud Ethereum. Ce tutoriel suppose que le lecteur exécute déjà un nœud Geth. Plus d'informations sur les nœuds et les clients sont disponibles [ici](/developers/docs/nodes-and-clients/run-a-node). Veuillez vous référer à la documentation de chaque [client](/developers/docs/nodes-and-clients/) pour voir comment démarrer le JSON-RPC HTTP pour les clients non-Geth. La plupart des clients servent par défaut sur `localhost:8545`.
```javascript
contract Multiply7 {
@@ -1649,12 +1773,12 @@ La première chose à faire est de s'assurer que l'interface HTTP RPC est activ
geth --http --dev console 2>>geth.log
```
-Cela démarrera l'interface HTTP RPC sur `http://localhost:8545`.
+Cela démarrera l'interface RPC HTTP sur `http://localhost:8545`.
Nous pouvons vérifier que l'interface est en cours d'exécution en récupérant l'adresse coinbase (en obtenant la première adresse dans le tableau des comptes) et le solde en utilisant [curl](https://curl.se). Veuillez noter que les données contenues dans ces exemples seront différentes sur votre noeud local. Si vous voulez essayer ces commandes, remplacez les paramètres de la requête dans la deuxième requête avec le résultat retourné par la première.
```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
@@ -1668,9 +1792,9 @@ web3.fromWei("0x1639e49bba16280000", "ether")
// "410"
```
-Maintenant que notre chaîne de développement privé a un certain poids, nous pouvons déployer le contrat. La première étape est de compiler le contrat Multiply7 en byte code qui peut être envoyé à l'EVM. Pour installer solc, le compilateur Solidity, suivez la [documentation Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Vous pouvez utiliser une ancienne version `solc` à des fins de correspondance à [la version du compilateur utilisée pour notre exemple](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
+Maintenant que notre chaîne de développement privé a un certain poids, nous pouvons déployer le contrat. La première étape est de compiler le contrat Multiply7 en byte code qui peut être envoyé à l'EVM. Pour installer solc, le compilateur Solidity, suivez la [documentation Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Vous voudrez peut-être utiliser une ancienne version de `solc` pour correspondre à [la version du compilateur utilisée pour notre exemple](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
-L'étape suivante est de compiler le contrat Multiply7 en code d'octets qui peut être envoyé à l'EVM.
+L'étape suivante consiste à compiler le contrat Multiply7 en code d'octet qui peut être envoyé à l'EVM.
```bash
echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
@@ -1694,7 +1818,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from
{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
```
-La transaction est acceptée par le noeud et un hachage de la transaction est retourné. Ce hachage peut être utilisé pour suivre la transaction. La prochaine étape consiste à déterminer l'adresse où notre contrat est déployé. Chaque transaction exécutée créera un reçu. Ce reçu contient diverses informations sur la transaction telle que le bloc dans lequel la transaction a été incluse et la quantité de gaz utilisée par l'EVM. Si une transaction crée un contrat, elle contiendra également l'adresse du contrat. Nous pouvons récupérer le reçu avec la méthode `eth_getTransactionReceipt` RPC.
+La transaction est acceptée par le noeud et un hachage de la transaction est retourné. Ce hachage peut être utilisé pour suivre la transaction. La prochaine étape consiste à déterminer l'adresse où notre contrat est déployé. Chaque transaction exécutée créera un reçu. Ce reçu contient diverses informations sur la transaction telle que le bloc dans lequel la transaction a été incluse et la quantité de gaz utilisée par l'EVM. Si une transaction crée un contrat, elle contiendra également l'adresse du contrat. Nous pouvons récupérer le reçu avec la méthode RPC `eth_getTransactionReceipt`.
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
@@ -1705,9 +1829,9 @@ Notre contrat a été créé sur `0x4d03d617d700cf81935d7f797f4e2ae719648262`. U
#### Interagir avec les contrats intelligents {#interacting-with-smart-contract}
-Dans cet exemple, nous enverrons une transaction en utilisant `eth_sendTransaction` à la méthode `multiply` du contrat.
+Dans cet exemple, nous allons envoyer une transaction en utilisant `eth_sendTransaction` à la méthode `multiply` du contrat.
-`eth_sendTransaction` nécessite plusieurs arguments, spécifiquement `from`, `to` et `data`. `From` est l'adresse publique de notre compte et `to` est l'adresse du contrat. L'argument `data` contient une charge utile qui définit quelle méthode doit être appelée et avec quels arguments. C'est ici que [l'ABI (interface binaire de l'application)](https://docs.soliditylang.org/en/latest/abi-spec.html) entre en jeu. L'ABI est un fichier JSON qui définit comment définir et encoder les données pour l'EVM.
+`eth_sendTransaction` nécessite plusieurs arguments, en particulier `from`, `to` et `data`. `From` est l'adresse publique de notre compte et `to` est l'adresse du contrat. L'argument `data` contient une charge utile qui définit quelle méthode doit être appelée et avec quels arguments. C'est là que l'[ABI (interface binaire d'application)](https://docs.soliditylang.org/en/latest/abi-spec.html) entre en jeu. L'ABI est un fichier JSON qui définit comment définir et encoder les données pour l'EVM.
Les octets de la charge utile définissent quelle méthode dans le contrat est appelée. Il s'agit des 4 premiers octets du hachage de Keccak sur le nom de la fonction et ses types d'arguments, encodés en hexa. La fonction multiplier accepte un uint qui est un alias pour uint256. Cela nous laisse avec :
@@ -1718,11 +1842,11 @@ web3.sha3("multiply(uint256)").substring(0, 10)
L'étape suivante est d'encoder les arguments. Il n'y a qu'un seul uint256, par exemple, la valeur 6. L'ABI a une section qui spécifie comment encoder les types uint256.
-`int: enc(X)` est l'encodage gros-boutiste en complément à deux de X, ajouté sur le côté supérieur (gauche) avec Jeff pour X négatif et avec zéro > octets pour X positif de sorte que la longueur est un multiple de 32 octets.
+`int: enc(X)` est l'encodage en complément à deux gros-boutiste de X, complété sur le côté d'ordre supérieur (gauche) avec 0xff pour X négatif et avec des octets nuls pour X positif de sorte que la longueur soit un multiple de 32 octets.
Ceci encode en `0000000000000000000000000000000000000000000000000000000000000006`.
-La combinaison du sélecteur de fonction et de l'argument encodé sera `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
+En combinant le sélecteur de fonction et l'argument encodé, nos données seront `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
Cela peut maintenant être envoyé au nœud :
@@ -1755,7 +1879,7 @@ Puisqu'une transaction a été envoyée, un hachage de transaction a été retou
}
```
-Le reçu contient un journal d'activités. Ce journal a été généré par l'EVM lors de l'exécution de la transaction et est inclus dans le reçu. La fonction `multiply` montre que l'événement `Print` a été levé avec le temps d'entrée 7. Puisque l'argument de l'événement `Print` était un uint256, nous pouvons le décoder selon les règles ABI qui nous laisseront avec la décimale prévue 42. Mis à part les données, il est intéressant de noter que les sujets peuvent être utilisés pour déterminer quel événement a créé le journal :
+Le reçu contient un journal d'activités. Ce journal a été généré par l'EVM lors de l'exécution de la transaction et est inclus dans le reçu. La fonction `multiply` montre que l'événement `Print` a été déclenché avec l'entrée fois 7. Puisque l'argument pour l'événement `Print` était un uint256, nous pouvons le décoder selon les règles de l'ABI, ce qui nous donnera la décimale attendue 42. Mis à part les données, il est intéressant de noter que les sujets peuvent être utilisés pour déterminer quel événement a créé le journal :
```javascript
web3.sha3("Print(uint256)")
@@ -1767,7 +1891,7 @@ Il ne s'agissait que d'une brève introduction à certaines des tâches les plus
## Sujets connexes {#related-topics}
- [Spécification JSON-RPC](http://www.jsonrpc.org/specification)
-- [ Nœuds et clients](/developers/docs/nodes-and-clients/)
+- [Nœuds et clients](/developers/docs/nodes-and-clients/)
- [API JavaScript](/developers/docs/apis/javascript/)
-- [API back-end](/developers/docs/apis/backend/)
+- [API backend](/developers/docs/apis/backend/)
- [Clients d'exécution](/developers/docs/nodes-and-clients/#execution-clients)
diff --git a/public/content/translations/fr/developers/docs/blocks/index.md b/public/content/translations/fr/developers/docs/blocks/index.md
index 0f2746b983a..357fb5a1d3b 100644
--- a/public/content/translations/fr/developers/docs/blocks/index.md
+++ b/public/content/translations/fr/developers/docs/blocks/index.md
@@ -1,6 +1,6 @@
---
title: Blocs
-description: Présentation des blocs de la blockchain Ethereum, leur structure de données, pourquoi ils sont nécessaires et comment ils sont créés.
+description: "Présentation des blocs de la blockchain Ethereum, leur structure de données, pourquoi ils sont nécessaires et comment ils sont créés."
lang: fr
---
@@ -8,13 +8,14 @@ Les blocs sont des lots de transactions avec un hachage du bloc précédent dans
## Prérequis {#prerequisites}
-Les blocs sont un sujet très accessible pour les débutants. Mais pour vous aider à mieux comprendre cette page, nous vous recommandons de commencer par lire les pages [Comptes](/developers/docs/accounts/), [Transactions](/developers/docs/transactions/) et [Introduction à Ethereum](/developers/docs/intro-to-ethereum/).
+Les blocs sont un sujet très accessible pour les débutants. Mais pour vous aider à mieux comprendre cette page, nous vous recommandons de lire d'abord [Comptes](/developers/docs/accounts/), [Transactions](/developers/docs/transactions/), et notre [introduction à Ethereum](/developers/docs/intro-to-ethereum/).
## Pourquoi les blocs? {#why-blocks}
Afin de s'assurer que tous les participants du réseau Ethereum restent synchronisés et s'accordent sur l'historique exacte des transactions, les transactions sont traitées par blocs. Cela signifie que des dizaines (ou centaines) de transactions sont engagées, acceptées et synchronisées en même temps.
- _Schéma adapté à partir du document [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramme adapté de [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
En espaçant les engagements, nous donnons à tous les participants du serveur assez de temps pour parvenir à un consensus : même si les demande de transaction se présentent des dizaines de fois par seconde, les blocs sont seulement créés et engagés sur Ethereum toutes les douze secondes.
@@ -24,39 +25,39 @@ Pour préserver l'historique des transactions, les blocs sont strictement ordonn
Une fois qu'un bloc a été lié aux autres blocs par un validateur sélectionné aléatoirement sur le réseau, il est scellé au reste du réseau ; ce bloc ajouté à la chaîne de bloc (blockchain) est lié au précédent, et une copie est transmise à tous les noeuds du réseau, ensuite un autre validateur est sélectionné pour créer le nouveau bloc. Le processus exact d'assemblage de blocs et le processus d'engagement/consensus sont actuellement spécifiés par le protocole de la « preuve d'enjeu » d'Ethereum.
-## Protocole de la preuve d'enjeu {#proof-of-work-protocol}
+## Protocole de preuve d'enjeu {#proof-of-stake-protocol}
La preuve d'enjeu implique les éléments suivants :
- La validation des nœuds nécessite de miser 32 ETH dans un contrat de dépôt comme collatéral contre les mauvais comportements. Cela aide à protéger le réseau puisque des activités manifestement malhonnêtes mènent à la destruction de tout ou partie des mises.
- Dans chaque créneau (espacés de douze secondes), un validateur est sélectionné aléatoirement pour être le proposant de bloc. Ils regroupent les transactions ensemble, les exécutent et déterminent un nouvel « état ». Ils enveloppent ces informations dans un bloc et les transmettent à d'autres validateurs.
-- Les autres validateurs qui entendent parler d'un nouveau bloc exécutent à nouveau les transactions pour s'assurer qu'ils sont d'accord avec le changement proposé d'état global. En supposant que le bloc soit valide, ils l'ajoutent à leur propre base de données.
+- Les autres validateurs qui ont connaissance du nouveau bloc réexécutent les transactions pour s'assurer qu'ils sont d'accord avec la modification proposée de l'état global. En supposant que le bloc soit valide, ils l'ajoutent à leur propre base de données.
- Si des validateurs entendent parler de deux blocs en conflit pour le même créneau, ils utilisent leur algorithme de choix de fourche pour choisir celui supporté par le plus grand nombre de mise en jeu d'ETH.
[En savoir plus sur la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos)
-## Que contient un bloc ? {#block-anatomy}
+## Que contient un bloc ? Anatomie du bloc {#block-anatomy}
Un bloc contient de nombreuses informations. Au plus haut niveau, un bloc contient les champs suivants :
| Champ | Description |
-|:---------------- |:-------------------------------------------------------------- |
-| `Créneau` | le créneau auquel appartient le bloc |
+| :--------------- | :------------------------------------------------------------- |
+| `créneau` | le créneau auquel appartient le bloc |
| `proposer_index` | l'ID du validateur proposant le bloc |
| `parent_root` | le hachage du bloc précédent |
| `state_root` | le hachage racine de l'objet état |
| `présentation` | un objet contenant plusieurs champs, tel que défini ci-dessous |
-Le corps `body` du bloc contient plusieurs champs propres :
+Le corps `body` du bloc contient plusieurs champs qui lui sont propres :
| Champ | Description |
-|:-------------------- |:-------------------------------------------------------------------- |
+| :------------------- | :------------------------------------------------------------------- |
| `randao_reveal` | une valeur utilisée pour sélectionner le prochain proposant de bloc |
| `eth1_data` | informations sur le contrat de dépôt |
| `graffiti` | données arbitraires utilisées pour étiqueter les blocs |
| `proposer_slashings` | liste des validateurs à délester |
| `attester_slashings` | liste des validateurs à sanctionner |
-| `attestations` | liste des attestations en faveur du bloc actuel |
+| `attestations` | liste des attestations effectuées pour les créneaux précédents |
| `dépôts` | liste des nouveaux dépôts au contrat de dépôt |
| `voluntary_exits` | liste des validateurs quittant le réseau |
| `sync_aggregate` | sous-ensemble de validateurs utilisés pour servir les clients légers |
@@ -64,48 +65,48 @@ Le corps `body` du bloc contient plusieurs champs propres :
Le champ `attestations` contient une liste de toutes les attestations dans le bloc. Les attestations ont leur propre type de données, qui contient plusieurs morceaux de données. Chaque attestation contient :
-| Champ | Description |
-|:------------------ |:------------------------------------------------------------- |
-| `aggregation_bits` | une liste des validateurs ayant participé à cette attestation |
-| `données` | un conteneur avec plusieurs sous-champs |
-| `signature` | agrégat de signature de tous les validateurs attestant |
-
-Le champ `data` dans `attestation` contient les éléments suivants :
-
-| Champ | Description |
-|:------------------- |:--------------------------------------------------- |
-| `Créneau` | le créneau auquel se rapporte l'attestation |
-| `Index` | indices pour les validateurs attestant |
-| `beacon_block_root` | le hachage racine du bloc Phare contenant cet objet |
-| `source` | le dernier point de contrôle justifié |
-| `target` | le dernier bloc limite de l'époque |
-
-Exécuter les transactions dans `execution_payload` met à jour l'état global. Tous les clients réexécutent les transactions dans le champ `execution_payload` pour s'assurer que le nouvel état corresponde à celui du champ `state_root` du nouveau bloc. C'est ainsi que les clients peuvent dire qu'un nouveau bloc est valide et sûr afin de l'ajouter à leur blockchain. Le `bloc d'exécution` est lui-même un objet doté de plusieurs champs. Il existe également un `execution_payload_header` qui contient des informations sommaires importantes sur les données d'exécution. Ces structures des données sont organisées de la manière suivante :
-
-`execution_payload_header` contient les champs suivants :
-
-| Champ | Description |
-|:------------------- |:----------------------------------------------------------------------------------- |
-| `parent_hash` | hachage du bloc parent |
-| `fee_recipient` | adresse du compte pour le paiement des frais de transaction |
-| `state_root` | hachage racine pour l'état global après avoir appliqué les changements dans ce bloc |
-| `receipts_root` | hachage de la transaction de l'arboresence des reçus |
-| `logs_bloom` | structure de données contenant les journaux d'événements |
-| `prev_randao` | valeur utilisée dans la sélection aléatoire du validateur |
-| `block_number` | le numéro de bloc actuel |
-| `gas_limit` | gaz maximum autorisé dans ce bloc |
-| `gas_used` | la quantité de gaz réelle utilisée dans ce bloc |
-| `horodatage` | la durée du bloc |
-| `extra_data` | données supplémentaires arbitraires en octets bruts |
-| `base_fee_per_gas` | la valeur des frais de base |
-| `block_hash` | hachage du bloc d'exécution |
-| `transactions_root` | hachage racine des transactions dans le bloc |
-| `withdrawal_root` | hachage racine des retraits dans le bloc |
-
-`execution_payload` contient lui-même ce qui suit (notez que cela est identique à l'en-tête sauf qu'au lieu du hachage racine des transactions, il inclut la liste réelle des transactions et des informations de retrait) :
+| Champ | Description |
+| :----------------- | :-------------------------------------------------------------------------- |
+| `aggregation_bits` | une liste des validateurs ayant participé à cette attestation |
+| `données` | un conteneur avec plusieurs sous-champs |
+| `signature` | signature agrégée d'un ensemble de validateurs portant sur la partie `data` |
+
+Le champ `data` dans l'`attestation` contient les éléments suivants :
+
+| Champ | Description |
+| :------------------ | :------------------------------------------------------------------- |
+| `créneau` | le créneau auquel se rapporte l'attestation |
+| `index` | indices pour les validateurs attestant |
+| `beacon_block_root` | le hachage racine du bloc phare considéré comme la tête de la chaîne |
+| `source` | le dernier point de contrôle justifié |
+| `target` | le dernier bloc limite de l'époque |
+
+L'exécution des transactions dans `execution_payload` met à jour l'état global. Tous les clients réexécutent les transactions dans l'`execution_payload` pour s'assurer que le nouvel état corresponde à celui du champ `state_root` du nouveau bloc. C'est ainsi que les clients peuvent dire qu'un nouveau bloc est valide et sûr afin de l'ajouter à leur blockchain. La `charge utile d'exécution` elle-même est un objet avec plusieurs champs. Il existe également un `execution_payload_header` qui contient d'importantes informations récapitulatives sur les données d'exécution. Ces structures des données sont organisées de la manière suivante :
+
+L'`execution_payload_header` contient les champs suivants :
+
+| Champ | Description |
+| :------------------ | :-------------------------------------------------------------------------------- |
+| `parent_hash` | hachage du bloc parent |
+| `fee_recipient` | adresse du compte pour le paiement des frais de transaction |
+| `state_root` | hachage racine pour l'état global une fois appliqués les changements dans ce bloc |
+| `receipts_root` | hachage de la transaction de l'arborescence des reçus |
+| `logs_bloom` | structure de données contenant les journaux d'événements |
+| `prev_randao` | valeur utilisée dans la sélection aléatoire du validateur |
+| `block_number` | le numéro de bloc actuel |
+| `gas_limit` | gaz maximum autorisé dans ce bloc |
+| `gas_used` | la quantité de gaz réelle utilisée dans ce bloc |
+| `timestamp` | le temps de bloc |
+| `extra_data` | données supplémentaires arbitraires en octets bruts |
+| `base_fee_per_gas` | la valeur des frais de base |
+| `block_hash` | hachage du bloc d'exécution |
+| `transactions_root` | hachage racine des transactions dans le bloc |
+| `withdrawal_root` | hachage racine des retraits dans le bloc |
+
+L'`execution_payload` lui-même contient ce qui suit (notez que c'est identique à l'en-tête, sauf qu'au lieu du hachage racine des transactions, il inclut la liste réelle des transactions et les informations de retrait) :
| Champ | Description |
-|:------------------ |:--------------------------------------------------------------------------------- |
+| :----------------- | :-------------------------------------------------------------------------------- |
| `parent_hash` | hachage du bloc parent |
| `fee_recipient` | adresse du compte pour le paiement des frais de transaction |
| `state_root` | hachage racine pour l'état global une fois appliqués les changements dans ce bloc |
@@ -119,29 +120,29 @@ Exécuter les transactions dans `execution_payload` met à jour l'état global.
| `extra_data` | données supplémentaires arbitraires en octets bruts |
| `base_fee_per_gas` | la valeur des frais de base |
| `block_hash` | hachage du bloc d'exécution |
-| `des transactions` | liste des transactions à exécuter |
+| `transactions` | liste des transactions à exécuter |
| `retraits` | liste des objets de retrait |
-La liste `withdrawals` contient les objets `withdrawal` structurée de la façon suivante :
+La liste `withdrawals` contient des objets `withdrawal` structurés de la manière suivante :
| Champ | Description |
-|:---------------- |:---------------------------------- |
-| `address` | adresse du compte qui s'est retiré |
+| :--------------- | :--------------------------------- |
+| `adresse` | adresse du compte qui s'est retiré |
| `montant` | montant du retrait |
-| `Index` | valeur d'index du retrait |
+| `index` | valeur d'index du retrait |
| `validatorIndex` | valeur d'index du validateur |
-## Durée de blocage {#block-time}
+## Temps de bloc {#block-time}
Le temps de bloc fait référence au temps qui sépare les blocs. Dans Ethereum, le temps est divisé en unités de douze secondes appelées « créneau ». Pour chaque créneau, un validateur est choisi pour proposer un bloc. Si tous les validateurs sont en ligne et complétement opérationnels, il y aura un bloc dans chaque créneau, ce qui signifie que le temps de bloc est de 12 s. Occasionnellement, des validateurs peuvent être hors-ligne lorsqu'ils sont appelés pour valider un bloc, de sorte que les créneaux peuvent parfois être vide.
-Cette implémentation diffère des systèmes fondés sur la preuve de travail (PoW), dans lesquels la génération d'un bloc est une occurrence naturelle, compensée par la difficulté de mining du protocole. Le temps moyen de propagation des blocs d'Ethereum [average block time](https://etherscan.io/chart/blocktime) est l'exemple parfait de l'implementation de la preuve d'enjeu, et donc du passage de la preuve de travail (PoW) à la preuve d'enjeu (PoS), rendu possible grâce à un nouvel ajustement du temps de propagation des blocs, qui est passé à 12 secondes.
+Cette implémentation diffère des systèmes fondés sur la preuve de travail (PoW), dans lesquels la génération d'un bloc est une occurrence naturelle, compensée par la difficulté de mining du protocole. Le [temps de bloc moyen](https://etherscan.io/chart/blocktime) d'Ethereum en est un parfait exemple, car il permet de déduire clairement la transition de la preuve de travail à la preuve d'enjeu grâce à la régularité du nouveau temps de bloc de 12 s.
-## Taille des blocs {#block-size}
+## Taille de bloc {#block-size}
Une dernière remarque importante : les blocs eux-mêmes sont limités par la taille. Chaque bloc vise une taille cible de 30 millions de gaz, mais leur taille s'adapte aux exigences du réseau, jusqu'à la limite de 60 millions de gaz (deux fois la taille cible de bloc). La limite de gaz d'un bloc peut être ajustée à la hausse ou à la baisse par un facteur de 1/1024 par rapport à la limite de gaz du bloc précédent. Ainsi, les validateurs peuvent modifier la limite de gaz des blocs par consensus. La quantité totale de gaz dépensée par toutes les transactions dans le bloc doit être inférieure à la limite de gaz du bloc. Ce point est important car il garantit que les blocs ne peuvent pas être arbitrairement grands. Si les blocs pouvaient être arbitrairement grands, les nœuds complets moins performants cesseraient progressivement de suivre le réseau à cause des exigences d'espace et de vitesse. Plus le bloc est grand, plus il faut de puissance de calcul pour traiter la transaction à temps pour le prochain créneau. Il s'agit d'un facteur de centralisation, auquel nous nous opposons en plafonnant la taille des blocs.
-## Complément d'information {#further-reading}
+## En savoir plus {#further-reading}
_Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !_
diff --git a/public/content/translations/fr/developers/docs/bridges/index.md b/public/content/translations/fr/developers/docs/bridges/index.md
index d0c7c2af504..bb5eb5b5067 100644
--- a/public/content/translations/fr/developers/docs/bridges/index.md
+++ b/public/content/translations/fr/developers/docs/bridges/index.md
@@ -1,12 +1,12 @@
---
title: Passerelles
-description: Un aperçu de la passerelle pour les développeurs
+description: "Un aperçu de la passerelle pour les développeurs"
lang: fr
---
-Avec la prolifération des blockchains L1 et des solutions L2 [scaling](/developers/docs/scaling/), aux côtés d'un nombre sans cesse croissant d'applications décentralisées passant d'une chaîne à l'autre, la nécessité de communiquer et de déplacer les actifs d'une chaîne à l'autre est devenue un élément essentiel de l'infrastructure du réseau. Différents types de passerelles existent pour aider à rendre cela possible.
+Avec la prolifération des blockchains L1 et des solutions de [mise à l'échelle](/developers/docs/scaling/) L2, ainsi qu'un nombre toujours croissant d'applications décentralisées devenant inter-chaînes, le besoin de communication et de mouvement d'actifs entre les chaînes est devenu une partie essentielle de l'infrastructure du réseau. Différents types de passerelles existent pour aider à rendre cela possible.
-## Besoin de passerelles {#need-for-bridges}
+## Besoin de ponts {#need-for-bridges}
Des ponts existent pour connecter les différentes blockchains. Ils permettent la connectivité et l'interopérabilité entre les blockchains.
@@ -14,7 +14,7 @@ Les blockchains existent dans des environnements cloisonnés, ce qui signifie qu
Les ponts offrent un moyen pour des environnements isolés de la blockchain de se connecter entre eux. Ils établissent une voie de transport entre les blockchains où les jetons, les messages, les données arbitraires et même les appels de [contrats intelligents](/developers/docs/smart-contracts/) peuvent être transférés d'une chaîne à l'autre.
-## Avantages des passerelles {#benefits-of-bridges}
+## Avantages des ponts {#benefits-of-bridges}
En termes simples, les ponts débloquent de nombreux cas d'utilisation en permettant aux réseaux blockchain d'échanger des données et de déplacer des actifs entre eux.
@@ -30,49 +30,49 @@ Pour les développeurs, les ponts activent les éléments suivants :
## Comment fonctionnent les ponts ? {#how-do-bridges-work}
-Bien qu'il existe différents [types de modèles de ponts](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), trois façons de faciliter le transfert inter-chaîne d'actifs se distinguent :
+Bien qu'il existe de nombreux [types de conceptions de ponts](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), trois manières de faciliter le transfert inter-chaînes d'actifs se distinguent :
-- **Verrouiller et frapper -** Verrouiller les actifs sur la chaîne source et frapper les actifs sur la chaîne de destination.
-- **Brûler et frapper -** Brûler les actifs sur la chaîne source et frapper les actifs sur la chaîne de destination.
-- **Échanges atomiques -** Échanger des actifs sur la chaîne source contre des actifs sur la chaîne de destination avec une autre partie.
+- **Verrouiller et frapper –** Verrouiller les actifs sur la chaîne source et frapper les actifs sur la chaîne de destination.
+- **Brûler et frapper –** Brûler les actifs sur la chaîne source et frapper les actifs sur la chaîne de destination.
+- **Échanges atomiques –** Échanger des actifs sur la chaîne source contre des actifs sur la chaîne de destination avec une autre partie.
## Types de ponts {#bridge-types}
Les ponts peuvent généralement être classés dans l'un des compartiments suivants :
-- **Ponts natifs -** Ces ponts sont généralement construits pour amorcer la liquidité sur une blockchain particulière, ce qui permet aux utilisateurs de transférer plus facilement des fonds vers l'écosystème. Par exemple, l'[Arbitrum Bridge](https://bridge.arbitrum.io/) est conçu pour permettre aux utilisateurs de passer facilement du réseau principal Ethereum à Arbitrum. Parmi les autres ponts de ce type, citons le pont PoS Polygon, [Optimism Gateway](https://app.optimism.io/bridge), etc.
-- **Ponts basés sur des validateurs ou des oracles -** Ces ponts s'appuient sur un ensemble de validateurs ou d'oracles externes pour valider les transferts inter-chaînes. Exemples : Multichain et Across.
-- **Passerelles généralisées de passage de messages -** Ces passerelles peuvent transférer des actifs, ainsi que des messages et des données arbitraires à travers les chaînes. Exemples : Axelar, LayerZero, et Nomad.
-- **Réseaux de liquidité -** Ces ponts se concentrent principalement sur le transfert d'actifs d'une chaîne à une autre via des swaps atomiques. En général, ils ne prennent pas en charge le passage de messages inter-chaînes. Exemples : Connext et Hop.
+- **Ponts natifs –** Ces ponts sont généralement construits pour amorcer la liquidité sur une blockchain particulière, ce qui permet aux utilisateurs de transférer plus facilement des fonds vers l'écosystème. Par exemple, le [pont Arbitrum](https://bridge.arbitrum.io/) est conçu pour permettre aux utilisateurs de passer facilement du réseau principal Ethereum à Arbitrum. D'autres ponts de ce type incluent le pont PoS de Polygon, [Optimism Gateway](https://app.optimism.io/bridge), etc.
+- **Ponts basés sur un validateur ou un oracle –** Ces ponts s'appuient sur un ensemble de validateurs ou d'oracles externes pour valider les transferts inter-chaînes. Exemples : Multichain et Across.
+- **Ponts généralisés de transmission de messages –** Ces ponts peuvent transférer des actifs, ainsi que des messages et des données arbitraires entre les chaînes. Exemples : Axelar, LayerZero, et Nomad.
+- **Réseaux de liquidités –** Ces ponts se concentrent principalement sur le transfert d'actifs d'une chaîne à une autre via des échanges atomiques. En général, ils ne prennent pas en charge le passage de messages inter-chaînes. Exemples : Connext et Hop.
-## Les compromis à prendre en compte {#trade-offs}
+## Compromis à prendre en compte {#trade-offs}
Avec les ponts, il n'y a pas de solution parfaite. Au contraire, il n'y a que des compromis faits pour remplir un objectif. Les développeurs et les utilisateurs peuvent évaluer les ponts en fonction des facteurs suivants :
-- **Sécurité -** Qui vérifie le système ? Les ponts sécurisés par des validateurs externes sont généralement moins sûrs que les ponts qui sont sécurisés localement ou nativement par les validateurs de la blockchain.
-- **Convivialité -** Combien de temps faut-il pour effectuer une transaction, et combien de transactions un utilisateur a-t-il dû signer ? Pour un développeur, combien de temps faut-il pour intégrer un pont, et quelle est la complexité du processus ?
-- **Connectivité -** Quelles sont les différentes chaînes de destination qu'un pont peut connecter (c'est-à-dire les rollups, les chaînes latérales, les autres blockchains de couche 1, etc.), et quelle est la difficulté d'intégrer une nouvelle blockchain ?
-- **Capacité à transmettre des données plus complexes -** Un pont peut-il permettre le transfert de messages et de données arbitraires plus complexes à travers les chaînes, ou ne prend-il en charge que les transferts d'actifs inter-chaînes ?
-- **Coût-efficacité -** Combien cela coûte-t-il de transférer des actifs d'une chaîne à l'autre via un pont ? En général, les ponts facturent une redevance fixe ou variable en fonction du coût du gaz et de la liquidité de certains itinéraires. Il est également essentiel d'évaluer la rentabilité d'un pont en fonction du capital nécessaire pour assurer sa sécurité.
+- **Sécurité –** Qui vérifie le système ? Les ponts sécurisés par des validateurs externes sont généralement moins sûrs que les ponts qui sont sécurisés localement ou nativement par les validateurs de la blockchain.
+- **Commodité –** Combien de temps faut-il pour finaliser une transaction et combien de transactions un utilisateur doit-il signer ? Pour un développeur, combien de temps faut-il pour intégrer un pont, et quelle est la complexité du processus ?
+- **Connectivité –** Quelles sont les différentes chaînes de destination qu'un pont peut connecter (p. ex. rollups, chaînes latérales, autres blockchains de couche 1, etc.) et quel est le degré de difficulté pour intégrer une nouvelle blockchain ?
+- **Capacité à transmettre des données plus complexes –** Un pont peut-il permettre le transfert de messages et de données arbitraires plus complexes entre les chaînes, ou ne prend-il en charge que les transferts d'actifs inter-chaînes ?
+- **Rentabilité –** Combien coûte le transfert d'actifs entre les chaînes via un pont ? En général, les ponts facturent une redevance fixe ou variable en fonction du coût du gaz et de la liquidité de certains itinéraires. Il est également essentiel d'évaluer la rentabilité d'un pont en fonction du capital nécessaire pour assurer sa sécurité.
À un niveau élevé, les ponts peuvent être classés en deux catégories : ceux qui sont fiables et ceux qui ne le sont pas.
-- **Trusted -** Les ponts de confiance sont vérifiés de l'extérieur. Ils utilisent un ensemble externe de vérificateurs (fédérations avec multi-sig, systèmes de calcul multi-parties, réseau d'oracles) pour envoyer des données à travers les chaînes. Par conséquent, ils peuvent offrir une grande connectivité et permettre un passage de messages entièrement généralisé à travers les chaînes. Ils ont également tendance à être performants en termes de rapidité et de rentabilité. Cela se fait au détriment de la sécurité, car les utilisateurs doivent s'en remettre à la sécurité du pont.
-- **Trustless -** Ces ponts s'appuient sur les blockchains qu'ils connectent et leurs validateurs pour transférer des messages et des jetons. Elles sont « sans confiance » car elles n'ajoutent pas de nouvelles hypothèses de confiance (en plus des blockchains). Par conséquent, les ponts sans confiance sont considérés comme plus sûrs que les ponts avec confiance.
+- **De confiance –** Les ponts de confiance sont vérifiés de manière externe. Ils utilisent un ensemble externe de vérificateurs (fédérations avec multi-sig, systèmes de calcul multi-parties, réseau d'oracles) pour envoyer des données à travers les chaînes. Par conséquent, ils peuvent offrir une grande connectivité et permettre un passage de messages entièrement généralisé à travers les chaînes. Ils ont également tendance à être performants en termes de rapidité et de rentabilité. Cela se fait au détriment de la sécurité, car les utilisateurs doivent s'en remettre à la sécurité du pont.
+- **Sans confiance –** Ces ponts s'appuient sur les blockchains qu'ils connectent et leurs validateurs pour transférer des messages et des jetons. Elles sont « sans confiance » car elles n'ajoutent pas de nouvelles hypothèses de confiance (en plus des blockchains). Par conséquent, les ponts sans confiance sont considérés comme plus sûrs que les ponts avec confiance.
Pour évaluer les ponts sans confiance en fonction d'autres facteurs, nous devons les décomposer en ponts de passage de messages généralisés et en réseaux de liquidité.
-- **Ponts généralisés de passage de messages -** Ces ponts excellent en matière de sécurité et de capacité à transférer des données plus complexes à travers les chaînes. En général, ils sont également bons en termes de rentabilité. Cependant, ces points forts se font généralement au détriment de la connectivité pour les ponts de clients légers (ex : IBC) et des inconvénients de vitesse pour les ponts optimistes (ex : Nomad) qui utilisent des preuves de fraude.
-- **Réseaux de liquidité -** Ces ponts utilisent des swaps atomiques pour transférer les actifs et sont des systèmes vérifiés localement (c'est-à-dire qu'ils utilisent les validateurs des blockchains sous-jacentes pour vérifier les transactions). Par conséquent, ils excellent en matière de sécurité et de rapidité. En outre, ils sont considérés comme comparativement rentables et offrent une bonne connectivité. Toutefois, le principal inconvénient est leur incapacité à transmettre des données plus complexes, car ils ne prennent pas en charge le passage de messages inter-chaînes.
+- **Ponts généralisés de transmission de messages –** Ces ponts excellent en matière de sécurité et par leur capacité à transférer des données plus complexes entre les chaînes. En général, ils sont également bons en termes de rentabilité. Cependant, ces points forts se font généralement au détriment de la connectivité pour les ponts de clients légers (ex : IBC) et des inconvénients de vitesse pour les ponts optimistes (ex : Nomad) qui utilisent des preuves de fraude.
+- **Réseaux de liquidités –** Ces ponts utilisent des échanges atomiques pour transférer des actifs et sont des systèmes vérifiés localement (c'est-à-dire qu'ils utilisent les validateurs des blockchains sous-jacentes pour vérifier les transactions). Par conséquent, ils excellent en matière de sécurité et de rapidité. En outre, ils sont considérés comme comparativement rentables et offrent une bonne connectivité. Toutefois, le principal inconvénient est leur incapacité à transmettre des données plus complexes, car ils ne prennent pas en charge le passage de messages inter-chaînes.
-## Risque avec les ponts {#risk-with-bridges}
+## Risques liés aux ponts {#risk-with-bridges}
-Les ponts représentent les trois premiers [plus gros hacks de DeFi](https://rekt.news/leaderboard/) et en sont encore aux premiers stades de développement. L'utilisation de tout pont comporte les risques suivants :
+Les ponts sont à l'origine des trois plus [grands piratages de la DeFi](https://rekt.news/leaderboard/) et sont encore à un stade précoce de leur développement. L'utilisation de tout pont comporte les risques suivants :
-- **Risque lié aux contrats intelligents -** Alors que de nombreux ponts ont passé avec succès les audits, il suffit d'une faille dans un contrat intelligent pour que les actifs soient exposés à des piratages (ex : [Pont Wormhole de Solana](https://rekt.news/wormhole-rekt/)).
-- **Risques financiers systémiques** - De nombreux ponts utilisent des actifs enveloppés pour frapper des versions canoniques de l'actif original sur une nouvelle chaîne. Cela expose l'écosystème à un risque systémique, car nous avons vu des versions enveloppées de jetons exploités.
-- **Risque de contrepartie -** Certains ponts utilisent une conception de confiance qui exige que les utilisateurs se fient à l'hypothèse selon laquelle les validateurs ne s'entendront pas pour voler les fonds des utilisateurs. La nécessité pour les utilisateurs de faire confiance à ces acteurs tiers les expose à des risques tels que les rabattements, la censure et d'autres activités malveillantes.
-- **Problèmes en suspens -** Étant donné que les ponts en sont aux premiers stades de leur développement, de nombreuses questions restent sans réponse quant à la manière dont les ponts se comporteront dans différentes conditions de marché, comme les périodes de congestion du réseau et lors d'événements imprévus tels que des attaques au niveau du réseau ou des reculs de l'état. Cette incertitude présente certains risques, dont le degré est encore inconnu.
+- **Risque lié aux contrats intelligents –** Bien que de nombreux ponts aient passé avec succès des audits, il suffit d'une seule faille dans un contrat intelligent pour que les actifs soient exposés à des piratages (ex. : [le pont Wormhole de Solana](https://rekt.news/wormhole-rekt/)).
+- **Risques financiers systémiques –** De nombreux ponts utilisent des actifs enveloppés pour frapper des versions canoniques de l'actif original sur une nouvelle chaîne. Cela expose l'écosystème à un risque systémique, car nous avons vu des versions enveloppées de jetons exploités.
+- **Risque de contrepartie –** Certains ponts utilisent une conception de confiance qui exige des utilisateurs qu'ils partent du principe que les validateurs ne s'entendront pas pour voler leurs fonds. La nécessité pour les utilisateurs de faire confiance à ces acteurs tiers les expose à des risques tels que les rabattements, la censure et d'autres activités malveillantes.
+- **Questions ouvertes –** Étant donné que les ponts n'en sont qu'aux premiers stades de leur développement, de nombreuses questions restent sans réponse quant à la manière dont ils se comporteront dans différentes conditions de marché, comme les périodes de congestion du réseau et lors d'événements imprévus tels que des attaques au niveau du réseau ou des retours en arrière de l'état. Cette incertitude présente certains risques, dont le degré est encore inconnu.
## Comment les dApps peuvent utiliser les ponts ? {#how-can-dapps-use-bridges}
@@ -82,56 +82,57 @@ Voici quelques applications pratiques que les développeurs peuvent envisager à
Pour les développeurs, il existe de nombreuses façons d'ajouter la prise en charge des ponts :
-1. **Construire son propre pont -** Construire un pont sécurisé et fiable n'est pas chose aisée, surtout si l'on emprunte une voie qui minimise la confiance. En outre, elle exige des années d'expérience et d'expertise technique liées aux études d'évolutivité et d'interopérabilité. En outre, il faudrait une équipe expérimentée pour maintenir un pont et attirer suffisamment de liquidités pour le rendre réalisable.
+1. **Construire votre propre pont –** Construire un pont sécurisé et fiable n'est pas chose aisée, surtout si vous empruntez une voie qui minimise la confiance. En outre, elle exige des années d'expérience et d'expertise technique liées aux études d'évolutivité et d'interopérabilité. En outre, il faudrait une équipe expérimentée pour maintenir un pont et attirer suffisamment de liquidités pour le rendre réalisable.
-2. **Afficher pour les utilisateurs plusieurs options de pont -** De nombreuses [dApps](/developers/docs/dapps/) exigent que les utilisateurs disposent de leur jeton natif pour interagir avec elles. Pour permettre aux utilisateurs d'accéder à leurs jetons, ils proposent différentes options de pont sur leur site web. Cependant, cette méthode est une solution rapide au problème car elle éloigne l'utilisateur de l'interface de la dApp et l'oblige à interagir avec d'autres dApps et ponts. Il s'agit d'une expérience d'intégration lourde, avec un risque accru de faire des erreurs.
+2. **Présenter plusieurs options de pont aux utilisateurs –** De nombreuses [dapps](/developers/docs/dapps/) exigent que les utilisateurs disposent de leur jeton natif pour interagir avec elles. Pour permettre aux utilisateurs d'accéder à leurs jetons, ils proposent différentes options de pont sur leur site web. Cependant, cette méthode est une solution rapide au problème car elle éloigne l'utilisateur de l'interface de la dApp et l'oblige à interagir avec d'autres dApps et ponts. Il s'agit d'une expérience d'intégration lourde, avec un risque accru de faire des erreurs.
-3. **Intégration d'un pont -** Cette solution ne nécessite pas que la dApp envoie les utilisateurs vers le pont externe et les interfaces des DEX. Il permet aux dApps d'améliorer l'expérience d'intégration des utilisateurs. Toutefois, cette approche a ses limites :
+3. **Intégrer un pont –** Cette solution ne nécessite pas que la dapp envoie les utilisateurs vers le pont externe et les interfaces des DEX. Il permet aux dApps d'améliorer l'expérience d'intégration des utilisateurs. Toutefois, cette approche a ses limites :
- L'évaluation et l'entretien des ponts sont difficiles et prennent beaucoup de temps.
- La sélection d'un seul pont crée un point unique de défaillance et de dépendance.
- La dApp est limitée par les capacités du pont.
- Les ponts seuls pourraient ne pas suffire. Les dApps pourraient avoir besoin des DEX pour offrir plus de fonctionnalités telles que les échanges inter-chaînes.
-4. **Intégration de plusieurs ponts -** Cette solution résout de nombreux problèmes liés à l'intégration d'un seul pont. Cependant, elle présente également des limites, car l'intégration de plusieurs ponts consomme des ressources et crée des frais généraux techniques et de communication pour les développeurs - la ressource la plus rare dans le domaine de la cryptographie.
+4. **Intégrer plusieurs ponts –** Cette solution résout de nombreux problèmes liés à l'intégration d'un seul pont. Cependant, elle présente également des limites, car l'intégration de plusieurs ponts consomme des ressources et crée des frais généraux techniques et de communication pour les développeurs - la ressource la plus rare dans le domaine de la cryptographie.
-5. **Intégrer un agrégateur de ponts -** Une autre option pour les dApps consiste à intégrer une solution d'agrégation de ponts qui leur donne accès à plusieurs ponts. Les agrégateurs de ponts héritent des forces de tous les ponts et ne sont donc pas limités par les capacités d'un seul pont. En particulier, les agrégateurs de ponts assurent généralement la maintenance des intégrations de ponts, ce qui évite à la dApp d'avoir à se préoccuper des aspects techniques et opérationnels d'une intégration de pont.
+5. **Intégrer un agrégateur de ponts –** Une autre option pour les dapps consiste à intégrer une solution d'agrégation de ponts qui leur donne accès à plusieurs ponts. Les agrégateurs de ponts héritent des forces de tous les ponts et ne sont donc pas limités par les capacités d'un seul pont. En particulier, les agrégateurs de ponts assurent généralement la maintenance des intégrations de ponts, ce qui évite à la dApp d'avoir à se préoccuper des aspects techniques et opérationnels d'une intégration de pont.
Cela dit, les agrégateurs de ponts ont aussi leurs limites. Par exemple, s'ils peuvent offrir plus d'options de pont, il existe généralement beaucoup plus de ponts sur le marché que ceux proposés sur la plateforme de l'agrégateur. En outre, tout comme les ponts, les agrégateurs de ponts sont également exposés aux risques liés aux contrats intelligents et à la technologie (plus de contrats intelligents = plus de risques).
Si une dapp emprunte la voie de l'intégration d'un pont ou d'un agrégateur, il existe différentes options en fonction du degré d'intégration souhaité. Par exemple, s'il s'agit uniquement d'une intégration frontale visant à améliorer l'expérience d'accueil des utilisateurs, une dApp intégrera le widget. Toutefois, si l'intégration vise à explorer des stratégies inter-chaînes plus approfondies comme le jalonnement, l'agriculture de rendement, etc., la dApp intègre le SDK ou l'API.
-### Déploiement d'une dApp sur plusieurs chaînes {#deploying-a-dapp-on-multiple-chains}
+### Déployer une dapp sur plusieurs chaînes {#deploying-a-dapp-on-multiple-chains}
-Pour déployer une dApp sur plusieurs chaînes, les développeurs peuvent utiliser des plateformes de développement telles que [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), etc. En général, ces plateformes sont fournies avec des plugins composables qui permettent aux dApps de passer d'une chaîne à l'autre. Par exemple, les développeurs peuvent utiliser un proxy de déploiement déterministe proposé par le plugin [hardhat-deploy](https://github.com/wighawag/hardhat-deploy).
+Pour déployer une dapp sur plusieurs chaînes, les développeurs peuvent utiliser des plateformes de développement comme [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), etc. En général, ces plateformes sont fournies avec des plugins composables qui permettent aux dApps de passer d'une chaîne à l'autre. Par exemple, les développeurs peuvent utiliser un proxy de déploiement déterministe proposé par le [plugin hardhat-deploy](https://github.com/wighawag/hardhat-deploy).
#### Exemples :
-- [Comment construire des dApps inter-chaine](https://moralis.io/how-to-build-cross-chain-dapps/)
-- [Création d'une place de marché NFT inter-chaînes](https://youtu.be/WZWCzsB1xUE)
-- [Moralis : Construire des dApps NFT inter-chaîne](https://www.youtube.com/watch?v=ehv70kE1QYo)
+- [Comment créer des dapps inter-chaînes](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [Créer une place de marché NFT inter-chaînes](https://youtu.be/WZWCzsB1xUE)
+- [Moralis : Créer des dapps NFT inter-chaînes](https://www.youtube.com/watch?v=ehv70kE1QYo)
-### Suivi de l'activité contractuelle à travers les chaînes {#monitoring-contract-activity-across-chains}
+### Surveiller l'activité des contrats entre les chaînes {#monitoring-contract-activity-across-chains}
-Pour surveiller l'activité des contrats dans les chaînes, les développeurs peuvent utiliser des sous-graphes et des plateformes de développement comme Tenderly pour observer les contrats intelligents en temps réel. Ces plates-formes disposent également d'outils qui offrent une plus grande fonctionnalité de surveillance des données pour les activités inter-chaînes, comme la vérification des [événements émis par les contrats](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), etc.
+Pour surveiller l'activité des contrats dans les chaînes, les développeurs peuvent utiliser des sous-graphes et des plateformes de développement comme Tenderly pour observer les contrats intelligents en temps réel. Ces plateformes disposent également d'outils qui offrent une plus grande fonctionnalité de surveillance des données pour les activités inter-chaînes, comme la vérification des [événements émis par les contrats](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), etc.
#### Outils
-- [Le réseau Graph](https://thegraph.com/en/)
+- [The Graph](https://thegraph.com/en/)
- [Tenderly](https://tenderly.co/)
-## Complément d'information {#further-reading}
-- [Blockchain Bridges](/bridges/) – ethereum.org
-- [Cadre d’évaluation des risques des ponts de L2Beat](https://l2beat.com/bridges/summary)
-- [Ponts Blockchain : Construire des réseaux de crypto-réseaux](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8 septembre 2021– Dmitriy Berenzon
-- [Le Trilemme d'interopérabilité](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1er octobre 2021 – Arjun Bhuptani
-- [Clusters : comment les ponts de confiance et les ponts à confiance minimisée façonnent le paysage multi-chaîne](https://blog.celestia.org/clusters/) – 4 octobre 2021 – Mustafa Al-Bassam
-- [LI.FI : Avec les ponts, la confiance est un spectre](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) – 28 avril 2022 – Arjun Chand
+## En savoir plus {#further-reading}
+
+- [Ponts de blockchain](/bridges/) – ethereum.org
+- [Cadre de risque des ponts de L2Beat](https://l2beat.com/bridges/summary)
+- [Ponts de blockchain : construire des réseaux de cryptoréseaux](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8 septembre 2021 – Dmitriy Berenzon
+- [Le trilemme de l'interopérabilité](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1er octobre 2021 – Arjun Bhuptani
+- [Clusters : Comment les ponts de confiance et à confiance minimisée façonnent le paysage multichaîne](https://blog.celestia.org/clusters/) - 4 octobre 2021 – Mustafa Al-Bassam
+- [LI.FI : Avec les ponts, la confiance est un spectre](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 28 avril 2022 – Arjun Chand
- [L'état des solutions d'interopérabilité des rollups](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 20 juin 2024 – Alex Hook
-- [Exploiter la sécurité partagée pour une interopérabilité cross-chain sécurisée : comités d'état Lagrange et au-delà](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12 juin 2024 – Emmanuel Awosika
+- [Exploiter la sécurité partagée pour une interopérabilité inter-chaînes sécurisée : les comités d'état de Lagrange et au-delà](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12 juin 2024 – Emmanuel Awosika
-En outre, voici quelques présentations perspicaces de [James Prestwich](https://twitter.com/_prestwich) qui peuvent aider à développer une compréhension plus approfondie des ponts :
+De plus, voici quelques présentations pertinentes de [James Prestwich](https://twitter.com/_prestwich) qui peuvent aider à développer une compréhension plus approfondie des ponts :
- [Construire des ponts, pas des jardins clos](https://youtu.be/ZQJWMiX4hT0)
-- [Faire tomber les ponts](https://youtu.be/b0mC-ZqN8Oo)
-- [Pourquoi les ponts brûlent-ils ?](https://youtu.be/c7cm2kd20j8)
+- [Analyse des ponts](https://youtu.be/b0mC-ZqN8Oo)
+- [Pourquoi les ponts brûlent-ils](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/index.md
index 827efdffaa6..1d840a3502e 100644
--- a/public/content/translations/fr/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/index.md
@@ -1,20 +1,20 @@
---
-title: Mécanismes de consensus
-description: Explication des protocoles de consensus dans les systèmes distribués et du rôle qu'ils jouent dans Ethereum.
+title: "Mécanismes de consensus"
+description: "Explication des protocoles de consensus dans les systèmes distribués et du rôle qu'ils jouent dans Ethereum."
lang: fr
---
-Le terme « mécanisme de consensus » est souvent utilisé familièrement pour désigner les protocoles de preuve d'enjeu, de preuve de travail ou de preuve d'autorité. Néanmoins, ceux-ci ne sont que des composantes du mécanisme de consensus qui protègent de façon préventive contre les [attaques de type 'Sybil](/glossary/#sybil-attack). Les mécanismes de consensus désignent la pile complète des idées, protocoles et incitations qui permettent à un ensemble de nœuds distribués de se mettre d'accord sur l'état d'une blockchain.
+Le terme « mécanisme de consensus » est souvent utilisé familièrement pour désigner les protocoles de preuve d'enjeu, de preuve de travail ou de preuve d'autorité. Cependant, ce ne sont que des composantes des mécanismes de consensus qui protègent contre les [attaques Sybil](/glossary/#sybil-attack). Les mécanismes de consensus désignent la pile complète des idées, protocoles et incitations qui permettent à un ensemble de nœuds distribués de se mettre d'accord sur l'état d'une blockchain.
## Prérequis {#prerequisites}
-Pour mieux comprendre cette page, nous vous recommandons de commencer par lire cette [introduction à Ethereum](/developers/docs/intro-to-ethereum/).
+Pour mieux comprendre cette page, nous vous recommandons de lire d'abord notre [introduction à Ethereum](/developers/docs/intro-to-ethereum/).
## Qu'est-ce que le consensus ? {#what-is-consensus}
Par consensus, nous voulons dire qu'un accord général a été trouvé. Prenons le cas d'un groupe de personnes qui vont au cinéma. S'il n'existe pas de désaccord sur le choix du film, alors un consensus se dégage. En cas de désaccord, le groupe doit avoir les moyens de décider du film à voir. Dans un cas extrême, le groupe finira par se séparer.
-En ce qui concerne la blockchain Ethereum, parvenir à un consensus signifie qu'au moins 66 % des nœuds du réseau sont d'accord sur l'état global du réseau.
+En ce qui concerne la blockchain Ethereum, le processus est formalisé, et parvenir à un consensus signifie qu'au moins 66 % des nœuds du réseau s'accordent sur l'état global du réseau.
## Qu'est-ce qu'un mécanisme de consensus ? {#what-is-a-consensus-mechanism}
@@ -32,7 +32,7 @@ Ces composantes forment ensemble le mécanisme de consensus.
### Basé sur la preuve de travail {#proof-of-work}
-Tout comme Bitcoin, Ethereum a utilisé un protocole de consensus basé sur la **preuve de travail (PoW)**.
+Tout comme Bitcoin, Ethereum utilisait autrefois un protocole de consensus basé sur la **preuve de travail (PoW)**.
#### Création de blocs {#pow-block-creation}
@@ -56,7 +56,7 @@ Les validateurs créent des blocs. Un validateur est sélectionné aléatoiremen
Un système de preuve d'enjeu est sécurisé économiquement dans la mesure où un attaquant qui tente de prendre le contrôle de la chaîne doit détruire une quantité massive d'ETH. Un système de récompenses encourage les validateurs individuels à se comporter honnêtement et les pénalités dissuadent les validateurs d’agir de manière malveillante.
-En savoir plus sur la [preuve de travail](/developers/docs/consensus-mechanisms/pos/)
+En savoir plus sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/)
### Un guide visuel {#types-of-consensus-video}
@@ -64,27 +64,27 @@ En savoir plus sur les différents types de mécanismes de consensus utilisés s