diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/attestations/index.md index 80891b750b7..4504d06faa5 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/attestations/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -8,35 +8,35 @@ Un validateur doit créer, signer et diffuser une attestation à chaque période ## Qu'est-ce qu'une attestation ? {#what-is-an-attestation} -Chaque [période](/glossary/#epoch) (6,4 minutes) au cours de laquelle un validateur propose une attestation au réseau. L'attestation est destinée à un créneau spécifique dans la période. Le but de l'attestation est de voter en faveur de l'approche du validateur sur la chaîne, en particulier le bloc justifié le plus récent et le premier bloc de la période actuelle (connu sous le nom de points de contrôle `source` et `cible`). Cette information est combinée pour tous les validateurs participants, permettant au réseau de parvenir à un consensus sur l'état de la blockchain. +À chaque [période](/glossary/#epoch) (6,4 minutes), un validateur propose une attestation au réseau. L'attestation est destinée à un créneau spécifique dans la période. L'objectif de l'attestation est de voter en faveur de la vision qu'a le validateur de la chaîne, en particulier le bloc justifié le plus récent et le premier bloc de la période actuelle (connus sous le nom de points de contrôle `source` et `target`). Cette information est combinée pour tous les validateurs participants, permettant au réseau de parvenir à un consensus sur l'état de la blockchain. L'attestation contient les composants suivants : -- `aggregation_bits` : une liste de validateurs bits, où la position est mappée à l'index du validateur dans leur comité ; la valeur (0/1) indique si le validateur a signé la `data` (c'est-à-dire - s’ils sont actifs et sont d’accord avec l’auteur du bloc) +- `aggregation_bits` : une liste de bits de validateurs où la position correspond à l'index du validateur dans son comité ; la valeur (0/1) indique si le validateur a signé les `data` (c'est-à-dire, s'il est actif et d'accord avec le proposeur de bloc). - `data` : détails relatifs à l'attestation, tels que définis ci-dessous - `signature` : une signature BLS qui regroupe les signatures des validateurs individuels -La première tâche pour un validateur attestant est de construire les `data`. Les `data` contiennent les informations suivantes : +La première tâche d'un validateur attestant est de construire les `data`. Les `data` contiennent les informations suivantes : - `slot` : Le numéro de créneau auquel l'attestation fait référence - `index` : Un nombre qui identifie à quel comité appartient le validateur dans un créneau donné -- `beacon_block_root` : Hachage racine du bloc que le validateur voit à la tête de la chaîne (le résultat de l'application de l'algorithme de choix de fourche) -- `source` : Partie du vote de finalité indiquant ce que les validateurs voient comme le bloc justifié le plus récent +- `beacon_block_root` : hachage racine du bloc que le validateur voit en tête de chaîne (le résultat de l'application de l'algorithme de choix de fourche) +- `source` : partie du vote de finalité indiquant ce que les validateurs voient comme le bloc justifié le plus récent - `target` : partie du vote de finalité indiquant ce que les validateurs voient comme le premier bloc de la période actuelle -Une fois que les `data` sont construites, le validateur peut retourner le bit en `aggregation_bits` correspondant à leur propre index de validateur de 0 à 1 pour montrer qu'ils ont participé. +Une fois les `data` construites, le validateur peut faire passer le bit de 0 à 1 dans `aggregation_bits`, correspondant à son propre index de validateur, pour montrer qu'il a participé. Enfin, le validateur signe l'attestation et la diffuse sur le réseau. ### Attestation agrégée {#aggregated-attestation} -Les frais additionnels associés au transfert de données pour chaque validateur sur le réseau sont très élevés. Ainsi, les attestations des validateurs individuels sont regroupées au sein de sous-réseaux avant d’être diffusées plus largement. Cela inclut l'agrégation des signatures afin qu'une attestation diffusée comprenne les `data` de consensus et une signature unique formée en combinant les signatures de tous les validateurs qui sont d'accord avec ces `data`. Ceci peut être vérifié en utilisant `aggregation_bits` parce que ce champ fournit l'index de chaque validateur dans leur comité (dont l'ID est fournit dans `data`) qui peut être utilisé pour faire une requête sur les signatures individuelles. +Les frais additionnels associés au transfert de données pour chaque validateur sur le réseau sont très élevés. Ainsi, les attestations des validateurs individuels sont regroupées au sein de sous-réseaux avant d’être diffusées plus largement. Cela inclut l'agrégation des signatures afin qu'une attestation diffusée comprenne les `data` de consensus et une signature unique formée en combinant les signatures de tous les validateurs qui sont d'accord avec ces `data`. Cela peut être vérifié à l'aide d'`aggregation_bits`, car ce champ fournit l'index de chaque validateur dans son comité (dont l'ID est fourni dans les `data`), qui peut être utilisé pour interroger les signatures individuelles. -À chaque période, 16 validateurs de chaque sous-réseau sont sélectionnés pour être les `agrégateurs`. Les agrégateurs collectent toutes les attestations dont ils entendent parler sur le réseau gossip disposant de `données` équivalentes aux leurs. L'expéditeur de chaque attestation correspondante est enregistré dans les `aggregation_bits`. Les agrégateurs diffusent ensuite l'agrégat d'attestation sur le réseau plus large. +À chaque période, 16 validateurs de chaque sous-réseau sont sélectionnés pour être les `agrégateurs`. Les agrégateurs collectent toutes les attestations dont ils entendent parler sur le réseau gossip qui ont des `data` équivalentes aux leurs. L'expéditeur de chaque attestation correspondante est enregistré dans les `aggregation_bits`. Les agrégateurs diffusent ensuite l'agrégat d'attestation sur le réseau plus large. Lorsqu'un validateur est sélectionné pour proposer un bloc, il regroupe les attestations globales des sous-réseaux jusqu'au dernier emplacement du nouveau bloc. -### Cycle de vie de l'inclusion de l'attestation {#attestation-inclusion-lifecycle} +### Cycle de vie de l'inclusion d'attestation {#attestation-inclusion-lifecycle} 1. Génération 2. Propagation @@ -46,7 +46,7 @@ Lorsqu'un validateur est sélectionné pour proposer un bloc, il regroupe les at Le cycle de vie de l'attestation est décrit dans le schéma ci-dessous : -![cycle de vie des transactions](./attestation_schematic.png) +![Cycle de vie de l'attestation](./attestation_schematic.png) ## Récompenses {#rewards} @@ -64,29 +64,29 @@ Le taux d'attestation de l'indicateur est mesuré en utilisant la somme des sold La récompense de base est calculée en fonction du nombre de validateurs présentant une attestation et de leurs soldes d'éther effectivement misés : -`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` +`récompense de base = solde effectif du validateur x 2^6 / SQRT(solde effectif de tous les validateurs actifs)` #### Délai d'inclusion {#inclusion-delay} -Au moment où les validateurs votaient pour la tête de chaîne (`block n`), le `block n+1` n'était pas encore proposé. Par conséquent, les attestations naturellement incluses **un bloc plus tard** donc toutes les attestations qui ont voté sur `block n` étant la tête de chaîne ont été incluses dans `block n+1` et, le **délai d'inclusion** est 1. Si le délai d'inclusion double et atteint deux créneaux, la récompense de l'attestation sera réduite de moitié, parce que pour calculer la récompense de l'attestation, la récompense de base est multipliée par la réciproque du délai d'inclusion. +Au moment où les validateurs ont voté pour la tête de la chaîne (`bloc n`), le `bloc n+1` n'avait pas encore été proposé. Par conséquent, les attestations sont naturellement incluses **un bloc plus tard**. Ainsi, toutes les attestations qui ont voté pour que le `bloc n` soit la tête de la chaîne sont incluses dans le `bloc n+1`, et le **délai d'inclusion** est de 1. Si le délai d'inclusion double et atteint deux créneaux, la récompense de l'attestation sera réduite de moitié, parce que pour calculer la récompense de l'attestation, la récompense de base est multipliée par la réciproque du délai d'inclusion. ### Scénarios d'attestation {#attestation-scenarios} -#### Validateur de vote manquant {#missing-voting-validator} +#### Validateur votant manquant {#missing-voting-validator} Les validateurs ont un maximum de 1 période pour soumettre leur attestation. Si l'attestation a été manquée à la période 0, ils peuvent la soumettre avec un délai d'inclusion à la période 1. #### Agrégateur manquant {#missing-aggregator} -Il y a 16 agrégateurs par période au total. De plus, les validateurs aléatoires s'abonnent à **deux sous-réseaux pour 256 périodes** et servent de sauvegarde au cas où des agrégateurs seraient manquants. +Il y a 16 agrégateurs par période au total. De plus, des validateurs aléatoires s'abonnent à **deux sous-réseaux pendant 256 périodes** et servent de sauvegarde au cas où des agrégateurs seraient manquants. -#### Proposant de bloc manquant {#missing-block-proposer} +#### Proposeur de bloc manquant {#missing-block-proposer} Notez que, dans certains cas, un agrégateur chanceux peut aussi devenir le proposeur de blocs. Si l'attestation n'a pas été incluse parce que le proposant du bloc a disparu, le proposant du bloc suivant récupérerait l'attestation agrégée et l'inclurait dans le bloc suivant. Cependant, le **délai d'inclusion** augmentera de un. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Attestations dans la spécification du consensus annoté de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Attestations dans la spécification du consensus annotée de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) - [Attestations dans eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) _Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !_ diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md index 02cfb2eedbd..b78054ed69d 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -1,6 +1,6 @@ --- title: Proposition de bloc -description: Comment les blocs sont proposés en preuve d'enjeu sur Ethereum. +description: "Comment les blocs sont proposés en preuve d'enjeu sur Ethereum." lang: fr --- @@ -8,7 +8,7 @@ Les blocs sont les unités de base de la blockchain. Ce sont des paquets d'infor ## Prérequis {#prerequisites} -La proposition de blocs fait partie du protocole de preuve d'enjeu. Pour mieux comprendre cette page, nous vous recommandons de lire celle sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) et [l'architecture des blocs](/developers/docs/blocks/). +La proposition de blocs fait partie du protocole de preuve d'enjeu. Pour vous aider à comprendre cette page, nous vous recommandons de lire les articles sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) et [l'architecture des blocs](/developers/docs/blocks/). ## Qui produit les blocs ? {#who-produces-blocks} @@ -16,9 +16,9 @@ Les comptes de validateurs proposent les blocs. Les validateurs sont gérés par ### Sélection aléatoire {#random-selection} -Un seul validateur est choisi de manière pseudo-aléatoire pour proposer un bloc à chaque créneau. Il n'existe pas de véritable aléa dans une blockchain, car si chaque nœud générait des nombres véritablement aléatoires, ils ne pourraient pas parvenir à atteindre un consensus. Au lieu de cela, l'objectif est de rendre le processus de sélection des validateurs imprévisible. Le pseudo-aléa est réalisé sur Ethereum à l'aide d'un algorithme appelé RANDAO, qui mélange un hachage du validateur qui propose le bloc avec une graine qui est mise à jour à chaque bloc. Cette valeur est utilisée pour sélectionner un validateur spécifique parmi l'ensemble des validateurs. La sélection des validateurs est fixée deux périodes à l'avance afin de se protéger contre certains types de manipulation de la graine utilisée. +Un seul validateur est choisi de manière pseudo-aléatoire pour proposer un bloc à chaque créneau. Il n'existe pas de véritable aléa dans une blockchain, car si chaque nœud générait des nombres véritablement aléatoires, ils ne pourraient pas parvenir à atteindre un consensus. Au lieu de cela, l'objectif est de rendre le processus de sélection des validateurs imprévisible. Le pseudo-aléa est réalisé sur Ethereum à l'aide d'un algorithme appelé RANDAO, qui mélange un hachage du validateur qui propose le bloc avec une graine qui est mise à jour à chaque bloc. Cette valeur est utilisée pour sélectionner un validateur spécifique parmi l'ensemble total des validateurs. La sélection des validateurs est fixée deux périodes à l'avance afin de se protéger contre certains types de manipulation de la graine utilisée. -Bien que les validateurs ajoutent des données à RANDAO à chaque créneau, la valeur globale de RANDAO est mise à jour une seule fois par période. Pour calculer l'indice du prochain validateur choisi, la valeur de RANDAO est mélangée avec le numéro du créneau pour donner une valeur unique à chaque créneau. La probabilité qu'un validateur individuel soit sélectionné n'est pas simplement de `1/N` (où `N` = total des validateurs actifs). Elle est plutôt pondérée par le solde effectif d'ETH de chaque validateur. Le solde ETH effectif maximal est de 32 ETH (cela signifie que le `solde < 32 ETH` conduit à un poids inférieur par rapport à un `solde == 32 ETH`, mais un `solde > 32 ETH` ne conduit pas à un poids supérieur au `solde == 32 ETH`). +Bien que les validateurs ajoutent des données à RANDAO à chaque créneau, la valeur globale de RANDAO est mise à jour une seule fois par période. Pour calculer l'indice du prochain validateur choisi, la valeur de RANDAO est mélangée avec le numéro du créneau pour donner une valeur unique à chaque créneau. La probabilité qu'un validateur individuel soit sélectionné n'est pas simplement de `1/N` (où `N` = le nombre total de validateurs actifs). Elle est plutôt pondérée par le solde effectif d'ETH de chaque validateur. Le solde effectif maximal est de 32 ETH (cela signifie qu'un `balance < 32 ETH` conduit à une pondération inférieure à `balance == 32 ETH`, mais `balance > 32 ETH` ne conduit pas à une pondération supérieure à `balance == 32 ETH`). Un seul validateur est sélectionné à chaque créneau pour proposer un bloc. Dans des conditions normales, un seul producteur de bloc crée et publie un unique bloc dans son créneau dédié. Créer deux blocs pour le même créneau est une infraction passible de sanction, souvent appelée « équivoque ». @@ -42,9 +42,9 @@ class BeaconBlockBody(Container): execution_payload: ExecutionPayload ``` -Le champ `randao_reveal` prend une valeur aléatoire vérifiable que le validateur de bloc crée en signant le numéro de la période actuelle. `eth1_data` est un vote du point de vue du proposeur du bloc sur l'état du contrat de dépôt, incluant la racine de l'arbre Merkle des dépôts et le nombre total de dépôts, permettant ainsi de vérifier de nouveaux dépôts. `graffiti` est un champ facultatif qui peut être utilisé pour ajouter un message au bloc. `proposer_slashings` et `attester_slashings` sont des champs qui contiennent la preuve que certains validateurs ont commis des infractions pouvant être sanctionnées selon la vue du proposeur sur l'état de la chaîne. `deposits` est une liste de nouveaux dépôts de validateurs dont le proposeur de ce bloc a connaissance, et `voluntary_exits` est une liste de validateurs souhaitant quitter le réseau, dont le proposeur de bloc a reçu le message via le réseau de diffusion de la couche de consensus. Le `sync_aggregate` est un vecteur montrant quels validateurs ont été précédemment affectés à un comité de synchronisation (un sous-ensemble de validateurs servant à fournir des données aux clients légers) et ont participé à la signature de données. +Le champ `randao_reveal` prend une valeur aléatoire vérifiable que le proposeur de bloc crée en signant le numéro de l'époque actuelle. `eth1_data` est un vote du point de vue du proposeur du bloc sur le contrat de dépôt, incluant la racine de l'arbre de Merkle des dépôts et le nombre total de dépôts, permettant ainsi de vérifier les nouveaux dépôts. `graffiti` est un champ facultatif qui peut être utilisé pour ajouter un message au bloc. `proposer_slashings` et `attester_slashings` sont des champs qui contiennent la preuve que certains validateurs ont commis des infractions passibles de slashing selon la vue du proposeur sur l'état de la chaîne. `deposits` est une liste de nouveaux dépôts de validateurs dont le proposeur de bloc a connaissance, et `voluntary_exits` est une liste de validateurs souhaitant quitter le réseau, dont le proposeur de bloc a entendu parler sur le réseau de diffusion (gossip network) de la couche de consensus. `sync_aggregate` est un vecteur montrant quels validateurs ont été précédemment affectés à un comité de synchronisation (un sous-ensemble de validateurs servant des données aux clients légers) et ont participé à la signature de données. -L'`exécution_payload` permet aux informations des transactions d'être transmises entre les clients d'exécution et de consensus. L'`execution_payload` est un bloc de données d'exécution qui est imbriqué à l'intérieur d'un bloc phare. Les champs à l'intérieur de l'`execution_payload` reflètent la structure du bloc telle qu'indiquée dans le Livre jaune d'Ethereum, à l'exception qu'il n'y a pas de blocs oncles et que `prev_randao` remplace `difficulty`. Le client d'exécution a accès à un pool local de transactions qu'il a reçues sur son propre réseau de diffusion d'informations. Ces transactions sont exécutées localement pour générer un état mis à jour connu sous le nom d'état final. Les transactions sont incluses dans l'`execution_payload` en tant que liste appelée `transactions` et l'état final est inscrit dans le champ `state-root`. +La `execution_payload` permet aux informations des transactions d'être transmises entre les clients d'exécution et les clients de consensus. La `execution_payload` est un bloc de données d'exécution qui est imbriqué à l'intérieur d'un bloc balise. Les champs à l'intérieur de la `execution_payload` reflètent la structure de bloc décrite dans le livre jaune d'Ethereum, à l'exception qu'il n'y a pas d'ommers (blocs oncles) et que `prev_randao` existe à la place de `difficulty`. Le client d'exécution a accès à un pool local de transactions qu'il a reçues sur son propre réseau de diffusion d'informations. Ces transactions sont exécutées localement pour générer un état mis à jour connu sous le nom d'état final. Les transactions sont incluses dans la `execution_payload` sous forme de liste appelée `transactions` et l'état final est fourni dans le champ `state-root`. Toutes ces données sont collectées dans un bloc phare, signées, puis diffusées aux pairs du proposeur de bloc, qui les propagent à leurs propres pairs, et ainsi de suite. @@ -52,18 +52,18 @@ En savoir plus sur [l'anatomie des blocs](/developers/docs/blocks). ## Qu'arrive-t-il au block ? {#what-happens-to-blocks} -Le bloc est ajouté à la base de données locale du proposeur de bloc puis diffusé aux pairs via le réseau de communication de la couche de consensus. Lorsqu'un validateur reçoit le bloc, il vérifie les données qu'il contient, notamment en vérifiant que le bloc a le bon bloc parent, correspond au créneau actuel, que l'index du proposeur est bien celui attendu, que RANDAO est valide et enfin que le proposeur n'a pas été sanctionné. L'`exécution_payload` est décompressé, et le client d'exécution du validateur exécute à nouveau toutes les transactions de la liste pour vérifier le changement d'état proposé. Si le bloc passe toutes ces vérifications, chaque validateur ajoute le bloc à sa propre chaîne canonique. Le processus recommence ensuite lors du créneau suivant. +Le bloc est ajouté à la base de données locale du proposeur de bloc puis diffusé aux pairs via le réseau de communication de la couche de consensus. Lorsqu'un validateur reçoit le bloc, il vérifie les données qu'il contient, notamment en vérifiant que le bloc a le bon bloc parent, correspond au créneau actuel, que l'index du proposeur est bien celui attendu, que RANDAO est valide et enfin que le proposeur n'a pas été sanctionné. La `execution_payload` est dégroupée et le client d'exécution du validateur ré-exécute les transactions de la liste pour vérifier le changement d'état proposé. Si le bloc passe toutes ces vérifications, chaque validateur ajoute le bloc à sa propre chaîne canonique. Le processus recommence ensuite lors du créneau suivant. -## Récompenses du bloc {#block-rewards} +## Récompenses de bloc {#block-rewards} -Le proposeur de bloc reçoit une rémunération pour son travail. Il y a `base_reward`, une récompense de base calculée en fonction du nombre de validateurs actifs et de leurs soldes effectifs. Ensuite, le validateur reçoit une fraction de la récompense de base (`base_reward`) pour chaque attestation valide incluse dans le bloc ; plus il y a de validateurs qui attestent le bloc, plus grande est la récompense pour le proposeur de bloc. Il y a également une récompense pour les validateurs signalant des infractions passibles de sanction, égale à `1/512 * effective balance` pour chaque validateur sanctionné. +Le proposeur de bloc reçoit une rémunération pour son travail. Il existe une `base_reward` (récompense de base) calculée en fonction du nombre de validateurs actifs et de leurs soldes effectifs. Le proposeur de bloc reçoit alors une fraction de la `base_reward` pour chaque attestation valide incluse dans le bloc ; plus il y a de validateurs qui attestent du bloc, plus la récompense du proposeur de bloc est importante. Il existe également une récompense pour le signalement des validateurs qui devraient être slashés, égale à `1/512 * effective balance` pour chaque validateur slashé. -[Plus d'informations sur les récompenses et sanctions](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) +[En savoir plus sur les récompenses et les pénalités](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} - [Introduction aux blocs](/developers/docs/blocks/) -- [Introduction à la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) -- [Spécifications de consensus Ethereum](https://github.com/ethereum/consensus-specs) -- [Introduction à Gasper](/developers/docs/consensus-mechanisms/pos/) -- [Mise à jour d'Ethereum](https://eth2book.info/) +- Introduction à la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) +- [Spécifications du consensus Ethereum](https://github.com/ethereum/consensus-specs) +- [Introduction à Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Mise à niveau d'Ethereum](https://eth2book.info/) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/faqs/index.md index 764d530a6ea..8e1d0053b8d 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/faqs/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -1,14 +1,14 @@ --- title: Foire aux questions -description: Foire aux questions à propos de la preuve d'enjeu Ethereum. +description: "Foire aux questions à propos de la preuve d'enjeu Ethereum." lang: fr --- -## Qu'est-ce que la preuve d'enjeu ? {#what-is-proof-of-stake} +## Qu'est-ce que la preuve d'enjeu {#what-is-proof-of-stake} La preuve d'enjeu est une classe d'algorithme qui assure la sécurité des blockchains en garantissant que les actifs de valeur sont perdus par les attaquants qui agissent de manière malhonnête. Les systèmes de preuve d'enjeu nécessitent qu'un ensemble de validateurs mette à disposition un actif qui peut être détruit si le validateur se livre à un comportement manifestement malhonnête. Ethereum utilise un mécanisme de preuve d'enjeu pour sécuriser sa blockchain. -## Comment la preuve d'enjeu se compare-t-elle à la preuve de travail ? {#comparison-to-proof-of-work} +## Comment la preuve d'enjeu se compare-t-elle à la preuve de travail ? Comparaison avec la preuve de travail {#comparison-to-proof-of-work} La preuve de travail et la preuve d'enjeu sont toutes deux des mécanismes qui dissuadent économiquement les acteurs malveillants de ralentir ou de frauder le réseau. Dans les deux cas, les nœuds qui participent activement au consensus mettent un actif « dans le réseau » qu'ils perdront s'ils se comportent mal. @@ -18,7 +18,7 @@ La preuve d'enjeu nécessite que les nœuds, appelés validateurs, soumettent ex La preuve de travail est beaucoup plus gourmande en énergie car de l'électricité est consommée lors du processus de minage. La preuve d'enjeu, en revanche, ne nécessite qu'une très faible quantité d'énergie - les validateurs Ethereum peuvent même fonctionner sur un appareil à faible puissance tel qu'un Raspberry Pi. Le mécanisme de preuve d'enjeu d'Ethereum est considéré comme plus sûr que la preuve de travail car le coût d'une attaque est plus élevé et les conséquences pour un attaquant sont plus graves. -La comparaison entre la preuve de travail et la preuve d'enjeu est un sujet controversé. Le blog de [Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) et le débat entre Justin Drake et Lyn Alden offrent un bon résumé des arguments. +La comparaison entre la preuve de travail et la preuve d'enjeu est un sujet controversé. Le [blog de Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) et le débat entre Justin Drake et Lyn Alden donnent un bon résumé des arguments. @@ -26,27 +26,27 @@ La comparaison entre la preuve de travail et la preuve d'enjeu est un sujet cont Oui. Les nœuds sur un réseau en preuve d'enjeu utilisent une quantité infime d'énergie. Une étude tierce a conclu que l'ensemble du réseau Ethereum basé sur la preuve d'enjeu consomme environ 0,0026 TWh/an - soit environ 13 000 fois moins que les jeux vidéo aux États-Unis uniquement. -[Plus d'infos sur la consommation d'énergie d'Ethereum](/energy-consumption/). +[En savoir plus sur la consommation d'énergie d'Ethereum](/energy-consumption/). ## La preuve d'enjeu est-elle sécurisée ? {#is-pos-secure} La preuve d'enjeu d'Ethereum est très sécurisée. Le mécanisme a été recherché, développé et testé rigoureusement pendant huit ans avant d'être mis en service. Les garanties de sécurité sont différentes des blockchains basées sur la preuve de travail. Dans la preuve d'enjeu, les validateurs malveillants peuvent être activement sanctionnés (« évincés ») et expulsés de l'ensemble des validateurs, ce qui coûte une somme importante d'ETH. Sous le régime de la preuve de travail, un attaquant peut continuer à répéter son attaque tant qu'il dispose d'une puissance de hachage suffisante. Il est également plus coûteux de lancer des attaques équivalentes sur Ethereum en preuve d'enjeu qu'en preuve de travail. Pour affecter la validation de la chaîne, au moins 33 % de l'ether total misé sur le réseau sont nécessaires (sauf dans les cas d'attaques très sophistiquées avec une probabilité de succès extrêmement faible). Pour contrôler le contenu des blocs futurs, au moins 51 % de l'ETH total misé est nécessaire, et pour réécrire l'histoire, plus de 66 % de la mise totale est nécessaire. Le protocole Ethereum détruirait ces actifs dans les scénarios d'attaque de 33 % ou 51 % et par consensus social dans le scénario d'attaque de 66 %. -- [Plus d'informations sur la défense contre les attaquants d'Ethereum en preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [En savoir plus sur la défense de la preuve d'enjeu d'Ethereum contre les attaquants](/developers/docs/consensus-mechanisms/pos/attack-and-defense) - [En savoir plus sur la conception de la preuve d'enjeu](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) ## Est-ce que la preuve d'enjeu rend Ethereum moins cher à utiliser ? {#does-pos-make-ethereum-cheaper} Non. Le coût d'envoi d'une transaction (frais de gaz) est déterminé par un marché dynamique des frais qui augmente avec la demande sur le réseau. Le mécanisme de consensus n'influence pas directement cela. -[Plus d'information sur le gaz](/developers/docs/gas). +[En savoir plus sur le gaz](/developers/docs/gas). ## Que sont les nœuds, les clients et les validateurs ? {#what-are-nodes-clients-and-validators} Les nœuds sont des ordinateurs connectés au réseau Ethereum. Les clients sont les logiciels qu'ils exécutent et qui transforment l'ordinateur en un nœud. Il existe deux types de clients : les clients d'exécution et les clients de consensus. Les deux sont nécessaires pour créer un nœud. Un validateur est un complément optionnel à un client de consensus qui permet au nœud de participer à un consensus à preuve d'enjeu. Cela signifie créer et proposer des blocs lorsqu'ils sont sélectionnés et attester des blocs dont ils entendent parler sur le réseau. Pour faire fonctionner un validateur, l'opérateur du nœud doit déposer 32 ETH dans le contrat de dépôt. - [En savoir plus sur les nœuds et les clients](/developers/docs/nodes-and-clients) -- [Plus d'infos sur la mise en jeu](/staking) +- [En savoir plus sur la mise en jeu](/staking) ## Est-ce que la preuve d'enjeu est une nouvelle idée ? {#is-pos-new} @@ -66,7 +66,7 @@ La combinaison de Casper et LMD_GHOST est connue sous le nom de Gasper. La « pénalisation » est le terme donné à la destruction d'une partie de la mise d'un validateur et à l'expulsion du validateur du réseau. La quantité d'ETH perdue lors d'une sanction augmente proportionnellement avec le nombre de validateurs sanctionnés - cela signifie que les validateurs regroupés sont punis plus sévèrement que les individus. -[En savoir plus sur les sanctions](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) +[En savoir plus sur le délestage](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) ## Pourquoi les validateurs ont-ils besoin de 32 ETH ? {#why-32-eth} @@ -82,26 +82,26 @@ Un seul validateur est choisi de manière pseudo-aléatoire pour proposer un blo La « manipulation d'enjeu » est une catégorie d'attaque sur les réseaux de preuve d'enjeu où l'attaquant tente de biaiser l'algorithme de sélection des validateurs en faveur de ses propres validateurs. Les attaques de « manipulation » sur RANDAO nécessitent environ la moitié du total d'ETH mis en jeu. -[En savoir plus sur la manipulation de la mise en jeu](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) +[En savoir plus sur le stake grinding](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) ## Qu'est-ce qu'une sanction communautaire ? {#what-is-social-slashing} Le « sanction communautaire » est la capacité de la communauté à coordonner une fourche de la blockchain en réponse à une attaque. Elle permet à la communauté de se remettre d'une attaque ayant finalisé une chaîne malhonnête. La répression sociale peut également être utilisée contre les attaques de censure. -- [En savoir plus sur la sanction communautaire](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) -- [Vitalik Buterin à propos des sanctions communautaires](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [En savoir plus sur le délestage social](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Vitalik Buterin sur le délestage social](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) ## Vais-je être sanctionné ? {#will-i-get-slashed} En tant que validateur, il est très difficile d'être sanctionné à moins de vous engager délibérément dans un comportement malveillant. La sanction n'est mise en œuvre que dans des scénarios très spécifiques où les validateurs proposent plusieurs blocs pour le même créneau ou se contredisent avec leurs attestations - ces situations sont très peu susceptibles de survenir accidentellement. -[En savoir plus sur les conditions entrainant une sanction](https://eth2book.info/altair/part2/incentives/slashing) +[En savoir plus sur les conditions de délestage](https://eth2book.info/altair/part2/incentives/slashing) ## Qu'est-ce que le problème dit de l'absence d'enjeu ? {#what-is-nothing-at-stake-problem} Le problème de l'absence d'enjeu est un problème conceptuel avec certains mécanismes de preuve d'enjeu où il n'y a que des récompenses et aucune pénalité. Si rien n'est en jeu, un validateur pragmatique est tout aussi heureux d'attester de n'importe quelle fourche, voire de plusieurs fourches, de la blockchain, car cela augmente ses récompenses. Ethereum contourne ce problème en utilisant des conditions de finalité et des sanctions pour garantir une chaîne canonique unique. -[En savoir plus le problème dit de l'absence d'enjeu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) +[En savoir plus sur le problème du rien en jeu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) ## Qu'est-ce que l'algorithme de choix de fourche ? {#what-is-a-fork-choice-algorithm} @@ -121,13 +121,13 @@ La finalité dans la preuve d'enjeu est la garantie qu'un bloc donné fait parti La subjectivité faible ou weak subjectivity est une caractéristique des réseaux de preuve d'enjeu où l'information sociale est utilisée pour confirmer l'état actuel de la blockchain. Les nouveaux nœuds ou les nœuds rejoignant le réseau après avoir été hors ligne pendant une longue période peuvent recevoir un état récent afin que le nœud puisse voir immédiatement s'ils sont sur la bonne chaîne. Ces états sont connus sous le nom de « points de contrôle de la faible subjectivité » et peuvent être obtenus auprès d'autres opérateurs de nœuds éloignés, ou auprès d'explorateurs de blocs, ou de plusieurs points de terminaison publics. -[En savoir plus sur la « faible subjectivité »](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) +[En savoir plus sur la subjectivité faible](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) ## Est-ce que la preuve d'enjeu peut résister à la censure ? {#is-pos-censorship-resistant} La résistance à la censure est actuellement difficile à prouver. Cependant, contrairement à la preuve de travail, la preuve d'enjeu offre la possibilité de coordonner les sanctions pour punir les validateurs pratiquant la censure. Il y a des changements à venir dans le protocole qui séparent les constructeurs de blocs des proposeurs de blocs et mettent en œuvre des listes de transactions que les constructeurs doivent inclure dans chaque bloc. Cette proposition est connue sous le nom de séparation des constructeurs et des proposeurs appropriés et aide à empêcher les validateurs de censurer les transactions. -[En savoir plus sur la séparation des rôles de constructeur et de proposeur](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) +[En savoir plus sur la séparation proposant-constructeur](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) ## Est-ce qu'Ethereum en système de preuve d'enjeu peut subir une attaque 51% ? {#pos-51-attack} @@ -139,7 +139,7 @@ Oui. La preuve d'enjeu est vulnérable aux attaques à 51%, tout comme la preuve La coordination sociale est la dernière ligne de défense pour Ethereum qui permettrait de récupérer une chaîne honnête à la suite d'une attaque ayant finalisé des blocs malhonnêtes. Dans ce cas, la communauté Ethereum devrait se coordonner « hors chaine » et s'accorder pour utiliser une fourche minoritaire honnête, tout en sanctionnant les validateurs de l'attaquant dans le processus. Cela nécessiterait également que les applications et les plateformes d'échange reconnaissent la fourche honnête. -[En savoir plus sur la coordination communautaire](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) +[En savoir plus sur la coordination sociale](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) ## Est-ce que les riches deviennent plus riches grâce à la preuve d'enjeu ? {#do-rich-get-richer} @@ -147,9 +147,9 @@ Plus une personne doit miser d’ETH, plus elle peut exécuter de validateurs et ## Est-ce que la preuve d'enjeu est plus centralisée que la preuve de travail ? {#is-pos-decentralized} -Non, la preuve de travail tend vers la centralisation car les coûts d'exploitation minière augmentent et évincent les individus, puis évincent les petites entreprises, et ainsi de suite. Le problème actuel avec la preuve d'enjeu est l'influence des produits dérivés de mise en jeu (DSL). Ce sont des jetons représentant de l'ETH mis en jeu par un fournisseur que n'importe qui peut échanger sur les marchés secondaires sans que l'ETH réel ne soit retiré de la mise. Les LSD permettent aux utilisateurs de mettre en jeu moins de 32 ETH, mais ils créent également un risque de centralisation où quelques grandes organisations peuvent finir par contrôler une grande partie de la mise. C'est pourquoi [mettre en jeu ses propres Eth](/staking/solo) est le mieux pour le réseau. +Non, la preuve de travail tend vers la centralisation car les coûts d'exploitation minière augmentent et évincent les individus, puis évincent les petites entreprises, et ainsi de suite. Le problème actuel avec la preuve d'enjeu est l'influence des produits dérivés de mise en jeu (DSL). Ce sont des jetons représentant de l'ETH mis en jeu par un fournisseur que n'importe qui peut échanger sur les marchés secondaires sans que l'ETH réel ne soit retiré de la mise. Les LSD permettent aux utilisateurs de mettre en jeu moins de 32 ETH, mais ils créent également un risque de centralisation où quelques grandes organisations peuvent finir par contrôler une grande partie de la mise. C'est pourquoi la [mise en jeu en solo](/staking/solo) est la meilleure option pour Ethereum. -[En savoir plus sur la centralisation des LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) +[En savoir plus sur la centralisation de la mise en jeu dans les LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) ## Pourquoi je ne peux mettre en jeu que des ETH ? {#why-can-i-only-stake-eth} @@ -163,10 +163,10 @@ Non, il existe plusieurs blockchains basées sur la preuve d'enjeu. Aucun n'est La fusion a été le moment où Ethereum a désactivé son mécanisme de consensus basé sur la preuve de travail et a activé son mécanisme de consensus basé sur la preuve d'enjeu. La Fusion a eu lieu le 15 septembre 2022. -[Plus d'infos sur la fusion](/roadmap/merge) +[En savoir plus sur La Fusion](/roadmap/merge) ## Qu'est-ce que la disponibilité et la sécurité ? {#what-are-liveness-and-safety} -La disponibilité et la sécurité sont les deux préoccupations fondamentales en matière de sécurité pour une blockchain. La disponibilité est l'accessibilité à une chaîne finalisée. Si la chaîne cesse de se finaliser ou si les utilisateurs ne peuvent pas y accéder facilement, ce sont des échecs de disponibilité. Un coût d'accès extrêmement élevé pourrait également être considéré comme un échec de disponibilité. La sécurité fait référence à la difficulté d'attaquer la chaîne - c'est-à-dire de finaliser des points de contrôle conflictuels. +La disponibilité et la sécurité sont les deux préoccupations fondamentales en matière de sécurité pour une blockchain. La disponibilité est l'accessibilité à une chaîne finalisée. Si la chaîne cesse de se finaliser ou si les utilisateurs ne peuvent pas y accéder facilement, ce sont des échecs de disponibilité. Un coût d'accès extrêmement élevé pourrait également être considéré comme un échec de disponibilité. La sécurité fait référence à la difficulté d'attaquer la chaîne, c'est-à-dire de finaliser des points de contrôle conflictuels. -[En savoir plus sur Casper](https://arxiv.org/pdf/1710.09437.pdf) +[En savoir plus dans l'article Casper](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/gasper/index.md index b145eabab45..17d4d744bf1 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/gasper/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -1,16 +1,16 @@ --- title: Gasper -description: Explication du mécanisme de preuve d'enjeu Gasper. +description: "Explication du mécanisme de preuve d'enjeu Gasper." lang: fr --- Gasper est une combinaison de Casper the Friendly Finality Gadget (Casper-FFG) et de l'algorithme de choix de fourche LMD-GHOST. Ensemble, ces composants forment le mécanisme de consensus qui garantit la preuve d'enjeu d'Ethereum. Casper est le mécanisme qui met à niveau certains blocs vers le statut « finalized » afin que les nouveaux entrants sur le réseau puissent être sûrs qu'ils se synchronisent à la chaîne canonique. L'algorithme de choix de fourche utilise des votes cumulés pour s'assurer que les nœuds peuvent facilement sélectionner le bon lorsque des fourches apparaissent dans la blockchain. -**Remarquez** que la définition originale de Casper-FFG a été légèrement mise à jour pour l'inclusion dans Gasper. Sur cette page, nous considérerons la version mise à jour. +**Remarque :** la définition originale de Casper-FFG a été légèrement mise à jour pour son inclusion dans Gasper. Sur cette page, nous considérerons la version mise à jour. -## Prérequis +## Les prérequis -Pour comprendre ce mécanisme, il est nécessaire de lire la page d'introduction sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/). +Pour comprendre ce sujet, il est nécessaire de lire la page d'introduction sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/). ## Le rôle de Gasper {#role-of-gasper} @@ -23,7 +23,7 @@ La finalité est une propriété de certains blocs qui signifie qu'ils ne peuven 1. Deux tiers du total des éthers mis en jeu doivent avoir voté en faveur de l'inclusion de ce bloc dans la chaîne canonique. Cette condition fait passer le bloc à « justifié ». Les blocs justifiés ont peu de chances d'être annulés, mais ils peuvent l'être sous certaines conditions. 2. Lorsqu'un autre bloc est justifié au-dessus d'un bloc justifié, il passe à « finalisé ». La finalisation d'un bloc est un engagement à inclure le bloc dans la chaîne canonique. Il ne peut pas être inversé à moins qu'un attaquant ne détruise des millions d'éther (des milliards de $USD). -Ces améliorations de blocs ne se produisent pas dans tous les emplacements. Au lieu de cela, seuls les blocs à la limite de la période peuvent être justifiés et finalisés. Ces blocs sont appelés « points de contrôle ». La mise à niveau considère des paires de points de contrôle. Un « lien de supermajorité » doit exister entre deux points de contrôle successifs (c'est-à-dire que deux tiers du total de l'éther misé votent que le point de contrôle B est le descendant correct du point de contrôle A) pour faire passer le point de contrôle le moins récent à finalisé et le bloc le plus récent à justifié. +Ces améliorations de blocs ne se produisent pas dans tous les emplacements. Au lieu de cela, seuls les blocs à la limite de la période peuvent être justifiés et finalisés. Ces blocs sont appelés « points de contrôle ». La mise à niveau considère des paires de points de contrôle. Un « lien de supermajorité » doit exister entre deux points de contrôle successifs (c.-à-d. que deux tiers du total de l'ether misé votent que le point de contrôle B est le descendant correct du point de contrôle A) pour faire passer le point de contrôle le moins récent à l'état finalisé et le bloc le plus récent à l'état justifié. Étant donné que la finalité exige un accord des deux tiers sur le caractère canonique d'un bloc, un attaquant ne peut pas créer une autre chaîne finalisée sans ce qui suit : @@ -32,21 +32,21 @@ Ces améliorations de blocs ne se produisent pas dans tous les emplacements. Au La première condition découle du fait que les deux tiers de l'éther mis en jeu sont nécessaires pour finaliser une chaîne. La deuxième condition se pose car si deux tiers de la participation totale ont voté en faveur des deux bifurcations, alors un tiers doit avoir voté sur les deux. Le double vote est une condition sournoise qui serait punie au maximum, et un tiers de l'enjeu total serait détruit. En mai 2022, un attaquant devait ainsi brûler environ 10 milliards de dollars d'éther. L'algorithme qui justifie et finalise les blocs dans Gasper est une forme légèrement modifiée de [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). -### Incitations et Pénalités {#incentives-and-slashing} +### Incitatifs et délestage {#incentives-and-slashing} Les validateurs sont récompensés pour avoir proposé et validé honnêtement des blocs. L'éther est récompensé et ajouté à leur mise en jeu. Par contre, les validateurs qui sont absents et qui n'agissent pas lorsqu'ils sont appelés à manquer ces récompenses et perdent parfois une petite partie de leur participation existante. Cependant, les pénalités pour être hors ligne sont modestes et, dans la plupart des cas, s'élèvent au coût d'opportunité des récompenses manquantes. Cependant, certaines actions de validateur sont très difficiles à faire accidentellement et signifient une intention malveillante, comme proposer plusieurs blocs pour le même emplacement, attester plusieurs blocs pour le même emplacement, ou contredire les votes précédents de point de contrôle. Il s'agit de comportements « slashables » qui sont pénalisés de manière plus sévère : le slashing entraîne la destruction d'une partie de l'enjeu du validateur et le validateur est retiré du réseau des validateurs. Ce processus prend 36 jours. Le premier jour, la pénalité initiale peut atteindre 1 ETH. Puis l'éther coupé du validateur s'égoutte lentement sur la période de sortie, mais le jour 18, ils reçoivent une « pénalité de corrélation », qui est plus grande quand plus de validateurs sont coupés à la même heure. La pénalité maximale est l'enjeu entier. Ces récompenses et ces pénalités sont conçues pour encourager les validateurs honnêtes et décourager les attaques sur le réseau. -### Fuite d’inactivité {#inactivity-leak} +### Fuite d'inactivité {#inactivity-leak} En plus de la sécurité, Gasper offre également une « preuve de vie plausible ». C'est la condition que tant que les deux tiers de l'éther total misé votent honnêtement et suivent le protocole, la chaîne sera en mesure de finaliser indépendamment de toute autre activité (comme les attaques, les problèmes de latence ou les slashings). Autrement dit, un tiers du total de l'éther misé doit être compromis d'une manière ou d'une autre pour empêcher la finalisation de la chaîne. En Gasper, il y a une ligne de défense supplémentaire contre une défaillance de la vie, connue sous le nom de « fuite d'inactivité ». Ce mécanisme s'active lorsque la chaîne n'a pas pu être finalisée pour plus de quatre périodes. Les validateurs qui ne témoignent pas activement de la chaîne majoritaire se voient égoutter progressivement leur participation jusqu'à ce que la majorité récupère les deux tiers de l'enjeu total, veiller à ce que les échecs de la vivacité ne soient que temporaires. -### Choix de fourche {#fork-choice} +### Choix de la fourche {#fork-choice} -La définition originale de Casper-FFG incluait un algorithme de choix de fourche qui imposait la règle : `follow the chain containing the justified checkpoint that pas the gréâtes height` où la hauteur est définie comme la plus grande distance par rapport au bloc de genèse. En Gasper, la règle de choix de fourche originale est dépréciée en faveur d'un algorithme plus sophistiqué appelé LMD-GHOST. Il est important de réaliser que dans des conditions normales, une règle de choix de fourche (fork) est inutile - il y a un seul proposeur de bloc pour chaque créneau, et les validateurs honnêtes l'attestent. Ce n'est que dans les cas d'asynchronie du réseau ou quand un auteur de bloc malhonnête a mis en doute la nécessité d'un algorithme de choix de fourche. Cependant, lorsque ces cas se produisent, l'algorithme de choix de fourche est une défense critique qui sécurise la chaîne correcte. +La définition originale de Casper-FFG comprenait un algorithme de choix de fourche qui imposait la règle suivante : `suivre la chaîne contenant le point de contrôle justifié qui a la plus grande hauteur`, où la hauteur est définie comme la plus grande distance par rapport au bloc de genèse. En Gasper, la règle de choix de fourche originale est dépréciée en faveur d'un algorithme plus sophistiqué appelé LMD-GHOST. Il est important de réaliser que dans des conditions normales, une règle de choix de fourche (fork) est inutile - il y a un seul proposeur de bloc pour chaque créneau, et les validateurs honnêtes l'attestent. Ce n'est que dans les cas d'asynchronie du réseau ou quand un auteur de bloc malhonnête a mis en doute la nécessité d'un algorithme de choix de fourche. Cependant, lorsque ces cas se produisent, l'algorithme de choix de fourche est une défense critique qui sécurise la chaîne correcte. LMD-GHOST signifie « le dernier sous-arbre observé le plus gourmand, alimenté par des messages de messages ». C'est une façon lourde de jargon de définir un algorithme qui sélectionne la bifurcation avec le plus grand poids accumulé d'attestations comme le canonique (sous-arbre le plus gourmand) et que si plusieurs messages sont reçus d'un validateur, seule la dernière est prise en compte (dernière génération de messages). Avant d'ajouter le bloc le plus lourd à sa chaîne canonique, chaque validateur évalue chaque bloc à l'aide de cette règle. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Gasper : Combiner GHOST et Casper](https://arxiv.org/pdf/2003.03052.pdf) -- [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) +- [Gasper: Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/index.md index bf31079b7ad..8bd85058b6b 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/index.md @@ -1,14 +1,14 @@ --- title: Preuve d'enjeu (PoS) -description: Explication du protocole de consensus « Preuve d'enjeu » et de son rôle dans Ethereum. +description: "Explication du protocole de consensus « Preuve d'enjeu » et de son rôle dans Ethereum." lang: fr --- -La preuve d'enjeu (PoS) sous-tend le [mécanisme de consensus](/developers/docs/consensus-mechanisms/) Ethereum. Ethereum est passé au mécanisme de preuve d'enjeu en 2022 parce que celui-ci est plus sécurisé, moins énergivore, et parfait pour l'implémentation de nouvelles solutions de mise à l'échelle par rapport à la précédente architecture de [preuve de travail](/developers/docs/consensus-mechanisms/pow). +La preuve d'enjeu (PoS) est à la base du [mécanisme de consensus](/developers/docs/consensus-mechanisms/) d'Ethereum. Ethereum est passé à son mécanisme de preuve d'enjeu en 2022, car il est plus sécurisé, moins énergivore et mieux adapté à la mise en œuvre de nouvelles solutions de mise à l'échelle par rapport à l'architecture précédente de [preuve de travail](/developers/docs/consensus-mechanisms/pow). ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, nous vous recommandons d'abord de lire la page [Mécanismes de consensus](/developers/docs/consensus-mechanisms/). +Pour mieux comprendre cette page, nous vous recommandons de vous informer d'abord sur les [mécanismes de consensus](/developers/docs/consensus-mechanisms/). ## Qu'est-ce que la preuve d'enjeu (PoS) ? {#what-is-pos} @@ -20,38 +20,38 @@ Pour participer en tant que validateur, un utilisateur doit déposer 32 ETH dans Alors qu'avec le consensus de preuve de travail, la fréquence des blocs est déterminée par la difficulté minière, avec la preuve d'enjeu, cette fréquence reste fixe. Dans le consensus de mise en jeu d'Ethereum, le temps est divisé en créneaux (12 secondes) et périodes (32 créneaux). Un validateur est sélectionné aléatoirement pour proposer un bloc dans chaque créneau. Ce validateur est responsable de la création d'un nouveau bloc et de son envoi aux autres nœuds du réseau. De même, dans chaque créneau, un comité de validateurs est choisi au hasard, et leurs votes servent à déterminer la validité du bloc proposé. Il est important de diviser le validateur mis en place en comités pour maintenir la charge du réseau gérable. Les validateurs sont répartis en comités de telle façon que chaque validateur actif atteste à chaque période, mais pas à chaque créneau. -## Comment une transaction est exécutée sur Ethereum PoS {#transaction-execution-ethereum-pos} +## Comment une transaction est exécutée sur l'Ethereum PoS {#transaction-execution-ethereum-pos} Ce qui suit fournit une explication de bout en bout de la façon dont une transaction est exécutée avec la preuve d'enjeu Ethereum (PoS). -1. Un utilisateur crée et signe une [transaction](/developers/docs/transactions/) avec sa clé privée. Ceci est généralement géré par un portefeuille ou une bibliothèque telle que [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) etc. mais sous le capot l'utilisateur fait une requête à un nœud en utilisant l'API [JSON-RPC](/developers/docs/apis/json-rpc/) d'Ethereum. L'utilisateur définit la quantité de gaz qu'il est prêt à payer comme un pourboire au validateur pour l'encourager à inclure la transaction dans un bloc. Les [pourboires](/developers/docs/gas/#priority-fee) sont payés au validateur alors que les [frais de base](/developers/docs/gas/#base-fee) sont brûlés. -2. La transaction est soumise à un client d'exécution [Ethereum](/developers/docs/nodes-and-clients/#execution-client) qui vérifie sa validité. Cela signifie s'assurer que l'expéditeur a suffisamment d'ETH pour remplir la transaction et qu'il l'a signée avec la bonne clé. +1. Un utilisateur crée et signe une [transaction](/developers/docs/transactions/) avec sa clé privée. Ceci est généralement géré par un portefeuille ou une bibliothèque telle que [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/), etc., mais en arrière-plan, l'utilisateur fait une requête à un nœud en utilisant l'[API JSON-RPC](/developers/docs/apis/json-rpc/) d'Ethereum. L'utilisateur définit la quantité de gaz qu'il est prêt à payer comme un pourboire au validateur pour l'encourager à inclure la transaction dans un bloc. Les [pourboires](/developers/docs/gas/#priority-fee) sont payés au validateur tandis que les [frais de base](/developers/docs/gas/#base-fee) sont brûlés. +2. La transaction est soumise à un [client d'exécution](/developers/docs/nodes-and-clients/#execution-client) Ethereum qui en vérifie la validité. Cela signifie s'assurer que l'expéditeur a suffisamment d'ETH pour remplir la transaction et qu'il l'a signée avec la bonne clé. 3. Si la transaction est valide, le client d'exécution l'ajoute à son mempool local (liste des transactions en attente) et le transmet également à d'autres nœuds sur le réseau d'informations de la couche d'exécution. Quand d'autres nœuds reçoivent la transaction, ils l'ajoutent également à leur mempool local. Les utilisateurs avancés peuvent s'abstenir de diffuser leur transaction et la transmettre à des créateurs de blocs spécialisés tels que [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Cela leur permet d'organiser les transactions dans les blocs à venir pour un profit maximal ([MEV](/developers/docs/mev/#mev-extraction)). -4. Un des nœuds de validation sur le réseau est le bloc proposé pour le créneau actuel, après avoir été précédemment sélectionné aléatoirement en utilisant la fonction RANDAO. Ce noeud est responsable de la construction et de la diffusion du prochain bloc à ajouter à la blockchain Ethereum et de la mise à jour de l'état global. Le noeud est composé de trois parties : un client d'exécution, un client de consensus et un client validateur. Le client d'exécution relie les transactions depuis le mempool local à une « charge utile d'exécution » et les exécute localement pour générer un changement d'état. Ces informations sont transmises au client de consensus où la charge utile d'exécution est enveloppée dans un « bloc balise » qui contient également des informations sur les récompenses, les pénalités, les réductions, les attestations, etc. qui permettent au réseau de se mettre d'accord sur la séquence de blocs en tête de la chaîne. La communication entre l'exécution et les clients de consensus est décrite plus en détail dans [Connecting the Consensus and Execution Clients](/developers/docs/networking-layer/#connecting-clients). -5. Les autres nœuds reçoivent le nouveau bloc phare sur le réseau d'informations de la couche de consensus. Ils le transmettent à leur client d'exécution où les transactions sont réexécutées localement pour s'assurer que le changement d'état proposé est valide. Le client de validateur atteste ensuite que le bloc est valide et qu'il est le bloc suivant logique dans leur vue de la chaîne (ce qui signifie qu'il se construit sur la chaîne avec le plus grand poids d'attestations tel que défini dans les [règles de choix de fourche](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Le bloc est ajouté à la base de données locale de chaque noeud qui l'atteste. +4. Un des nœuds de validation sur le réseau est le bloc proposé pour le créneau actuel, après avoir été précédemment sélectionné aléatoirement en utilisant la fonction RANDAO. Ce noeud est responsable de la construction et de la diffusion du prochain bloc à ajouter à la blockchain Ethereum et de la mise à jour de l'état global. Le noeud est composé de trois parties : un client d'exécution, un client de consensus et un client validateur. Le client d'exécution relie les transactions depuis le mempool local à une « charge utile d'exécution » et les exécute localement pour générer un changement d'état. Ces informations sont transmises au client de consensus où la charge utile d'exécution est enveloppée dans un « bloc balise » qui contient également des informations sur les récompenses, les pénalités, les réductions, les attestations, etc. qui permettent au réseau de se mettre d'accord sur la séquence de blocs en tête de la chaîne. La communication entre les clients d'exécution et de consensus est décrite plus en détail dans [Connexion des clients de consensus et d'exécution](/developers/docs/networking-layer/#connecting-clients). +5. Les autres nœuds reçoivent le nouveau bloc phare sur le réseau d'informations de la couche de consensus. Ils le transmettent à leur client d'exécution où les transactions sont réexécutées localement pour s'assurer que le changement d'état proposé est valide. Le client validateur atteste alors que le bloc est valide et qu'il s'agit du bloc logique suivant dans sa vision de la chaîne (ce qui signifie qu'il se construit sur la chaîne avec le plus grand poids d'attestations, comme défini dans les [règles de choix de fourche](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Le bloc est ajouté à la base de données locale de chaque noeud qui l'atteste. 6. La transaction peut être considérée comme « finalisée » si elle fait partie d’une chaîne avec un « lien de majorité qualifiée » entre deux points de contrôle. Les points de contrôle ont lieu au début de chaque période. Ils existent pour tenir compte du fait que parmi les validateurs actifs, seul un sous-ensemble atteste à chaque créneau alors que tous attestent au cours de chaque période. Par conséquent, ce n’est qu’entre les périodes qu’un « lien de majorité qualifié » peut être démontré (durant lequel 66 % de tous les ETH misés sur le réseau s’accordent sur deux points de contrôle). Vous trouverez plus de détails sur la finalité ci-dessous. -## Finalisation {#finality} +## Finalité {#finality} -Une transaction atteint la « finalité » dans les réseaux distribués lorsqu’elle fait partie d’un bloc ne pouvant être modifié sans qu'une grande quantité d’ETH ne soit brûlée. Avec la preuve d'enjeu d'Ethereum, cela est géré via des blocs dits « checkpoint » ou « points de contrôle ». Le premier bloc de chaque période est un point de contrôle. Les validateurs votent pour des paires de blocs « points de contrôle » qu'ils considèrent comme étant valides. Si une paire de points de contrôle regroupe des votes représentant au moins les deux tiers de l'ETH total misé, les points de contrôle sont mis à niveau. La plus récente des deux (cible) devient « justifiée ». La plus ancienne des deux est déjà justifiée en ce qu'elle était la « cible » de la période précédente. Elle est ensuite mise à niveau vers le statut « finalisée ». +Une transaction atteint la « finalité » dans les réseaux distribués lorsqu’elle fait partie d’un bloc ne pouvant être modifié sans qu'une grande quantité d’ETH ne soit brûlée. Avec la preuve d'enjeu d'Ethereum, cela est géré via des blocs dits « checkpoint » ou « points de contrôle ». Le premier bloc de chaque période est un point de contrôle. Les validateurs votent pour des paires de blocs « points de contrôle » qu'ils considèrent comme étant valides. Si une paire de points de contrôle regroupe des votes représentant au moins les deux tiers de l'ETH total misé, les points de contrôle sont mis à niveau. La plus récente des deux (cible) devient « justifiée ». La plus ancienne des deux est déjà justifiée en ce qu'elle était la « cible » de la période précédente. Elle est ensuite mise à niveau vers le statut « finalisée ». Ce processus de mise à niveau des points de contrôle est géré par **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG est un outil de finalité de bloc pour le consensus. Une fois qu'un bloc est finalisé, il ne peut être ni annulé ni modifié sans une sanction de la majorité des validateurs, ce qui le rend économiquement non viable. -Pour annuler un bloc finalisé, un attaquant devrait s'engager à perdre au moins un tiers de l'ETH total mis en jeu. La raison exacte de ce phénomène est expliquée [dans ce post de blog de l'Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Puisque la finalisation requiert une majorité des deux tiers, un attaquant pourrait empêcher le réseau d'atteindre la finalité en votant avec un tiers de la mise totale. Il existe un mécanisme visant à se défendre contre ce type d'attaque : la [fuite d'inactivité](https://eth2book.info/bellatrix/part2/incentives/inactivity). Ce mécanisme s'active lorsque la chaîne échoue à finaliser plus de quatre périodes. La fuite d'inactivité détruit progressivement les ETH mis en jeu par les validateurs qui votent contre la majorité, permettant à celle -ci de retrouver une majorité des deux tiers et de finaliser la chaîne. +Pour annuler un bloc finalisé, un attaquant devrait s'engager à perdre au moins un tiers de l'ETH total mis en jeu. La raison exacte de ce phénomène est expliquée dans cet [article de blog de la Fondation Ethereum](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Puisque la finalisation requiert une majorité des deux tiers, un attaquant pourrait empêcher le réseau d'atteindre la finalité en votant avec un tiers de la mise totale. Il existe un mécanisme pour se défendre contre cela : la [fuite d'inactivité](https://eth2book.info/bellatrix/part2/incentives/inactivity). Ce mécanisme s'active lorsque la chaîne échoue à finaliser plus de quatre périodes. La fuite d'inactivité détruit progressivement les ETH mis en jeu par les validateurs qui votent contre la majorité, permettant à celle -ci de retrouver une majorité des deux tiers et de finaliser la chaîne. -## Sécurité Crypto-économique {#crypto-economic-security} +## Sécurité crypto-économique {#crypto-economic-security} Faire fonctionner un validateur est un engagement. Il est attendu du validateur qu'il maintienne un matériel et une connectivité suffisants pour participer à la validation et à la proposition de blocs. En retour, le validateur est payé en ETH (le solde misé augmente). D'autre part, la participation en tant que validateur ouvre également de nouvelles possibilités pour les utilisateurs d'attaquer le réseau en vue de réaliser un gain personnel ou un sabotage. Pour éviter cela, les validateurs ratent les récompenses en ETH s'ils ne participent pas quand ils sont appelés, et leur mise actuelle peut être détruite s'ils se comportent de manière malhonnête. Deux principaux comportements peuvent être considérés comme malhonnêtes : proposer plusieurs blocs pour un même créneau (équivoque) et soumettre des attestations contradictoires. -La quantité d'ETH détruite dépend du nombre de validateurs qui sont sanctionnés en même temps. Ce mécanisme est connu sous le nom de [« pénalité de corrélation »](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) ; il peut être mineur (~1 % de la mise en jeu pour un seul validateur sanctionné) ou entraîner la destruction de 100 % de la mise en jeu du validateur (échec massif). Elle est imposée à mi-chemin d’une période de sortie forcée qui commence par une pénalité immédiate (jusqu’à 1 ETH) le jour 1, la pénalité de corrélation le jour 18 et enfin l’expulsion du réseau le jour 36. Les validateurs reçoivent chaque jour des pénalités d'attestation mineures parce qu'ils sont présents sur le réseau mais ne soumettent pas de votes. Tout cela signifie qu’une attaque coordonnée serait très coûteuse pour l’attaquant. +La quantité d'ETH détruite dépend du nombre de validateurs qui sont sanctionnés en même temps. Ce phénomène est connu sous le nom de [« pénalité de corrélation »](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), et il peut être mineur (~1 % de la mise pour un seul validateur sanctionné) ou peut entraîner la destruction de 100 % de la mise du validateur (événement de sanction de masse). Elle est imposée à mi-chemin d’une période de sortie forcée qui commence par une pénalité immédiate (jusqu’à 1 ETH) le jour 1, la pénalité de corrélation le jour 18 et enfin l’expulsion du réseau le jour 36. Les validateurs reçoivent chaque jour des pénalités d'attestation mineures parce qu'ils sont présents sur le réseau mais ne soumettent pas de votes. Tout cela signifie qu’une attaque coordonnée serait très coûteuse pour l’attaquant. ## Choix de la fourche {#fork-choice} -Lorsque le réseau fonctionne de manière optimale et honnête, il n'y a jamais qu'un nouveau bloc en tête de chaîne, et tous les validateurs l'attestent. Cependant, il est possible pour les validateurs d'avoir des points de vue différents sur le bloc en tête de la chaîne, en raison de la latence du réseau ou parce qu'un validateur a émis des données contradictoires. Par conséquent, les clients de consensus ont besoin d'un algorithme pour décider lequel favoriser. L'algorithme utilisé dans la preuve d'enjeu Ethereum est appelé [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), et il travaille en identifiant la fourche qui a le plus grand poids d'attestations dans son histoire. +Lorsque le réseau fonctionne de manière optimale et honnête, il n'y a jamais qu'un nouveau bloc en tête de chaîne, et tous les validateurs l'attestent. Cependant, il est possible pour les validateurs d'avoir des points de vue différents sur le bloc en tête de la chaîne, en raison de la latence du réseau ou parce qu'un validateur a émis des données contradictoires. Par conséquent, les clients de consensus ont besoin d'un algorithme pour décider lequel favoriser. L'algorithme utilisé dans la preuve d'enjeu d'Ethereum s'appelle [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) et il fonctionne en identifiant la fourche qui a le plus grand poids d'attestations dans son historique. ## Preuve d'enjeu et sécurité {#pos-and-security} -Avec un consensus de preuve d'enjeu (comme avec la preuve de travail), la menace d'une attaque de [51 %](https://www.investopedia.com/terms/1/51-attack.asp) existe toujours, mais elle est encore plus risquée pour les attaquants. Un attaquant aurait besoin de 51 % de l'ETH mis en jeu. Ils pourraient alors utiliser leurs propres attestations pour s'assurer que leur fourche préférée est celle qui possède le plus d'attestations. Les clients de consensus utilisent le « poids » des attestations cumulées pour déterminer la chaîne correcte, de sorte que cet attaquant serait en mesure de faire de sa fourche la fourche canonique. Toutefois, l'intérêt de la preuve d'enjeu comparé à la preuve de travail est que la communauté a la possibilité de monter une contre-attaque. Par exemple, les validateurs honnêtes pourraient décider de continuer de construire sur la chaîne minoritaire et ignorer totalement la fourche de l'attaquant tout en encourageant les applications, les échanges et les pools à faire de même. Ils pourraient également décider de sortir l'attaquant de force du réseau et de détruire l'ETH misé. Ces possibilités constituent des défenses fortes contre une attaque de type 51 %. +La menace d'une [attaque des 51 %](https://www.investopedia.com/terms/1/51-attack.asp) existe toujours avec la preuve d'enjeu, tout comme avec la preuve de travail, mais elle est encore plus risquée pour les attaquants. Un attaquant aurait besoin de 51 % de l'ETH mis en jeu. Ils pourraient alors utiliser leurs propres attestations pour s'assurer que leur fourche préférée est celle qui possède le plus d'attestations. Les clients de consensus utilisent le « poids » des attestations cumulées pour déterminer la chaîne correcte, de sorte que cet attaquant serait en mesure de faire de sa fourche la fourche canonique. Toutefois, l'intérêt de la preuve d'enjeu comparé à la preuve de travail est que la communauté a la possibilité de monter une contre-attaque. Par exemple, les validateurs honnêtes pourraient décider de continuer de construire sur la chaîne minoritaire et ignorer totalement la fourche de l'attaquant tout en encourageant les applications, les échanges et les pools à faire de même. Ils pourraient également décider de sortir l'attaquant de force du réseau et de détruire l'ETH misé. Ces possibilités constituent des défenses fortes contre une attaque de type 51 %. Au-delà des attaques à 51 %, les acteurs mal intentionnés pourraient également tenter d'autres types d'activités malveillantes, telles que : @@ -64,12 +64,12 @@ Dans l'ensemble, il a été démontré que la preuve d'enjeu, telle qu'elle est ## Avantages et inconvénients {#pros-and-cons} -| Avantages | Inconvénients | -| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | +| Avantages | Inconvénients | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | La mise en jeu rend plus accessible la participation du grand public à la sécurisation du réseau, promouvant ainsi la décentralisation. Un nœud de validateur peut être mis en place sur un ordinateur portable basique. Les pools de staking permettent aux utilisateurs de miser sans pour autant posséder 32 ETH. | La preuve d'enjeu est plus jeune et il existe moins de données concernant sa résilience en cas d'attaque que le consensus de preuve de travail | -| Le système de mise est plus décentralisé. Les économies d’échelle ne s’appliquent pas de la même manière que pour le minage effectué sous un consensus de preuve de travail. | La preuve d'enjeu est plus complexe à mettre en place que la preuve de travail | -| La preuve d'enjeu offre une plus grande sécurité crypto-économique que la preuve de travail | Les utilisateurs doivent utiliser trois logiciels pour participer à la preuve d'enjeu d'Ethereum. | -| Une émission moindre de nouveaux ETH est nécessaire pour inciter la participation au réseau | | +| Le système de mise est plus décentralisé. Les économies d’échelle ne s’appliquent pas de la même manière que pour le minage effectué sous un consensus de preuve de travail. | La preuve d'enjeu est plus complexe à mettre en place que la preuve de travail | +| La preuve d'enjeu offre une plus grande sécurité crypto-économique que la preuve de travail | Les utilisateurs doivent utiliser trois logiciels pour participer à la preuve d'enjeu d'Ethereum. | +| Une émission moindre de nouveaux ETH est nécessaire pour inciter la participation au réseau | | ### Comparaison avec la preuve de travail {#comparison-to-proof-of-work} @@ -82,16 +82,16 @@ Initialement, Ethereum utilisait la preuve de travail, mais est passé à la pre - les sanctions économiques en cas de fraude rendent les attaques de type 51% plus onéreuses pour un attaquant que la preuve de travail - La communauté peut, en dernier recours, voter pour la récupération d'une chaîne viable dans le cas où surviendrait une attaque de type 51% malgré les barrières économiques évoquées ci-dessus. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [FAQ pour la preuve d'enjeu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html)_Vitalik Buterin_ -- [Qu'est-ce qu'une Preuve d'enjeu ?](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ -- [Qu'est-ce qu'une preuve d'enjeu et pourquoi c'est important ?](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ -- [Pourquoi la preuve d'enjeu (Nov 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ -- [Preuve d'enjeu : comment j'ai appris à aimer la subjectivité faible ?](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ -- [Attaque et défense des preuves d'enjeu pour Ethereum](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) -- [Une philosophie de design pour la Preuve d'enjeu](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ -- [Vidéo : Vitalik Buterin explique la preuve d'enjeu à Lex Fridman](https://www.youtube.com/watch?v=3yrqBG-7EVE) +- [FAQ sur la preuve d'enjeu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [Qu'est-ce que la preuve d'enjeu](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Qu'est-ce que la preuve d'enjeu et pourquoi c'est important](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [Pourquoi la preuve d'enjeu (nov. 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [Preuve d'enjeu : Comment j'ai appris à aimer la faible subjectivité](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [Attaque et défense de l'Ethereum en preuve d'enjeu](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Une philosophie de conception de la preuve d'enjeu](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [Vidéo : Vitalik Buterin explique la preuve d'enjeu à Lex Fridman](https://www.youtube.com/watch?v=3yrqBG-7EVE) ## Sujets connexes {#related-topics} diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/keys/index.md index 3f7a82378e3..9b5395a5b14 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -1,31 +1,31 @@ --- -title: Les clés dans la preuve d'enjeu d'Ethereum -description: Explications des clés utilisées dans le mécanisme de consensus de preuve d'enjeu d'Ethereum +title: "Les clés dans la preuve d'enjeu d'Ethereum" +description: "Explications des clés utilisées dans le mécanisme de consensus de preuve d'enjeu d'Ethereum" lang: fr --- Ethereum sécurise les actifs des utilisateurs au moyen de la cryptographie à clé publique-privée. La clé publique sert de base à une adresse Ethereum, c'est-à-dire qu'elle est visible par le grand public et utilisée comme identifiant unique. La clé privée (ou secrète) ne doit être accessible qu'à un propriétaire de compte. La clé privée est utilisée pour signer les transactions et les données, afin que la cryptographie puisse prouver que le propriétaire approuve une action d'une clé privée spécifique. -Les clés Ethereum sont générées à l'aide de la cryptographie à [courbe elliptique](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). +Les clés d'Ethereum sont générées à l'aide de la [cryptographie sur les courbes elliptiques](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). -Cependant, quand Ethereum est passé de la [preuve de travail](/developers/docs/consensus-mechanisms/pow) à la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos), un nouveau type de clé a été ajouté à Ethereum. Les clés d'origine fonctionnent toujours exactement comme avant — il n'y a eu aucune modification aux clés basées sur des courbes elliptiques qui sécurisent les comptes. Toutefois, les utilisateurs avaient besoin d'un nouveau type de clé pour participer à la preuve d'enjeu en stakant l'ETH et en exécutant les validateurs. Ce besoin est né des problèmes d'évolutivité associés aux nombreux messages passant entre un grand nombre de validateurs, qui nécessitaient une méthode cryptographique pouvant être facilement agrégée afin de réduire la quantité de communication nécessaire à l'obtention d'un consensus dans le réseau. +Cependant, lorsque Ethereum est passé de la [preuve de travail](/developers/docs/consensus-mechanisms/pow) à la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos), un nouveau type de clé a été ajouté à Ethereum. Les clés d'origine fonctionnent toujours exactement comme avant — il n'y a eu aucune modification aux clés basées sur des courbes elliptiques qui sécurisent les comptes. Toutefois, les utilisateurs avaient besoin d'un nouveau type de clé pour participer à la preuve d'enjeu en stakant l'ETH et en exécutant les validateurs. Ce besoin est né des problèmes d'évolutivité associés aux nombreux messages passant entre un grand nombre de validateurs, qui nécessitaient une méthode cryptographique pouvant être facilement agrégée afin de réduire la quantité de communication nécessaire à l'obtention d'un consensus dans le réseau. -Ce nouveau type de clés utilise le [schéma de signature **Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS permet une agrégation très efficace des signatures mais permet également l'ingénierie inverse des clés individuelles des validateurs agrégées et est idéal pour gérer les actions entre validateurs. +Ce nouveau type de clé utilise le [schéma de signature **Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS permet une agrégation très efficace des signatures mais permet également l'ingénierie inverse des clés individuelles des validateurs agrégées et est idéal pour gérer les actions entre validateurs. ## Les deux types de clés de validateur {#two-types-of-keys} -Avant le passage à la preuve d'enjeu, les utilisateurs d'Ethereum ne disposaient que d'une seule clé privée basée sur la courbe elliptique pour accéder à leurs fonds. Avec l'introduction de la preuve d'enjeu, les utilisateurs qui souhaitaient être des stakers individuels avaient également besoin d'une **clé de validateur** et d'une **clé de retrait**. +Avant le passage à la preuve d'enjeu, les utilisateurs d'Ethereum ne disposaient que d'une seule clé privée basée sur la courbe elliptique pour accéder à leurs fonds. Avec l'introduction de la preuve d'enjeu, les utilisateurs qui souhaitaient être des validateurs individuels avaient également besoin d'une **clé de validateur** et d'une **clé de retrait**. ### La clé de validateur {#validator-key} La clé de signature du validateur est constituée de deux éléments : -- La **clé privée** du validateur -- La **clé publique ** du validateur +- Clé **privée** de validateur +- Clé **publique** de validateur L'objectif de la clé privée du validateur est de signer des opérations sur la blockchain telles que les propositions de bloc et les attestations. Pour cette raison, ces clés doivent être conservées dans un portefeuille chaud. -Cette flexibilité a l'avantage de déplacer très rapidement les clés de signature du validateur d'un appareil à un autre. Cependant, si elles se sont perdues ou sont volées, le voleur peut **agir malicieusement** de plusieurs façons : +Cette flexibilité a l'avantage de déplacer très rapidement les clés de signature du validateur d'un appareil à un autre. Cependant, si elles se sont perdues ou sont volées, le voleur peut agir malicieusement de plusieurs façons : - Slasher le validateur en : - Être proposant et signer deux blocs phares différents pour le même emplacement @@ -33,13 +33,13 @@ Cette flexibilité a l'avantage de déplacer très rapidement les clés de signa - Être un attesteur et signer deux attestations différentes ayant la même cible - Forcer une sortie volontaire, qui empêche le validateur de staker et accorde l'accès à son solde ETH au propriétaire de la clé de retrait -La **clé publique de validation** est incluse dans les données de transaction lorsqu'un utilisateur dépose l'ETH dans le contrat de dépôt du staking. Ceci est connu sous le nom de _données de dépôt_, et il permet à Ethereum d'identifier le validateur. +La **clé publique du validateur** est incluse dans les données de la transaction lorsqu'un utilisateur dépose des ETH sur le contrat de dépôt de staking. Ces informations sont appelées _données de dépôt_ et permettent à Ethereum d'identifier le validateur. ### Identifiants de retrait {#withdrawal-credentials} -Chaque validateur possède une propriété appelée _identifiants de retrait_. Ce champ de 32 octets commence soit par un `0x00`, représentant les identifiants de retrait BLS, soit par un `0x01`, représentant des identifiants qui pointent vers une adresse d'exécution. +Chaque validateur possède une propriété connue sous le nom d'_identifiants de retrait_. Ce champ de 32 octets commence soit par un `0x00`, représentant les identifiants de retrait BLS, soit par un `0x01`, représentant les identifiants qui pointent vers une adresse d'exécution. -Les validateurs avec des clés BLS commençant par `0x00` doivent mettre à jour ces identifiants pour les diriger vers une adresse d'exécution afin d'activer les paiements de solde excédentaire ou le retrait complet de la mise. Cela peut être fait en fournissant une adresse d'exécution dans les données de dépôt lors de la génération initiale de la clé, _OU_ en utilisant ultérieurement la clé de retrait pour signer et diffuser un message `BLSToExecutionChange`. +Les validateurs avec des clés BLS `0x00` doivent mettre à jour ces identifiants pour qu'ils pointent vers une adresse d'exécution afin d'activer les paiements de solde excédentaire ou le retrait complet du staking. Cela peut être fait en fournissant une adresse d'exécution dans les données de dépôt lors de la génération de clé initiale, _OU_ en utilisant la clé de retrait ultérieurement pour signer et diffuser un message `BLSToExecutionChange`. ### La clé de retrait {#withdrawal-key} @@ -47,20 +47,22 @@ La clé de retrait sera nécessaire pour mettre à jour les justificatifs de ret Tout comme les clés de validation, les clés de retrait sont également composées de deux éléments : -- La **clé privée** de retrait -- La **clé publique** de retrait +- Clé **privée** de retrait +- Clé **publique** de retrait -Perdre cette clé avant de mettre à jour les justificatifs de retrait au type `0x01` signifie perdre l'accès au solde du validateur. Le validateur peut toujours signer des attestations et des blocs, car ces actions ne nécessitent pas sa clé privée. Cependant, il existe peu ou pas d'avantage à continuer si les clés de retrait sont perdues. +Perdre cette clé avant de mettre à jour les identifiants de retrait vers le type `0x01` signifie perdre l'accès au solde du validateur. Le validateur peut toujours signer des attestations et des blocs, car ces actions ne nécessitent pas sa clé privée. Cependant, il existe peu ou pas d'avantage à continuer si les clés de retrait sont perdues. La séparation des clés de validateur des clés de comptes Ethereum permet à plusieurs validateurs d'être exécutés par un seul utilisateur. -![schéma de la clé de validateur](validator-key-schematic.png) +![schéma de clé du validateur](validator-key-schematic.png) -## Dérivation des clés à partir d'une phrase de récupération {#deriving-keys-from-seed} +**Remarque** : Pour se retirer des fonctions de staking et retirer le solde d'un validateur, il faut actuellement signer un [message de sortie volontaire (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) avec la clé du validateur. Cependant, l'[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) est une proposition qui permettra à un utilisateur de déclencher la sortie d'un validateur et de retirer son solde en signant des messages de sortie avec la clé de retrait à l'avenir. Cela réduira les hypothèses de confiance en permettant aux stakers qui délèguent des ETH à des [fournisseurs de staking en tant que service](/staking/saas/#what-is-staking-as-a-service) de garder le contrôle de leurs fonds. + +## Dérivation de clés à partir d'une phrase de récupération {#deriving-keys-from-seed} Si chaque mise en jeu de 32 ETH nécessitait un nouvel ensemble de 2 clés complètement indépendantes, la gestion des clés deviendrait rapidement ingérable, en particulier pour les utilisateurs gérant plusieurs validateurs. Au lieu de cela, plusieurs clés de validateur peuvent être dérivées d'un seul secret commun et le stockage de ce seul secret permet d'accéder à plusieurs clés de validateur. -Les [mnémoniques](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) et les chemins sont des éléments importants que les utilisateurs rencontrent souvent lorsqu'[ils accèdent](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) à leurs portefeuilles. Le mnémonique est une séquence de mots qui agit comme une graine initiale pour une clé privée. Lorsqu'il est combiné avec des données supplémentaires, le mnémonique génère un hash connu sous le nom de clé maîtresse. Cela peut être considéré comme la racine d'un arbre. Des branches à partir de cette racine peuvent ensuite être dérivées en utilisant un chemin hiérarchique, de sorte que les nœuds enfants peuvent exister comme des combinaisons du hachage de leur nœud parent et de leur indice dans l'arbre. Lisez les normes [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) et [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) à propos de la génération de clés basée sur des mnémoniques. +Les [mnémoniques](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) et les chemins de dérivation sont des caractéristiques importantes que les utilisateurs rencontrent souvent lorsqu'[ils accèdent](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) à leurs portefeuilles. Le mnémonique est une séquence de mots qui agit comme une graine initiale pour une clé privée. Lorsqu'il est combiné avec des données supplémentaires, le mnémonique génère un hash connu sous le nom de clé maîtresse. Cela peut être considéré comme la racine d'un arbre. Des branches à partir de cette racine peuvent ensuite être dérivées en utilisant un chemin hiérarchique, de sorte que les nœuds enfants peuvent exister comme des combinaisons du hachage de leur nœud parent et de leur indice dans l'arbre. En savoir plus sur les normes [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) et [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) pour la génération de clés à partir de mnémoniques. Ces chemins ont la structure suivante, qui sera familière aux utilisateurs qui ont interagi avec des portefeuilles matériels : @@ -74,7 +76,7 @@ Les barres obliques dans ce chemin séparent les composants de la clé privée c master_key / purpose / coin_type / account / change / address_index ``` -Cette logique permet aux utilisateurs d'attacher autant de validateurs que possible à une seule **phrase mnémotechnique** car la racine de l'arbre peut être commune, et la différenciation se produit au niveau des branches. L'utilisateur peut **dériver un nombre quelconque de clés** à partir d'une phrase mnémotechnique. +Cette logique permet aux utilisateurs d'associer autant de validateurs que possible à une seule **phrase mnémonique**, car la racine de l'arbre peut être commune et la différenciation peut se faire au niveau des branches. L'utilisateur peut **dériver un nombre quelconque de clés** à partir de la phrase mnémonique. ``` [m / 0] @@ -88,9 +90,11 @@ Cette logique permet aux utilisateurs d'attacher autant de validateurs que possi Chaque branche est séparée par un `/`, donc `m/2` signifie commencer avec la clé maîtresse et suivre la branche 2. Dans le schéma ci-dessus, une seule phrase mnémonique est utilisée pour stocker trois clés de retrait, chacune associée à deux validateurs. -![logique de la clé de validateur](multiple-keys.png) +![logique des clés de validateur](multiple-keys.png) ## En savoir plus {#further-reading} -- [Article de blog de l'Ethereum Foundation par Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/) -- [EIP-2333 BLS12-381 génération de clé](https://eips.ethereum.org/EIPS/eip-2333) +- [Article de blog de la Fondation Ethereum par Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 Génération de clé BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002 : Sorties déclenchées par la couche d'exécution](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Gestion des clés à grande échelle](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md index f1b7ce8eb22..e274c4b3e7d 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -1,6 +1,6 @@ --- title: Preuve d'enjeu contre preuve de travail -description: Une comparaison entre le mécanisme de consensus basé sur la preuve d'enjeu et la preuve de travail d'Ethereum +description: "Une comparaison entre le mécanisme de consensus basé sur la preuve d'enjeu et la preuve de travail d'Ethereum" lang: fr --- @@ -12,19 +12,19 @@ Cette page décrit les raisons pour lesquelles Ethereum est passé de la preuve Les chercheurs d'Ethereum considèrent que la preuve d'enjeu est plus sûre que la preuve de travail. Cependant, elle n'a été mise en œuvre que récemment pour le réseau principal Ethereum et elle est moins éprouvée que la preuve de travail. Les sections suivantes présentent les avantages et les inconvénients du modèle de sécurité de la preuve d'enjeu par rapport à celui de la preuve de travail. -### Coût de l'attaque {#cost-to-attack} +### Coût d'une attaque {#cost-to-attack} -Dans la preuve d'enjeu, les validateurs sont tenus de mettre en dépôt (« mise ») au moins 32 ETH dans un contrat intelligent. Ethereum peut détruire l'éther mis en jeu pour punir les validateurs qui se comportent mal. Pour parvenir à un consensus, il faut qu'au moins 66 % du total d'éthers mis en jeu votent en faveur d'un ensemble particulier de blocs. Les blocs approuvés par >=66 % des participants deviennent « finalisés », ce qui signifie qu'ils ne peuvent pas être supprimés ou réorganisés. +Dans la preuve d'enjeu, les validateurs sont tenus de mettre en dépôt (« mise ») au moins 32 ETH dans un contrat intelligent. Ethereum peut détruire l'éther mis en jeu pour punir les validateurs qui se comportent mal. Pour parvenir à un consensus, il faut qu'au moins 66 % du total d'éthers mis en jeu votent en faveur d'un ensemble particulier de blocs. Les blocs approuvés par >= 66 % de la mise deviennent « finalisés », ce qui signifie qu'ils ne peuvent être ni supprimés ni réorganisés. Attaquer le réseau peut signifier empêcher la chaîne de se finaliser ou garantir une certaine organisation des blocs dans la chaîne canonique qui profite d'une manière ou d'une autre à l'attaquant. Pour ce faire, l'attaquant doit détourner la voie d'un consensus honnête, soit en accumulant une grande quantité d'éther et en votant directement avec, soit en trompant les validateurs honnêtes pour qu'ils votent d'une manière particulière. Hormis les attaques sophistiquées et peu probables qui trompent les validateurs honnêtes, le coût d'une attaque contre Ethereum est le coût de l'enjeu qu'un attaquant doit accumuler pour influencer le consensus en sa faveur. -Le coût d'attaque le plus bas est >33 % de l'enjeu total. Un attaquant détenant >33 % de l'enjeu total peut provoquer un retard de finalité simplement en se déconnectant. Il s'agit d'un problème relativement mineur pour le réseau, car il existe un mécanisme connu sous le nom de « fuite d'inactivité » qui fait fuir les enjeux des validateurs hors ligne jusqu'à ce que la majorité en ligne représente 66 % des enjeux et puisse à nouveau finaliser la chaîne. Il est également théoriquement possible pour un attaquant de provoquer une double finalité avec un peu plus de 33 % de l'enjeu total en créant deux blocs au lieu d'un lorsqu'on lui demande d'être producteur de blocs, puis en procédant à un double vote avec tous ses validateurs. Chaque fourche ne nécessite que 50 % des validateurs honnêtes restants pour voir chaque bloc en premier, donc s'ils parviennent à synchroniser correctement leurs messages, ils pourront peut-être finaliser les deux fourches. Cela a peu de chances de réussir, mais si un attaquant parvenait à causer une double-finalité, la communauté Ethereum devrait décider de suivre une des fourches, auquel cas les validateurs de l'attaquant seraient nécessairement sanctionnés sur l'autre. +Le coût d'attaque le plus bas est supérieur à 33 % de la mise totale. Un attaquant détenant plus de 33 % de la mise totale peut entraîner un retard de finalité simplement en se déconnectant. Il s'agit d'un problème relativement mineur pour le réseau, car il existe un mécanisme connu sous le nom de « fuite d'inactivité » qui fait fuir les enjeux des validateurs hors ligne jusqu'à ce que la majorité en ligne représente 66 % des enjeux et puisse à nouveau finaliser la chaîne. Il est également théoriquement possible pour un attaquant de provoquer une double finalité avec un peu plus de 33 % de l'enjeu total en créant deux blocs au lieu d'un lorsqu'on lui demande d'être producteur de blocs, puis en procédant à un double vote avec tous ses validateurs. Chaque fourche ne nécessite que 50 % des validateurs honnêtes restants pour voir chaque bloc en premier, donc s'ils parviennent à synchroniser correctement leurs messages, ils pourront peut-être finaliser les deux fourches. Cela a peu de chances de réussir, mais si un attaquant parvenait à causer une double-finalité, la communauté Ethereum devrait décider de suivre une des fourches, auquel cas les validateurs de l'attaquant seraient nécessairement sanctionnés sur l'autre. -Avec >33% de la mise totale, un attaquant a une chance d'avoir un effet mineur (retard de finalité) ou plus grave (double finalité) sur le réseau Ethereum. Avec plus de 14 000 000 ETH bloqués sur le réseau et un prix représentatif de 1 000 $/ETH, le coût minimum pour faire ces attaques est de `1000 x 14 000 000 x 0,33 = 4 620 000 000 $`. L'attaquant perdrait son argent à cause des pénalités et serait expulsé du réseau. Pour attaquer à nouveau, ils devraient accumuler >33 % de la mise (encore une fois) et la brûler (encore une fois). Chaque tentative d'attaque du réseau coûterait > 4,6 milliards de dollars (à 1 000 $/ETH et 14M ETH misés). L'attaquant est également expulsé du réseau lorsqu'il est sanctionné, et il doit donc rejoindre la file d'attente d'activation pour revenir. Cela signifie que la fréquence d'une attaque répétée est limitée non seulement par la vitesse à laquelle l'attaquant peut accumuler >33 % de la mise totale, mais aussi par le temps nécessaire pour intégrer tous leurs validateurs sur le réseau. Chaque fois que l'attaquant lance une attaque, il devient beaucoup plus pauvre, et le reste de la communauté s'enrichit, grâce au choc d'offre qui en résulte. +Avec plus de 33 % de la mise totale, un attaquant a une chance d'avoir un effet mineur (retard de finalité) ou plus grave (double finalité) sur le réseau Ethereum. Avec plus de 14 000 000 d'ETH mis en jeu sur le réseau et un prix représentatif de 1 000 $/ETH, le coût minimum pour monter ces attaques est de `1000 x 14 000 000 x 0,33 = 4 620 000 000 $`. L'attaquant perdrait son argent à cause des pénalités et serait expulsé du réseau. Pour attaquer à nouveau, ils devraient accumuler plus de 33 % de la mise (encore) et la brûler (encore). Chaque tentative d'attaque du réseau coûterait plus de 4,6 milliards de dollars (à 1 000 $/ETH et 14M d'ETH misés). L'attaquant est également expulsé du réseau lorsqu'il est sanctionné, et il doit donc rejoindre la file d'attente d'activation pour revenir. Cela signifie que la fréquence d'une attaque répétée est limitée non seulement par la vitesse à laquelle l'attaquant peut accumuler plus de 33 % de la mise totale, mais aussi par le temps nécessaire pour intégrer tous ses validateurs sur le réseau. Chaque fois que l'attaquant lance une attaque, il devient beaucoup plus pauvre, et le reste de la communauté s'enrichit, grâce au choc d'offre qui en résulte. D'autres attaques, telles que les attaques 51 % ou la réversion de la finalité avec 66 % de la mise totale, nécessitent beaucoup plus d'ETH et coûtent beaucoup plus cher à l'attaquant. -Comparons cela avec le mécanisme de preuve de travail. Le coût du lancement d’une attaque contre la preuve de travail Ethereum était le coût de la possession constante de >50 % du taux de hachage total du réseau. Cela équivalait au coût du matériel et aux frais de fonctionnement nécessaires pour disposer d'une puissance de calcul suffisante pour surpasser régulièrement les autres mineurs dans le calcul des solutions de preuve de travail. Ethereum était principalement exploité à l'aide de GPU plutôt que d'ASIC, ce qui permettait de réduire les coûts (même si Ethereum était resté sur une preuve de travail, l'exploitation minière ASIC serait peut-être devenue plus populaire). Un attaquant devrait acheter beaucoup de matériel et payer pour l'électricité nécessaire afin d'attaquer un réseau Ethereum basé sur la preuve de travail, mais le coût total serait inférieur au coût nécessaire pour accumuler suffisamment d'ETH pour lancer une attaque. Une attaque à 51 % est ~[20 fois](https://youtu.be/1m12zgJ42dI?t=1562) moins chère sur la preuve de travail que sur la preuve d'enjeu. Si l'attaque était détectée et que la chaîne effectuait une séparation pour supprimer leurs altérations, l'attaquant pourrait utiliser à nouveau le même matériel pour attaquer la nouvelle fourche. +Comparons cela avec le mécanisme de preuve de travail. Le coût du lancement d’une attaque sur l'Ethereum à preuve de travail était le coût de la possession constante de plus de 50 % du taux de hachage total du réseau. Cela équivalait au coût du matériel et aux frais de fonctionnement nécessaires pour disposer d'une puissance de calcul suffisante pour surpasser régulièrement les autres mineurs dans le calcul des solutions de preuve de travail. Ethereum était principalement exploité à l'aide de GPU plutôt que d'ASIC, ce qui permettait de réduire les coûts (même si Ethereum était resté sur une preuve de travail, l'exploitation minière ASIC serait peut-être devenue plus populaire). Un attaquant devrait acheter beaucoup de matériel et payer pour l'électricité nécessaire afin d'attaquer un réseau Ethereum basé sur la preuve de travail, mais le coût total serait inférieur au coût nécessaire pour accumuler suffisamment d'ETH pour lancer une attaque. Une attaque à 51 % est environ [20 fois moins](https://youtu.be/1m12zgJ42dI?t=1562) coûteuse en preuve de travail qu'en preuve d'enjeu. Si l'attaque était détectée et que la chaîne effectuait une séparation pour supprimer leurs altérations, l'attaquant pourrait utiliser à nouveau le même matériel pour attaquer la nouvelle fourche. ### Complexité {#complexity} @@ -36,7 +36,7 @@ Pour développer et tester en toute sécurité la logique de consensus de la pre La preuve d'enjeu est plus complexe que la preuve de travail, ce qui signifie qu'il y a davantage de vecteurs d'attaque potentiels à gérer. Au lieu d'un réseau pair-à-pair reliant les clients, il y en a deux, chacun mettant en œuvre un protocole distinct. Le fait qu'un validateur spécifique soit présélectionné pour proposer un bloc dans chaque créneau crée un risque de déni de service lorsque de grandes quantités de trafic réseau mettent ce validateur spécifique hors ligne. -Les attaquants peuvent également programmer avec soin la publication de leurs blocs ou attestations de manière à ce qu'ils soient reçus par une certaine proportion du réseau honnête, l'incitant ainsi à voter d'une certaine manière. Finalement, un attaquant peut simplement accumuler suffisamment d'ETH en vue de le mettre en jeu et de dominer le mécanisme de consensus. Chacun de ces [vecteurs d'attaque a des défenses associées](/developers/docs/consensus-mechanisms/pos/attack-and-defense), mais ils n'existent pas pour être défendus sous preuve de travail. +Les attaquants peuvent également programmer avec soin la publication de leurs blocs ou attestations de manière à ce qu'ils soient reçus par une certaine proportion du réseau honnête, l'incitant ainsi à voter d'une certaine manière. Finalement, un attaquant peut simplement accumuler suffisamment d'ETH en vue de le mettre en jeu et de dominer le mécanisme de consensus. Chacun de ces [vecteurs d'attaque a des défenses associées](/developers/docs/consensus-mechanisms/pos/attack-and-defense), mais ils n'existent pas pour être défendus dans le cadre de la preuve de travail. ## Décentralisation {#decentralization} @@ -46,7 +46,7 @@ D'un autre côté, l'invention des produits dérivés de mise en jeu liquide a c Pour Ethereum, la meilleure option consiste à faire fonctionner les validateurs localement, sur des ordinateurs personnels, afin de maximiser la décentralisation. Cela explique pourquoi Ethereum résiste aux changements qui augmentent les exigences matérielles pour le fonctionnement d'un nœud/validateur. -## Développement durable {#sustainability} +## Durabilité {#sustainability} La preuve d'enjeu est une manière peu gourmande en carbone de sécuriser la blockchain. Dans le cadre de la preuve de travail, les mineurs sont en concurrence pour obtenir le droit de miner un bloc. Les mineurs sont plus performants lorsqu'ils peuvent effectuer des calculs plus rapidement, ce qui incite à investir dans le matériel et la consommation d'énergie. C'est ce qui a été observé pour Ethereum avant de passer à la preuve d'enjeu. Peu avant le passage à la preuve d'enjeu, Ethereum consommait environ 78 TWh/an, soit autant qu'un petit pays. Cependant, le passage à la preuve d'enjeu a permis de réduire cette dépense énergétique de ~99,98 %. La preuve d'enjeu a fait d'Ethereum une plateforme économe en énergie et à faible émission de carbone. @@ -62,8 +62,8 @@ Regardez Justin Drake expliquer les avantages de la preuve d'enjeu par rapport -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} - [La philosophie de conception de la preuve d'enjeu par Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) -- [Les FAQ de Vitalik sur la preuve d'enjeu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) -- [Vidéo de « Simply Explained » sur pas vs pow](https://www.youtube.com/watch?v=M3EFi_POhps) +- [FAQ sur la preuve d'enjeu par Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Vidéo « Simplement expliqué » sur PoS contre PoW](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 0efabd0e088..9853951e71b 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -1,10 +1,10 @@ --- -title: Récompenses et pénalités de preuve d'enjeu -description: Découvrez les incitations intégrées au protocole dans la preuve de mise en jeu d'Ethereum. +title: "Récompenses et pénalités de preuve d'enjeu" +description: "Découvrez les incitations intégrées au protocole dans la preuve de mise en jeu d'Ethereum." lang: fr --- -Ethereum est sécurisé à l'aide de sa cryptomonnaie native, l'ether (ETH). Les opérateurs de nœuds qui souhaitent participer à la validation de blocs et identifier la tête de la chaîne déposent de l'éther dans le [contrat de dépôt](/staking/deposit-contract/) sur Ethereum. Ils sont ensuite payés en ether pour exécuter un logiciel de validateur qui vérifie la validité des nouveaux blocs reçus sur le réseau peer-to-peer et applique l'algorithme de choix de fourche pour identifier la tête de la chaîne. +Ethereum est sécurisé à l'aide de sa cryptomonnaie native, l'ether (ETH). Les opérateurs de nœuds qui souhaitent participer à la validation des blocs et à l'identification de la tête de la chaîne déposent de l'éther dans le [contrat de dépôt](/staking/deposit-contract/) sur Ethereum. Ils sont ensuite payés en ether pour exécuter un logiciel de validateur qui vérifie la validité des nouveaux blocs reçus sur le réseau peer-to-peer et applique l'algorithme de choix de fourche pour identifier la tête de la chaîne. Il y a deux rôles principaux pour un validateur : 1) vérifier les nouveaux blocs et les « attester » s'ils sont valides, 2) proposer de nouveaux blocs lorsqu'il est sélectionné au hasard dans la réserve de validateur totale. Si le validateur ne parvient pas à faire l'une de ces tâches quand il lui est demandé de ne pas recevoir un paiement par éther. Les validateurs sont aussi parfois chargés d'agréger les signatures et de participer à des comités de synchronisation. @@ -18,51 +18,51 @@ Continuez pour plus de détails... ### Récompenses {#rewards} -Les validateurs reçoivent des récompenses lorsqu'ils effectuent des votes cohérents avec la majorité des autres validateurs, lorsqu'ils proposent des blocs et lorsqu'ils participent à des comités de synchronisation. La valeur des récompenses à chaque époque est calculée à partir d'une `base_reward`. Il s'agit de l'unité de base à partir de laquelle les autres récompenses sont calculées. La `base_reward` représente la récompense moyenne reçue par un validateur dans des conditions optimales par période. Ceci est calculé à partir du solde effectif du validateur et du nombre total de validateurs actifs comme suit : +Les validateurs reçoivent des récompenses lorsqu'ils effectuent des votes cohérents avec la majorité des autres validateurs, lorsqu'ils proposent des blocs et lorsqu'ils participent à des comités de synchronisation. La valeur des récompenses à chaque époque est calculée à partir d'une `base_reward`. Il s'agit de l'unité de base à partir de laquelle les autres récompenses sont calculées. La `base_reward` représente la récompense moyenne reçue par un validateur dans des conditions optimales par époque. Ceci est calculé à partir du solde effectif du validateur et du nombre total de validateurs actifs comme suit : ``` base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) ``` -où `base_reward_factor` est 64, `base_rewards_per_epoch` est 4 et `sum(active balance)` représente le montant total d'Ether mis en jeu par l'ensemble des validateurs actifs. +où `base_reward_factor` est 64, `base_rewards_per_epoch` est 4 et `sum(active balance)` est le total d'ether mis en jeu par l'ensemble des validateurs actifs. -Cela signifie que la récompense de base est proportionnelle au solde effectif du validateur et inversement proportionnelle au nombre de validateurs sur le réseau. Plus il y a de validateurs, plus l'émission globale est importante (selon la formule `sqrt(N))`, mais plus la `base_reward` par validateur est petite (selon la formule `1/sqrt(N)`). Ces facteurs influencent le Taux de Rendement Annuel (APR) pour un nœud de mise en jeu. Lisez la justification de cela dans [les notes de Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). +Cela signifie que la récompense de base est proportionnelle au solde effectif du validateur et inversement proportionnelle au nombre de validateurs sur le réseau. Plus il y a de validateurs, plus l'émission globale est importante (en tant que `sqrt(N)`), mais plus la `base_reward` par validateur est petite (en tant que `1/sqrt(N)`). Ces facteurs influencent le Taux de Rendement Annuel (APR) pour un nœud de mise en jeu. Lisez la justification de ceci dans les [notes de Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). La récompense totale est ensuite calculée comme la somme de cinq composants, chacun ayant un poids qui détermine la contribution de chaque composant à la récompense totale. Les composants sont : ``` -1. source vote: the validator has made a timely vote for the correct source checkpoint -2. target vote: the validator has made a timely vote for the correct target checkpoint -3. head vote: the validator has made a timely vote for the correct head block -4. sync committee reward: the validator has participated in a sync committee -5. proposer reward: the validator has proposed a block in the correct slot +1. vote de source : le validateur a voté à temps pour le point de contrôle de source correct +2. vote de cible : le validateur a voté à temps pour le point de contrôle de cible correct +3. vote de tête : le validateur a voté à temps pour le bloc de tête correct +4. récompense du comité de synchronisation : le validateur a participé à un comité de synchronisation +5. récompense du proposant : le validateur a proposé un bloc dans le créneau correct ``` Les pondérations pour chaque composant sont les suivantes : ``` -TIMELY_SOURCE_WEIGHT uint64(14) -TIMELY_TARGET_WEIGHT uint64(26) -TIMELY_HEAD_WEIGHT uint64(14) -SYNC_REWARD_WEIGHT uint64(2) -PROPOSER_WEIGHT uint64(8) +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) ``` -Ces poids s'additionnent pour atteindre 64. La récompense est calculée comme la somme des poids applicables divisée par 64. Un validateur ayant effectué des votes de source, de cible et de tête en temps opportun, proposé un bloc et participé à un comité de synchronisation pourrait recevoir `64/64 * base_reward == base_reward`. Cependant, un validateur n'est généralement pas un proposeur de bloc, donc sa récompense maximale est `64-8 /64 * base_reward == 7/8 * base_reward`. Les validateurs qui ne sont ni des proposeurs de blocs ni figurant dans un comité de synchronisation peuvent recevoir `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. +Ces poids s'additionnent pour atteindre 64. La récompense est calculée comme la somme des poids applicables divisée par 64. Un validateur qui a effectué des votes de source, de cible et de tête en temps opportun, proposé un bloc et participé à un comité de synchronisation pourrait recevoir `64/64 * base_reward == base_reward`. Cependant, un validateur n'est généralement pas un proposeur de bloc, donc sa récompense maximale est `64-8 /64 * base_reward == 7/8 * base_reward`. Les validateurs qui ne sont ni des proposeurs de blocs ni dans un comité de synchronisation peuvent recevoir `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. -Une récompense additionnelle est prévue pour promouvoir les attestations rapides. C'est le `inclusion_delay_reward`. Cela a une valeur égale à la `base_reward` multipliée par `1/delay` où `delay` est le nombre de créneaux séparant la proposition de bloc et son attestation. Par exemple, si l'attestation est soumise dans un créneau de la proposition de bloc, le attestateur reçoit `base_reward * 1/1 == base_reward`. Si l'attestation arrive sur le créneau suivant, l'attestateur reçoit `base_reward * 1/2` et ainsi de suite. +Une récompense additionnelle est prévue pour promouvoir les attestations rapides. C'est la `inclusion_delay_reward`. Elle a une valeur égale à la `base_reward` multipliée par `1/delay` où `delay` est le nombre de créneaux séparant la proposition de bloc et l'attestation. Par exemple, si l'attestation est soumise dans un délai d'un créneau après la proposition de bloc, l'attestant reçoit `base_reward * 1/1 == base_reward`. Si l'attestation arrive dans le créneau suivant, l'attestant reçoit `base_reward * 1/2` et ainsi de suite. -Les proposeurs de blocs reçoivent `8 / 64 * base_reward` pour **chaque attestation valide** incluse dans le bloc, donc la valeur réelle de la récompense évolue avec le nombre de validateurs attestant. Les proposeurs de blocs peuvent également augmenter leur récompense en incluant des preuves de comportement malhonnête d'autres validateurs dans le bloc qu'ils proposent. Ces récompenses sont les « carottes » qui encouragent l'honnêteté des validateurs. Un proposeur de bloc qui inclut une pénalité sera récompensé par le montant de `slashed_validators_effective_balance / 512`. +Les proposeurs de blocs reçoivent `8 / 64 * base_reward` pour **chaque attestation valide** incluse dans le bloc, donc la valeur réelle de la récompense évolue avec le nombre de validateurs qui attestent. Les proposeurs de blocs peuvent également augmenter leur récompense en incluant des preuves de comportement malhonnête d'autres validateurs dans le bloc qu'ils proposent. Ces récompenses sont les « carottes » qui encouragent l'honnêteté des validateurs. Un proposeur de bloc qui inclut un délestage sera récompensé avec `slashed_validators_effective_balance / 512`. ### Pénalités {#penalties} Jusqu'à présent, nous avons pris en compte les validateurs qui agissent conformément aux règles, mais qu'en est-il des validateurs qui ne votent pas en temps voulu pour la tête, la source et la cible, ou qui le font lentement ? -Les pénalités pour avoir manqué les votes de cible et de source sont égales aux récompenses que l'attestateur aurait reçues s'il les avait soumis. Cela signifie qu'au lieu d'avoir la récompense ajoutée à leur solde, ils voient une valeur égale retirée de leur solde. Il n'y a pas de pénalité pour avoir manqué le vote de tête (les votes de tête sont uniquement récompensés, jamais pénalisés). Aucune pénalité n'est associée au `inclusion_delay` - la récompense ne sera tout simplement pas ajoutée au solde du validateur. Il n'y a également aucune pénalité pour ne pas avoir réussi à proposer un bloc. +Les pénalités pour avoir manqué les votes de cible et de source sont égales aux récompenses que l'attestateur aurait reçues s'il les avait soumis. Cela signifie qu'au lieu d'avoir la récompense ajoutée à leur solde, ils voient une valeur égale retirée de leur solde. Il n'y a pas de pénalité pour avoir manqué le vote de tête (c.-à-d. que les votes de tête sont seulement récompensés, jamais pénalisés). Aucune pénalité n'est associée au `inclusion_delay` : la récompense ne sera tout simplement pas ajoutée au solde du validateur. Il n'y a également aucune pénalité pour ne pas avoir réussi à proposer un bloc. -Pour en savoir plus sur les récompenses et les pénalités, consultez les [spécifications de consensus](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Les récompenses et les pénalités ont été ajustées lors de la mise à niveau Bellatrix - regardez Danny Ryan et Vitalik en discuter dans cette vidéo [Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). +En savoir plus sur les récompenses et les pénalités dans les [spécifications du consensus](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Les récompenses et les pénalités ont été ajustées dans la mise à niveau Bellatrix : regardez Danny Ryan et Vitalik en discuter dans cette [vidéo Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). -## Sanction {#slashing} +## Délestage {#slashing} Le « slashing » est une action plus sévère qui entraîne la suppression forcée d'un validateur du réseau et la perte associée de leur ether mis en jeu. Il existe trois façons dont un validateur peut être « slashé » (sanctionné), toutes impliquant la proposition ou l'attestation malhonnête de blocs : @@ -70,20 +70,21 @@ Le « slashing » est une action plus sévère qui entraîne la suppression forc - En attestant un bloc qui « entoure » un autre bloc (modifiant effectivement l'historique) - En « votant double » en attestant deux candidats pour le même bloc -Si ces actions sont détectées, le validateur est sanctionné. Cela signifie que 1/32 de leur ether mis en jeu (jusqu'à un maximum d'1 ether) est immédiatement brûlé, puis une période de suppression de 36 jours commence. Pendant cette période de suppression, la mise du validateur diminue progressivement. À mi-parcours (jour 18), une pénalité supplémentaire est appliquée, dont l'ampleur varie en fonction de l'ether mis en jeu total de tous les validateurs sanctionnés au cours des 36 jours précédant l'événement de « slash ». Cela signifie que lorsque davantage de validateurs sont sanctionnés, l'ampleur de la pénalité augmente. Le slash maximum est le solde effectif total de tous les validateurs slashés (c'est-à-dire que s'il y a beaucoup de validateurs slashés, ils pourraient perdre la totalité de leur mise). D'autre part, un seul événement de « slash » isolé ne brûle qu'une petite partie de la mise du validateur. Cette pénalité intermédiaire qui varie en fonction du nombre de validateurs sanctionnés est appelée « pénalité de corrélation ». +Si ces actions sont détectées, le validateur est sanctionné. Cela signifie que 0,0078125 est immédiatement brûlé pour un validateur de 32 ETH (valeur ajustée de manière linéaire en fonction du solde actif), puis une période de retrait de 36 jours commence. Pendant cette période de suppression, la mise du validateur diminue progressivement. À mi-parcours (jour 18), une pénalité supplémentaire est appliquée, dont l'ampleur varie en fonction de l'ether mis en jeu total de tous les validateurs sanctionnés au cours des 36 jours précédant l'événement de « slash ». Cela signifie que lorsque davantage de validateurs sont sanctionnés, l'ampleur de la pénalité augmente. Le délestage maximum est le solde effectif total de tous les validateurs délestés (c.-à-d. que si de nombreux validateurs sont délestés, ils pourraient perdre la totalité de leur mise). D'autre part, un seul événement de « slash » isolé ne brûle qu'une petite partie de la mise du validateur. Cette pénalité intermédiaire qui varie en fonction du nombre de validateurs sanctionnés est appelée « pénalité de corrélation ». -## Fuite d’inactivité {#inactivity-leak} +## Fuite d'inactivité {#inactivity-leak} Si la couche de consensus a passé plus de quatre périodes sans se finaliser, un protocole d'urgence appelé « fuite d'inactivité » est activé. Le but ultime de la fuite d'inactivité est de créer les conditions nécessaires pour que la chaîne retrouve sa finalité. Comme expliqué précédemment, la finalité nécessite une majorité de 2/3 de l'ether mis en jeu total pour s'entendre sur les points de contrôle source et cible. Si les validateurs représentant plus d'1/3 du total des validateurs se déconnectent ou ne soumettent pas les attestations correctes, il n'est pas possible pour une supermajorité des 2/3 de finaliser les points de contrôle. La fuite d'inactivité permet à la mise participant aux validateurs inactifs de s'épuiser progressivement jusqu'à ce qu'ils contrôlent moins d'un tiers de la mise totale, permettant ainsi aux validateurs actifs restants de finaliser la chaîne. Cependant, quelle que soit la taille du groupe de validateurs inactifs, les validateurs actifs restants finiront par contrôler plus de 2/3 des ETH en jeu. La perte d'ETH est une forte incitation pour les validateurs inactifs à se réactiver dès que possible ! Un scénario de fuite d'inactivité a été rencontré sur le réseau de test Medalla lorsque moins de 66 % des validateurs actifs ont pu parvenir à un consensus sur la tête actuelle de la blockchain. La fuite d'inactivité a été activée et la finalité a finalement été retrouvée ! La récompense, la pénalité et le mécanisme de sanction du mécanisme de consensus encouragent les validateurs individuels à se comporter correctement. Cependant, de ces choix de conception émerge un système qui encourage fortement une répartition égale des validateurs entre plusieurs clients, et devrait fortement décourager la domination d’un seul client. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Améliorer Ethereum : la couche d'incitations](https://eth2book.info/altair/part2/incentives) -- [Incitations dans le protocole Casper hybride d'Ethereum](https://arxiv.org/pdf/1903.04205.pdf) +- [Mettre à niveau Ethereum : la couche d'incitation](https://eth2book.info/altair/part2/incentives) +- [Incitatifs dans le protocole hybride Casper d'Ethereum](https://arxiv.org/pdf/1903.04205.pdf) - [Spécifications annotées de Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) -- [Conseils de prévention de pénalité pour Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Conseils pour la prévention du délestage sur Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Analyse des pénalités de délestage dans le cadre de l'EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) _Sources_ diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md index 4563ec076fc..5e45acb84e1 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -1,6 +1,6 @@ --- title: Weak subjectivity -description: Une explication de la « faible subjectivité » et de son rôle dans la PoS d'Ethereum. +description: "Une explication de la « faible subjectivité » et de son rôle dans la PoS d'Ethereum." lang: fr --- @@ -8,9 +8,9 @@ La subjectivité dans les blockchains se réfère au recours à l'information so ## Prérequis {#prerequisites} -Pour comprendre cette page, il faut d'abord comprendre les fondamentaux de [la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/). +Pour comprendre cette page, il faut d'abord comprendre les fondamentaux de la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/). -## Quels problèmes la faible subjectivité résout-elle ? {#problems-ws-solves} +## Quels problèmes la faible subjectivité résout-elle ? Problèmes résolus par la faible subjectivité {#problems-ws-solves} La subjectivité est inhérente aux blockchains en preuve d'enjeu puisque la sélection de la bonne chaîne depuis plusieurs forks est réalisée par le comptage des votes historiques. Cela expose la blockchain à plusieurs vecteurs d'attaque, y compris les attaques de longue portée par lesquelles les nœuds qui ont participé très tôt à la chaîne maintiennent un fork alternatif qu'ils libèrent beaucoup plus tard à leur propre avantage. Alternativement, si 33 % des validateurs retirent leur mise mais continuent à attester et à produire des blocs, ils pourraient générer un fork alternatif qui entrerait en conflit avec la chaîne canonique. Les nouveaux nœuds ou ceux qui sont hors connexion depuis longtemps peuvent ne pas être avisés que ces validateurs hostiles ont retiré leurs fonds, afin que les attaquants puissent amener les nœuds à suivre une chaîne incorrecte. Ethereum peut parer à ces vecteurs d'attaque en imposant des contraintes qui réduisent au strict minimum les aspects subjectifs du mécanisme, et ainsi les hypothèses de confiance. @@ -30,10 +30,10 @@ Un point de contrôle de la faible subjectivité peut même faire partie du logi Enfin, les points de contrôle peuvent être demandés à d'autres nœuds  ; il se peut qu'un autre utilisateur d'Ethereum qui exécute un nœud complet puisse fournir un point de contrôle que les validateurs peuvent ensuite vérifier par rapport aux données d'un explorateur de blocs. Globalement, faire confiance au fournisseur d'un point de contrôle de subjectivité faible peut être considéré comme aussi problématique que de faire confiance aux développeurs du client. La confiance globale requise est faible. Il est important de noter que ces considérations ne deviennent importantes que dans le cas très improbable où une majorité de validateurs conspirent pour produire une autre fourche de la blockchain. Dans toutes les autres circonstances, il n'y a qu'une seule chaîne Ethereum parmi laquelle choisir. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Faible subjectivité dans Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) -- [Vitalik : comment j'ai appris à aimer la faible subjectivité](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) -- [Faible subjectivité (Teku docs)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/) -- [Guide de la faible subjectivité Phase-0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [La faible subjectivité dans Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik : Comment j'ai appris à aimer la faible subjectivité](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Faible subjectivité (documentation Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Guide sur la faible subjectivité de la Phase 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) - [Analyse de la faible subjectivité dans Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/index.md index f34c44ab3a2..9e7264b97db 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/index.md @@ -1,27 +1,27 @@ --- title: Preuve de travail (PoW) -description: Explication du protocole de consensus « preuve de travail » et de son rôle dans Ethereum. +description: "Explication du protocole de consensus « preuve de travail » et de son rôle dans Ethereum." lang: fr --- -Le réseau Ethereum a commencé par utiliser un mécanisme de consensus basé sur la **[Preuve de travail (PoW)](/developers/docs/consensus-mechanisms/pow)**. Cela permet à l'ensemble des nœuds du réseau Ethereum de s'accorder sur l'état de toutes les informations enregistrées sur la blockchain Ethereum, empêchant ainsi certains types d'attaques économiques. Ethereum a néanmoins abandonné la preuve de travail en 2022 et a commencé à utiliser la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos). +Le réseau Ethereum a commencé par utiliser un mécanisme de consensus qui impliquait la **[preuve de travail (PoW)](/developers/docs/consensus-mechanisms/pow)**. Cela permet à l'ensemble des nœuds du réseau Ethereum de s'accorder sur l'état de toutes les informations enregistrées sur la blockchain Ethereum, empêchant ainsi certains types d'attaques économiques. Cependant, Ethereum a abandonné la preuve de travail en 2022 et a commencé à utiliser la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos) à la place. - La preuve de travail est maintenant obsolète. Ethereum n'utilise plus la preuve de travail dans le cadre de son mécanisme de consensus. En lieu et place, Ethereum utilise la preuve d'enjeu. En savoir plus sur la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) et le [staking](/staking/). + La preuve de travail est maintenant obsolète. Ethereum n'utilise plus la preuve de travail dans le cadre de son mécanisme de consensus. En lieu et place, Ethereum utilise la preuve d'enjeu. Read more on [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) and [staking](/staking/). ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, nous vous recommandons de commencer par lire celles concernant [les transactions](/developers/docs/transactions/), [les blocs](/developers/docs/blocks/) et [les mécanismes de consensus](/developers/docs/consensus-mechanisms/). +Pour mieux comprendre cette page, nous vous recommandons d'abord d'en lire plus sur les transactions (/developers/docs/transactions/), les blocs (/developers/docs/blocks/), et les mécanismes de consensus (/developers/docs/consensus-mechanisms/). ## Qu'est ce que la preuve de travail (PoW) ? {#what-is-pow} -Le consensus Nakamoto, qui utilise la preuve de travail, est le mécanisme qui a autrefois permis au réseau Ethereum décentralisé de parvenir à un consensus (c.-à-d. que l'ensemble des nœuds sont d'accord) sur des choses telles que les soldes des comptes et l'ordre des transactions. Cela empêche les utilisateurs d'effectuer une « double dépense » et garantit qu'il est extrêmement difficile d'attaquer la chaîne Ethereum ou de la manipuler. Ces propriétés de sécurité proviennent désormais de la preuve d'enjeu, en utilisant le mécanisme de consensus connu sous le nom de [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). +Le consensus Nakamoto, qui utilise la preuve de travail, est le mécanisme qui a autrefois permis au réseau Ethereum décentralisé de parvenir à un consensus (c.-à-d. que tous les nœuds s'accordent) sur des points tels que les soldes des comptes et l'ordre des transactions. Cela empêche les utilisateurs d'effectuer une « double dépense » et garantit qu'il est extrêmement difficile d'attaquer la chaîne Ethereum ou de la manipuler. Ces propriétés de sécurité proviennent désormais de la preuve d'enjeu qui utilise le mécanisme de consensus connu sous le nom de [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). ## Preuve de travail et minage {#pow-and-mining} @@ -34,8 +34,8 @@ La preuve de travail est l'algorithme sous-jacent qui définit la difficulté et Les transactions Ethereum sont traitées en blocs. Avec le processus désormais obsolète de preuve de travail d'Ethereum, chaque bloc contenait : - une difficulté de bloc (par ex. : 3,324,092,183,262,715) ; -- un mixHash (par ex. : `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`) ; -- un nonce (par ex. : `0xd3ee432b4fb3d26b`). +- mixHash – par exemple : `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce – par exemple : `0xd3ee432b4fb3d26b` Ces données de bloc étaient directement liées à la preuve de travail. @@ -61,27 +61,27 @@ Pour créer de manière constante des blocs malveillants mais valides, un mineur La preuve de travail était également responsable de l'émission de nouvelles devises dans le système et encourageait les mineurs à y travailler. -Depuis [la mise à jour Constantinople](/ethereum-forks/#constantinople), les mineurs ayant réussi à créer un bloc étaient récompensés par deux ETH fraîchement minés et une partie des frais de transaction. Les blocs Ommer étaient également récompensés par 1,75 ETH. Les blocs Ommer étaient des blocs valides créés par un mineur pratiquement en même temps qu'un autre mineur créait le bloc canonique, qui était finalement déterminé par la chaîne construite en premier. Les blocs Ommer apparaissaient généralement en raison de la latence du réseau. +Depuis la [mise à niveau Constantinople](/ethereum-forks/#constantinople), les mineurs qui réussissaient à créer un bloc étaient récompensés par deux ETH fraîchement frappés et une partie des frais de transaction. Les blocs Ommer étaient également récompensés par 1,75 ETH. Les blocs Ommer étaient des blocs valides créés par un mineur pratiquement en même temps qu'un autre mineur créait le bloc canonique, qui était finalement déterminé par la chaîne construite en premier. Les blocs Ommer apparaissaient généralement en raison de la latence du réseau. -## Finalisation {#finality} +## Finalité {#finality} Une transaction était « finalisée » sur Ethereum lorsqu'elle faisait partie d'un bloc qui ne pouvait pas changer. Dans la mesure où les mineurs travaillaient de manière décentralisée, deux blocs valides pouvaient être minés en même temps. Cela créait une fourche temporaire. Finalement, l'une de ces chaînes devenait la chaîne acceptée après qu'un bloc suivant aura été miné et ajouté, ce qui la rendra plus longue. -Mais pour compliquer davantage les choses, les transactions rejetées sur la fourche temporaire pouvaient ne pas avoir été incluses dans la chaîne acceptée. Cela signifie qu'elle pourrait être inversée. La finalisation fait dont référence au temps que vous devez attendre avant de considérer une transaction comme irréversible. Dans le cadre de la précédente preuve de travail d'Ethereum, plus le nombre de blocs minés au-dessus d'un bloc spécifique `N` était élevé, plus la confiance dans les transactions de `N` était élevée et n'était pas inversée. Désormais, avec la preuve d'enjeu, la finalisation d'un bloc est une propriété explicite, plutôt que probabiliste. +Mais pour compliquer davantage les choses, les transactions rejetées sur la fourche temporaire pouvaient ne pas avoir été incluses dans la chaîne acceptée. Cela signifie qu'elle pourrait être inversée. La finalisation fait dont référence au temps que vous devez attendre avant de considérer une transaction comme irréversible. Avec l'ancienne preuve de travail d'Ethereum, plus on minait de blocs par-dessus un bloc `N` spécifique, plus on pouvait être sûr que les transactions dans `N` étaient réussies et ne seraient pas annulées. Désormais, avec la preuve d'enjeu, la finalisation d'un bloc est une propriété explicite, plutôt que probabiliste. -## Consommation d'énergie et preuve de travail {#energy} +## Preuve de travail et consommation d'énergie {#energy} -Une critique majeure de la preuve de travail est la quantité d'énergie nécessaire pour assurer la sécurité du réseau. Pour maintenir la sécurité et la décentralisation, Ethereum consommait de grandes quantités d'énergie avec la preuve de travail. Peu avant de passer à la preuve d'enjeu, les mineurs d'Ethereum consommaient collectivement environ 70 TWh/an (à peu près autant que la République tchèque - selon le [digiconomist](https://digiconomist.net/) le 18 juillet 2022). +Une critique majeure de la preuve de travail est la quantité d'énergie nécessaire pour assurer la sécurité du réseau. Pour maintenir la sécurité et la décentralisation, Ethereum consommait de grandes quantités d'énergie avec la preuve de travail. Peu avant de passer à la preuve d'enjeu, les mineurs d'Ethereum consommaient collectivement environ 70 TWh/an (à peu près autant que la République tchèque, selon [digiconomist](https://digiconomist.net/) le 18 juillet 2022). ## Avantages et inconvénients {#pros-and-cons} -| Avantages | Inconvénients | -| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| La preuve de travail est neutre. Vous n'avez pas besoin d'ETH pour commencer et les récompenses de bloc vous permettent de passer de 0 ETH à un solde positif. Avec la [preuve d'enjeu (PoS)](/developers/docs/consensus-mechanisms/pos/) vous avez besoin de posséder de l'ETH pour commencer. | La preuve de travail consomme tellement d'énergie que c'est mauvais pour l'environnement. | -| La preuve de travail est un mécanisme de consensus éprouvé qui a permis de sécuriser et de décentraliser les Bitcoins et Ethereum depuis de nombreuses années. | Si vous voulez miner, vous avez besoin de tels équipements spécialisés que l'investissement pour commencer est important. | -| Comparé à la preuve d'enjeu, elle est relativement facile à implémenter. | En raison des besoins de calcul croissants, les pools de minage pourraient potentiellement dominer le jeu, entraînant des risques de centralisation et de sécurité. | +| Avantages | Inconvénients | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| La preuve de travail est neutre. Vous n'avez pas besoin d'ETH pour commencer et les récompenses de bloc vous permettent de passer de 0 ETH à un solde positif. Avec la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/), vous avez besoin d'ETH pour commencer. | La preuve de travail consomme tellement d'énergie que c'est mauvais pour l'environnement. | +| La preuve de travail est un mécanisme de consensus éprouvé qui a permis de sécuriser et de décentraliser les Bitcoins et Ethereum depuis de nombreuses années. | Si vous voulez miner, vous avez besoin de tels équipements spécialisés que l'investissement pour commencer est important. | +| Comparé à la preuve d'enjeu, elle est relativement facile à implémenter. | En raison des besoins de calcul croissants, les pools de minage pourraient potentiellement dominer le jeu, entraînant des risques de centralisation et de sécurité. | ## Comparaison avec la preuve d'enjeu {#compared-to-pos} @@ -94,14 +94,14 @@ Une critique majeure de la preuve de travail est la quantité d'énergie nécess [En savoir plus sur la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) -## En savoir plus via un apprenti visuel ? {#visual-learner} +## Davantage qu'un apprenant visuel ? {#visual-learner} -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Attaque de la majorité](https://en.bitcoin.it/wiki/Majority_attack) -- [A propos de l'accord de finalisation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Attaque majoritaire](https://en.bitcoin.it/wiki/Majority_attack) +- [Sur la finalité du règlement](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) ### Vidéos {#videos} diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/index.md index 83748b6953d..3e0c123f7dc 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -1,6 +1,6 @@ --- -title: Minage -description: Une explication de la façon dont le minage fonctionnait sur Ethereum. +title: Le minage +description: "Une explication de la façon dont le minage fonctionnait sur Ethereum." lang: fr --- @@ -8,14 +8,14 @@ lang: fr -La preuve de travail n'est plus le mécanisme de consensus d'Ethereum, ce qui implique que le minage a été désactivé. À la place, Ethereum est sécurisé par les validateurs qui misent de l'ETH. Vous pouvez commencer à miser votre ETH aujourd'hui. En savoir plus sur La Fusion, la preuve d'enjeu et la mise en jeu. Cette page n'a qu'un intérêt historique. +La preuve de travail n'est plus le mécanisme de consensus d'Ethereum, ce qui implique que le minage a été désactivé. À la place, Ethereum est sécurisé par les validateurs qui misent de l'ETH. Vous pouvez commencer à miser votre ETH dès aujourd'hui. En savoir plus sur La Fusion, la preuve d'enjeu et la mise en jeu. Cette page n'a qu'un intérêt historique. ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, nous vous recommandons de commencer par lire celles concernant [les transactions](/developers/docs/transactions/), [les blocs](/developers/docs/blocks/) et [la preuve de travail](/developers/docs/consensus-mechanisms/pow/). +Pour mieux comprendre cette page, nous vous recommandons de vous informer au préalable sur les [transactions](/developers/docs/transactions/), les [blocs](/developers/docs/blocks/) et la [preuve de travail](/developers/docs/consensus-mechanisms/pow/). ## Qu'est-ce que le minage Ethereum ? {#what-is-ethereum-mining} @@ -44,30 +44,30 @@ Auparavant, n'importe qui pouvait miner sur le réseau Ethereum à l'aide de son Pour explorer davantage la rentabilité du minage, utilisez un calculateur de minage, tel que celui fourni par [Etherscan](https://etherscan.io/ether-mining-calculator). -## Comment les transactions Ethereum étaient-elles minées ? {#how-ethereum-transactions-were-mined} +## Comment les transactions Ethereum étaient minées {#how-ethereum-transactions-were-mined} -Ce qui suit donne un aperçu de la façon dont les transactions ont été exécutés dans la preuve de travail Ethereum. Une description analogue de ce processus pour la preuve d'enjeu Ethereum peut être trouvée [ici](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). +Ce qui suit donne un aperçu de la façon dont les transactions ont été exécutés dans la preuve de travail Ethereum. Vous trouverez une description analogue de ce processus pour la preuve d'enjeu d'Ethereum [ici](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). 1. Un utilisateur rédige et signe une demande de [transaction](/developers/docs/transactions/) avec la clé privée d'un [compte](/developers/docs/accounts/). -2. L'utilisateur diffuse la demande de transaction sur l'ensemble du réseau Ethereum à partir de certains [nœuds](/developers/docs/nodes-and-clients/). +2. L'utilisateur diffuse la demande de transaction à l'ensemble du réseau Ethereum à partir d'un [nœud](/developers/docs/nodes-and-clients/). 3. Dès qu'il a connaissance de la nouvelle demande de transaction, chaque nœud du réseau Ethereum l'ajoute à son « mempool », une zone d'attente de toutes les demandes de transaction dont il a connaissance et qui n'ont pas encore été engagées dans un bloc de la blockchain. -4. À un moment donné, un nœud de minage regroupe plusieurs dizaines ou centaines de demandes de transaction dans un [bloc](/developers/docs/blocks/) potentiel, de façon à maximiser les [frais de transaction](/developers/docs/gas/) gagnés, tout en restant sous la limite de gaz du bloc. Dès lors, le nœud de minage : - 1. Vérifie la validité de chaque demande de transaction (c'est-à-dire que personne n'essaie de transférer un ether depuis un compte pour lequel il n'a pas fourni de signature, que la demande n'est pas mal rédigée, etc.), puis exécute le code de la demande, modifiant l'état de sa copie locale de l'EVM, la machine virtuelle d'Ethereum. Le mineur attribue les frais de transaction pour chaque demande de transaction à son propre compte. +4. À un moment donné, un nœud de minage regroupe plusieurs dizaines ou centaines de demandes de transaction en un [bloc](/developers/docs/blocks/) potentiel, de manière à maximiser les [frais de transaction](/developers/docs/gas/) qu'il perçoit, tout en restant sous la limite de gaz du bloc. Dès lors, le nœud de minage : + 1. Vérifie la validité de chaque demande de transaction (c'est-à-dire que personne n'essaie de transférer de l'ether depuis un compte pour lequel il n'a pas produit de signature, que la demande n'est pas malformée, etc.), puis exécute le code de la demande, modifiant l'état de sa copie locale de l'EVM. Le mineur attribue les frais de transaction pour chaque demande de transaction à son propre compte. 2. Commence le processus de production du « certificat de légitimité de preuve de travail » pour le bloc potentiel, une fois que toutes les demandes de transaction du bloc ont été vérifiées et exécutées sur la copie locale de l'EVM. 5. Enfin, un mineur finira de produire un certificat pour un bloc qui inclut notre demande de transaction spécifique. Le mineur diffuse ensuite le bloc terminé qui comprend le certificat et la somme de contrôle du nouvel état de l'EVM. 6. D'autres nœuds prennent connaissance du nouveau bloc. Ils vérifient le certificat, exécutent eux-mêmes toutes les transactions sur le bloc (y compris celle initialement diffusée par notre utilisateur), et vérifient que la somme de contrôle du nouvel état de leur EVM après exécution de toutes les transactions correspond à la somme de contrôle de l'état revendiqué par le bloc du mineur. Ce n'est qu'à ce moment-là que ces nœuds ajoutent ce bloc à la queue de leur blockchain, et acceptent le nouvel état de l'EVM comme étant conforme. 7. Chaque nœud supprime toutes les transactions du nouveau bloc de son mempool local de demandes de transaction non satisfaites. 8. Les nouveaux nœuds qui rejoignent le réseau téléchargent tous les blocs en séquence, y compris le bloc contenant la transaction qui nous intéresse. Ils initialisent une copie locale de l'EVM (qui débute en tant qu'EVM vide), puis commencent l'exécution de chaque transaction dans chaque bloc en plus de leur copie locale de l'EVM, en vérifiant la somme de contrôle de l'état de chaque bloc dans le processus. -Chaque transaction est minée (incluse dans un nouveau bloc et propagée pour la première fois) une fois, mais exécutée et vérifiée par chaque participant au processus d'avancement vers l'état conforme de l'EVM. Cette approche met en avant l'une des principales devises de la blockchain : **Ne faites pas confiance, vérifiez**. +Chaque transaction est minée (incluse dans un nouveau bloc et propagée pour la première fois) une fois, mais exécutée et vérifiée par chaque participant au processus d'avancement vers l'état conforme de l'EVM. Cela met en évidence l'une des devises centrales de la blockchain : **Ne faites pas confiance, vérifiez**. -## Blocs ommer (oncle) {#ommer-blocks} +## Blocs Ommer (oncle) {#ommer-blocks} -Le minage du bloc reposant sur la preuve de travail (PoW) n'était alors que probabiliste, ce qui signifie que, parfois, il arrivait que deux blocs, ayant déjà été validés, soient en même temps exposés au public, notamment en raison de la latence du réseau. Dans ce cas, le protocole devait déterminer la chaîne la plus longue (et donc la plus « valide ») tout en assurant l'équité envers les mineurs en récompensant partiellement le bloc valide non inclus proposé. Cela a encouragé une plus grande décentralisation du réseau pour les mineurs plus petits, qui pourraient être confrontés à une plus grande latence, leur permettant de générer des rendements par le biais d'un bloc de récompenses [ommer](/glossary/#ommer) . +Le minage du bloc reposant sur la preuve de travail (PoW) n'était alors que probabiliste, ce qui signifie que, parfois, il arrivait que deux blocs, ayant déjà été validés, soient en même temps exposés au public, notamment en raison de la latence du réseau. Dans ce cas, le protocole devait déterminer la chaîne la plus longue (et donc la plus « valide ») tout en assurant l'équité envers les mineurs en récompensant partiellement le bloc valide non inclus proposé. Cela a encouragé une décentralisation accrue du réseau, car les mineurs plus modestes, qui pouvaient être confrontés à une latence plus importante, pouvaient tout de même générer des revenus via les récompenses de bloc [ommer](/glossary/#ommer). -On utilise de préférence le terme « ommer », plus neutre, pour désigner le frère ou la sœur d'un bloc parent, mais on parle aussi parfois d'« oncle ». **Depuis le passage d'Ethereum à la preuve d'enjeu, les blocs Ommer ne sont plus minés** puisque seulement un acteur de l'écosystème peut être élu dans chaque slot. Vous pouvez voir ce changement en visualisant le [graphique historique](https://ycharts.com/indicators/ethereum_uncle_rate) des blocs Ommer minés. +On utilise de préférence le terme « ommer », plus neutre, pour désigner le frère ou la sœur d'un bloc parent, mais on parle aussi parfois d'« oncle ». **Depuis le passage d'Ethereum à la preuve d'enjeu, les blocs ommer ne sont plus minés**, car un seul proposeur est élu à chaque créneau. Vous pouvez constater ce changement en consultant le [graphique historique](https://ycharts.com/indicators/ethereum_uncle_rate) des blocs ommer minés. -## Démonstration visuelle {#a-visual-demo} +## Une démo visuelle {#a-visual-demo} Regardez Austin vous guider à travers le minage et la blockchain de la preuve de travail. @@ -75,9 +75,9 @@ Regardez Austin vous guider à travers le minage et la blockchain de la preuve d ## L'algorithme de minage {#mining-algorithm} -Le réseau principal Ethereum n'a jamais utilisé qu'un seul algorithme de minage - ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash était le successeur d'un algorithme R&D originel connu sous le nom de [«Dagger-Hashimoto»](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). +Le réseau principal Ethereum n'a jamais utilisé qu'un seul algorithme de minage : ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash était le successeur d'un algorithme de R&D original connu sous le nom de ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). -[Plus de détails sur les algorithmes de minage](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). +[En savoir plus sur les algorithmes de minage](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). ## Sujets connexes {#related-topics} diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md index 5ca1eff5dec..50e60524ed8 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -1,29 +1,29 @@ --- title: Dagger-Hashimoto -description: Un regard détaillé sur l'algorithme Dagger-Hashimoto. +description: "Un regard détaillé sur l'algorithme Dagger-Hashimoto." lang: fr --- -Dagger-Hashimoto représentait l'implémentation et la spécification originales de recherche pour l'algorithme de minage d'Ethereum. Dagger-Hashimoto a été remplacé par [Ethash](#ethash). Le minage a été complètement arrêté avec [La Fusion](/roadmap/merge/) du 15 septembre 2022. Depuis lors, Ethereum a été sécurisé en utilisant à la place un mécanisme de [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos). Cette page a un intérêt historique - l'information fournie n'est plus pertinente depuis La Fusion Ethereum. +Dagger-Hashimoto représentait l'implémentation et la spécification originales de recherche pour l'algorithme de minage d'Ethereum. Dagger-Hashimoto a été remplacé par [Ethash](#ethash). Le minage a été complètement arrêté lors de [La Fusion](/roadmap/merge/) le 15 septembre 2022. Depuis lors, Ethereum est sécurisé par un mécanisme de [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos). Cette page a un intérêt historique - l'information fournie n'est plus pertinente depuis La Fusion Ethereum. ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, nous vous recommandons de lire d'abord le [consensus de preuve de travail](/developers/docs/consensus-mechanisms/pow), [le minage](/developers/docs/consensus-mechanisms/pow/mining), et [les algorithmes de minage](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). +Pour mieux comprendre cette page, nous vous recommandons de vous informer d'abord sur le [consensus de preuve de travail](/developers/docs/consensus-mechanisms/pow), le [minage](/developers/docs/consensus-mechanisms/pow/mining) et les [algorithmes de minage](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). ## Dagger-Hashimoto {#dagger-hashimoto} Dagger-Hashimoto vise à satisfaire deux objectifs : -1. **Résistance aux ASIC** : l'avantage de créer du matériel spécialisé pour l'algorithme devrait être aussi faible que possible -2. **Vérification possible par les clients allégés** : un bloc doit être vérifié efficacement par un client allégé. +1. **Résistance aux ASIC** : l'avantage de la création de matériel spécialisé pour l'algorithme doit être aussi minime que possible. +2. **Vérifiabilité par un client léger** : un bloc doit pouvoir être vérifié efficacement par un client léger. Avec une modification supplémentaire, et si cela vous intéresse, nous vous spécifierons également comment réaliser un troisième objectif mais au prix d'une complexité supplémentaire : -**Le stockage de chaîne complète** : le minage doit nécessiter un stockage de l'état de la blockchain complète (en raison de la structure irrégulière de la tentative d'état d'Ethereum, nous nous attendons à ce qu'un certain raccourcissement soit possible, en particulier pour certains contrats souvent utilisés tout en minimisant ceci). +**Stockage de la chaîne complète** : le minage doit nécessiter le stockage de l'état complet de la blockchain (en raison de la structure irrégulière du trie d'état d'Ethereum, nous prévoyons qu'un certain élagage sera possible, en particulier pour certains contrats souvent utilisés, mais nous voulons minimiser cela). -## Génération DAG {#dag-generation} +## Génération du DAG {#dag-generation} -Le code de l'algorithme sera défini ci-dessous en Python. Premièrement, nous donnons un `encode_int` pour le marquage des entiers non signés de précision spécifiés aux chaînes de caractères. L'inverse est également donné : +Le code de l'algorithme sera défini ci-dessous en Python. Tout d'abord, nous donnons `encode_int` pour la sérialisation d'entiers non signés de précision spécifiée en chaînes de caractères. L'inverse est également donné : ```python NUM_BITS = 512 @@ -45,7 +45,7 @@ def decode_int(s): return x ``` -Nous supposons maintenant que `sha3` est une fonction qui prend un entier et donne un entier, et `dbl_sha3` est une fonction double-sha3 ; si vous convertissez ce code de référence dans une utilisation d'implémentation : +Nous supposons ensuite que `sha3` est une fonction qui prend un entier et renvoie un entier, et que `dbl_sha3` est une fonction double-sha3 ; si vous convertissez ce code de référence en une implémentation, utilisez : ```python from pyethereum import utils @@ -82,9 +82,9 @@ params = { } ``` -Dans ce cas `P` est une prime choisie telle que `log₂(P)` soit juste un peu en deçà de 512, qui correspond aux 512 bits que nous utilisons pour représenter nos nombres. Notez que seule la dernière moitié du DAG doit être stockée, ainsi le besoin de mémoire commence de fait à 1 Go et augmente de 441 Mo par an. +`P` dans ce cas est un nombre premier choisi de telle sorte que `log₂(P)` soit juste légèrement inférieur à 512, ce qui correspond aux 512 bits que nous avons utilisés pour représenter nos nombres. Notez que seule la dernière moitié du DAG doit être stockée, ainsi le besoin de mémoire commence de fait à 1 Go et augmente de 441 Mo par an. -### Construction graphique Dagger {#dagger-graph-building} +### Construction du graphe Dagger {#dagger-graph-building} La construction graphique Dagger primitive est définie comme suit : @@ -101,11 +101,11 @@ def produce_dag(params, seed, length): return o ``` -Essentiellement, cela commence par un graphique en tant que nœud unique, `sha3(seed)`, puis, à partir de ce stade, comment l'ajout séquentiel sur d'autres nœuds basés sur des nœuds précédents aléatoires. Lorsqu'un nouveau nœud est créé, la puissance modulaire de la graine est calculée pour sélectionner aléatoirement des indices inférieurs à `i` (en utilisant `x % i` ci-dessus), et les valeurs des noeuds au regard de ces indices sont utilisées dans un calcul pour générer une nouvelle valeur pour `x`, qui est ensuite alimentée par une fonction de preuve de travail sommaire (basée sur XOR) pour finalement générer la valeur du graphique à l'indice `i`. La raison d'être de cette conception particulière est de forcer l'accès séquentiel du DAG ; la valeur suivante du DAG qui sera accessible ne peut pas être déterminée tant que la valeur courante n'est pas connue. Enfin, l’exponentiation modulaire permet de hacher le résultat. +Essentiellement, il initialise un graphe comme un nœud unique, `sha3(seed)`, et à partir de là, commence à ajouter séquentiellement d'autres nœuds en se basant sur des nœuds précédents aléatoires. Lorsqu'un nouveau nœud est créé, une puissance modulaire de la graine est calculée pour sélectionner de manière aléatoire certains indices inférieurs à `i` (en utilisant `x % i` ci-dessus), et les valeurs des nœuds à ces indices sont utilisées dans un calcul pour générer une nouvelle valeur pour `x`, qui est ensuite transmise à une petite fonction de preuve de travail (basée sur XOR) pour finalement générer la valeur du graphe à l'indice `i`. La raison d'être de cette conception particulière est de forcer l'accès séquentiel du DAG ; la valeur suivante du DAG qui sera accessible ne peut pas être déterminée tant que la valeur courante n'est pas connue. Enfin, l’exponentiation modulaire permet de hacher le résultat. Cet algorithme repose sur plusieurs résultats de la théorie des nombres. Consultez l'annexe ci-dessous à des fins de discussion. -## Évaluation du client allégé {#light-client-evaluation} +## Évaluation par le client léger {#light-client-evaluation} La construction du graphique ci-dessus vise à permettre à chaque nœud du graphique d'être reconstruit en calculant une sous-arborescence d'un petit nombre de nœuds et en ne nécessitant qu'une petite quantité de mémoire auxiliaire. Notez qu'avec k=1, la sous-arborescence n'est qu'une chaîne de valeurs allant jusqu'au premier élément du DAG. @@ -131,11 +131,11 @@ def quick_calc(params, seed, p): return quick_calc_cached(p) ``` -Il s'agit essentiellement d'une réécriture de l'algorithme ci-dessus qui supprime la boucle de calcul des valeurs pour l'ensemble du DAG et remplace la précédente recherche du nœud par un appel récursif ou une recherche de cache. Notez que pour `k=1` le cache n'est pas nécessaire, bien qu'une optimisation supplémentaire calcule au préalable en fait les premiers milliers de valeurs du DAG et conserve cela en tant que cache statique pour les calculs ; voir l'annexe pour une implémentation de code de cette fonction. +Il s'agit essentiellement d'une réécriture de l'algorithme ci-dessus qui supprime la boucle de calcul des valeurs pour l'ensemble du DAG et remplace la précédente recherche du nœud par un appel récursif ou une recherche de cache. Notez que pour `k=1`, le cache est inutile, bien qu'une optimisation supplémentaire précalcule les quelques milliers de premières valeurs du DAG et les conserve comme un cache statique pour les calculs ; voir l'annexe pour une implémentation de code de ceci. ## Double tampon de DAG {#double-buffer} -Dans un client complet, un [_double tampon_](https://wikipedia.org/wiki/Multiple_buffering) de 2 DAG produit par la formule ci-dessus est utilisé. L'idée est que les DAG produisent tous les nombres de blocs `epochtime` selon les paramètres ci-dessus. Au lieu d'utiliser le dernier DAG produit, le client utilise le précédent. L'avantage est qu'il permet aux DAG d'être remplacés au fil du temps sans avoir besoin d'incorporer une étape où les mineurs devraient soudainement recalculer toutes les données. Sinon, il existe un risque de ralentissement brutal et temporaire du traitement en chaîne à intervalles réguliers et d'augmentation spectaculaire de la centralisation. Ainsi, il existe un risque d'attaques de 51% au cours de ces quelques minutes avant que toutes les données ne soient recalculées. +Dans un client complet, un [_double tampon_](https://wikipedia.org/wiki/Multiple_buffering) de 2 DAG produits par la formule ci-dessus est utilisé. L'idée est que les DAG sont produits tous les `epochtime` blocs, conformément aux paramètres ci-dessus. Au lieu d'utiliser le dernier DAG produit, le client utilise le précédent. L'avantage est qu'il permet aux DAG d'être remplacés au fil du temps sans avoir besoin d'incorporer une étape où les mineurs devraient soudainement recalculer toutes les données. Sinon, il existe un risque de ralentissement brutal et temporaire du traitement en chaîne à intervalles réguliers et d'augmentation spectaculaire de la centralisation. Ainsi, il existe un risque d'attaques de 51% au cours de ces quelques minutes avant que toutes les données ne soient recalculées. L'algorithme utilisé pour générer l'ensemble des DAG utilisés pour calculer le travail d'un bloc est le suivant : @@ -164,7 +164,7 @@ def get_daggerset(params, block): dagsz = get_dagsize(params, block) seedset = get_seedset(params, block) if seedset["front_hash"] <= 0: - # No back buffer is possible, just make front buffer + # Aucun tampon arrière n'est possible, il suffit de créer un tampon avant return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), "block_number": 0}} else: @@ -254,56 +254,52 @@ Notez également que Dagger-Hashimoto impose des exigences supplémentaires à l - Pour que la vérification de deux couches fonctionne, un en-tête de bloc doit avoir à la fois la valeur nonce et la valeur moyenne pré-sha3 - Quelque part, un en-tête de bloc doit stocker la sha3 de l'actuel ensemble de données -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} _Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !_ ## Annexe {#appendix} -Comme mentionné ci-dessus, le RNG utilisé pour la génération de DAG repose sur des résultats tirés de la théorie des nombres. Premièrement, nous fournissons l'assurance que le RNG Lehmer qui est la base de la variable `picker` dispose d'une période longue. Deuxièmement, nous montrons que `pow(x,3,P)` ne fera pas correspondre `x` à `1` ou `P-1` fourni `x ∈ [2,P-2]` pour commencer. Enfin, nous montrons que `pow(x,3,P)` a un faible taux de collision lorsqu'il est traité comme une fonction de hachage. +Comme mentionné ci-dessus, le RNG utilisé pour la génération de DAG repose sur des résultats tirés de la théorie des nombres. Premièrement, nous donnons l'assurance que le générateur de nombres aléatoires (RNG) de Lehmer, qui est à la base de la variable `picker`, a une longue période. Deuxièmement, nous montrons que `pow(x,3,P)` ne fera pas correspondre `x` à `1` ou `P-1`, à condition que `x ∈ [2,P-2]` au départ. Enfin, nous montrons que `pow(x,3,P)` a un faible taux de collision lorsqu'il est traité comme une fonction de hachage. -### Générateur de nombre aléatoire Lehmer {#lehmer-random-number} +### Générateur de nombres aléatoires de Lehmer {#lehmer-random-number} -Alors que la fonction `produce_dag` n'a pas besoin de produire des nombres aléatoires impartiaux, une menace potentielle est que `seed**i % P` prenne uniquement une poignée de valeurs. Cela pourrait être un avantage pour les mineurs qui reconnaissent le modèle par rapport à ceux qui ne le font pas. +Bien que la fonction `produce_dag` n'ait pas besoin de produire des nombres aléatoires non biaisés, une menace potentielle est que `seed**i % P` ne prenne qu'une poignée de valeurs. Cela pourrait être un avantage pour les mineurs qui reconnaissent le modèle par rapport à ceux qui ne le font pas. -Pour éviter cela, un résultat de la théorie du nombre est exercé. Un [_Safe Prime_](https://en.wikipedia.org/wiki/Safe_prime) est défini comme un premier `P` tel que `(P-1)/2` est également un nombre premier. L'_ordre_ d'un membre `x` du [groupe multiplicateur](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` est défini pour être le minimum `m` tel que 
xᵐ mod P ≡ 1
-Compte tenu de ces définitions, nous avons : +Pour éviter cela, un résultat de la théorie du nombre est exercé. Un [_nombre premier sûr_](https://en.wikipedia.org/wiki/Safe_prime) est défini comme un nombre premier `P` tel que `(P-1)/2` est aussi un nombre premier. L'_ordre_ d'un membre `x` du [groupe multiplicatif](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` est défini comme le `m` minimal tel que 
xᵐ mod P ≡ 1
+Compte tenu de ces définitions, nous avons : -> Observation 1. Laisser `x` être un membre du groupe multiplicateur `ℤ/Pℤ` pour un nombre premier sûr `P`. Si `x mod P ≠ 1 mod P` et `x mod P ≠ P-1 mod P`, alors l'ordre de `x` est soit `P-1` soit `(P-1)/2`. +> Observation 1. Soit `x` un membre du groupe multiplicatif `ℤ/Pℤ` pour un nombre premier sûr `P`. Si `x mod P ≠ 1 mod P` et `x mod P ≠ P-1 mod P`, alors l'ordre de `x` est soit `P-1` soit `(P-1)/2`. -_Preuve_. Puisque `P` est un nombre premier sécurisé, puis par \[Lagrange's Theorem\]\[lagrange\] nous trouvons que l'ordre de `x` est soit `1`, `2`, `(P-1)/2`, soit `P-1`. +_Preuve_. Puisque `P` est un nombre premier sûr, alors d'après le [théorème de Lagrange][lagrange], nous avons que l'ordre de `x` est soit `1`, `2`, `(P-1)/2`, ou `P-1`. -L'ordre de `x` ne peut pas être `1`, puisque suivant le petit théorème de Fermat, nous avons : +L'ordre de `x` ne peut pas être `1`, car d'après le petit théorème de Fermat, nous avons : 
xP-1 mod P ≡ 1
-C'est pourquoi `x` doit être une identité multiplicative de `ℤ/nℤ`, ce qui est unique. Puisque nous supposons que `x ≠ 1` par hypothèse, ce n'est pas possible. +Par conséquent, `x` doit être une identité multiplicative de `ℤ/nℤ`, qui est unique. Puisque nous avons supposé que `x ≠ 1`, ceci n'est pas possible. -L'ordre de `x` ne peut pas être `2` sauf si `x = P-1`, car cela violerait le principe que `P` soit un nombre premier. +L'ordre de `x` ne peut pas être `2` à moins que `x = P-1`, car cela violerait le fait que `P` est un nombre premier. -À partir de la proposition ci-dessus, nous pouvons reconnaître que l'itération `(picker * init) % P` aura une longueur de cycle d'au moins `(P-1)/2`. Ceci est dû au fait que nous avons sélectionné `P` pour être un nombre premier sûr approximativement égal à une puissance supérieure de deux, et `init` est dans l'intervalle `[2,2**256+1]`. Compte tenu de la magnitude de `P`, nous ne devrions jamais nous attendre à un cycle d'exponentiation modulaire. +D'après la proposition ci-dessus, nous pouvons reconnaître que l'itération de `(picker * init) % P` aura une longueur de cycle d'au moins `(P-1)/2`. C'est parce que nous avons sélectionné `P` pour être un nombre premier sûr approximativement égal à une puissance supérieure de deux, et `init` se trouve dans l'intervalle `[2,2**256+1]`. Étant donné la magnitude de `P`, nous ne devrions jamais nous attendre à un cycle provenant de l'exponentiation modulaire. -Lorsque nous assignons la première cellule dans le DAG (la variable étiquetée `init`), nous calculons `pow(sha3(seed) + 2, 3, P)`. À première vue, cela ne garantit pas que le résultat n'est ni `1` ni `P-1`. Cependant, puisque `P-1` est un nombre premier sûr, nous émettons l'hypothèse supplémentaire suivante, qui est un corollaire de l'observation 1 : +Lorsque nous attribuons la première cellule dans le DAG (la variable étiquetée `init`), nous calculons `pow(sha3(seed) + 2, 3, P)`. À première vue, cela ne garantit pas que le résultat n'est ni `1` ni `P-1`. Cependant, puisque `P-1` est un nombre premier sûr, nous avons l'assurance supplémentaire suivante, qui est un corollaire de l'Observation 1 : -> Observation 2. Laissons `x` être membre du groupe multiplicateur `ℤ/Pℤ` pour un nombre premier sûr `P`, et laissons `w` être un nombre naturel. Si `x mod P ≠ 1 mod P` et `x mod P ≠ P-1 mod P`, tout comme `w mod P ≠ P-1 mod P` et `w mod P ≠ 0 mod P`, alors `xʷ mod P ≠ 1 mod P` et `xʷ mod P ≠ P-1 mod P` +> Observation 2. Soit `x` un membre du groupe multiplicatif `ℤ/Pℤ` pour un nombre premier sûr `P`, et soit `w` un nombre naturel. Si `x mod P ≠ 1 mod P` et `x mod P ≠ P-1 mod P`, ainsi que `w mod P ≠ P-1 mod P` et `w mod P ≠ 0 mod P`, alors `xʷ mod P ≠ 1 mod P` et `xʷ mod P ≠ P-1 mod P` -### Exponentiation modulaire comme fonction de hachage {#modular-exponentiation} +### Exponentiation modulaire en tant que fonction de hachage {#modular-exponentiation} -Pour certaines valeurs de `P` et `w`, la fonction `pow(x, w, P)` peut présenter de nombreuses collisions. Par exemple, `pow(x,9,19)` ne prend que les valeurs `{1,18}`. +Pour certaines valeurs de `P` et `w`, la fonction `pow(x, w, P)` peut avoir de nombreuses collisions. Par exemple, `pow(x,9,19)` ne prend que les valeurs `{1,18}`. -Étant donné que `P` est un nombre premier, alors un `w` approprié pour une fonction de hachage d'exponentiation modulaire peut être choisi en utilisant le résultat suivant : +Étant donné que `P` est un nombre premier, un `w` approprié pour une fonction de hachage par exponentiation modulaire peut être choisi en utilisant le résultat suivant : -> Observation 3. Laissez `P` être un nombre premier ; `w` et `P-1` sont relativement premiers si et seulement si pour tous les `a` et `b` en `ℤ/Pℤ` : -> ->
-> `aʷ mod P ≡ bʷ mod P` si et seulement si `a mod P ≡ b mod P` ->
+> Observation 3. Soit `P` un nombre premier ; `w` et `P-1` sont premiers entre eux si et seulement si pour tous les `a` et `b` dans `ℤ/Pℤ` :
`aʷ mod P ≡ bʷ mod P` si et seulement si `a mod P ≡ b mod P`
-Ainsi, étant donné que `P` est un nombre premier et que `w` est relativement premier à `P-1`, nous avons `|{pow(x, w, P) : x ∈ ℤ}| = P`, ce qui implique que la fonction de hachage a le taux de collision minimal possible. +Ainsi, étant donné que `P` est un nombre premier et que `w` est premier avec `P-1`, nous avons `|{pow(x, w, P) : x ∈ ℤ}| = P`, ce qui implique que la fonction de hachage a le taux de collision le plus bas possible. -Dans le cas spécial ou `P` est un nombre premier sûr comme nous l'avons sélectionné, alors `P-1` n'aura que les facteurs 1, 2, `(P-1)/2` et `P-1`. Puisque `P` > 7, nous savons que 3 est relativement premier à `P-1`, donc `w=3` satisfait la proposition ci-dessus. +Dans le cas particulier où `P` est un nombre premier sûr comme nous l'avons sélectionné, `P-1` n'a alors que les facteurs 1, 2, `(P-1)/2` et `P-1`. Puisque `P` > 7, nous savons que 3 est premier avec `P-1`, donc `w=3` satisfait la proposition ci-dessus. -## Algorithme d'évaluation basé sur un cache plus efficace {#cache-based-evaluation} +## Algorithme d'évaluation plus efficace basé sur le cache {#cache-based-evaluation} ```python def quick_calc(params, seed, p): diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index 28ee02d5b6d..24711c66dd0 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -1,6 +1,6 @@ --- title: Ethash -description: Un aperçu en détail de l'algorithme Ethash. +description: "Un aperçu en détail de l'algorithme Ethash." lang: fr --- @@ -8,12 +8,12 @@ lang: fr - Ethash était l'algorithme de minage par preuve de travail d'Ethereum. La preuve de travail est maintenant **arrêtée entièrement** et Ethereum est maintenant sécurisé en utilisant [la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) à la place. En savoir plus sur [La Fusion](/roadmap/merge/), [la preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/) et la [mise en jeu](/staking/). Cette page n'a qu'un intérêt historique ! + Ethash était l'algorithme de minage par preuve de travail d'Ethereum. La preuve de travail a maintenant été **entièrement désactivée** et Ethereum est désormais sécurisé par la [preuve d'enjeu](/developers/docs/consensus-mechanisms/pos/). En savoir plus sur [The Merge](/roadmap/merge/), [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) et [staking](/staking/). Cette page n'a qu'un intérêt historique ! -Ethash est une version modifiée de l'algorithme [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). La preuve de travail d'Ethash est une [mémoire solide](https://wikipedia.org/wiki/Memory-hard_function), qui était censée rendre l'algorithme ASIC plus résistant. Les Ethash ASIC ont finalement été développés, mais le minage via GPU restait encore une option viable jusqu’à ce que la preuve de travail soit désactivée. Ethash est toujours utilisé pour miner d'autres jetons sur des réseaux autres qu'Ethereum fonctionnant avec la preuve de travail. +Ethash est une version modifiée de l'algorithme [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). La preuve de travail Ethash est [à mémoire difficile](https://wikipedia.org/wiki/Memory-hard_function), ce qui était censé rendre l'algorithme résistant aux ASIC. Les Ethash ASIC ont finalement été développés, mais le minage via GPU restait encore une option viable jusqu’à ce que la preuve de travail soit désactivée. Ethash est toujours utilisé pour miner d'autres jetons sur des réseaux autres qu'Ethereum fonctionnant avec la preuve de travail. ## Comment fonctionne Ethash ? {#how-does-ethash-work} @@ -22,8 +22,8 @@ La complexité de la mémoire est obtenue avec un algorithme de preuve de travai Le parcours habituel de l'algorithme est le suivant : 1. Il existe une **graine** qui peut être calculée pour chaque bloc en scannant les en-têtes de bloc jusqu'à ce point. -2. À partir de la graine, on peut calculer un **cache pseudoaléatoire de 16 Mo**. Les clients légers stockent le cache. -3. À partir du cache, nous pouvons générer un **jeu de données 1 Go**, avec la propriété que chaque élément du jeu de données ne dépend que d'un petit nombre d'éléments du cache. Les clients et les mineurs au complet stockent le jeu de données. Le jeu de données croît linéairement avec le temps. +2. À partir de la graine, on peut calculer un **cache pseudo-aléatoire de 16 Mo**. Les clients légers stockent le cache. +3. À partir du cache, nous pouvons générer un **jeu de données de 1 Go**, avec la propriété que chaque élément du jeu de données ne dépend que d'un petit nombre d'éléments du cache. Les clients et les mineurs au complet stockent le jeu de données. Le jeu de données croît linéairement avec le temps. 4. Le minage consiste à saisir des tranches aléatoires de l'ensemble des données et à les hacher ensemble. La vérification peut être faite avec peu de mémoire en utilisant le cache pour régénérer les morceaux spécifiques du jeu de données dont vous avez besoin, ainsi, vous avez uniquement besoin de stocker le cache. Le grand ensemble de données est mis à jour une fois tous les 30 000 blocs, de sorte que la grande majorité des efforts d'un mineur sera de lire l'ensemble des données, et non d'y apporter des modifications. @@ -33,23 +33,23 @@ Le grand ensemble de données est mis à jour une fois tous les 30 000 blocs, de Nous utilisons les définitions suivantes : ``` -WORD_BYTES = 4 # bytes in word -DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis -DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch -CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis -CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch -CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache -EPOCH_LENGTH = 30000 # blocks per epoch -MIX_BYTES = 128 # width of mix -HASH_BYTES = 64 # hash length in bytes -DATASET_PARENTS = 256 # number of parents of each dataset element -CACHE_ROUNDS = 3 # number of rounds in cache production -ACCESSES = 64 # number of accesses in hashimoto loop +WORD_BYTES = 4 # octets dans un mot +DATASET_BYTES_INIT = 2**30 # octets dans le jeu de données à la genèse +DATASET_BYTES_GROWTH = 2**23 # croissance du jeu de données par époque +CACHE_BYTES_INIT = 2**24 # octets dans le cache à la genèse +CACHE_BYTES_GROWTH = 2**17 # croissance du cache par époque +CACHE_MULTIPLIER=1024 # Taille du DAG par rapport au cache +EPOCH_LENGTH = 30000 # blocs par époque +MIX_BYTES = 128 # largeur du mix +HASH_BYTES = 64 # longueur du hachage en octets +DATASET_PARENTS = 256 # nombre de parents de chaque élément du jeu de données +CACHE_ROUNDS = 3 # nombre de tours dans la production du cache +ACCESSES = 64 # nombre d'accès dans la boucle hashimoto ``` ### L'utilisation de 'SHA3' {#sha3} -Le développement d'Ethereum a coïncidé avec le développement de la norme SHA3, et le processus de normes a réalisé un changement tardif dans le remplissage de l'algorithme de hachage finalisé de sorte que les hachages Ethereum "sha3_256" et "sha3_512" ne soient pas des hashs sha3 standard, mais une variante appelée souvent « Keccak-256 » et « Keccak-512 » dans d'autres contextes. Voir la discussion, par exemple [ici](https://eips.ethereum.org/EIPS/eip-1803), [ici](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), ou [ici](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). +Le développement d'Ethereum a coïncidé avec le développement de la norme SHA3, et le processus de normes a réalisé un changement tardif dans le remplissage de l'algorithme de hachage finalisé de sorte que les hachages Ethereum "sha3_256" et "sha3_512" ne soient pas des hashs sha3 standard, mais une variante appelée souvent « Keccak-256 » et « Keccak-512 » dans d'autres contextes. Voir la discussion, par exemple, [ici](https://eips.ethereum.org/EIPS/eip-1803), [ici](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), ou [ici](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). Veuillez garder cela à l'esprit, car les hachages « sha3 » sont mentionnés dans la description de l'algorithme ci-dessous. @@ -75,7 +75,7 @@ def get_full_size(block_number): Les tables de jeu de données et les valeurs de taille de cache sont fournies dans l'annexe. -## Génération de cache {#cache-generation} +## Génération du cache {#cache-generation} Maintenant, nous spécifions la fonction pour produire un cache : @@ -97,11 +97,11 @@ def mkcache(cache_size, seed): return o ``` -Le processus de production du cache implique d'abord le remplissage séquentiel de 32 Mo de mémoire, effectuant alors deux passes de l'algorithme _RandMemoHash_ de Sergio Demian Lerner à partir de [_Strict Memory Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). La sortie est un ensemble de valeurs de 524288 de 64 octets. +Le processus de production du cache implique d'abord de remplir séquentiellement 32 Mo de mémoire, puis d'effectuer deux passes de l'algorithme _RandMemoHash_ de Sergio Demian Lerner, tiré de [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). La sortie est un ensemble de valeurs de 524288 de 64 octets. ## Fonction d'agrégation de données {#date-aggregation-function} -Nous utilisons un algorithme inspiré du [hachage FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) dans certains cas comme un substitut non associatif pour XOR. Notez que nous multiplions le premier par l'entrée 32 bits, contrairement à la spécification FNV-1 qui multiplie le premier avec un octet à son tour. +Nous utilisons un algorithme inspiré du [hachage FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) dans certains cas comme substitut non associatif pour XOR. Notez que nous multiplions le premier par l'entrée 32 bits, contrairement à la spécification FNV-1 qui multiplie le premier avec un octet à son tour. ```python FNV_PRIME = 0x01000193 @@ -140,27 +140,27 @@ def calc_dataset(full_size, cache): ## Boucle principale {#main-loop} -Maintenant, nous spécifions la boucle principale « hashimoto », où nous agrégeons les données du jeu de données complet, afin de produire notre valeur finale pour un en-tête et un nonce. Dans le code ci-dessous, `header` représente le _hachage_ SHA3-256 de la représentation RLP d'un en-tête de bloc _tronqué_, qui est d'un en-tête excluant les champs **mixHash** et **nonce**. `nonce` constitue les huit octets d'un entier 64 bits non signé dans un ordre big-endian. Ainsi `nonce[::-1]` est la représentation de huit octets little-endian de cette valeur : +Maintenant, nous spécifions la boucle principale « hashimoto », où nous agrégeons les données du jeu de données complet, afin de produire notre valeur finale pour un en-tête et un nonce. Dans le code ci-dessous, `header` représente le _hachage_ SHA3-256 de la représentation RLP d'un en-tête de bloc _tronqué_, c'est-à-dire d'un en-tête excluant les champs **mixHash** et **nonce**. `nonce` représente les huit octets d'un entier non signé de 64 bits dans l'ordre big-endian. Ainsi, `nonce[::-1]` est la représentation little-endian sur huit octets de cette valeur : ```python def hashimoto(header, nonce, full_size, dataset_lookup): n = full_size / HASH_BYTES w = MIX_BYTES // WORD_BYTES mixhashes = MIX_BYTES / HASH_BYTES - # combine header+nonce into a 64 byte seed + # combine l'en-tête et le nonce en une graine de 64 octets s = sha3_512(header + nonce[::-1]) - # start the mix with replicated s + # initialise le mix avec s répliqué mix = [] for _ in range(MIX_BYTES / HASH_BYTES): mix.extend(s) - # mix in random dataset nodes + # mélange avec des nœuds aléatoires du jeu de données for i in range(ACCESSES): p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes newdata = [] for j in range(MIX_BYTES / HASH_BYTES): newdata.extend(dataset_lookup(p + j)) mix = map(fnv, mix, newdata) - # compress mix + # compresse le mix cmix = [] for i in range(0, len(mix), 4): cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) @@ -176,9 +176,9 @@ def hashimoto_full(full_size, dataset, header, nonce): return hashimoto(header, nonce, full_size, lambda x: dataset[x]) ``` -Essentiellement, nous maintenons un « mix » de 128 octets de taille, et récupérons séquentiellement 128 octets du jeu de données complet et utilisons la fonction `fnv` à des fins de combinaison avec le mix. 128 octets d'accès séquentiel sont utilisés de sorte que chaque tour de l'algorithme récupère toujours une page complète de la RAM. Minimiser le tampon de lecture de la traduction loupe ce que l'ASIC serait théoriquement en mesure d'éviter. +Essentiellement, nous maintenons un "mix" de 128 octets de large, et récupérons de manière répétée et séquentielle 128 octets du jeu de données complet pour les combiner avec le mix à l'aide de la fonction `fnv`. 128 octets d'accès séquentiel sont utilisés de sorte que chaque tour de l'algorithme récupère toujours une page complète de la RAM. Minimiser le tampon de lecture de la traduction loupe ce que l'ASIC serait théoriquement en mesure d'éviter. -Si la sortie de cet algorithme est en dessous de la cible souhaitée, alors le nonce est valide. Notez que l'application supplémentaire de `sha3_256` à la fin garantit qu'il existe un nonce intermédiaire qui peut être fourni pour prouver qu'au moins une petite quantité de travail a été faite ; cette vérification externe rapide de PoW peut être utilisée à des fins anti-DDoS. Cela sert également à fournir une assurance statistique que le résultat est un nombre non biaisé de 256 bits. +Si la sortie de cet algorithme est en dessous de la cible souhaitée, alors le nonce est valide. Notez que l'application supplémentaire de `sha3_256` à la fin garantit qu'il existe un nonce intermédiaire qui peut être fourni pour prouver qu'au moins une petite quantité de travail a été effectuée ; cette vérification PoW externe rapide peut être utilisée à des fins d'anti-DDoS. Cela sert également à fournir une assurance statistique que le résultat est un nombre non biaisé de 256 bits. ## Minage {#mining} @@ -186,7 +186,7 @@ L'algorithme de minage est défini comme suit : ```python def mine(full_size, dataset, header, difficulty): - # zero-pad target to compare with hash on the same digit + # remplissage par des zéros de la cible pour la comparer au hachage sur le même chiffre target = zpad(encode_int(2**256 // difficulty), 64)[::-1] from random import randint nonce = randint(0, 2**64) @@ -209,7 +209,7 @@ Afin de calculer le hachage de la graine qui serait utilisé pour miner au-dessu Notez que pour un minage et une vérification en douceur, nous recommandons de calculer au préalable les futures semences et les jeux de données dans un fil séparé. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} _Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !_ @@ -220,7 +220,7 @@ Le code suivant devrait être préfixé si vous souhaitez exécuter la spécific ```python import sha3, copy -# Assumes little endian bit ordering (same as Intel architectures) +# Suppose un ordre des bits little-endian (identique aux architectures Intel) def decode_int(s): return int(s[::-1].encode('hex'), 16) if s else 0 @@ -248,7 +248,7 @@ def serialize_cache(ds): serialize_dataset = serialize_cache -# sha3 hash function, outputs 64 bytes +# fonction de hachage sha3, génère 64 octets en sortie def sha3_512(x): return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) diff --git a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index b6c616b3d17..1527d22792b 100644 --- a/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md +++ b/public/content/translations/fr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -1,6 +1,6 @@ --- title: Algorithmes de minage -description: Un regard détaillé sur les algorithmes utilisés pour le minage Ethereum. +description: "Un regard détaillé sur les algorithmes utilisés pour le minage Ethereum." lang: fr --- @@ -8,7 +8,7 @@ lang: fr -La preuve de travail n'est plus le mécanisme de consensus d'Ethereum, ce qui signifie que le minage a été arrêté. En lieu et place, Ethereum est sécurisé par les validateurs qui misent de l'ETH. Vous pouvez commencer à miser votre ETH dès aujourd'hui. En savoir plus sur La Fusion, la preuve d'enjeu et la mise en jeu. Cette page n'a qu'un intérêt historique. +La preuve de travail n'est plus le mécanisme de consensus d'Ethereum, ce qui implique que le minage a été désactivé. À la place, Ethereum est sécurisé par les validateurs qui misent de l'ETH. Vous pouvez commencer à miser votre ETH dès aujourd'hui. En savoir plus sur La Fusion, la preuve d'enjeu et la mise en jeu. Cette page n'a qu'un intérêt historique. @@ -17,26 +17,26 @@ Le minage Ethereum utilisait un algorithme connu sous le nom d'Ethash. L'idée f ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, nous vous recommandons de lire d'abord le [consensus de preuve de travail](/developers/docs/consensus-mechanisms/pow) et le [minage](/developers/docs/consensus-mechanisms/pow/mining). +Pour mieux comprendre cette page, nous vous recommandons de vous informer d'abord sur le [consensus de preuve de travail](/developers/docs/consensus-mechanisms/pow) et le [minage](/developers/docs/consensus-mechanisms/pow/mining). ## Dagger Hashimoto {#dagger-hashimoto} Dagger Hashimoto était un algorithme de recherche précurseur pour le minage Ethereum qu'Ethash a remplacé. Il s'agissait de la fusion de deux algorithmes différents : Dagger et Hashimoto. Il ne s'agissait que d'une implémentation de recherche et a été remplacé par Ethash au moment du lancement du réseau principal Ethereum. -[Dagger](http://www.hashcash.org/papers/dagger.html) implique la génération d'un [Graphe orienté acyclique (DAG en anglais)](https://en.wikipedia.org/wiki/Directed_acyclic_graph), dont des tranches aléatoires sont hachées ensemble. Le principe fondamental est que chaque nonce ne nécessite qu'une petite partie d'un grand arbre de données. Recalculer le sous-arbre pour chaque nonce est prohibitif pour le minage – d’où la nécessité de stocker l’arbre – mais correct pour un unique once de vérification. Dagger a été conçu pour être une alternative aux algorithmes existants comme Scrypt, qui sont difficiles à vérifier lorsque la difficulté de mémoire augmente à des niveaux réellement sécurisés. Cependant, Dagger était vulnérable à une accélération matérielle de la mémoire partagée et a été abandonné en faveur d'autres pistes de recherche. +[Dagger](http://www.hashcash.org/papers/dagger.html) implique la génération d'un [graphe orienté acyclique](https://en.wikipedia.org/wiki/Directed_acyclic_graph), dont des tranches aléatoires sont hachées ensemble. Le principe fondamental est que chaque nonce ne nécessite qu'une petite partie d'un grand arbre de données. Recalculer le sous-arbre pour chaque nonce est prohibitif pour le minage – d’où la nécessité de stocker l’arbre – mais correct pour un unique once de vérification. Dagger a été conçu pour être une alternative aux algorithmes existants comme Scrypt, qui sont difficiles à vérifier lorsque la difficulté de mémoire augmente à des niveaux réellement sécurisés. Cependant, Dagger était vulnérable à une accélération matérielle de la mémoire partagée et a été abandonné en faveur d'autres pistes de recherche. -[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) est un algorithme qui ajoute une résistance ASIC en étant lié aux E / S (c'est-à-dire que les lectures de mémoire sont le facteur limitant du processus de minage). La théorie est que la RAM est plus disponible que le calcul. Des milliards de dollars de recherche ont déjà investis pour étudier les possibilités d'optimisation de la mémoire vive pour différents cas d’utilisation, ce qui implique souvent des modèles d’accès quasi aléatoires (d’où la « mémoire à accès aléatoire »). En conséquence, la RAM existante est susceptible d'être modérément proche de l'optimisation pour l'évaluation de l'algorithme. Hashimoto utilise la blockchain comme source de données, satisfaisant simultanément (1) et (3) ci-dessus. +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) est un algorithme qui ajoute une résistance aux ASIC en étant lié aux E/S (c'est-à-dire que les lectures de mémoire sont le facteur limitant dans le processus de minage). La théorie est que la RAM est plus disponible que le calcul. Des milliards de dollars de recherche ont déjà investis pour étudier les possibilités d'optimisation de la mémoire vive pour différents cas d’utilisation, ce qui implique souvent des modèles d’accès quasi aléatoires (d’où la « mémoire à accès aléatoire »). En conséquence, la RAM existante est susceptible d'être modérément proche de l'optimisation pour l'évaluation de l'algorithme. Hashimoto utilise la blockchain comme source de données, satisfaisant simultanément (1) et (3) ci-dessus. -Dagger-Hashimoto a utilisé des versions modifiées des algorithmes Dagger et Hashimoto. La différence entre Dagger Hashimoto et Hashimoto réside dans le fait qu'au lieu d'utiliser la blockchain comme une source de données, Dagger Hashimoto utilise un ensemble de données générées sur mesure, qui se met à jour en fonction des données de chaque bloc N. L'ensemble de données est généré à l'aide de l'algorithme Dagger permettant de calculer efficacement un sous-ensemble spécifique à chaque nonce pour l'algorithme de vérification du client léger. La différence entre Dagger Hashimoto et Dagger est que, contrairement à l'original Dagger, le jeu de données utilisé pour interroger le bloc est semi-permanent, mis à jour uniquement à intervalles occasionnels (par exemple une fois par semaine). Cela signifie que la partie de l'effort de génération du jeu de données est proche de zéro. Les arguments de Sergio Lerner concernant les vitesses de mémoires partagées deviennent donc négligeables. +Dagger-Hashimoto a utilisé des versions modifiées des algorithmes Dagger et Hashimoto. La différence entre Dagger Hashimoto et Hashimoto réside dans le fait qu'au lieu d'utiliser la blockchain comme une source de données, Dagger Hashimoto utilise un ensemble de données générées sur mesure, qui se met à jour en fonction des données de chaque bloc N. L'ensemble de données est généré à l'aide de l'algorithme Dagger permettant de calculer efficacement un sous-ensemble spécifique à chaque nonce pour l'algorithme de vérification du client léger. La différence entre Dagger Hashimoto et Dagger est que, contrairement au Dagger original, l'ensemble de données utilisé pour interroger le bloc est semi-permanent, mis à jour uniquement à intervalles occasionnels (par exemple, une fois par semaine). Cela signifie que la partie de l'effort de génération du jeu de données est proche de zéro. Les arguments de Sergio Lerner concernant les vitesses de mémoires partagées deviennent donc négligeables. En savoir plus sur [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). ## Ethash {#ethash} -Ethash était l'algorithme de minage qui était en fait utilisé sur le véritable réseau principal Ethereum sous l'architecture désormais obsolète de la preuve de travail. Ethash a été en fait un nouveau nom donné à une version spécifique de Dagger-Hashimoto après que l'algorithme a été mis à jour de manière significative, tout en héritant des principes fondamentaux de son prédécesseur. Le réseau principal Ethereum n'a toujours utilisé qu'Ethash, Dagger Hashimoto était une version R&D de l'algorithme de minage qui a été remplacé avant que le minage commence sur le réseau principal Ethereum. +Ethash était l'algorithme de minage qui était en fait utilisé sur le véritable réseau principal Ethereum sous l'architecture désormais obsolète de la preuve de travail. Ethash a été en fait un nouveau nom donné à une version spécifique de Dagger-Hashimoto après que l'algorithme a été mis à jour de manière significative, tout en héritant des principes fondamentaux de son prédécesseur. Le réseau principal Ethereum n'a jamais utilisé qu'Ethash. Dagger Hashimoto était une version R&D de l'algorithme de minage qui a été remplacée avant le début du minage sur le réseau principal Ethereum. [En savoir plus sur Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). -## 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/dapps/index.md b/public/content/translations/fr/developers/docs/dapps/index.md index 23c4e41f9c5..2a585d35349 100644 --- a/public/content/translations/fr/developers/docs/dapps/index.md +++ b/public/content/translations/fr/developers/docs/dapps/index.md @@ -1,91 +1,91 @@ --- -title: Introduction aux dApps +title: "Introduction technique aux dApps (applications décentralisées)" description: lang: fr --- -Une application décentralisée (dApp) est une application construite sur un réseau décentralisé qui combine un [contrat intelligent](/developers/docs/smart-contracts/) et une interface utilisateur en frontend. Notez que les contrats intelligents Ethereum sont accessibles et transparents, comme les API ouvertes, de sorte que votre dApp peut même inclure un contrat intelligent que quelqu'un d'autre a rédigé. +Une application décentralisée (dapp) est une application construite sur un réseau décentralisé qui combine un [contrat intelligent](/developers/docs/smart-contracts/) et une interface utilisateur frontend. Notez que les contrats intelligents Ethereum sont accessibles et transparents, comme les API ouvertes, de sorte que votre dApp peut même inclure un contrat intelligent que quelqu'un d'autre a rédigé. ## Prérequis {#prerequisites} -Avant d'en apprendre plus sur les dApps, vous devriez connaître les [bases de la blockchain](/developers/docs/intro-to-ethereum/) et vous informer sur le réseau Ethereum et la façon dont il est décentralisé. +Avant d'en apprendre plus sur les dapps, vous devriez couvrir les [bases de la blockchain](/developers/docs/intro-to-ethereum/) et vous informer sur le réseau Ethereum et la façon dont il est décentralisé. -## Définition d'une dApp {#definition-of-a-dapp} +## Définition d'une dapp {#definition-of-a-dapp} Une dApp a son code backend qui s'exécute sur un réseau décentralisé P2P, contrairement aux applications traditionnelles, dont le code du backend est executé sur des serveurs centralisés. -Une dApp peut comporter du code frontend et des interfaces utilisateur rédigées dans n'importe quelle langue (comme une application) qui peuvent passer des appels vers son backend. De plus, son frontend peut être hébergé sur un système de stockage décentralisé comme [IPFS](https://ipfs.io/). +Une dApp peut comporter du code frontend et des interfaces utilisateur rédigées dans n'importe quelle langue (comme une application) qui peuvent passer des appels vers son backend. De plus, son frontend peut être hébergé sur un stockage décentralisé tel que [IPFS](https://ipfs.io/). -- **Décentralisé** - les dApps fonctionnent sur Ethereum, une plateforme publique décentralisée ouverte où personne ni aucun groupe n'a le contrôle -- **Déterministes** - les dApps exécutent la même fonction indépendamment de l'environnement où elles sont exécutées -- **Turing terminé** - les dApps peuvent exécuter n'importe quelle action au regard des ressources requises -- **Isolées** - les dApps s'exécutent dans un environnement virtuel connu sous le nom de Machine Virtuelle Ethereum (EVM en anglais) de sorte que si le contrat intelligent comporte un bogue, cela n'entravera pas le fonctionnement normal du réseau blockchain +- **Décentralisé** - les dapps fonctionnent sur Ethereum, une plateforme publique, ouverte et décentralisée où aucune personne ou aucun groupe n'a le contrôle +- **Déterministe** - les dapps exécutent la même fonction quel que soit l'environnement dans lequel elles sont exécutées +- **Turing-complet** - les dapps peuvent exécuter n'importe quelle action à condition de disposer des ressources nécessaires +- **Isolé** - les dapps sont exécutées dans un environnement virtuel connu sous le nom de machine virtuelle Ethereum (EVM), de sorte que si le contrat intelligent contient un bogue, il n'entravera pas le fonctionnement normal du réseau blockchain -### À propos des contrats intelligents {#on-smart-contracts} +### Sur les contrats intelligents {#on-smart-contracts} -Pour présenter les dApps, nous devons tout d'abord présenter les contrats intelligents (qui sont des dApps du backend, à défaut d'un meilleur terme). Pour une vue d'ensemble détaillée, rendez-vous dans notre section sur [Contrats intelligents](/developers/docs/smart-contracts/). +Pour présenter les dApps, nous devons tout d'abord présenter les contrats intelligents (qui sont des dApps du backend, à défaut d'un meilleur terme). Pour un aperçu détaillé, consultez notre section sur les [contrats intelligents](/developers/docs/smart-contracts/). Un contrat intelligent est un code présent sur la blockchain Ethereum qui fonctionne exactement comme programmé. Une fois les contrats intelligents déployés sur le réseau, vous ne pouvez pas les modifier. Les dApps peuvent être décentralisées car elles sont contrôlées par la logique rédigée dans le contrat, pas par un individu ni une entreprise. Cela signifie que vous devez concevoir vos contrats très soigneusement et les tester de façon approfondie. -## Avantages du développement de dApps {#benefits-of-dapp-development} +## Avantages du développement de dapps {#benefits-of-dapp-development} -- **Zéro temps d'arrêt** : une fois que le contrat intelligent au cœur d'une application est déployé et présent sur la blockchain, le réseau dans son ensemble sera toujours en mesure de servir les clients qui cherchent à interagir avec le contrat. Les acteurs malveillants ne peuvent donc pas lancer d'attaques par déni de service ciblées sur les dApps. -- **Confidentialité** : vous n'avez pas à fournir une identité réelle pour déployer ou interagir avec une dApp. -- **Résistance à la censure** : aucune entité du réseau ne peut empêcher les utilisateurs de soumettre des transactions, de déployer des dApps ou de lire des données de la blockchain. -- **Intégrité complète des données** : grâce à des procédés cryptographiques appelés « primitives cryptographiques », les données stockées sur la blockchain sont immuables et indiscutables. Les acteurs malveillants ne peuvent pas falsifier des transactions ni d'autres données qui ont déjà été rendues publiques. -- **Calcul trustless/comportement vérifiable** : les contrats intelligents peuvent être analysés et offrent la garantie d'une exécution prévisible sans avoir besoin de faire confiance à une autorité centrale. Ce n'est pas le cas dans les modèles financiers traditionnels. Par exemple, lorsque nous utilisons des systèmes bancaires en ligne, nous devons avoir confiance dans le fait que les institutions financières n'utiliseront pas nos données financières à mauvais escient, ne falsifieront pas les documents et ne seront pas piratées. +- **Aucune interruption de service** – Une fois que le contrat intelligent est déployé sur la blockchain, le réseau dans son ensemble sera toujours en mesure de servir les clients qui cherchent à interagir avec le contrat. Les acteurs malveillants ne peuvent donc pas lancer d'attaques par déni de service ciblées sur les dApps. +- **Confidentialité** – Vous n'avez pas besoin de fournir une identité du monde réel pour déployer une dapp ou interagir avec elle. +- **Résistance à la censure** – Aucune entité unique sur le réseau ne peut empêcher les utilisateurs de soumettre des transactions, de déployer des dapps ou de lire des données de la blockchain. +- **Intégrité totale des données** – Les données stockées sur la blockchain sont immuables et indiscutables, grâce aux primitives cryptographiques. Les acteurs malveillants ne peuvent pas falsifier des transactions ni d'autres données qui ont déjà été rendues publiques. +- **Calcul sans confiance/comportement vérifiable** – Les contrats intelligents peuvent être analysés et leur exécution est garantie de manière prévisible, sans qu'il soit nécessaire de faire confiance à une autorité centrale. Ce n'est pas le cas dans les modèles financiers traditionnels. Par exemple, lorsque nous utilisons des systèmes bancaires en ligne, nous devons avoir confiance dans le fait que les institutions financières n'utiliseront pas nos données financières à mauvais escient, ne falsifieront pas les documents et ne seront pas piratées. -## Inconvénients du développement de dApps {#drawbacks-of-dapp-development} +## Inconvénients du développement de dapps {#drawbacks-of-dapp-development} -- **Maintenance** : Les dApps peuvent être plus difficiles à maintenir car les données et le code publiés sur la blockchain sont plus difficiles à modifier. Il est difficile pour les développeurs de mettre à jour leurs dApps (ou les données sous-jacentes stockées par une dApp) une fois celles-ci déployées , même si des bogues ou des risques de sécurité ont été identifiés dans une version antérieure. -- **Impacts sur la performance** : Il y a d'énormes impacts sur la performance et l'évolutivité est vraiment difficile. Pour atteindre le niveau de sécurité, d'intégrité, de transparence et de fiabilité auquel Ethereum aspire, chaque nœud exécute et stocke chaque transactions. En plus de cela, il faut du temps pour parvenir à un consensus par preuve d'enjeu. -- **Congestion du réseau** : dans le modèle actuel, si une dApp utilise trop de ressources de calcul, l'ensemble du réseau est sauvegardé. Actuellement, le réseau ne peut traiter qu'une dizaine de transactions par seconde. Si les transactions sont envoyées plus rapidement que cela, le groupe de transactions non confirmées peut rapidement augmenter. -- **Expérience utilisateur** : il pourrait s'avérer plus difficile de concevoir des expériences conviviales. L'utilisateur moyen pourrait trouver trop difficile de mettre en place la pile d'outils nécessaire pour interagir avec la blockchain de façon réellement sécurisée. -- **Centralisation** : des solutions conviviales pour les utilisateurs et les développeurs basées sur la couche de base d'Ethereum pourraient ressembler à des services centralisés de toute façon. Par exemple, de tels services peuvent stocker des clés ou d'autres informations sensibles côté serveur, servir un frontend en utilisant un serveur centralisé ou exécutez une logique commerciale importante sur un serveur centralisé avant d'écrire dans la blockchain. La centralisation élimine de nombreux avantages de la blockchain (voir tous) par rapport au modèle traditionnel. +- **Maintenance** – Les dapps peuvent être plus difficiles à maintenir, car le code et les données publiés sur la blockchain sont plus difficiles à modifier. Il est difficile pour les développeurs de mettre à jour leurs dApps (ou les données sous-jacentes stockées par une dApp) une fois celles-ci déployées , même si des bogues ou des risques de sécurité ont été identifiés dans une version antérieure. +- **Surcharge de performance** – Il y a une énorme surcharge de performance, et la mise à l'échelle est très difficile. Pour atteindre le niveau de sécurité, d'intégrité, de transparence et de fiabilité auquel Ethereum aspire, chaque nœud exécute et stocke chaque transactions. En plus de cela, il faut du temps pour parvenir à un consensus par preuve d'enjeu. +- **Congestion du réseau** – Lorsqu'une dapp utilise trop de ressources de calcul, l'ensemble du réseau est engorgé. Actuellement, le réseau ne peut traiter qu'une dizaine de transactions par seconde. Si les transactions sont envoyées plus rapidement que cela, le groupe de transactions non confirmées peut rapidement augmenter. +- **Expérience utilisateur** – Il peut être plus difficile de concevoir des expériences conviviales, car l'utilisateur final moyen pourrait trouver trop difficile de mettre en place la pile d'outils nécessaire pour interagir avec la blockchain d'une manière vraiment sécurisée. +- **Centralisation** – Les solutions conviviales pour les utilisateurs et les développeurs, construites sur la couche de base d'Ethereum, pourraient de toute façon finir par ressembler à des services centralisés. Par exemple, de tels services peuvent stocker des clés ou d'autres informations sensibles côté serveur, servir un frontend en utilisant un serveur centralisé ou exécutez une logique commerciale importante sur un serveur centralisé avant d'écrire dans la blockchain. La centralisation élimine de nombreux avantages de la blockchain (voir tous) par rapport au modèle traditionnel. -## En savoir plus via un apprenti visuel ? {#visual-learner} +## Davantage qu'un apprenant visuel ? {#visual-learner} -## Outils pour créer des dApps {#dapp-tools} +## Outils pour créer des dapps {#dapp-tools} **Scaffold-ETH _- Expérimentez rapidement avec Solidity en utilisant un frontend qui s'adapte à votre contrat intelligent._** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -- [Exemple dApp](https://punkwallet.io/) +- [Exemple de dapp](https://punkwallet.io/) -**Créez une App Eth _- Créez des applications sous Ethereum en une seule commande._** +**Create Eth App _- Créez des applications alimentées par Ethereum avec une seule commande._** - [GitHub](https://github.com/paulrberg/create-eth-app) -**One Click Dapp _- outil FOSS pour générer des interfaces dapp en frontend à partir d'une [ABI](/glossary/#abi)._** +**One Click Dapp _- Outil FOSS pour générer des frontends de dapp à partir d'une [ABI](/glossary/#abi)._** - [oneclickdapp.com](https://oneclickdapp.com) - [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) -**Etherflow _- Outil FOSS permettant aux développeurs Ethereum de tester leur nœud, et de composer et déboguer les appels RPC du navigateur._** +**Etherflow _- Outil FOSS pour les développeurs Ethereum pour tester leur nœud, et composer et déboguer les appels RPC depuis le navigateur._** - [etherflow.quiknode.io](https://etherflow.quiknode.io/) - [GitHub](https://github.com/abunsen/etherflow) -**thirdweb _- SDKs dans tous les langages, smart contrats, outils et infrastructure pour le développement web3._** +**thirdweb _- Des SDK dans tous les langages, des contrats intelligents, des outils et une infrastructure pour le développement web3._** - [Page d'accueil](https://thirdweb.com/) - [Documentation](https://portal.thirdweb.com/) - [GitHub](https://github.com/thirdweb-dev/) -**Crossmint - _ Plateforme de développement web3 de niveau entreprise pour déployer des contrats intelligents, permettre les paiements par carte de crédit et inter-chaîne, et utiliser des API pour créer, distribuer, vendre, stocker et modifier des NFT_** +**Crossmint _- Plateforme de développement web3 de niveau entreprise pour déployer des contrats intelligents, permettre les paiements par carte de crédit et inter-chaînes, et utiliser des API pour créer, distribuer, vendre, stocker et modifier des NFT._** - [crossmint.com](https://www.crossmint.com) - [Documentation](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Explorez des applications décentralisées](/apps) -- [L'Architecture d'une application Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ -- [Le guide 2021 pour les applications décentralisées](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ -- [Qu'est-ce que les applications décentralisées ?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [Explorer les dapps](/apps) +- [L'architecture d'une application Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [Un guide 2021 des applications décentralisées](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [Que sont les applications décentralisées ?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ - [Dapps populaires](https://www.alchemy.com/dapps) - _Alchemy_ _Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !_ diff --git a/public/content/translations/fr/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/fr/developers/docs/data-and-analytics/block-explorers/index.md index 126e37bd633..ef390998e20 100644 --- a/public/content/translations/fr/developers/docs/data-and-analytics/block-explorers/index.md +++ b/public/content/translations/fr/developers/docs/data-and-analytics/block-explorers/index.md @@ -1,6 +1,6 @@ --- -title: Explorateurs de blocs -description: Introduction aux explorateurs de blocs, votre portail vers le monde des données de la blockchain, où vous pouvez rechercher des informations sur les transactions, les comptes, les contrats et bien plus. +title: Explorateurs de bloc +description: "Introduction aux explorateurs de blocs, votre portail vers le monde des données de la blockchain, où vous pouvez rechercher des informations sur les transactions, les comptes, les contrats et bien plus." lang: fr sidebarDepth: 3 --- @@ -9,23 +9,21 @@ Les explorateurs de blocs sont votre portail vers les données Ethereum. Vous po ## Prérequis {#prerequisites} -Pour que les données fournies par un explorateur de blocs aient du sens, vous devez avoir compris les concepts de base d'Ethereum. Commencez par lire la page [Introduction à Ethereum](/developers/docs/intro-to-ethereum/). +Pour que les données fournies par un explorateur de blocs aient du sens, vous devez avoir compris les concepts de base d'Ethereum. Commencez par [une introduction à Ethereum](/developers/docs/intro-to-ethereum/). ## Services {#services} -- [Etherscan](https://etherscan.io/) - _Également disponible en chinois, coréen, russe et japonais_ +- [Etherscan](https://etherscan.io/) -_Également disponible en chinois, coréen, russe et japonais_ - [3xpl](https://3xpl.com/ethereum) - [Beaconcha.in](https://beaconcha.in/) -- [Blockchair](https://blockchair.com/ethereum) - _Également disponible en espagnol, français, italien, néerlandais, portugais, russe, chinois et Farsi_ +- [Blockchair](https://blockchair.com/ethereum) -_Également disponible en espagnol, français, italien, néerlandais, portugais, russe, chinois et farsi_ - [Blockscout](https://eth.blockscout.com/) - [Chainlens](https://www.chainlens.com/) -- [Explorateurs de bloc DexGuru](https://ethereum.dex.guru/) +- [Explorateur de blocs DexGuru](https://ethereum.dex.guru/) - [Etherchain](https://www.etherchain.org/) -- [Ethernow](https://www.ethernow.xyz/) -- [Ethplorer](https://ethplorer.io/) - _Aussi disponible en chinois, espagnol, français, turc, russe, coréen et vietnamien_ +- [Ethplorer](https://ethplorer.io/) -_Également disponible en chinois, espagnol, français, turc, russe, coréen et vietnamien_ - [EthVM](https://www.ethvm.com/) - [OKLink](https://www.oklink.com/eth) -- [Rantom](https://rantom.app/) - [Ethseer](https://ethseer.io) ## Outils open source {#open-source-tools} @@ -95,7 +93,7 @@ De plus en plus d'utilisateurs tirent parti des explorateurs de blocs pour suivr - Gas limit (limite de gaz) - Le nombre maximum d'unités de gaz que cette transaction peut consommer - Gas used (gaz utilisé) - Le montant réel des unités de gaz consommées par la transaction - Gas price (prix du gaz) - Le prix fixé par unité de gaz -- Nonce - Le numéro de transaction pour l'adresse `from` (gardez à l'esprit que cela commence à 0 donc un nonce de `100` serait en fait la 101e transaction soumise par ce compte +- Nonce - Le numéro de transaction pour l'adresse `from` (n'oubliez pas que la numérotation commence à 0 et qu'un nonce de `100` serait donc la 101e transaction soumise par ce compte) - Input data (données d'entrée) - Toutes les informations supplémentaires requises par la transaction ### Comptes {#accounts} @@ -145,7 +143,7 @@ Certaines données de bloc sont préoccupées par la santé d'Ethereum de maniè - Total ETH supply (fourniture totale d'ETH) - Nombre d'ETH en circulation - souvenez-vous que de nouveaux ETH sont créés avec la création de chaque bloc sous la forme de récompenses de blocs - Market cap (capitalisation boursière) - Calcul du prix\*approvisionnement -## Données de couche de consensus {#consensus-layer-data} +## Données de la couche de consensus {#consensus-layer-data} ### Période {#epoch} @@ -238,16 +236,12 @@ Les données de couches de consensus de haut niveau comprennent les éléments s ## Explorateurs de blocs {#block-explorers} -- [Etherscan](https://etherscan.io/) - un explorateur de blocs que vous pouvez utiliser pour récupérer des données pour le réseau principal Ethereum -- [Etherscan Sepolia](https://sepolia.etherscan.io/) - un explorateur de blocs que vous pouvez utiliser pour récupérer des données pour le réseau de test Sepolia -- [Etherscan Hoodi](https://hoodi.etherscan.io/) - un explorateur de blocs que vous pouvez utiliser pour récupérer des données pour le réseau de test Hoodi -- [3xpl](https://3xpl.com/ethereum) - un explorateur Ethereum open source sans publicité qui permet de télécharger ses ensembles de données -- [Beaconcha.in](https://beaconcha.in/) - un explorateur de blocs open source pour le réseau principal Ethereum -- [Blockchair](https://blockchair.com/ethereum) - l'explorateur Ethereum le plus privé. Également pour le tri et le filtrage des données (mempool) +- [Etherscan](https://etherscan.io/) - un explorateur de blocs que vous pouvez utiliser pour récupérer des données pour le réseau principal Ethereum et les réseaux de test +- [3xpl](https://3xpl.com/ethereum) - un explorateur Ethereum open source et sans publicité qui permet de télécharger ses ensembles de données +- [Beaconcha.in](https://beaconcha.in/) - un explorateur de blocs open source pour le réseau principal Ethereum et les réseaux de test +- [Blockchair](https://blockchair.com/ethereum) - l'explorateur Ethereum le plus privé. Egalement pour trier et filtrer des données (mempool). - [Etherchain](https://www.etherchain.org/) - un explorateur de blocs pour le réseau principal Ethereum - [Ethplorer](https://ethplorer.io/) - un explorateur de blocs axé sur les jetons pour le réseau principal Ethereum et le réseau de test Kovan -- [Rantom](https://rantom.app/) - Un visualiseur de transactions DeFi et NFT open source convivial pour des informations détaillées -- [Ethernow](https://www.ethernow.xyz/) - un explorateur de transactions en temps réel qui vous permet de voir la couche pré-chaîne du réseau principal Ethereum ## En savoir plus {#further-reading} diff --git a/public/content/translations/fr/developers/docs/data-and-analytics/index.md b/public/content/translations/fr/developers/docs/data-and-analytics/index.md index 0cf2e892bdc..e572823085b 100644 --- a/public/content/translations/fr/developers/docs/data-and-analytics/index.md +++ b/public/content/translations/fr/developers/docs/data-and-analytics/index.md @@ -1,6 +1,6 @@ --- -title: Données et analyses -description: Comment obtenir des analyses et des données en chaîne utiles pour vos dApps +title: "Données et analyses" +description: "Comment obtenir des analyses et des données en chaîne utiles pour vos dApps" lang: fr --- @@ -10,46 +10,63 @@ lang: fr Les fournisseurs de données existants peuvent accélérer le développement, produire des résultats plus précis et réduire les efforts de maintenance. Cela permettra à une équipe de se concentrer sur la fonctionnalité de base que son projet essaie de fournir. -## Pré-requis {#prerequisites} +## Prérequis {#prerequisites} -Vous devez comprendre le concept de base des [Explorateurs de bloc](/developers/docs/data-and-analytics/block-explorers/) afin de mieux comprendre leur utilisation dans le contexte de l'analyse des données. De plus, familiarisez-vous avec le concept d'[indice](/glossary/#index) pour comprendre les avantages qu'ils apportent à la conception d'un système. +Vous devez comprendre le concept de base des [Explorateurs de blocs](/developers/docs/data-and-analytics/block-explorers/) afin de mieux comprendre leur utilisation dans le contexte de l'analyse des données. De plus, familiarisez-vous avec le concept d'[index](/glossary/#index) pour comprendre les avantages qu'ils apportent à la conception d'un système. -En termes de fondamentaux architecturaux, comprendre ce qu'est une [API](https://www.wikipedia.org/wiki/API) et un[REST](https://www.wikipedia.org/wiki/Representational_state_transfer) (Representational state transfer), même en théorie. +En termes de fondamentaux architecturaux, comprendre ce qu'est une [API](https://www.wikipedia.org/wiki/API) et [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), même en théorie. -## Explorateurs de bloc {#block-explorers} +## Explorateurs de blocs {#block-explorers} -De nombreux [Explorateurs de bloc](/developers/docs/data-and-analytics/block-explorers/) offrent des passerelles [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) qui fournissent une visibilité aux développeurs sur les données en temps réel sur les blocs, les transactions, les validateurs, les comptes et autres activités sur la chaîne. +De nombreux [explorateurs de blocs](/developers/docs/data-and-analytics/block-explorers/) proposent des passerelles [API](https://www.wikipedia.org/wiki/API) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) qui offrent aux développeurs une visibilité sur les données en temps réel des blocs, des transactions, des validateurs, des comptes et d'autres activités en chaîne. -Les développeurs peuvent alors traiter et transformer ces données afin de leur donner leurs informations d'utilisateurs uniques et leurs interactions avec la [blockchain](/glossary/#blockchain). Par exemple, [Etherscan](https://etherscan.io) fournit des données d'exécution et de consensus pour chaque créneau de 12 secondes. +Les développeurs peuvent ensuite traiter et transformer ces données pour offrir à leurs utilisateurs des informations uniques et des interactions avec la [blockchain](/glossary/#blockchain). Par exemple, [Etherscan](https://etherscan.io) et [Blockscout](https://eth.blockscout.com) fournissent des données d'exécution et de consensus pour chaque créneau de 12 s. -## Le réseau Graph {#the-graph} +## The Graph {#the-graph} -Le [réseau Graph](https://thegraph.com/) est un protocole d'indexation décentralisé pour organiser les données de la blockchain. Au lieu de construire et de gérer des stockages de données hors chaîne et centralisés pour agréger les données sur la chaîne, avec The Graph, les développeurs peuvent construire des applications sans serveur qui fonctionnent entièrement sur une infrastructure publique. +[The Graph](https://thegraph.com/) est un protocole d'indexation qui offre un moyen simple d'interroger les données de la blockchain via des API ouvertes appelées sous-graphes. -En utilisant [GraphQL](https://graphql.org/), les développeurs peuvent interroger n'importe laquelle des API ouvertes organisées, connues sous le nom de sub-graphe, pour acquérir les informations nécessaires pour faire fonctionner leur dApp. En interrogeant ces subs-graphs indexés, les rapports et les dApps non seulement obtiennent des avantages en termes de performances et d'évolutivité, mais obtiennent aussi la précision intégrée fournie par consensus sur le réseau. Au fur et à mesure que de nouvelles améliorations et/ou sub-graphs sont ajoutées au réseau, vos projets peuvent rapidement se renouveler pour tirer parti de ces améliorations. +Avec The Graph, les développeurs peuvent bénéficier de : -## Diversité des clients +- Indexation décentralisée : Permet d’indexer les données de la blockchain via plusieurs indexeurs, éliminant ainsi tout point de défaillance unique +- Requêtes GraphQL : Offre une interface GraphQL puissante pour interroger des données indexées, ce qui rend la récupération des données très simple +- Personnalisation : Définissez votre propre logique pour transformer et stocker les données de la blockchain, et réutilisez les sous-graphes publiés par d'autres développeurs sur The Graph Network. -[La diversité du client](/developers/docs/nodes-and-clients/client-diversity/) est importante pour la santé globale du réseau Ethereum, car elle fournit de la résilience aux bogues et aux exploitations. Il existe désormais plusieurs tableaux de bord sur la diversité des clients, notamment [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) and [Ethernodes](https://ethernodes.org/). +Suivez ce guide de [démarrage rapide](https://thegraph.com/docs/en/quick-start/) pour créer, déployer et interroger un sous-graphe en moins de 5 minutes. + +## Diversité des clients {#client-diversity} + +[La diversité des clients](/developers/docs/nodes-and-clients/client-diversity/) est importante pour la santé globale du réseau Ethereum, car elle offre une résilience face aux bogues et aux exploits. Il existe maintenant plusieurs tableaux de bord sur la diversité des clients, notamment [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) et [Ethernodes](https://ethernodes.org/). ## Dune Analytics {#dune-analytics} -[Dune Analytics](https://dune.com/) prétraite les données de la blockchain en tables de base de données relationnelles (DuneSQL), permet aux utilisateurs d'interroger les données de la blockchain en utilisant SQL et de construire des tableaux de bord basés sur les résultats des requêtes. Les données sur la chaîne sont réparties en 4 tables brutes : `blocs`, `transactions`, (événement) `logs` et (appel) `traces`. Les contrats et protocoles populaires ont été décodés et chacun a son propre ensemble de tables d'événements et d'appels. Ces tables d'événements et d'appels sont traitées et organisées en tables d'abstraction par le type de protocoles, par exemple, dex, prêt, stablecoins, etc. +[Dune Analytics](https://dune.com/) prétraite les données de la blockchain en tables de base de données relationnelles (DuneSQL), permet aux utilisateurs d'interroger les données de la blockchain en utilisant SQL et de construire des tableaux de bord basés sur les résultats des requêtes. Les données en chaîne sont organisées en 4 tables brutes : `blocks`, `transactions`, (événement) `logs` et (appel) `traces`. Les contrats et protocoles populaires ont été décodés et chacun a son propre ensemble de tables d'événements et d'appels. Ces tables d'événements et d'appels sont traitées et organisées en tables d'abstraction par le type de protocoles, par exemple, dex, prêt, stablecoins, etc. + +## SQD {#sqd} -## Réseau SubQuery {#subquery-network} +[SQD](https://sqd.dev/) est une plateforme de données décentralisée, hyper-scalable, optimisée pour offrir un accès efficace et sans permission à de grands volumes de données. Il fournit actuellement des données historiques on-chain, y compris les journaux d’événements, les reçus de transaction, les traces et les différences d’état par transaction. SQD offre un ensemble d’outils puissants pour créer des pipelines personnalisés d’extraction et de traitement des données, atteignant une vitesse d’indexation allant jusqu’à 150k blocs par seconde. + +Pour commencer, consultez la [documentation](https://docs.sqd.dev/) ou regardez des [exemples EVM](https://github.com/subsquid-labs/squid-evm-examples) de ce que vous pouvez construire avec SQD. + +## SubQuery Network {#subquery-network} [SubQuery](https://subquery.network/) est un indexeur de données de premier plan qui offre aux développeurs des API rapides, fiables, décentralisées et personnalisées pour leurs projets web3. Suber permet aux développeurs de plus de 165+ écosystèmes (y compris Ethereum) de disposer de riches données indexées pour construire des expériences intuitives et immersives pour leurs utilisateurs. Le réseau SubQuery alimente votre application inarrêtable avec un réseau d'infrastructures résiliant et décentralisé. Utilisez la boite à outils de développeur blockchain de SubQuery pour construire les applications Web3 du futur, sans passer de temps à concevoir un backend personnalisé pour les activités de traitement de données. -Pour commencer, consultez le [guide de démarrage rapide Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) pour commencer à indexer les données de la blockchain Ethereum en quelques minutes dans un environnement Docker local à des fins de test avant de mettre en ligne sur un [service géré de SubQuery](https://managedservice.subquery.network/) ou sur le [réseau décentralisé de SubQuery](https://app.subquery.network/dashboard). +Pour commencer, consultez le [guide de démarrage rapide d'Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) pour commencer à indexer les données de la blockchain Ethereum en quelques minutes dans un environnement Docker local à des fins de test avant la mise en service sur le [service géré de SubQuery](https://managedservice.subquery.network/) ou sur le [réseau décentralisé de SubQuery](https://app.subquery.network/dashboard). + +## Langage de requête EVM {#evm-query-language} -## Ethernow - Le programme de données de la mempool {#ethernow} -[Blocknative](https://www.blocknative.com/) offre un accès ouvert à son [archive de données historique de la mempool](https://www.ethernow.xyz/mempool-data-archive) Ethereum. Cela permet aux chercheurs et aux bons projets communautaires d'explorer la couche pré-chaîne du réseau principal Ethereum. L'ensemble de données est activement maintenu et constitue l'enregistrement historique le plus complet des événements de transaction de la mempool au sein de l'écosystème Ethereum. En savoir plus sur [Ethernow](https://www.ethernow.xyz/). +Le langage de requête EVM (EQL) est un langage similaire au SQL, conçu pour interroger les chaînes compatibles avec la machine virtuelle Ethereum (EVM). L’objectif principal d’EQL est de prendre en charge des requêtes relationnelles complexes sur les entités principales des chaînes EVM (blocs, comptes et transactions), tout en offrant aux développeurs et chercheurs une syntaxe ergonomique pour une utilisation quotidienne. Avec EQL, les développeurs peuvent récupérer des données de la blockchain en utilisant une syntaxe familière proche du SQL, ce qui leur permet d’éliminer le besoin de code standard complexe. EQL prend en charge les requêtes standards de données blockchain (par exemple, récupérer le nonce et le solde d’un compte sur Ethereum, ou obtenir la taille et l’horodatage du bloc actuel) et ajoute en permanence la prise en charge de requêtes plus complexes et de nouvelles fonctionnalités. -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Présentation du réseau Graph](https://thegraph.com/docs/en/about/) -- [Bac à sable de requêtes Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) -- [Examples de code d'APIs sur EtherScan](https://etherscan.io/apis#contracts) -- [Explorateur de Beacon Chain](https://beaconcha.in) -- [Basiques de Dune](https://docs.dune.com/#dune-basics) -- [Guide de démarrage rapide de SubQuery Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Exploration des données cryptographiques I : Architectures de flux de données](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Aperçu du réseau Graph](https://thegraph.com/docs/en/about/) +- [Playground de requêtes Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Exemples de code d'API sur Etherscan](https://etherscan.io/apis#contracts) +- [Documentation de l'API sur Blockscout](https://docs.blockscout.com/devs/apis) +- [Explorateur de la Chaîne phare Beaconcha.in](https://beaconcha.in) +- [Les bases de Dune](https://docs.dune.com/#dune-basics) +- [Guide de démarrage rapide SubQuery pour Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Aperçu du réseau SQD](https://docs.sqd.dev/) +- [Langage de requête EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/fr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/fr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md index 71e5b22e4ef..22207aa99bd 100644 --- a/public/content/translations/fr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md +++ b/public/content/translations/fr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -1,6 +1,6 @@ --- -title: Stratégies de stockage des données de la Blockchain -description: Il existe plusieurs façons de stocker des données en utilisant la blockchain. Cet article comparera les différentes stratégies, leurs coûts et avantages, ainsi que les conditions requises pour les utiliser en toute sécurité. +title: "Stratégies de stockage des données de la Blockchain" +description: "Il existe plusieurs façons de stocker des données en utilisant la blockchain. Cet article comparera les différentes stratégies, leurs coûts et avantages, ainsi que les conditions requises pour les utiliser en toute sécurité." lang: fr --- @@ -10,13 +10,13 @@ Il existe de multiples façons de stocker des informations, soit directement sur - Données d'appel - Hors chaîne avec des mécanismes de couche de niveau 1 - "Code" de contrat -- Évènements +- Événements - Stockage EVM Le choix de la méthode à utiliser repose sur plusieurs critères : - La source de l'information. Les informations dans calldata ne peuvent pas provenir directement de la blockchain elle-même. -- La destination de l'information. Le calldata n'est disponible que dans la transaction qu'il initie. Les événements ne sont pas accessibles sur la chaine. +- La destination de l'information. Le calldata n'est disponible que dans la transaction qui l'inclut. Les événements ne sont pas accessibles sur la chaine. - Quel niveau de complexité est acceptable ? Les ordinateurs qui exécutent un nœud complet peuvent effectuer plus de traitement qu'un client léger dans une application fonctionnant dans un navigateur. - Est-il nécessaire de faciliter l'accès aux informations depuis chaque nœud ? - Les exigences en matière de sécurité. @@ -27,7 +27,7 @@ En général, la sécurité de l'information se compose de trois attributs : - _Confidentialité_, les entités non autorisées n'ont pas le droit de lire les informations. Cela est important dans de nombreux cas, mais pas ici. _Il n'y a pas de secret sur la blockchain_. Les blockchains fonctionnent parce que n'importe qui peut vérifier les transitions d'état, de sorte qu'il est impossible de les utiliser pour stocker directement des secrets. Il existe des moyens de stocker des informations confidentielles sur la blockchain, mais ils reposent tous sur un composant hors blockchain pour stocker au moins une clé. -- _Intégrité_, les informations sont correctes, elles ne peuvent pas être modifiées par des entités non autorisées, ou de manière non autorisée (par exemple, en transférant des [jetons ERC-20] (https://eips.ethereum.org/EIPS/eip-20#events) sans un événement `Transfer`). Sur la blockchain, chaque nœud vérifie chaque changement d'état, ce qui garantit l'intégrité. +- _Intégrité_, les informations sont correctes, elles ne peuvent pas être modifiées par des entités non autorisées, ou de manière non autorisée (par exemple, en transférant des [jetons ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) sans un événement `Transfer`). Sur la blockchain, chaque nœud vérifie chaque changement d'état, ce qui garantit l'intégrité. - _Disponibilité_, l'information est accessible à toute entité autorisée. Sur la blockchain, cela est généralement réalisé en rendant l'information disponible sur chaque [nœud complet](https://ethereum.org/developers/docs/nodes-and-clients#full-node). @@ -114,5 +114,5 @@ Ce tableau résume les différentes options, leurs avantages et inconvénients. | Données d'appel | Hors chaîne | Garantie perpétuelle sur Ethereum (fait partie de la blockchain) | Disponible uniquement si écrit dans un contrat, et lors de cette transaction | | | Hors chaîne avec des mécanismes de couche de niveau 1 | Hors chaîne | Garantie d'un "vérificateur honnête" pendant la période de contestation | Hachage uniquement | Garanti par le mécanisme de contestation, seulement pendant la période de contestation | | Code contrat | Sur chaîne ou hors chaîne | Garantie perpétuelle sur Ethereum (fait partie de la blockchain) | Oui | Écrit à une adresse "aléatoire", ne peut pas commencer par `0xEF` | -| Évènements | Sur la chaîne | Garantie perpétuelle sur Ethereum (fait partie de la blockchain) | Non | | +| Événements | Sur la chaîne | Garantie perpétuelle sur Ethereum (fait partie de la blockchain) | Non | | | Stockage | Sur la chaîne | Garantie perpétuelle sur Ethereum (fait partie de la blockchain et de l'état actuel jusqu'à écrasement) | Oui | | diff --git a/public/content/translations/fr/developers/docs/data-availability/index.md b/public/content/translations/fr/developers/docs/data-availability/index.md index d035f45edca..2fa0abc6b9d 100644 --- a/public/content/translations/fr/developers/docs/data-availability/index.md +++ b/public/content/translations/fr/developers/docs/data-availability/index.md @@ -1,36 +1,36 @@ --- -title: Disponibilité des données -description: Un aperçu des problèmes et des solutions liés à la disponibilité des données sur Ethereum +title: "Disponibilité des données" +description: "Un aperçu des problèmes et des solutions liés à la disponibilité des données sur Ethereum" lang: fr --- « Ne pas faire confiance, vérifier » est une maxime courante dans Ethereum. L'idée est que votre nœud peut vérifier de façon indépendante que les informations qu'il reçoit sont correctes en exécutant toutes les transactions dans les blocs qu'il reçoit de ses pairs pour s'assurer que les changements proposés correspondent exactement à ceux calculés indépendamment par le noeud. Cela signifie que les nœuds n'ont pas à croire que les expéditeurs du bloc sont honnêtes. Ce n'est pas possible si les données sont manquantes. -**La disponibilité des données** fait référence à la confiance qu'un utilisateur peut avoir que les données requises pour vérifier qu'un bloc est vraiment disponible pour tous les participants au réseau. Pour les nœuds complets de la couche Ethereum 1, c'est relativement simple ; le noeud complet télécharge une copie de toutes les données dans chaque bloc - les données _doivent être disponibles_ pour que le téléchargement soit possible. Un bloc avec des données manquantes serait jeté plutôt que d'être ajouté à la blockchain. Il s'agit de la « disponibilité des données sur la chaîne » et c'est une caractéristique des blockchains monolithiques. Les nœuds complets ne peuvent pas être amenés à accepter des transactions invalides car ils téléchargent et exécutent chaque transaction pour eux-mêmes. Cependant, pour les blockchains modulaires, les rollups de la couche 2 et les clients légers, le paysage de disponibilité des données est plus complexe, nécessitant des procédures de vérification plus sophistiquées. +**La disponibilité des données** fait référence à la confiance qu'un utilisateur peut avoir dans le fait que les données nécessaires à la vérification d'un bloc sont réellement disponibles pour tous les participants du réseau. Pour les nœuds complets sur la couche 1 d'Ethereum, c'est relativement simple ; le nœud complet télécharge une copie de toutes les données de chaque bloc - les données _doivent_ être disponibles pour que le téléchargement soit possible. Un bloc avec des données manquantes serait jeté plutôt que d'être ajouté à la blockchain. Il s'agit de la « disponibilité des données sur la chaîne » et c'est une caractéristique des blockchains monolithiques. Les nœuds complets ne peuvent pas être amenés à accepter des transactions invalides car ils téléchargent et exécutent chaque transaction pour eux-mêmes. Cependant, pour les blockchains modulaires, les rollups de la couche 2 et les clients légers, le paysage de disponibilité des données est plus complexe, nécessitant des procédures de vérification plus sophistiquées. ## Prérequis {#prerequisites} -Vous devriez avoir une bonne compréhension des [fondamentaux de la blockchain](/developers/docs/intro-to-ethereum/), en particulier des [mécanismes de consensus](/developers/docs/consensus-mechanisms/). Cette page suppose également que le lecteur est familier avec les [blocs](/developers/docs/blocks/), [transactions](/developers/docs/transactions/), [noeuds](/developers/docs/nodes-and-clients/), [solutions d'échelle](/developers/docs/scaling/), et autres sujets pertinents. +Vous devez avoir une bonne compréhension des [principes fondamentaux de la blockchain](/developers/docs/intro-to-ethereum/), en particulier des [mécanismes de consensus](/developers/docs/consensus-mechanisms/). Cette page suppose également que le lecteur est familier avec les [blocs](/developers/docs/blocks/), les [transactions](/developers/docs/transactions/), les [nœuds](/developers/docs/nodes-and-clients/), les [solutions de mise à l'échelle](/developers/docs/scaling/) et d'autres sujets pertinents. -## Problème de disponibilité des données {#the-data-availability-problem} +## Le problème de la disponibilité des données {#the-data-availability-problem} Le problème de la disponibilité des données est la nécessité de prouver à l'ensemble du réseau que la forme résumée de certaines données de transaction qui sont ajoutées à la blockchain représente vraiment un ensemble de transactions valides, mais sans obliger tous les nœuds à télécharger toutes les données. Les données de transaction complètes sont nécessaires pour la vérification indépendante des blocs, mais exiger que tous les nœuds téléchargent toutes les données de transaction est un obstacle à la mise à l'échelle. Les solutions au problème de la disponibilité des données visent à fournir suffisamment d'assurance que toutes les données de transaction ont été mises à la disposition des participants du réseau qui ne téléchargent pas et ne stockent pas les données pour eux-mêmes. -[Les nœuds légers](/developers/docs/nodes-and-clients/light-clients) et [les rollups de la couche 2](/developers/docs/scaling) sont des exemples importants de participants au réseau qui nécessitent une forte assurance de disponibilité des données, mais ne peuvent pas télécharger et traiter les données de transaction pour eux-mêmes. Une opération de téléchargement des données de transaction non effectuée, c'est ce qui rend les light nodes légers, et permet à la fois aux rollups de se présenter en tant que véritables solutions pour résoudre les problèmes de scalabilité. +[Les nœuds légers](/developers/docs/nodes-and-clients/light-clients) et les [rollups de couche 2](/developers/docs/scaling) sont des exemples importants de participants au réseau qui nécessitent de solides garanties de disponibilité des données, mais ne peuvent pas télécharger et traiter les données de transaction par eux-mêmes. Une opération de téléchargement des données de transaction non effectuée, c'est ce qui rend les light nodes légers, et permet à la fois aux rollups de se présenter en tant que véritables solutions pour résoudre les problèmes de scalabilité. -La disponibilité des données constitue aussi un sujet de préoccupation majeure pour les clients [« apatrides »](/roadmap/statelessness) d'Ethereum à venir, qui n'auraient pas besoin de télécharger ou de stocker des données afin de vérifier des blocs. Les clients « stateless » ont constamment besoin d'être assurés que les données sont disponibles_, peu importe comment,_ et que le traitement des données s'est déroulé de façon correcte. +La disponibilité des données est également une préoccupation essentielle pour les futurs clients Ethereum [« sans état »](/roadmap/statelessness) qui n'ont pas besoin de télécharger et de stocker les données d'état pour vérifier les blocs. Les clients sans état doivent toujours être certains que les données sont disponibles _quelque part_ et qu'elles ont été traitées correctement. -## Des solutions garantissant la disponibilité des données {#data-availability-solutions} +## Solutions de disponibilité des données {#data-availability-solutions} ### Échantillonnage de la disponibilité des données (DAS) {#data-availability-sampling} -L'échantillonnage de la disponibilité des données (DAS) est un moyen pour le réseau de vérifier que les données sont disponibles sans mettre trop de pression sur un nœud individuel. Chaque nœud (y compris les nœuds non jalonnés) télécharge un petit sous-ensemble sélectionné au hasard des données totales. Le téléchargement réussi des échantillons confirme avec une grande confiance que toutes les données sont disponibles. Cela repose sur un système de chiffrage qui permet l'effacement de données, tout en favorisant l'extension d'un ensemble de données avec des informations redondantes (la façon dont cela s'effectue est d'adapter une fonction connue sous le nom de _fonctions polynomiales,_ sur les données et dévaluer ce polynôme en des points supplémentaires). Les données originales peuvent ainsi être recouvertes, si nécessaire, sur un ensemble de données redondantes. Par conséquent, si _aucune_ donnée originale n'était disponible, la création des données engendrait une perte de la _moitié_ des données étendues ! La quantité d'échantillons de données téléchargées peut être ajustée par noeud. De ce fait, il est _fort_ probable qu'au moins un des fragments de données échantillonnés par chaque client soit manquant _si_ moins de la moitié des données sont réellement disponibles. +L'échantillonnage de la disponibilité des données (DAS) est un moyen pour le réseau de vérifier que les données sont disponibles sans mettre trop de pression sur un nœud individuel. Chaque nœud (y compris les nœuds non jalonnés) télécharge un petit sous-ensemble sélectionné au hasard des données totales. Le téléchargement réussi des échantillons confirme avec une grande confiance que toutes les données sont disponibles. Cela repose sur le codage à effacement de données, qui étend un ensemble de données donné avec des informations redondantes (pour ce faire, on ajuste une fonction connue sous le nom de _polynôme_ sur les données et on évalue ce polynôme en des points supplémentaires). Les données originales peuvent ainsi être recouvertes, si nécessaire, sur un ensemble de données redondantes. Une conséquence de cette création de données est que si _une partie_ des données originales n'est pas disponible, la _moitié_ des données étendues sera manquante ! La quantité d'échantillons de données téléchargés par chaque nœud peut être ajustée de sorte qu'il soit _extrêmement_ probable qu'au moins un des fragments de données échantillonnés par chaque client soit manquant _si_ moins de la moitié des données est réellement disponible. -DAS sera employé pour permettre aux opérateurs de rollup de rendre leurs données de transaction disponibles, après l'implémentation du[Danksharding complet](/roadmap/danksharding/#what-is-danksharding). Les nœuds Ethereum procéderont à un échantillonnage aléatoire des données de transaction fournies dans les blobs en utilisant le schéma de redondance expliqué ci-dessus pour s'assurer que toutes les données existent. La même technique pourrait également être employée pour s'assurer que les producteurs de blocs mettent toutes leurs données à la disposition de la sécurisation des clients légers. De même, sous [la séparation proposant-constructeur](/roadmap/pbs), seul le constructeur d'un bloc serait requis pour traiter un bloc entier - d'autres validateurs procéderaient à une vérification en utilisant l'échantillonnage de la disponibilité des données. +Le DAS sera utilisé pour s'assurer que les opérateurs de rollup rendent leurs données de transaction disponibles après la mise en œuvre du [Danksharding complet](/roadmap/danksharding/#what-is-danksharding). Les nœuds Ethereum procéderont à un échantillonnage aléatoire des données de transaction fournies dans les blobs en utilisant le schéma de redondance expliqué ci-dessus pour s'assurer que toutes les données existent. La même technique pourrait également être employée pour s'assurer que les producteurs de blocs mettent toutes leurs données à la disposition de la sécurisation des clients légers. De même, dans le cadre de la [séparation proposant-constructeur](/roadmap/pbs), seul le constructeur de bloc serait tenu de traiter un bloc entier - les autres validateurs effectueraient une vérification en utilisant l'échantillonnage de disponibilité des données. ### Comités de disponibilité des données {#data-availability-committees} -Les comités de disponibilité des données (DAC) sont des tiers de confiance qui fournissent ou attestent de la disponibilité des données. Les DAC peuvent être utilisés à la place de, [ou en combinaison avec](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. Les garanties données par les comités en matière de sécurité, relèvent de leur mise en place spécifique. Ethereum utilise des échantillons aléatoires de sous-ensembles de validateurs pour attester de la disponibilité des données pour les nœuds légers, par exemple. +Les comités de disponibilité des données (DAC) sont des tiers de confiance qui fournissent ou attestent de la disponibilité des données. Les DAC peuvent être utilisés à la place du DAS, [ou en combinaison avec celui-ci](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). Les garanties données par les comités en matière de sécurité, relèvent de leur mise en place spécifique. Ethereum utilise des échantillons aléatoires de sous-ensembles de validateurs pour attester de la disponibilité des données pour les nœuds légers, par exemple. Les DAC sont également utilisés par certains validiums. Le DAC est un ensemble de noeuds de confiance qui stocke des copies de données hors ligne. Le DAC est nécessaire pour la mise à disposition des données en cas de litige. Les membres de la DAC publient également des attestations en chaîne pour prouver que les données en question sont effectivement disponibles. Certains Validiums remplacent les DAC par un système de validation par preuve d'enjeu (PoS). Ici, tout le monde peut devenir un validateur et stocker des données hors chaîne. Cependant, ils doivent fournir une « obligation », qui est déposée dans un contrat intelligent. En cas d'intention malveillante, telle que la retenue des données du validateur, cet accord pourrait être résilié. Les comités de disponibilité des données basée sur la preuve d'enjeu sont bien plus sécuritaires que les DAC régulières, car ils encouragent directement les comportements honnêtes. @@ -38,47 +38,47 @@ Les DAC sont également utilisés par certains validiums. Le DAC est un ensemble [Les nœuds légers](/developers/docs/nodes-and-clients/light-clients) doivent valider l'exactitude des en-têtes de bloc qu'ils reçoivent sans télécharger les données du bloc. Le coût de cette légèreté est l'incapacité à vérifier indépendamment les en-têtes de bloc en réexécutant les transactions localement à la manière des nœuds complets. -Les nœuds légers Ethereum font confiance à des ensembles aléatoires de 512 validateurs qui ont été assignés à un _comité de synchronisation_. Le comité de synchronisation agit comme une DAC qui signale aux clients légers que les données dans l'en-tête sont correctes en utilisant une signature cryptographique. Le comité de synchronisation effectue des rafraîchissements journaliers des données. Chaque en-tête de bloc alerte les nœuds légers quant aux validateurs qui s'attendent à approuver le bloc _suivant_, afin qu'ils ne puissent pas être amenés à faire confiance à un groupe malveillant prétendant être le vrai comité de synchronisation. +Les nœuds légers d'Ethereum font confiance à des ensembles aléatoires de 512 validateurs qui ont été assignés à un _comité de synchronisation_. Le comité de synchronisation agit comme une DAC qui signale aux clients légers que les données dans l'en-tête sont correctes en utilisant une signature cryptographique. Le comité de synchronisation effectue des rafraîchissements journaliers des données. Chaque en-tête de bloc informe les nœuds légers des validateurs qui devraient signer le bloc _suivant_, afin qu'ils ne puissent pas être amenés à faire confiance à un groupe malveillant se faisant passer pour le véritable comité de synchronisation. -Cependant, que se passe-t-il si un attaquant _parvient_ d'une manière ou d'une autre à transmettre un en-tête de bloc malveillant aux clients légers et à les convaincre qu'il a été approuvé par un comité de synchronisation honnête ? Dans ce cas, l'attaquant pourrait inclure des transactions invalides et le client léger les accepterait aveuglément, car il ne vérifie pas indépendamment tous les changements d'état résumés dans l'en-tête du bloc. Pour se prémunir contre cela, le client léger pourrait utiliser des preuves de fraude. +Cependant, que se passe-t-il si un attaquant parvient d'une manière ou d'une autre à transmettre un en-tête de bloc malveillant à des clients légers et à les convaincre qu'il a été signé par un comité de synchronisation honnête ? Dans ce cas, l'attaquant pourrait inclure des transactions invalides et le client léger les accepterait aveuglément, car il ne vérifie pas indépendamment tous les changements d'état résumés dans l'en-tête du bloc. Pour se prémunir contre cela, le client léger pourrait utiliser des preuves de fraude. La façon dont ces preuves de fraude fonctionnent est qu'un nœud complet, voyant une transition d'état invalide faire l'objet de commérages dans le réseau, pourrait rapidement générer une petite partie de données démontrant qu'une transition d'état proposée ne pourrait pas provenir d'un ensemble donné de transactions et diffuser ces données aux pairs. Les nœuds légers pourraient récupérer ces preuves de fraude et les utiliser pour éliminer les en-têtes de bloc défectueux, en s'assurant d'un maintien sur la même chaîne honnête que les nœuds complets. Cela repose sur des nœuds complets ayant accès à des données de transaction complètes. Un attaquant qui diffuse un mauvais en-tête de bloc et ne parvient pas non plus à rendre les données de transaction disponibles serait en mesure d'empêcher les nœuds complets de générer des preuves de fraude. Les nœuds complets pourraient être en mesure de signaler la présence d'un bloc défectueux, mais ils ne pourraient pas assurer la mise en place de leur avertissement avec une preuve, du fait de l'absence de disponibilité des données pour générer la preuve ! -DAS : la solution au problème de disponibilité des données. Les nœuds légers téléchargent de très petits morceaux aléatoires des données d'état complètes et utilisent les échantillons pour vérifier que l'ensemble de données complet est disponible. La probabilité réelle de supposer à tort la disponibilité totale des données après le téléchargement de N morceaux aléatoires peut être calculée ([pour 100 morceaux, la chance est de 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), c'est-à-dire incroyablement improbable). +DAS : la solution au problème de disponibilité des données. Les nœuds légers téléchargent de très petits morceaux aléatoires des données d'état complètes et utilisent les échantillons pour vérifier que l'ensemble de données complet est disponible. La probabilité réelle de supposer à tort une disponibilité totale des données après le téléchargement de N morceaux aléatoires peut être calculée ([pour 100 morceaux, la probabilité est de 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), c'est-à-dire incroyablement improbable). Même dans ce scénario, les attaques qui retiennent seulement quelques octets pourraient vraisemblablement passer inaperçues auprès des clients effectuant des demandes de données aléatoires. Le code d'effacement corrige cela en reconstruisant de petites parties de données manquantes qui peuvent être utilisées pour vérifier les changements d'état proposés. Une preuve de fraude pourrait alors être construite en utilisant les données reconstruites, empêchant les nœuds légers d'accepter de mauvais en-têtes. -**Remarque :** Les preuves DAS et de fraude n'ont pas encore été implémentées pour les clients légers Ethereum prouvés en jeu mais elles sont sur la feuille de route, très probablement sous la forme de preuves basées sur ZK-SNARK. Les clients légers d'aujourd'hui s'appuient sur une forme de DAC : ils vérifient les identités du comité de synchronisation et font ensuite confiance aux en-têtes de blocs signés qu'ils reçoivent. +**Note :** Le DAS et les preuves de fraude n'ont pas encore été implémentés pour les clients légers Ethereum à preuve d'enjeu, mais ils figurent sur la feuille de route, et prendront très probablement la forme de preuves basées sur les ZK-SNARK. Les clients légers d'aujourd'hui s'appuient sur une forme de DAC : ils vérifient les identités du comité de synchronisation et font ensuite confiance aux en-têtes de blocs signés qu'ils reçoivent. -## Disponibilité des données et couche 2 rollups {#data-availability-and-layer-2-rollups} +## Disponibilité des données et rollups de couche 2 {#data-availability-and-layer-2-rollups} -[Les solutions d'évolutivité de la couche 2](/layer-2/), telles que les [rollups](/glossary/#rollups), réduisent les coûts de transaction et augmentent le débit d'Ethereum en traitant les transactions hors chaîne. Les transactions de rollup sont compressées et publiées par lots sur Ethereum. Les lots représentent des milliers de transactions individuelles hors chaîne en une seule transaction sur Ethereum. Cela réduit la congestion de la couche de base et réduit les frais pour les utilisateurs. +[Les solutions de mise à l'échelle de couche 2](/layer-2/), telles que les [rollups](/glossary/#rollups), réduisent les coûts de transaction et augmentent le débit d'Ethereum en traitant les transactions hors chaîne. Les transactions de rollup sont compressées et publiées par lots sur Ethereum. Les lots représentent des milliers de transactions individuelles hors chaîne en une seule transaction sur Ethereum. Cela réduit la congestion de la couche de base et réduit les frais pour les utilisateurs. Cependant, il n'est possible de faire confiance aux transactions « résumées » publiées sur Ethereum que si le changement d'état proposé peut être vérifié indépendamment et confirmé comme étant le résultat de l'application de toutes les transactions individuelles hors chaîne. Si les opérateurs de rollup ne rendent pas disponibles les données de transaction pour cette vérification, ils pourraient envoyer des données incorrectes à Ethereum. -[Les rollups optimistes](/developers/docs/scaling/optimistic-rollups/) postent des données de transaction compressées sur Ethereum et attendent un certain temps (typiquement 7 jours) pour permettre aux vérificateurs indépendants de vérifier les données. Si quelqu'un identifie un problème, il peut générer une étanchéité à la fraude et l'utiliser pour défier le rollup. Cela provoquerait l'annulation de la chaîne et l'omission du bloc invalide. Ce n'est pas possible si les données sont manquantes. Actuellement, il existe deux façons pour les rollups optimistes de publier les données de transaction sur la couche de niveau 1. Certains rollups rendent les données disponibles de manière permanente en tant que `CALLDATA`, qui reste en permanence sur la chaîne. Avec l'introduction de l'EIP-4844, certains rollups publient plutôt leurs données de transaction dans un stockage blob moins coûteux. Il ne s'agit pas d'un stockage permanent. Les vérificateurs indépendants doivent interroger les blobs et soulever leurs objections dans un délai d'environ 18 jours avant que les données ne soient supprimées de la couche de niveau 1 d'Ethereum. La disponibilité des données n'est garantie que par le protocole Ethereum pour cette courte fenêtre fixe. Ensuite, cela incombe à d'autres entités de l'écosystème Ethereum. N'importe quel nœud peut vérifier la disponibilité des données en utilisant DAS, c'est-à-dire en téléchargeant de petits échantillons aléatoires des données du blob. +[Les rollups optimistes](/developers/docs/scaling/optimistic-rollups/) publient des données de transaction compressées sur Ethereum et attendent un certain temps (généralement 7 jours) pour permettre à des vérificateurs indépendants de contrôler les données. Si quelqu'un identifie un problème, il peut générer une étanchéité à la fraude et l'utiliser pour défier le rollup. Cela provoquerait l'annulation de la chaîne et l'omission du bloc invalide. Ce n'est pas possible si les données sont manquantes. Actuellement, il existe deux façons pour les rollups optimistes de publier les données de transaction sur la couche de niveau 1. Certains rollups rendent les données disponibles en permanence en tant que `CALLDATA` qui reste en permanence sur la chaîne. Avec l'introduction de l'EIP-4844, certains rollups publient plutôt leurs données de transaction dans un stockage blob moins coûteux. Il ne s'agit pas d'un stockage permanent. Les vérificateurs indépendants doivent interroger les blobs et soulever leurs objections dans un délai d'environ 18 jours avant que les données ne soient supprimées de la couche de niveau 1 d'Ethereum. La disponibilité des données n'est garantie que par le protocole Ethereum pour cette courte fenêtre fixe. Ensuite, cela incombe à d'autres entités de l'écosystème Ethereum. N'importe quel nœud peut vérifier la disponibilité des données en utilisant le DAS, c'est-à-dire en téléchargeant de petits échantillons aléatoires des données blob. -[Les rollups Zero-knowledge (ZK)](/developers/docs/scaling/zk-rollups) ne nécessitent pas de publier de données de transaction car [les preuves de validité de la nulle-connaissance](/glossary/#zk-proof) garantissent l'exactitude des transitions d'état. Cependant, la disponibilité des données reste un problème parce que nous ne pouvons pas garantir la fonctionnalité du ZK-rollup (ou interagir avec elle) sans accès à ses données d'état. Par exemple, les utilisateurs ne peuvent pas connaître leurs soldes si un opérateur retient des détails sur l’état du rollup. De plus, ils ne peuvent pas effectuer de mises à jour d'état en utilisant des informations contenues dans un bloc nouvellement ajouté. +[Les rollups à preuve à divulgation nulle de connaissance (ZK)](/developers/docs/scaling/zk-rollups) n'ont pas besoin de publier des données de transaction, car les [preuves de validité à divulgation nulle de connaissance](/glossary/#zk-proof) garantissent l'exactitude des transitions d'état. Cependant, la disponibilité des données reste un problème parce que nous ne pouvons pas garantir la fonctionnalité du ZK-rollup (ou interagir avec elle) sans accès à ses données d'état. Par exemple, les utilisateurs ne peuvent pas connaître leurs soldes si un opérateur retient des détails sur l’état du rollup. De plus, ils ne peuvent pas effectuer de mises à jour d'état en utilisant des informations contenues dans un bloc nouvellement ajouté. -## Disponibilité des données par rapport à la récupération des données {#data-availability-vs-data-retrievability} +## Disponibilité des données vs récupérabilité des données {#data-availability-vs-data-retrievability} Disponibilité des données par rapport à la récupération des données. La disponibilité des données est l'assurance que des nœuds complets ont été en mesure de vérifier l'ensemble des transactions associées à un bloc spécifique et d'y accéder. Il ne s'ensuit pas nécessairement que les données sont accessibles pour toujours. -La possibilité de récupérer des données est la capacité des nœuds à récupérer _des informations historiques_ de la blockchain. Ces données historiques ne sont pas nécessaires pour vérifier de nouveaux blocs, elles sont seulement requises pour synchroniser des nœuds complets à partir du bloc d'origine ou pour répondre à des requêtes historiques spécifiques. +La récupérabilité des données est la capacité des nœuds à récupérer des _informations historiques_ de la blockchain. Ces données historiques ne sont pas nécessaires pour vérifier de nouveaux blocs, elles sont seulement requises pour synchroniser des nœuds complets à partir du bloc d'origine ou pour répondre à des requêtes historiques spécifiques. -Le protocole Ethereum de base est principalement concerné par la disponibilité des données, et non par la récupération des données. La possibilité de récupérer les données peut être fournie par une petite population de nœuds d'archive exécutés par des tiers, ou une distribution est possible à travers le réseau en utilisant un stockage de fichiers décentralisé tel que le [réseau du portail](https://www.ethportal.net/). +Le protocole Ethereum de base est principalement concerné par la disponibilité des données, et non par la récupération des données. La récupérabilité des données peut être assurée par un petit nombre de nœuds d'archive gérés par des tiers, ou elle peut être répartie sur le réseau à l'aide d'un stockage de fichiers décentralisé tel que le [Réseau Portal](https://www.ethportal.net/). -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Le WTF est-il la disponibilité des données ?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) -- [Qu'est-ce que la disponibilité des données ?](https://coinmarketcap.com/alexandria/article/what-is-data-availability) -- [Un préfixe sur les vérifications de disponibilité des données](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) -- [Une explication de la proposition de fragmentation + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Une note sur la disponibilité des données et le codage de l'effacement](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [WTF is Data Availability?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Qu'est-ce que la disponibilité des données ?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Introduction aux contrôles de disponibilité des données](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Explication de la proposition de sharding + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Note sur la disponibilité des données et le codage à effacement](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) - [Comités de disponibilité des données.](https://medium.com/starkware/data-availability-e5564c416424) -- [Comités de disponibilité des données de preuve d'enjeu.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [Solutions au problème de récupération des données](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) -- [Disponibilité des données ou : Comment les Rollups ont appris à ne plus s'inquiéter et à aimer Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) -- [EIP-7623 - Augmenter le Coût du Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) +- [Comités de disponibilité des données à preuve d'enjeu.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Solutions au problème de la récupérabilité des données](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Data Availability Or: How Rollups Learned To Stop Worrying And Love Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623 : Augmentation du coût des Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/fr/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/fr/developers/docs/data-structures-and-encoding/index.md index 1c15140b107..0733d725504 100644 --- a/public/content/translations/fr/developers/docs/data-structures-and-encoding/index.md +++ b/public/content/translations/fr/developers/docs/data-structures-and-encoding/index.md @@ -1,32 +1,32 @@ --- -title: Structures de données et encodage -description: Un aperçu des structures fondamentales de données Ethereum. +title: "Structures de données et encodage" +description: "Un aperçu des structures fondamentales de données Ethereum." lang: fr sidebarDepth: 2 --- -Ethereum crée, stocke et transfère de grands volumes de données. Ces données doivent être formatées par des moyens standardisés et efficaces en matière de mémoire pour permettre à quiconque [d'exécuter un nœud](/run-a-node/) sur du matériel relativement modeste. Pour cela, plusieurs structures de données spécifiques sont utilisées sur la pile Ethereum. +Ethereum crée, stocke et transfère de grands volumes de données. Ces données doivent être formatées de manière standardisée et économe en mémoire pour permettre à quiconque d'[exécuter un nœud](/run-a-node/) sur du matériel grand public relativement modeste. Pour cela, plusieurs structures de données spécifiques sont utilisées sur la pile Ethereum. ## Prérequis {#prerequisites} -Vous devriez d'abord maitriser les fondamentaux d'Ethereum et notamment du [logiciel client](/developers/docs/nodes-and-clients/). Il est recommandé de vous familiariser avec la couche réseau et [le livre blanc Ethereum](/whitepaper/). +Vous devriez comprendre les fondamentaux d'Ethereum et les [logiciels clients](/developers/docs/nodes-and-clients/). Il est recommandé de vous familiariser avec la couche réseau et [le livre blanc d'Ethereum](/whitepaper/). -## Structures des données {#data-structures} +## Structures de données {#data-structures} -### Arbre de Merkle Patricia {#patricia-merkle-tries} +### Arbres de Merkle Patricia {#patricia-merkle-tries} Les arbres de Merkle Patricia sont des structures qui permettent d'encoder des paires clé-valeur dans un arbre déterministe et authentifié cryptographiquement. Ils sont largement utilisés dans la couche d'exécution d'Ethereum. [En savoir plus sur les arbres de Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) -### Préfixe de longueur récursive (RLP) {#recursive-length-prefix} +### Préfixe de longueur récursive {#recursive-length-prefix} Le préfixe de longueur récursive (RLP) est une méthode de sérialisation largement utilisée à travers la couche d'exécution d'Ethereum. -[En savoir plus sur le RLP](/developers/docs/data-structures-and-encoding/rlp) +[En savoir plus sur RLP](/developers/docs/data-structures-and-encoding/rlp) -### Sérialisation simple (Simple Serialize) {#simple-serialize} +### Sérialisation simple {#simple-serialize} La sérialisation simple (Simple Serialize, ou SSZ) est le format de sérialisation dominant sur la couche de consensus d'Ethereum en raison de sa compatibilité avec la merklelization. -[En savoir plus sur la SSZ](/developers/docs/data-structures-and-encoding/ssz) +[En savoir plus sur SSZ](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index fe93186638a..83c2f9c325b 100644 --- a/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -1,23 +1,23 @@ --- title: Arbre de Merkle Patricia -description: Introduction à l'Arbre de Merkle Patricia +description: "Introduction à l'Arbre de Merkle Patricia" lang: fr sidebarDepth: 2 --- -L'état d'Ethereum (l'ensemble des comptes, des soldes et des contrats intelligents) est codé dans une version spéciale de la structure de données couramment connue en informatique sous le nom d'arbre de Merkle. Cette structure est utile pour de nombreuses applications en cryptographie, car elle crée une relation vérifiable entre toutes les pièces de données individuelles entrelacées dans l'arbre, aboutissant à une seule valeur **racine** qui peut être utilisée pour prouver des éléments relatifs aux données. +L'état d'Ethereum (l'ensemble des comptes, des soldes et des contrats intelligents) est codé dans une version spéciale de la structure de données couramment connue en informatique sous le nom d'arbre de Merkle. Cette structure est utile pour de nombreuses applications en cryptographie, car elle crée une relation vérifiable entre toutes les données individuelles entrelacées dans l'arbre, ce qui aboutit à une seule valeur **racine** qui peut être utilisée pour prouver des éléments concernant les données. -La structure de données d'Ethereum est un arbre de Patricia Merkle modifié, nommé ainsi parce qu'il emprunte certaines caractéristiques de PATRICIA (ou Practical Algorithm To Retrieve Information Coded in Alphanumeric), et parce qu'il est conçu pour récupérer efficacement les données (re**trie**val) des éléments qui composent l'état Ethereum. +La structure de données d'Ethereum est un « Arbre de Merkle-Patricia modifié », ainsi nommé car il emprunte certaines fonctionnalités de PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) et parce qu'il est conçu pour une récupération efficace des données (re**trie**val) des éléments qui composent l'état d'Ethereum. -Un arbre de Patricia Merkle est déterministe et cryptographiquement vérifiable : la seule façon de générer une racine d'état est de la calculer à partir de chaque morceau individuel de l'état, et deux états qui sont identiques peuvent être facilement prouvés en comparant le hash de racine et les hashes qui y ont conduit (_a Merkle proof_). Inversement, il n'est pas possible de créer deux états différents avec le même hachage de racine, et toute tentative de modifier l'état avec différentes valeurs donnera lieu à un hachage de racine d'état différent. Théoriquement, cette structure fournit le sacré Graal de l'efficacité `O(log(n))` pour les inserts, les recherches et les suppressions. +Un arbre de Merkle-Patricia est déterministe et cryptographiquement vérifiable : la seule façon de générer une racine d'état est de la calculer à partir de chaque élément individuel de l'état, et deux états identiques peuvent être facilement prouvés comme tels en comparant le hachage racine et les hachages qui y ont conduit (_une preuve de Merkle_). Inversement, il n'est pas possible de créer deux états différents avec le même hachage de racine, et toute tentative de modifier l'état avec différentes valeurs donnera lieu à un hachage de racine d'état différent. Théoriquement, cette structure fournit le « Saint Graal » de l'efficacité `O(log(n))` pour les insertions, les recherches et les suppressions. Dans un avenir proche, Ethereum prévoit de migrer vers une structure en [arbre de Verkle](/roadmap/verkle-trees), ce qui ouvrira de nombreuses possibilités d'amélioration du protocole. ## Prérequis {#prerequisites} -Pour mieux comprendre cette page, il serait utile d'avoir des connaissances de base sur les [hachages](https://en.wikipedia.org/wiki/Hash_function), les [arbres de Merkle](https://en.wikipedia.org/wiki/Merkle_tree), les [arbres](https://en.wikipedia.org/wiki/Trie) et la [sérialisation](https://en.wikipedia.org/wiki/Serialization). Cet article commence par une description d'un [arbre radix](https://en.wikipedia.org/wiki/Radix_tree) de base, puis introduit progressivement les modifications nécessaires pour la construction d'une structure de données plus optimisée d'Ethereum. +Pour mieux comprendre cette page, il serait utile d'avoir des connaissances de base sur les [hachages](https://en.wikipedia.org/wiki/Hash_function), les [arbres de Merkle](https://en.wikipedia.org/wiki/Merkle_tree), les [tries](https://en.wikipedia.org/wiki/Trie) et la [sérialisation](https://en.wikipedia.org/wiki/Serialization). Cet article commence par une description d'un [arbre radix](https://en.wikipedia.org/wiki/Radix_tree) de base, puis introduit progressivement les modifications nécessaires à la structure de données plus optimisée d'Ethereum. -## Arbres radix de base {#basic-radix-tries} +## Tries radix de base {#basic-radix-tries} Dans un arbre radix de base, chaque nœud se présente comme suit : @@ -25,19 +25,19 @@ Dans un arbre radix de base, chaque nœud se présente comme suit : [i_0, i_1 ... i_n, value] ``` -Là où `i0 ... in` représentent les symboles de l'alphabet (souvent binaires ou hexagonaux), `value` est la valeur terminale du nœud, et les valeurs dans les créneaux `i0 ... in` sont soit `NULL` soit des pointeurs vers (dans notre cas, des hashs) d'autres nœuds. Cela forme un registre de base `(key, value)`. +Où `i_0 ...` i_n`représentent les symboles de l'alphabet (souvent binaire ou hexadécimal),`value`est la valeur terminale au niveau du nœud, et les valeurs dans les`i_0, i_1 ...`créneaux`i_n`sont soit`NULL`, soit des pointeurs vers (dans notre cas, des hachages) d'autres nœuds. Ceci forme un magasin `(clé, valeur)` de base. -Supposons que vous souhaitiez utiliser une structure de données d'arborescence radix pour maintenir une commande sur un ensemble de paires de valeurs clés. Pour connaître la valeur actuellement associée à `dog` dans le tableau, vous devriez d'abord convertir `dog` en lettres de l'alphabet (ce qui donne `64 6f 67`), puis descendre dans l'arbre en suivant ce chemin jusqu'à ce que vous trouviez la valeur. C'est-à-dire que vous commencez par chercher le hachage racine dans une base de données/valeur plate pour trouver le nœud racine de l'arbre. Il se présente sous la forme d'un tableau de clés pointant vers d'autres nœuds. Vous utilisez ensuite la valeur à l'index `6` comme clé et la recherchez dans la base de données clé/valeur pour obtenir le nœud un niveau plus bas. Ensuite, choisissez l'index `4` pour rechercher la valeur suivante, puis choisissez l'index `6`, et ainsi de suite, jusqu'à ce que, une fois suivi le chemin : `racine -> -> -> 6 - > 6 -> 15 -> 6 -> 7`, vous cherchiez la valeur du nœud et retourniez le résultat. +Supposons que vous souhaitiez utiliser une structure de données d'arborescence radix pour maintenir une commande sur un ensemble de paires de valeurs clés. Pour trouver la valeur actuellement mappée à la clé `dog` dans le trie, vous devez d'abord convertir `dog` en lettres de l'alphabet (ce qui donne `64 6f 67`), puis descendre dans le trie en suivant ce chemin jusqu'à trouver la valeur. C'est-à-dire que vous commencez par chercher le hachage racine dans une base de données/valeur plate pour trouver le nœud racine de l'arbre. Il se présente sous la forme d'un tableau de clés pointant vers d'autres nœuds. Vous utiliseriez la valeur à l'index `6` comme clé et la rechercheriez dans la base de données clé/valeur plate pour obtenir le nœud un niveau plus bas. Ensuite, choisissez l'index `4` pour rechercher la valeur suivante, puis l'index `6`, et ainsi de suite. Une fois le chemin suivi : `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, vous rechercherez la valeur du nœud et renverrez le résultat. Il y a une différence entre rechercher quelque chose dans l'"arbre" et la "base de données" plate sous-jacente (clé/valeur). Ils définissent tous deux des combinaisons clé/valeur, mais la base de données sous-jacente peut rechercher une clé en une seule étape basique. La recherche d'une clé dans le tableau nécessite plusieurs consultations de la base de données sous-jacente pour obtenir la valeur finale décrite ci-dessus. Faisons référence à ce dernier comme à un `path` (chemin) pour éliminer toute ambiguïté. Les opérations de mise à jour et de suppression pour les arbres radix peuvent être définies comme suit : -``` +```python def update(node_hash, path, value): - curnode = db.get(node_hash) if node_hash else [ NULL ] * 17 + curnode = db.get(node_hash) if node_hash else [NULL] * 17 newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = value else: newindex = update(curnode[path[0]], path[1:], value) @@ -51,7 +51,7 @@ Les opérations de mise à jour et de suppression pour les arbres radix peuvent else: curnode = db.get(node_hash) newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = NULL else: newindex = delete(curnode[path[0]], path[1:]) @@ -64,107 +64,110 @@ Les opérations de mise à jour et de suppression pour les arbres radix peuvent return hash(newnode) ``` -Un arbre Radix « Merkle» est construit en reliant les nœuds à l'aide des diagrammes de hachage cryptographiques générés de manière déterministe. Cette adresse de contenu (dans la base de données clé/valeur `key == keccak256(rlp(value))`) fournit une garantie d'intégrité cryptographique des données stockées. Si le hash racine d'un arbre donné est connu publiquement, alors tout le monde ayant accès à cette feuille peut fournir une preuve que l'arbre inclut une valeur donnée à un endroit spécifique, en fournissant les hachages de chaque nœud reliant une valeur spécifique à la racine de l'arborescence. +Un arbre Radix « Merkle» est construit en reliant les nœuds à l'aide des diagrammes de hachage cryptographiques générés de manière déterministe. Cet adressage de contenu (dans la base de données clé/valeur `key == keccak256(rlp(value))`) fournit une garantie d'intégrité cryptographique des données stockées. Si le hash racine d'un arbre donné est connu publiquement, alors tout le monde ayant accès à cette feuille peut fournir une preuve que l'arbre inclut une valeur donnée à un endroit spécifique, en fournissant les hachages de chaque nœud reliant une valeur spécifique à la racine de l'arborescence. -Il est impossible pour un attaquant de fournir une preuve d'une paire de `(path, value)` qui n'existe pas car le hachage racine est basé en fin de compte sur tous les hachages situés au-dessous. Toute modification sous-jacente modifierait le hash racine. Vous pouvez considérer le hash comme une représentation compressée des informations structurelles sur les données, sécurisée par la protection de pré-image de la fonction de hachage. +Il est impossible pour un attaquant de fournir une preuve d'une paire `(path, value)` qui n'existe pas, car le hachage racine est en fin de compte basé sur tous les hachages en dessous de lui. Toute modification sous-jacente modifierait le hash racine. Vous pouvez considérer le hash comme une représentation compressée des informations structurelles sur les données, sécurisée par la protection de pré-image de la fonction de hachage. -Nous allons faire référence à une unité atomique d'un arbre radix (par exemple un seul caractère hexadécimal, ou un nombre binaire de 4 bits) en tant que "nibble". Lorsque l'on parcourt un chemin un nibble à la fois, comme décrit ci-dessus, les nœuds peuvent faire référence à 16 enfants au maximum, mais peuvent également inclure un élément `value`. Nous les représentons donc comme un tableau de longueur 17. Nous appelons ces tableaux à 17 éléments des "nœuds de branches". +Nous désignerons une unité atomique d'un arbre radix (p. ex. un seul caractère hexadécimal ou un nombre binaire de 4 bits) par le terme "nibble". En parcourant un chemin un nibble à la fois, comme décrit ci-dessus, les nœuds peuvent au maximum faire référence à 16 enfants, mais ils incluent un élément `value`. Nous les représentons donc comme un tableau de longueur 17. Nous appelons ces tableaux à 17 éléments des "nœuds de branches". -## Arbre de Merkle de Patricia {#merkle-patricia-trees} +## Trie de Merkle-Patricia {#merkle-patricia-trees} -Cependant, les arbres radix ont une limitation majeure : ils sont inefficaces. Si vous voulez stocker une seule liaison `(path, value)` où le chemin est, comme dans Ethereum, long de 64 caractères (nombre de nibbles dans `bytes32`), vous aurez besoin de plus d'un kilooctet d'espace supplémentaire pour stocker un niveau par caractère, et chaque consultation ou suppression prendra les 64 étapes complètes. L'arbre de Patricia présenté dans ce qui suit résout ce problème. +Cependant, les arbres radix ont une limitation majeure : ils sont inefficaces. Si vous voulez stocker une seule liaison `(path, value)` où le chemin, comme dans Ethereum, est long de 64 caractères (le nombre de nibbles dans `bytes32`), vous aurez besoin de plus d'un kilooctet d'espace supplémentaire pour stocker un niveau par caractère, et chaque consultation ou suppression prendra les 64 étapes complètes. L'arbre de Patricia présenté dans ce qui suit résout ce problème. ### Optimisation {#optimization} Un nœud dans un arbre de Merkle Patricia correspond à l'un des éléments suivants : -1. `NULL` (représenté comme une chaîne vide) -2. `branch` Un nœud de 17 éléments `[ v0 ... v15, vt ]` -3. `leaf` Un nœud de 2 éléments `[ encodedPath, value ]` -4. `extension` Un nœud de 2 éléments `[ encodedPath, key ]` +1. `NULL` (représenté par la chaîne vide) +2. `branche` Un nœud de 17 éléments `[ v0 ...` v15, vt ]` +3. `feuille` Un nœud de 2 éléments `[ encodedPath, value ]` +4. `extension` Un nœud de 2 éléments `[ encodedPath, key ]` -Avec 64 chemins de caractères, il est inévitable qu'après avoir traversé les premières couches de l'arbre, vous atteigniez un nœud où aucun chemin divergent n'existe sur au moins une partie de la descente. Pour éviter de devoir créer jusqu'à 15 nœuds `NULL` épars le long du chemin, nous raccourcissons la descente en créant un nœud `extension` de la forme `[ encodedPath, key ]`, où `encodedPath` contient le "chemin partiel" à sauter (à l'aide d'un codage compact décrit ci-dessous), et où la `key` est destinée à la consultation suivante de la base de données. +Avec 64 chemins de caractères, il est inévitable qu'après avoir traversé les premières couches de l'arbre, vous atteigniez un nœud où aucun chemin divergent n'existe sur au moins une partie de la descente. Pour éviter d'avoir à créer jusqu'à 15 nœuds `NULL` épars le long du chemin, nous raccourcissons la descente en créant un nœud `extension` de la forme `[ encodedPath, key ]`, où `encodedPath` contient le "chemin partiel" à sauter (en utilisant un encodage compact décrit ci-dessous), et où la `key` est pour la prochaine consultation de la base de données. -Pour un nœud `feuille`, qui peut être marqué par un drapeau dans la première pièce du `encodedPath`, le chemin encode tous les fragments de chemin du nœud précédent et nous pouvons consulter la `valeur` directement. +Pour un nœud `leaf`, qui peut être marqué par un indicateur dans le premier nibble de l'`encodedPath`, le chemin encode tous les fragments de chemin du nœud précédent et nous pouvons consulter la `value` directement. Cette optimisation introduit toutefois une ambiguïté. -Lors de la traversée de chemins en nibbles, nous pourrions nous retrouver avec un nombre impair de nibbles à traverser, mais comme toutes les données sont stockées au format `bytes`, il est possible que le nombre de nibbles à parcourir soit impair. Il n'est pas possible de différencier entre, par exemple, le nibble `1`, et les nibbles `01` (les deux doivent être stockés sous la forme `<01>`). Pour spécifier une longueur impaire, le chemin partiel est précédé d'un drapeau. +En parcourant les chemins par nibbles, on peut se retrouver avec un nombre impair de nibbles à parcourir, mais comme toutes les données sont stockées au format `bytes`. Il n'est pas possible de différencier, par exemple, le nibble `1` des nibbles `01` (tous deux doivent être stockés sous la forme `<01>`). Pour spécifier une longueur impaire, le chemin partiel est précédé d'un drapeau. -### Spécification : Codage compact d'une séquence hexagonale avec terminateur optionnel {#specification} +### Spécification : Encodage compact de séquence hexadécimale avec terminateur optionnel {#specification} -Le marquage de la _longueur du chemin partiel restante impaire ou paire_ et de la _feuille ou nœud d'extension_, tel que décrit ci-dessus, se trouve dans le premier élément du chemin partiel de tout nœud à deux éléments. Cela se traduit comme suit : +Le marquage de la _longueur impaire ou paire du chemin partiel restant_ et du _nœud feuille ou extension_, tel que décrit ci-dessus, se trouve dans le premier nibble du chemin partiel de tout nœud à 2 éléments. Cela se traduit comme suit : - hex char bits | node type partial path length - ---------------------------------------------------------- - 0 0000 | extension even - 1 0001 | extension odd - 2 0010 | terminating (leaf) even - 3 0011 | terminating (leaf) odd +| char hex | bits | type partiel de nœud | longueur de chemin | +| -------- | ---- | ------------------------------------- | ------------------ | +| 0 | 0000 | extension | pairs | +| 1 | 0001 | extension | impair | +| 2 | 0010 | terminal (feuille) | pairs | +| 3 | 0011 | terminal (feuille) | impair | -Pour une longueur de chemin restante paire (`0` ou `2`), un autre nibble de "remplissage" de `0` suivra toujours. +Pour une longueur de chemin restante paire (`0` ou `2`), un autre nibble de « remplissage » `0` suivra toujours. -``` +```python def compact_encode(hexarray): term = 1 if hexarray[-1] == 16 else 0 - if term: hexarray = hexarray[:-1] + if term: + hexarray = hexarray[:-1] oddlen = len(hexarray) % 2 flags = 2 * term + oddlen if oddlen: hexarray = [flags] + hexarray else: hexarray = [flags] + [0] + hexarray - // hexarray now has an even length whose first nibble is the flags. - o = '' - for i in range(0,len(hexarray),2): - o += chr(16 * hexarray[i] + hexarray[i+1]) + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) return o ``` Exemples : -``` - > [ 1, 2, 3, 4, 5, ...] +```python + > [1, 2, 3, 4, 5, ...] '11 23 45' - > [ 0, 1, 2, 3, 4, 5, ...] + > [0, 1, 2, 3, 4, 5, ...] '00 01 23 45' - > [ 0, f, 1, c, b, 8, 10] + > [0, f, 1, c, b, 8, 10] '20 0f 1c b8' - > [ f, 1, c, b, 8, 10] + > [f, 1, c, b, 8, 10] '3f 1c b8' ``` Voici le code étendu pour obtenir un nœud dans l'arbre de Merkle Patricia : -``` - def get_helper(node_hash,path): - if path == []: return node_hash - if node_hash == '': return '' +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) if len(curnode) == 2: (k2, v2) = curnode k2 = compact_decode(k2) - if k2 == path[:len(k2)]: - return get(v2, path[len(k2):]) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) else: - return '' + return "" elif len(curnode) == 17: - return get_helper(curnode[path[0]],path[1:]) + return get_helper(curnode[path[0]], path[1:]) - def get(node_hash,path): + def get(node_hash, path): path2 = [] for i in range(len(path)): path2.push(int(ord(path[i]) / 16)) path2.push(ord(path[i]) % 16) path2.push(16) - return get_helper(node_hash,path2) + return get_helper(node_hash, path2) ``` -### Exemple d'arbre {#example-trie} +### Exemple de trie {#example-trie} -Supposons que nous voulions un tableau contenant quatre paires chemin/valeur `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. +Supposons que nous voulions un trie contenant quatre paires chemin/valeur `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. -Tout d'abord, nous convertissons les chemins et les valeurs en `bytes` (octets). Ci-dessous, les représentations réelles d'octets pour les _chemins_ sont désignées par `<>`, bien que les _valeurs_ soient toujours représentées sous forme de chaînes, désignées par `''`, pour une compréhension plus facile (elles aussi seraient en fait des `octets`) : +Tout d'abord, nous convertissons les chemins et les valeurs en `bytes`. Ci-dessous, les représentations d'octets réelles pour les _chemins_ sont indiquées par `<>`, bien que les _valeurs_ soient toujours affichées sous forme de chaînes, indiquées par `''`, pour une meilleure compréhension (elles aussi seraient en fait des `bytes`) : ``` <64 6f> : 'verb' @@ -183,38 +186,38 @@ Nous construisons un tel arbre avec les paires clé/valeur suivantes dans la bas hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] ``` -Lorsqu'un nœud est référencé à l'intérieur d'un autre nœud, ce qui est inclus est `H(rlp.encode(node))`, où `H(x) = keccak256(x) if len(x) >= 32 else x` et `rlp.encode` est la fonction d'encodage [RLP](/developers/docs/data-structures-and-encoding/rlp). +Lorsqu'un nœud est référencé à l'intérieur d'un autre nœud, ce qui est inclus est `keccak256(rlp.encode(node))`, si `len(rlp.encode(node)) >= 32` sinon `node` où `rlp.encode` est la fonction d'encodage [RLP](/developers/docs/data-structures-and-encoding/rlp). -Notez que lors de la mise à jour d'un arbre, on doit stocker la paire clé/valeur `(keccak256(x), x)`dans une table de consultation persistante _si_ le nœud nouvellement créé a une longueur >= 32. Toutefois, si le nœud est plus court que cela, il n'est pas nécessaire de stocker quoi que ce soit, puisque la fonction f(x) = x est réversible. +Notez que lors de la mise à jour d'un trie, il faut stocker la paire clé/valeur `(keccak256(x), x)` dans une table de recherche persistante _si_ le nœud nouvellement créé a une longueur >= 32. Toutefois, si le nœud est plus court que cela, il n'est pas nécessaire de stocker quoi que ce soit, puisque la fonction f(x) = x est réversible. -## Les arbres sur Ethereum {#tries-in-ethereum} +## Tries dans Ethereum {#tries-in-ethereum} Tous les arbres Merkle dans la couche d'exécution d'Ethereum font appel à un arbre de Merkle Patricia. L'en-tête d'un bloc comporte trois racines issues de trois de ces arbres. -1. stateRoot -2. transactionsRoot -3. receiptsRoot +1. stateRoot +2. transactionsRoot +3. receiptsRoot -### Arbre d'état {#state-trie} +### Trie d'état {#state-trie} -Il n'existe qu'un seul arbre d'état global, qui est mis à jour à chaque fois qu'un client traite un bloc. Dans celui-ci, un `path` est toujours : `keccak256(ethereumAddress)` et une `value` est toujours : `rlp(ethereumAccount)`. Plus précisément, un `account` ethereum est un tableau de 4 éléments de `[nonce,balance,storageRoot,codeHash]`. À ce stade, il convient de noter que ce `storageRoot` est la racine d'un autre arbre Patricia : +Il n'existe qu'un seul arbre d'état global, qui est mis à jour à chaque fois qu'un client traite un bloc. Dans celui-ci, un `path` est toujours : `keccak256(ethereumAddress)` et une `value` est toujours : `rlp(ethereumAccount)`. Plus précisément, un `account` Ethereum est un tableau de 4 éléments de `[nonce,solde,storageRoot,codeHash]`. À ce stade, il convient de noter que ce `storageRoot` est la racine d'un autre trie de Patricia : -### Arbre de stockage {#storage-trie} +### Trie de stockage {#storage-trie} -C'est dans l'arbre de stockage que se situent _toutes_ les données du contrat. Chaque compte dispose d'un arbre de stockage distinct. Pour récupérer des valeurs à des positions de stockage spécifiques et à une adresse donnée, l'adresse de stockage, la position entière des données stockées dans le stockage et l'ID du bloc sont nécessaires. Ceux-ci peuvent ensuite être transmis comme arguments à la fonction `eth_getStorageAt` définie dans l'API JSON-RPC, par exemple pour récupérer les données dans le créneau de stockage 0 pour l'adresse `0x295a70b2de5e3953354a6a8344e616ed314d7251` : +Le trie de stockage est l'endroit où se trouvent _toutes_ les données de contrat. Chaque compte dispose d'un arbre de stockage distinct. Pour récupérer des valeurs à des positions de stockage spécifiques et à une adresse donnée, l'adresse de stockage, la position entière des données stockées dans le stockage et l'ID du bloc sont nécessaires. Ceux-ci peuvent ensuite être transmis comme arguments à la fonction `eth_getStorageAt` définie dans l'API JSON-RPC, par exemple pour récupérer les données dans le créneau de stockage 0 pour l'adresse `0x295a70b2de5e3953354a6a8344e616ed314d7251` : -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} ``` -La récupération d'autres éléments dans le stockage est un peu plus complexe, car il faut d'abord calculer la position dans l'arbre de stockage. La position est calculée comme le hachage `keccak256` de l'adresse et de la position de stockage, toutes deux complétées à gauche par des zéros jusqu'à une longueur de 32 octets. Par exemple, la position des données dans l'emplacement de stockage 1 pour l'adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298` est : +La récupération d'autres éléments dans le stockage est un peu plus complexe, car il faut d'abord calculer la position dans l'arbre de stockage. La position est calculée comme le hachage `keccak256` de l'adresse et de la position de stockage, tous deux complétés à gauche par des zéros jusqu'à une longueur de 32 octets. Par exemple, la position des données dans le créneau de stockage 1 pour l'adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298` est : -``` +```python keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) ``` @@ -229,35 +232,35 @@ undefined Le `path` est donc `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. On peut maintenant l'utiliser pour récupérer les données de l'arbre de stockage comme précédemment : -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} ``` -Note : le `storageRoot` pour un compte Ethereum est vide par défaut s'il ne s'agit pas d'un compte de contrat. +Remarque : le `storageRoot` d'un compte Ethereum est vide par défaut s'il ne s'agit pas d'un compte de contrat. -### Arbre de transactions {#transaction-trie} +### Trie de transactions {#transaction-trie} -Il existe un arbre de transactions distinct pour chaque bloc, qui stocke à nouveau les paires `(key, value)` . Un chemin ici est : `rlp(transactionIndex)` qui représente la clé qui correspond à une valeur déterminée par : +Il existe un trie de transactions distinct pour chaque bloc, qui stocke à nouveau des paires `(clé, valeur)`. Ici, un chemin est : `rlp(transactionIndex)`, qui représente la clé correspondant à une valeur déterminée par : -``` +```python if legacyTx: value = rlp(tx) else: value = TxType | encode(tx) ``` -Plus d'informations à ce sujet peuvent être trouvées dans la documentation [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). +De plus amples informations à ce sujet peuvent être trouvées dans la documentation de l'[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). -### Arbre de reçus {#receipts-trie} +### Trie des reçus {#receipts-trie} -Chaque bloc a son propre arbre de reçus. Un `path` ici est : `rlp(transactionIndex)`. `transactionIndex` est son indice dans le bloc dans lequel il est inclus. Les arbres de reçus ne sont jamais mis à jour. De la même manière que pour les arbres de transactions, il existe des reçus actuels et des reçus hérités. Pour interroger un reçu spécifique dans la liste des reçus, l'indice de la transaction dans son bloc, les charges du reçu et le type de transaction sont nécessaires. Le reçu retourné peut être de type `Reçu` qui est défini comme la concaténation de `TransactionType` et `ReceiptPayload` ou il peut être de type `LegacyReceipt` qui est défini comme `rlp([statut, cumulativeGasUsed, logsBloom, logs])`. +Chaque bloc a son propre arbre de reçus. Un `path` ici est : `rlp(transactionIndex)`. `transactionIndex` est son indice dans le bloc où il a été inclus. Les arbres de reçus ne sont jamais mis à jour. De la même manière que pour les arbres de transactions, il existe des reçus actuels et des reçus hérités. Pour interroger un reçu spécifique dans la liste des reçus, l'indice de la transaction dans son bloc, les charges du reçu et le type de transaction sont nécessaires. Le reçu retourné peut être de type `Receipt`, qui est défini comme la concaténation de `TransactionType` et `ReceiptPayload` ou il peut être de type `LegacyReceipt` qui est défini comme `rlp([status, cumulativeGasUsed, logsBloom, logs])`. -Plus d'informations à ce sujet peuvent être trouvées dans la documentation [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). +De plus amples informations à ce sujet peuvent être trouvées dans la documentation de l'[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Modification de l'arbre de Merkle Patricia — Comment Ethereum sauvegarde un état](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) -- [Le Merkling sur Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) -- [Comprendre l'arbre Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) +- [Modified Merkle Patricia Trie — Comment Ethereum sauvegarde un état](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Le Merkling dans Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Comprendre le trie d'Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/fr/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/fr/developers/docs/data-structures-and-encoding/rlp/index.md index 863e915fb81..763e7748388 100644 --- a/public/content/translations/fr/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/translations/fr/developers/docs/data-structures-and-encoding/rlp/index.md @@ -1,24 +1,24 @@ --- -title: Sérialisation du préfixe de longueur récursive (RLP) -description: Une définition de l'encodage rlp dans la couche d'exécution d'Ethereum. +title: "Sérialisation du préfixe de longueur récursive (RLP)" +description: "Une définition de l'encodage rlp dans la couche d'exécution d'Ethereum." lang: fr sidebarDepth: 2 --- -La sérialisation Recursive Length Prefix (RLP) est largement utilisée dans les clients d'exécution d'Ethereum. RLP normalise le transfert de données entre les nœuds dans un format peu encombrant. L'objectif de RLP est d'encoder des tableaux de données binaires arbitrairement imbriqués. RLP est la principale méthode d'encodage utilisée pour sérialiser les objets dans la couche d'exécution d'Ethereum. L'objectif principal du RLP est d'encoder la structure ; à l'exception des entiers positifs, le RLP délègue l'encodage de types de données spécifiques (par exemple, les chaînes, les flottants) à des protocoles d'ordre supérieur. Les nombres entiers positifs doivent être représentés sous forme binaire big-endian sans zéros initiaux (ce qui rend la valeur entière zéro équivalente à un tableau d'octets vide). Les entiers positifs désérialisés avec des zéros en tête doivent être traités comme invalides par tout protocole d'ordre supérieur utilisant RLP. +La sérialisation Recursive Length Prefix (RLP) est largement utilisée dans les clients d'exécution d'Ethereum. RLP normalise le transfert de données entre les nœuds dans un format peu encombrant. L'objectif de RLP est d'encoder des tableaux de données binaires arbitrairement imbriqués. RLP est la principale méthode d'encodage utilisée pour sérialiser les objets dans la couche d'exécution d'Ethereum. L'objectif principal du RLP est d'encoder la structure ; à l'exception des entiers positifs, le RLP délègue l'encodage de types de données spécifiques (par ex., les chaînes, les flottants) à des protocoles d'ordre supérieur. Les nombres entiers positifs doivent être représentés sous forme binaire big-endian sans zéros initiaux (ce qui rend la valeur entière zéro équivalente à un tableau d'octets vide). Les entiers positifs désérialisés avec des zéros en tête doivent être traités comme invalides par tout protocole d'ordre supérieur utilisant RLP. -Plus d'informations dans [le livre jaune Ethereum (Annexe B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). +Plus d'informations dans [le papier jaune d'Ethereum (Annexe B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). Pour utiliser RLP afin d'encoder un dictionnaire, les deux formes canoniques suggérées sont : -- utiliser `[[k1,v1],[k2,v2]...]` avec des clés rangées en ordre lexicographique +- utilisez `[[k1,v1],[k2,v2]...]` avec les clés par ordre lexicographique - utiliser l'encodage Patricia Tree de haut niveau comme le fait Ethereum ## Définition {#definition} La fonction d'encodage RLP prend en charge un item. Un item est défini comme suit： -- une chaîne (c'est-à-dire un tableau d'octets) est un item +- une chaîne (c.-à-d. un tableau d'octets) est un élément - une liste d'items est un item - un nombre entier positif est un item @@ -27,7 +27,7 @@ Par exemple, tous les éléments suivants sont des items : - une chaîne vide ; - la chaîne contenant le mot "cat" ; - une liste contenant un nombre quelconque de chaînes ; -- et une structure de données plus complexe comme `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- et des structures de données plus complexes comme `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. - le nombre `100` Notez que dans le contexte du reste de cette page, "chaîne" signifie "un certain nombre d'octets de données binaires" ; aucun codage spécial n'est utilisé et aucune connaissance du contenu des chaînes n'est impliquée (à l'exception de la règle contre les nombres entiers positifs non minimaux). @@ -35,12 +35,12 @@ Notez que dans le contexte du reste de cette page, "chaîne" signifie "un certai L'encodage RLP est défini comme suit : - Pour un entier positif, il est converti en tableau d'octets le plus court dont l'interprétation big-endian est l'entier, puis encodé en tant que chaîne de caractères selon les règles ci-dessous. -- Pour un seul octet dont la valeur se situe dans la plage `[0x00, 0x7f]` (décimal `[0, 127]`), cet octet est son propre codage RLP. -- Sinon, si une chaîne a une longueur de 0 à 55 octets, le codage RLP consiste en un seul octet de valeur **0x80** (déc. 128) plus la longueur de la chaîne, suivi de la chaîne. La plage du premier octet est donc `[0x80, 0xb7]` (déc. `[128, 183]`). -- Si une chaîne de caractères a une longueur de plus de 55 octets, le codage RLP consiste en un seul octet ayant la valeur **0xb7** (déc. 183) plus la longueur en octets de la longueur de la chaîne de caractères sous forme binaire, suivie de la longueur de la chaîne de caractères, suivie de la chaîne de caractères. Par exemple, une chaîne de 1024 octets de long sera codée sous la forme `\xb9\x04\x00` (déc. `185, 4, 0`) suivie de la chaîne. Ici, `0xb9` (183 + 2 = 185) comme premier octet, suivi des 2 octets `0x0400` (déc. 1024) qui indiquent la longueur de la chaîne réelle. La plage du premier octet est donc `[0xb8, 0xbf]` (déc. `[184, 191]`). +- Pour un seul octet dont la valeur se situe dans l'intervalle `[0x00, 0x7f]` (décimal `[0, 127]`), cet octet est son propre codage RLP. +- Sinon, si une chaîne a une longueur de 0 à 55 octets, le codage RLP consiste en un seul octet de valeur **0x80** (déc. 128) plus la longueur de la chaîne, suivi de la chaîne. L'intervalle du premier octet est donc `[0x80, 0xb7]` (déc. `[128, 183]`). +- Si une chaîne est plus longue que 55 octets, le codage RLP consiste en un seul octet de valeur **0xb7** (déc. 183) plus la longueur en octets de la longueur de la chaîne sous forme binaire, suivi de la longueur de la chaîne, puis de la chaîne elle-même. Par exemple, une chaîne de 1024 octets de long serait encodée en `\xb9\x04\x00` (déc. `185, 4, 0`) suivi de la chaîne. Ici, `0xb9` (183 + 2 = 185) est le premier octet, suivi des 2 octets `0x0400` (déc. 1024) qui indiquent la longueur de la chaîne réelle. L'intervalle du premier octet est donc `[0xb8, 0xbf]` (déc. `[184, 191]`). - Si une chaîne de caractères a une longueur de 2^64 octets ou plus, elle ne peut pas être encodée. -- Si la charge utile totale d'une liste (c'est-à-dire la longueur combinée de tous ses éléments codés RLP) est de 0 à 55 octets, le codage RLP consiste en un seul octet de valeur **0xc0** plus la longueur de la charge utile, suivi de la concaténation des codages RLP des éléments. La plage du premier octet est donc `[0xc0, 0xf7]` (déc. `[192, 247]`). -- Si la charge utile totale d'une liste est supérieure à 55 octets, le codage RLP consiste en un seul octet ayant la valeur **0xf7** plus la longueur en octets de la charge utile sous forme binaire, suivie de la longueur de la charge utile, suivie de la concaténation des codages RLP des éléments. La plage du premier octet est donc `[0xf8, 0xff]` (déc. `[248, 255]`). +- Si la charge utile totale d'une liste (c.-à-d. la longueur combinée de tous ses éléments encodés en RLP) est comprise entre 0 et 55 octets, le codage RLP consiste en un seul octet de valeur **0xc0** plus la longueur de la charge utile, suivi de la concaténation des encodages RLP des éléments. L'intervalle du premier octet est donc `[0xc0, 0xf7]` (déc. `[192, 247]`). +- Si la charge utile totale d'une liste a une longueur de plus de 55 octets, le codage RLP consiste en un seul octet de valeur **0xf7** plus la longueur en octets de la longueur de la charge utile sous forme binaire, suivi de la longueur de la charge utile, puis de la concaténation des encodages RLP des éléments. L'intervalle du premier octet est donc `[0xf8, 0xff]` (déc. `[248, 255]`). En matière de code, cela donne : @@ -62,7 +62,7 @@ def encode_length(L, offset): elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL - raise Exception("input too long") + raise Exception("input too long") def to_binary(x): if x == 0: @@ -74,38 +74,38 @@ def to_binary(x): - la chaîne de caractères "dog" = [ 0x83, 'd', 'o', 'g' ] - la liste [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` -- la chaîne de caractères vide ('null') = `[ 0x80 ]` +- la chaîne vide ('null') = `[ 0x80 ]` - la liste vide = `[ 0xc0 ]` - l'entier 0 = `[ 0x80 ]` - l'octet '\\x00' = `[ 0x00 ]` - l'octet '\\x0f' = `[ 0x0f ]` - les octets '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` -- la [représentation théorique en théorie des ensembles](https://fr.wikipedia.org/wiki/Construction_des_entiers_naturels) de trois, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc0, 0xc1, 0xc0 ]` -- la chaîne de caractères "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` +- la [représentation en théorie des ensembles](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) de trois, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- la chaîne "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]` ## Décodage RLP {#rlp-decoding} Selon les règles et le processus d'encodage RLP, l'entrée du décodage RLP est considérée comme un tableau de données binaires. Le processus de décodage RLP est le suivant : -1. en fonction du premier octet (c'est-à-dire le préfixe) des données d'entrée et du décodage du type de données, de la longueur des données et du décalage ; +1. en se basant sur le premier octet (c.-à-d. le préfixe) des données d'entrée pour décoder le type de données, la longueur des données réelles et le décalage ; -2. selon le type et le décalage des données, décoder les données en conséquence, en respectant la règle de codage minimal pour les nombres entiers positifs ; +2. selon le type et le décalage des données, décoder les données en conséquence, en respectant la règle de codage minimal pour les nombres entiers positifs ; -3. continue à décoder le reste de l'entrée ; +3. continue à décoder le reste de l'entrée ; Parmi elles, les règles de décodage des types de données et du décalage sont les suivantes : -1. les données sont une chaîne de caractères si le premier octet (c'es-à-dire le préfixe) se trouve dans l'intervalle [0x00, 0x7f] et si la chaîne de caractères est le premier octet lui-même t; +1. les données correspondent à une chaîne si l'intervalle du premier octet (c.-à-d. le préfixe) est [0x00, 0x7f], et la chaîne est alors exactement le premier octet lui-même ; -2. les données sont une chaîne de caractères si le premier octet se trouve dans l'intervalle [0x80, 0xb7] et si la chaîne de caractères, dont la longueur est égale au premier octet moins 0x80, suit le premier octet ; +2. les données sont une chaîne de caractères si le premier octet se trouve dans l'intervalle [0x80, 0xb7] et si la chaîne de caractères, dont la longueur est égale au premier octet moins 0x80, suit le premier octet ; -3. les données sont une chaîne de caractères si le premier octet se trouve dans l'intervalle [0xb8, 0xbf] et si la longueur de la chaîne de caractères, dont la longueur en octet est égale au premier octet moins 0xb7, suit le premier octet et si la chaîne de caractères suit la longueur de la chaîne ; +3. les données sont une chaîne de caractères si le premier octet se trouve dans l'intervalle [0xb8, 0xbf] et si la longueur de la chaîne de caractères, dont la longueur en octet est égale au premier octet moins 0xb7, suit le premier octet et si la chaîne de caractères suit la longueur de la chaîne ; -4. les données sont une liste si l'intervalle du premier octet est [0xc0, 0xf7], et la concaténation des codages RLP de tous les éléments de la liste dont la charge utile totale est égale au premier octet moins 0xc0 suit le premier octet ; +4. les données sont une liste si l'intervalle du premier octet est [0xc0, 0xf7], et la concaténation des codages RLP de tous les éléments de la liste dont la charge utile totale est égale au premier octet moins 0xc0 suit le premier octet ; -5. les données sont une liste si l'intervalle du premier octet est [0xf8, 0xff], et la charge utile totale de la liste dont la longueur est égale au premier octet moins 0xf7 suit le premier octet, et la concaténation des codages RLP de tous les éléments de la liste suit la charge utile totale de la liste ; +5. les données sont une liste si l'intervalle du premier octet est [0xf8, 0xff], et la charge utile totale de la liste dont la longueur est égale au premier octet moins 0xf7 suit le premier octet, et la concaténation des codages RLP de tous les éléments de la liste suit la charge utile totale de la liste ; -Dans le code, c'est : +En matière de code, cela donne : ```python def rlp_decode(input): @@ -152,10 +152,10 @@ def to_integer(b): return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 ``` -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [RLP et Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) -- [Les dessous d'Ethereum : RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Le RLP dans Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum sous le capot : RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) - [Coglio, A. (2020). Préfixe de longueur récursive d'Ethereum dans ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) ## Sujets connexes {#related-topics} diff --git a/public/content/translations/fr/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/fr/developers/docs/data-structures-and-encoding/ssz/index.md index c201445cd9c..3f4fc747b3b 100644 --- a/public/content/translations/fr/developers/docs/data-structures-and-encoding/ssz/index.md +++ b/public/content/translations/fr/developers/docs/data-structures-and-encoding/ssz/index.md @@ -9,14 +9,14 @@ sidebarDepth: 2 ## Comment fonctionne SSZ ? {#how-does-ssz-work} -### La sérialisation {#serialization} +### Sérialisation {#serialization} SSZ est un schéma de sérialisation qui n'est pas auto-décrit, mais qui repose sur un schéma qui doit être connu à l'avance. L'objectif de la sérialisation SSZ est de représenter des objets d'une complexité arbitraire sous forme de chaînes d'octets. Il s'agit d'un processus très simple pour les "types de base". L'élément est simplement converti en octets hexadécimaux. Les types de base comprennent : - Les entiers non signés - Les booléens -Pour les types "composites" complexes, la sérialisation est plus compliquée car le type composite contient plusieurs éléments, ces derniers étant susceptibles d'avoir des types différents ou des tailles différentes, ou les deux. Lorsque ces objets ont tous une longueur fixe (c'est-à-dire que la taille des éléments sera toujours constante, quelles que soient leurs valeurs réelles), la sérialisation est simplement une conversion de chaque élément du type composite ordonné en bytestrings little-endian. Ces bytestrings sont liés entre eux. L'objet sérialisé contient la représentation bytelist des éléments de longueur fixe dans le même ordre que celui dans lequel ils apparaissent dans l'objet désérialisé. +Pour les types "composites" complexes, la sérialisation est plus compliquée car le type composite contient plusieurs éléments, ces derniers étant susceptibles d'avoir des types différents ou des tailles différentes, ou les deux. Lorsque ces objets ont tous une longueur fixe (c'est-à-dire que la taille des éléments sera toujours constante, quelles que soient leurs valeurs réelles), la sérialisation est simplement une conversion de chaque élément du type composite ordonné en chaînes d'octets petit-boutistes. Ces bytestrings sont liés entre eux. L'objet sérialisé contient la représentation bytelist des éléments de longueur fixe dans le même ordre que celui dans lequel ils apparaissent dans l'objet désérialisé. Pour les types de longueur variable, les données réelles sont remplacées par une valeur "offset" (de décalage) dans la position de cet élément dans l'objet sérialisé. Les données réelles sont ajoutées à un amas à la fin de l'objet sérialisé. La valeur de décalage est l'indice du début des données réelles dans l'amas, agissant comme un pointeur vers les octets concernés. @@ -44,14 +44,14 @@ L'exemple ci-dessous illustre comment le décalage fonctionne pour un conteneur ``` -`serialized` aurait la structure suivante (ici, elle n'est paddée que sur 4 bits, alors qu'elle est paddée sur 32 bits dans la réalité, et en gardant la représentation `int` pour plus de clarté) : +`serialized` aurait la structure suivante (complétée sur seulement 4 bits ici, mais sur 32 bits en réalité, et en conservant la représentation `int` pour plus de clarté) : ``` [37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------ ----------- ----------- ----------- ---------- | | | | | - number1 number2 offset for number 3 value for - vector vector + number1 number2 décalage pour number3 valeur pour + vector vector ``` @@ -59,11 +59,11 @@ divisé sur différentes lignes pour plus de clarté : ``` [ - 37, 0, 0, 0, # little-endian encoding of `number1`. - 55, 0, 0, 0, # little-endian encoding of `number2`. - 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 22, 0, 0, 0, # little-endian encoding of `number3`. - 1, 2, 3, 4, # The actual values in `vector`. + 37, 0, 0, 0, # codage petit-boutiste de `number1`. + 55, 0, 0, 0, # codage petit-boutiste de `number2`. + 16, 0, 0, 0, # Le « décalage » qui indique où commence la valeur de `vector` (petit-boutiste 16). + 22, 0, 0, 0, # codage petit-boutiste de `number3`. + 1, 2, 3, 4, # Les valeurs réelles dans `vector`. ] ``` @@ -71,54 +71,54 @@ Il s'agit encore d'une simplification - les nombres entiers et les zéros prése ``` [ - 10100101000000000000000000000000 # little-endian encoding of `number1` - 10110111000000000000000000000000 # little-endian encoding of `number2`. - 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 10010110000000000000000000000000 # little-endian encoding of `number3`. - 10000001100000101000001110000100 # The actual value of the `bytes` field. + 10100101000000000000000000000000 # codage petit-boutiste de `number1` + 10110111000000000000000000000000 # codage petit-boutiste de `number2`. + 10010000000000000000000000000000 # Le « décalage » qui indique où commence la valeur de `vector` (petit-boutiste 16). + 10010110000000000000000000000000 # codage petit-boutiste de `number3`. + 10000001100000101000001110000100 # La valeur réelle du champ `bytes`. ] ``` Ainsi, les valeurs réelles des types à longueur variable sont stockées dans un amas à la fin de l'objet sérialisé, et leurs décalages stockés dans leurs positions correctes dans la liste ordonnée des champs. -Il existe également des cas particuliers qui nécessitent un traitement spécifique, comme le type `BitList` qui nécessite l'ajout d'un plafond de longueur pendant la sérialisation et son retrait pendant la désérialisation. Tous les détails sont disponibles dans le [specSSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). +Il existe également des cas particuliers qui nécessitent un traitement spécifique, comme le type `BitList` qui nécessite l'ajout d'un plafond de longueur pendant la sérialisation et son retrait pendant la désérialisation. Tous les détails sont disponibles dans les [spécifications SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). -### La désérialisation {#deserialization} +### Désérialisation {#deserialization} La désérialisation de cet objet nécessite le schéma. Le schéma définit la disposition précise des données sérialisées afin que chaque élément spécifique puisse être désérialisé à partir d'un blob d'octets en un objet significatif dont les éléments ont le type, la valeur, la taille et la position appropriés. Ce schéma indique au désérialiseur quelles sont les valeurs réelles et quelles sont les valeurs décalées. Tous les noms de champs disparaissent lorsqu'un objet est sérialisé, mais sont réintégrés lors de la désérialisation selon le schéma. -Voir [ssz.dev](https://www.ssz.dev/overview) pour une explication interactive à ce sujet. +Consultez [ssz.dev](https://www.ssz.dev/overview) pour une explication interactive à ce sujet. -## La Merkleisation {#merkleization} +## Merkleisation {#merkleization} Cet objet sérialisé SSZ peut ensuite être merkléisé, c'est-à-dire transformé en une représentation en arbre de Merkle des mêmes données. Pour commencer, on détermine le nombre de morceaux de 32 octets dans l'objet sérialisé. Ce sont les "feuilles" de l'arbre. Le nombre total de feuilles doit être une puissance de 2 pour que le hachage des feuilles produise finalement une racine unique de l'arbre de hachage. Si ce n'est pas naturellement le cas, des feuilles supplémentaires contenant 32 octets de zéros sont ajoutées. De manière schématique : ``` - hash tree root + racine de l'arbre de hachage / \ / \ / \ / \ - hash of leaves hash of leaves - 1 and 2 3 and 4 + hachage des feuilles hachage des feuilles + 1 et 2 3 et 4 / \ / \ / \ / \ / \ / \ - leaf1 leaf2 leaf3 leaf4 + feuille1 feuille2 feuille3 feuille4 ``` Il existe également des cas où les feuilles de l'arbre ne se répartissent pas naturellement de manière égale comme dans l'exemple ci-dessus. Par exemple, la feuille 4 pourrait être un conteneur avec plusieurs éléments qui nécessitent une "profondeur" supplémentaire à ajouter à l'arbre de Merkle, créant ainsi un arbre inégal. -Au lieu de nous référer à ces éléments de l'arbre comme feuille X, nœud X, etc., nous pouvons leur donner des indices généralisés, en commençant par la racine = 1 et en comptant de gauche à droite sur chaque niveau. Il s'agit de l'indice généralisé expliqué ci-dessus. Chaque élément dans la liste sérialisée a un index généralisé égal à `2**profondeur + idx`, où idx est sa position indexée à partir de zéro dans l'objet sérialisé et la profondeur est le nombre de niveaux dans l'arbre de Merkle, qui peut être déterminé comme le logarithme en base deux du nombre d'éléments (feuilles). +Au lieu de nous référer à ces éléments de l'arbre comme feuille X, nœud X, etc., nous pouvons leur donner des indices généralisés, en commençant par la racine = 1 et en comptant de gauche à droite sur chaque niveau. Il s'agit de l'indice généralisé expliqué ci-dessus. Chaque élément de la liste sérialisée a un index généralisé égal à `2**depth + idx` où `idx` est sa position à indexation nulle dans l'objet sérialisé et `depth` est le nombre de niveaux dans l'arbre de Merkle, qui peut être déterminé comme le logarithme en base deux du nombre d'éléments (feuilles). ## Indices généralisés {#generalized-indices} -Un indice généralisé est un nombre entier qui représente un nœud dans un arbre de Merkle binaire où chaque nœud a un index généralisé `2 ** depth + index in row`. +Un index généralisé est un entier qui représente un nœud dans un arbre de Merkle binaire où chaque nœud a un index généralisé `2 ** depth + index in row`. ``` - 1 --depth = 0 2**0 + 0 = 1 - 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3 - 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + 1 --profondeur = 0 2**0 + 0 = 1 + 2 3 --profondeur = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --profondeur = 2 2**2 + 0 = 4, 2**2 + 1 = 5... ``` @@ -126,12 +126,13 @@ Cette représentation permet d'obtenir un indice de nœud pour chaque donnée de ## Preuves multiples {#multiproofs} -Fournir la liste des indices généralisés représentant un élément spécifique nous permet de le vérifier par rapport à la racine de l'arbre de hachage. Cette racine est notre version acceptée de la réalité. Toute donnée qui nous est fournie peut être vérifiée par rapport à cette réalité en l'insérant au bon endroit dans l'arbre de Merkle (déterminé par son index généralisé) et en observant que la racine reste constante. La spécification contient [ici](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) des fonctions qui montrent comment calculer l'ensemble minimal de nœuds requis pour vérifier le contenu d'un ensemble particulier d'indices généralisés. +Fournir la liste des indices généralisés représentant un élément spécifique nous permet de le vérifier par rapport à la racine de l'arbre de hachage. Cette racine est notre version acceptée de la réalité. Toute donnée qui nous est fournie peut être vérifiée par rapport à cette réalité en l'insérant au bon endroit dans l'arbre de Merkle (déterminé par son index généralisé) et en observant que la racine reste constante. La spécification contient des fonctions [ici](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) qui montrent comment calculer l'ensemble minimal de nœuds requis pour vérifier le contenu d'un ensemble particulier d'indices généralisés. -Par exemple, pour vérifier les données de l'indice 9 dans l'arbre ci-dessous, nous avons besoin du hachage des données aux indices 8, 9, 5, 3, 1. Le hachage de (8,9) devrait être égal au hachage (4), qui est haché avec 5 pour produire 2, qui est haché avec 3 pour produire la racine de l'arbre 1. Si des données incorrectes étaient fournies pour 9, la racine changerait - nous le détecterions et échouerions à vérifier la branche. +Par exemple, pour vérifier les données de l'indice 9 dans l'arbre ci-dessous, nous avons besoin du hachage des données aux indices 8, 9, 5, 3, 1. +Le hachage de (8,9) devrait être égal au hachage (4), qui est haché avec 5 pour produire 2, qui est haché avec 3 pour produire la racine de l'arbre 1. Si des données incorrectes étaient fournies pour 9, la racine changerait - nous le détecterions et échouerions à vérifier la branche. ``` -* = data required to generate proof +* = données requises pour générer la preuve 1* 2 3* @@ -140,10 +141,10 @@ Par exemple, pour vérifier les données de l'indice 9 dans l'arbre ci-dessous, ``` -## Complément d'information {#further-reading} +## En savoir plus {#further-reading} -- [Mise à jour Ethereum : SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) -- [Mise à jour Ethereum : Merkleisation](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [Mise à niveau d'Ethereum : SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Mise à niveau d'Ethereum : Merkleisation](https://eth2book.info/altair/part2/building_blocks/merkleization) - [Implémentations SSZ](https://github.com/ethereum/consensus-specs/issues/2138) -- [Calculeur SSZ](https://simpleserialize.com/) +- [Calculateur SSZ](https://simpleserialize.com/) - [SSZ.dev](https://www.ssz.dev/)