Comment fonctionne Ethereum?

Présentation

Certains d'entre vous savent sûrement ce qu'est la blockchain Ethereum (de l'anglais Ethereum), d'autres, au contraire, n'en ont même pas la moindre idée. D'une manière ou d'une autre, le premier et le deuxième ont entendu parler de cette plate-forme. Récemment, de nombreux articles dans divers grands magazines ont été consacrés à ce sujet, cependant, pour ceux qui ont peu entendu parler d'Ethereum, tous les articles sur ce sujet semblent être quelque chose de mystique et complètement incompréhensible. Alors, quelle est cette plateforme? En bref: Ethereum est une base de données accessible au public avec la possibilité de stocker des transactions numériques pour une durée illimitée. Il est également important de noter qu'aucun système de gestion de clés n'est requis pour maintenir et protéger une telle base de données. Au lieu de cela, cette plateforme fonctionne comme un système de transaction «sans défense» - un cadre dans lequel les individus peuvent effectuer des transactions peer-to-peer, alors qu'aucune des parties n'a d'obligation envers l'autre ou les tiers.

Je ne serais pas surpris si vous compreniez peu. En fait, le but de cet article est d'expliquer comment la blockchain Ethereum fonctionne à un niveau technique, sans recourir à des calculs mathématiques complexes ou à des formules terrifiantes par sa taille. Même si vous n'êtes pas programmeur, je suis convaincu que cet article vous aidera à comprendre les principes de la technologie Ethereum. Et même si certaines parties de cet article regorgent de définitions techniques qui peuvent vous sembler trop compliquées à comprendre, il ne faut pas désespérer, car son but est de vous faire comprendre cette plateforme dans son ensemble, sans entrer dans les subtilités techniques et mathématiques.

La plupart des sujets abordés dans cet article se penchent sur les concepts de base que vous avez probablement rencontrés plus d'une fois lors de la lecture du papier jaune (de l'anglais «yellow paper» est la spécification officielle d'Ethereum). J'ai ajouté mes propres explications et diagrammes afin que vous puissiez comprendre cette technologie le plus rapidement possible. Eh bien, pour les plus courageux et techniquement avertis, je peux vous conseiller de lire le papier jaune Ethereum.

Commençons!

Qu'est-ce que la blockchain?

La blockchain est un système transactionnel mono-élément sécurisé cryptographiquement avec un état commun. Ce n'est pas la définition la plus simple, n'est-ce pas? Décomposons chaque composant de cette définition en parties distinctes.

• «Cryptographiquement sécurisé» signifie que la sécurité des crypto-monnaies est assurée par des algorithmes mathématiques sophistiqués qu'il est presque impossible de contourner. La protection construite à l'aide de ces algorithmes est comme un pare-feu: grâce aux algorithmes utilisés, contourner le système de sécurité est pratiquement impossible (par exemple, il est impossible de créer de fausses transactions, de détruire des transactions, etc.).
• «Système singleton transactionnel» signifie qu'il n'y a qu'un seul état prédéterminé du système, en raison duquel toutes les transactions créées dans ce système se produisent. En d'autres termes, un seul état est fourni pour un système donné, qui est le seul vrai.
• «Avec un état commun» signifie que l'état spécifié dans le système est général et ouvert à tous.

Ainsi, la plate-forme Ethereum met en œuvre le paradigme de la blockchain ci-dessus.

Ethereum Blockchain Paradigm

La blockchain Ethereum est essentiellement un système d'état transactionnel . En informatique, un «système d'état» ou une «machine d'état» est un système qui traite les informations d'entrée et, sur la base de ces dernières, est converti en un nouvel état.

Dans la machine à états Ethereum, tous les processus commencent par «l'état initial». Cet état est un analogue de l'état zéro dans lequel se trouve la machine jusqu'au moment où des actions liées aux transactions commencent à se produire dans son réseau. Lorsque de telles actions commencent à avoir lieu, l'état initial est remplacé par l'état final, tandis qu'à tout moment, l'état final reflète l'état actuel d'Ethereum.


Ethereum a des millions de transactions. Ces transactions sont regroupées en «blocs». Un bloc contient une série de transactions, chaque bloc suivant étant connecté au précédent, ce qui garantit une sorte de chaîne de blocs.

Une transaction doit être correcte afin de provoquer sa transition d'un état à un autre. Une transaction n'est considérée comme correcte que lorsqu'elle a réussi le processus de vérification - le soi-disant «minage» . L'exploitation minière est lorsqu'un groupe de nœuds (ordinateurs) consomme leurs ressources informatiques pour créer un bloc de transactions correctes.

Tout nœud du réseau qui se déclare mineur peut essayer de créer et de vérifier un bloc de transactions. Une expérience courante est que de nombreux mineurs tentent de créer et de vérifier simultanément un bloc de transactions. Chaque mineur fournit sa propre «preuve» mathématique lors de l'envoi d'un bloc à la blockchain, et cette preuve agit comme une sorte de garantie: si la preuve existe, les transactions dans le bloc sont considérées comme correctes.

Le mineur doit fournir sa preuve mathématique plus rapidement que tout autre concurrent pour que son bloc soit ajouté à la blockchain principale. Le processus de vérification de chaque bloc, qui consiste à fournir au mineur sa preuve mathématique, est appelé «preuve de travail».

Le mineur, qui justifie le nouveau bloc, reçoit une certaine récompense pour avoir fait ce travail. De quel genre de récompense parlons-nous? La blockchain Ethereum utilise un jeton numérique intégré, appelé "ether" (de l'anglais ether - "ether"). Chaque fois qu'un mineur justifie son bloc de transactions, un nouveau jeton ou un nouvel éther est créé, et le mineur reçoit une récompense pour sa création.

Ensuite, vous pouvez avoir une question très logique: où est la garantie que chaque mineur adhérera à une seule chaîne de blocs? Comment puis-je m'assurer qu'une autre équipe de mineurs ne décide pas de créer sa propre chaîne de blocs?

Au tout début de cet article, nous avons déjà cité un tel concept comme un «système singleton transactionnel avec un état commun». Sur la base de cette définition, nous pouvons conclure qu'il n'y a pas deux ou plusieurs états actuels corrects - c'est unique en son genre. Ainsi, tous ceux qui participent au processus de justification de nouveaux blocs doivent accepter cette affirmation pour la vérité. La présence de plusieurs États (ou chaînes) détruirait l'ensemble du système, car il serait impossible de s'entendre sur lequel des États est correct. Par exemple, imaginez qu'il y aurait plusieurs chaînes de blocs. Ensuite, en théorie, vous pourriez collecter 10 pièces sur une chaîne, 20 pièces sur l'autre, 40 pièces sur la troisième, etc. Dans ce cas, il serait impossible de déterminer quelle chaîne est la plus «correcte».

Chaque fois que plusieurs chemins sont générés, un «fork» se produit. Souvent, les branches sont très indésirables, car elles violent l'intégrité du système, et les utilisateurs doivent choisir l'une des chaînes possibles.

Pour déterminer laquelle des voies possibles est correcte et empêcher la formation de multiples circuits, Ethereum utilise une méthode appelée «protocole GHOST» .

GHOST - «Le sous-arbre le plus gourmand observé»

Je vais essayer de l'expliquer en termes simples: le protocole GHOST annonce que nous ne devons choisir que la voie sur laquelle le plus grand nombre de calculs a été effectué . Pour déterminer ce chemin, vous pouvez utiliser le numéro du dernier bloc déterminé ("bloc feuille"). Grâce à cette approche, il est possible de déterminer le nombre total de blocs dans le chemin courant (hors bloc de l'état initial). Plus le bloc est haut, plus le chemin est long et plus les mineurs doivent justifier. Sur la base de telles considérations, la seule version correcte pour l'état actuel est acceptée.

Maintenant que vous avez déjà une idée de ce qu'est la blockchain, je propose de traiter des principaux composants qui composent le système Ethereum:

• comptes
• condition
• rémunération du carburant
• transactions
• blocs
• exécution de transaction
• l'exploitation minière
• justification

Une petite digression avant de commencer: quand on se réfère au hachage X, cela signifie le hachage KECCAK-256 utilisé dans Ethereum.

Comptes

L'état global global de la plate-forme Ethereum se compose de nombreux petits objets - des comptes qui interagissent entre eux via le paradigme de la messagerie. Chaque compte a un état spécifique et une adresse de 20 octets. L'adresse dans Ethereum est un identifiant de 160 bits utilisé pour identifier l'un des comptes.

Il existe deux types de comptes au total:

• Les comptes externes sont contrôlés à l'aide de clés privées. Cependant, ces enregistrements ne sont associés à aucun code.
• Les comptes de contrat sont contrôlés par un code spécial spécifié dans le contrat et associé à un code.

Comptes externes et contractuels

Examinons les principales différences entre les comptes externes et les comptes contractuels. Pour un compte externe, il est possible d'envoyer des messages à d'autres comptes externes, ainsi qu'à d'autres comptes de contrat . Pour cela, il est nécessaire de créer et d'enregistrer une nouvelle transaction à l'aide de la clé privée. Un message entre deux comptes externes n'est qu'une valeur à transférer. D'autre part, un message envoyé d'un compte externe à un compte de contrat implique l'activation du code de compte de contrat, et il est possible d'effectuer certaines actions (par exemple, en utilisant ce message, vous pouvez transférer des jetons, écrire des valeurs dans la mémoire interne, créer des jetons, en exécuter certains informatique, création de nouveaux contrats, etc.).

En utilisant des comptes de contrat, contrairement aux comptes externes, il est impossible d'initier de nouvelles transactions par vous-même . Au lieu de cela, en utilisant des comptes de contrat, vous ne pouvez démarrer des transactions qu'en réponse à d'autres transactions reçues (par exemple, celles reçues d'un compte externe ou d'un autre compte de contrat). Plus en détail sur les appels entre les comptes contractuels, nous nous arrêterons dans la section "Transactions et messages".



Chaque action sur la blockchain Ethereum se produit en raison de transactions lancées par des comptes contrôlés de l'extérieur.

Statut du compte

Le statut de chacun des comptes, quel que soit leur type, peut prendre l'une des quatre valeurs suivantes:

• nonce : si le compte courant correspond à un compte externe, le numéro reçu représente le nombre de transactions envoyées depuis l'adresse du compte. Si le compte est un compte de contrat, l'élément nonce est le nombre de contrats créés dans ce compte.
• solde : le nombre total de wei achetés par ce compte. Par exemple, chaque éther, qui est l'unité d'échange d'Ethereum, contient 10 ^ 18 wei - parties fractionnaires de l'éther.
• storageRoot : le hachage du nœud racine de l'arbre de préfixe de l'arbre Merkle (quel sera l'arbre Merkle un peu plus tard). L'arbre Merkle code un hachage du contenu de ce compte et, par défaut, il est vide.
• codeHash : un hachage du code EVM (de la machine virtuelle Ethereum anglaise; ce que je vais vous dire un peu plus tard) du compte. Pour les comptes de contrat, ce champ est un code haché et stocké en tant que codeHash.

Statut général du système

Nous avons donc compris que l'état global d'Ethereum est un mappage des états de compte aux adresses de compte. Ce mappage est stocké dans la structure de données, l' arborescence des préfixes Merkle .

L'arbre Merkle (ou «Merkle trie») est un type de fichier binaire composé d'un ensemble de nœuds qui comprennent:

• un certain nombre de nœuds foliaires, qui sont situés au bas de l'arbre contenant les données sous-jacentes;
• un ensemble de nœuds intermédiaires, chaque nœud étant un hachage de ses deux nœuds enfants
• un nœud racine, également formé d'un hachage de deux nœuds enfants, qui représente le sommet de l'arbre

Les données situées au bas de l'arborescence sont créées en divisant les données que nous voulons enregistrer en fragments séparés. En outre, ces fragments sont placés dans des paniers de stockage de données, après quoi ils sont hachés et un processus similaire est répété jusqu'à ce que le nombre total de hachages soit égal à un ou au hachage racine.



Pour chaque valeur stockée dans cet arbre, vous devrez entrer une clé spécifique. Pour obtenir la valeur correspondante stockée dans les nœuds feuilles, vous devez obtenir un raccourci clavier: à quelle chaîne de nœuds enfants vous devez adhérer. Comme pour Ethereum, le mappage de la clé / valeur requise pour l'arborescence d'état se situe entre les adresses et les comptes associés, y compris le solde, le nonce, le codeHash, ainsi que storageRoot pour chaque compte, tandis que storageRoot est une arborescence.



Une structure similaire de l'arborescence des préfixes peut également être utilisée pour stocker à la fois les transactions et la page d'acceptation de paiement. Si nous nous attardons sur cela plus en détail, alors chaque bloc a un soi-disant «en-tête» ou fichier d'en-tête, qui stocke le hachage du nœud racine de trois structures différentes de l'arbre Merkle, y compris:

• État de l'arborescence des préfixes
• Transactions d'arbre de préfixe
• Pages d'acceptation de paiement pour l'arborescence des préfixes

La possibilité de stocker efficacement ces informations dans l'arborescence des préfixes Merkle Ethereum est une solution incroyablement pratique pour les soi-disant clients légers ou nœuds légers. Il convient également de noter que la prise en charge de la chaîne de blocs est fournie via un ensemble de nœuds. En termes simples: au total, il existe deux types de nœuds: pleins et fins.

Un nœud d'archivage complet synchronise la chaîne de blocs en chargeant toute la chaîne du bloc d'état initial au bloc actuel contenant le fichier d'en-tête, et toutes les transactions qui s'y trouvent sont exécutées . En règle générale, les mineurs stockent le nœud d'archive complet, car sans ce dernier, ils n'auront pas la possibilité de participer au processus d'extraction. De plus, vous pouvez également télécharger un nœud complet, sans avoir besoin de terminer chaque transaction individuelle. Il convient également de noter que chaque nœud complet contient toujours une chaîne complète.

Dans le cas où le nœud n'a pas besoin d'effectuer chaque transaction individuelle ou de demander les données accumulées, le stockage de la chaîne complète peut être inutile. C'est dans ce cas que nous sommes confrontés à un concept tel qu'un nœud fin. Au lieu de charger et de stocker la chaîne complète, ainsi que l'exécution de toutes les transactions, les nœuds légers chargent uniquement la chaîne de fichiers d'en-tête du bloc d'état initial à l'en-tête actuel, et aucune transaction n'est effectuée . Étant donné que les nœuds légers ont accès aux en-têtes de bloc contenant un hachage de trois arborescences de préfixes, ils peuvent facilement créer et recevoir des réponses correspondantes concernant les transactions, les événements, le solde, etc.

Le hachage dans l'arbre Merkle se propage des branches inférieures aux branches supérieures, et si un attaquant tente de remplacer la transaction d'origine par une fausse au bas de l'arbre Merkle, cela entraînera une modification du hachage du nœud supérieur, et cela, à son tour, changera le hachage du nœud situé au-dessus de celui-ci et ainsi de suite, jusqu'à ce que, finalement, cela conduise à un changement de racine.



Tout nœud qui nécessite la vérification d'une partie des données utilise ce que l'on appelle la «preuve Merkle». Ce dernier comprend:

• Fragment de données à vérifier
• Hachage de racine d'arbre
• La soi-disant «branche» - tous les hachages, de la donnée vérifiée à la racine.

Chaque utilisateur qui lit une telle preuve peut vérifier si le hachage pour une branche particulière est approprié dans toute la section de l'arbre, et également si ce fragment occupe la position correspondante dans cet arbre.

Ainsi, nous pouvons conclure que l'avantage d'utiliser l'arborescence de préfixes de Merkle est que le nœud racine de cette structure dépend cryptographiquement des données stockées dans l'arborescence. Par conséquent, le hachage du nœud racine peut être utilisé comme identifiant sécurisé pour ces données. Étant donné que le hachage racine des arbres est inclus dans l'en-tête du bloc, ainsi que leur état, leurs transactions et les informations d'arrivée des paiements, n'importe lequel des nœuds peut vérifier telle ou telle partie de l'état Ethereum sans avoir besoin de stocker tous les états, qui peuvent être potentiellement illimités en taille.

Carburant et récompense

L'un des points importants du système Ethereum est le processus de paiement. Pour tout calcul effectué à la suite de transactions avec des transactions au sein du réseau Ethereum, des frais sont facturés . La valeur nominale de ce paiement est appelée "fuel" (du gaz anglais).

Le carburant est une unité de mesure utilisée pour déterminer le montant du paiement pour un calcul particulier. Le prix du carburant est la quantité «d'éther» que vous pouvez dépenser pour chaque unité de carburant. Le prix du carburant en gwei est mesuré. Wei est la plus petite unité d'éther, où 1018 Wei est juste 1 éther. Un gwei équivaut à 1 000 000 000 Wei.

Pour toute transaction, l'expéditeur doit fixer une limite de carburant , ainsi que le prix du carburant. Le prix du carburant et la limite de carburant sont le montant maximal en Wei que l'expéditeur est prêt à payer pour la transaction.

Imaginons que l'expéditeur fixe une limite de carburant de 50 000 gwei et un prix du carburant de 20 gwei. Cela signifie que l'expéditeur est prêt à ne pas dépenser plus de 50 000 x 20 gwei = 1 000 000 000 000 000 Wei ou 0,001 éther pour effectuer cette transaction.



Ainsi, la limite de carburant est la quantité maximale de carburant que l'expéditeur est prêt à payer. Dans le cas où il y a suffisamment d'éther sur le solde de son compte pour couvrir ce maximum, l'expéditeur peut effectuer des transactions. De plus, l'expéditeur est remboursé de toute perte liée à l'utilisation incomplète du carburant à la fin de la transaction, tandis que le carburant sera échangé au tarif d'origine.



Dans le cas où l'expéditeur n'aurait pas fourni la quantité de carburant requise pour la transaction, celle-ci sera effectuée «sans carburant» et sera considérée comme invalide. Ainsi, la transaction est interrompue et tout changement d'état est annulé, à la suite de quoi le système Ethereum renvoie les participants à la transaction dans son état d'origine. Il convient de noter que les informations relatives à une telle transaction ayant échoué sont enregistrées dans le système, afin que vous puissiez suivre les transactions qui ont été effectuées et à quelle étape la panne s'est produite. Et ce qui est également important: puisque jusqu'à ce que l'expéditeur manque de carburant, la machine avait déjà déployé certains efforts pour effectuer les calculs, il serait logique de supposer que les pertes liées à la consommation de carburant étaient déjàne sera pas remboursé à l'expéditeur .



«Où est-ce que j'envoie exactement du carburant? - demandez-vous. Ainsi, tout l'argent dépensé pour l'achat par l'expéditeur du carburant est envoyé à l'adresse du bénéficiaire, qui est dans la plupart des cas l'adresse du mineur . Étant donné que les mineurs effectuent des règlements et vérifient les transactions, ce sont eux qui reçoivent des frais de carburant en récompense.



En règle générale, plus le coût du carburant que l'expéditeur veut payer est élevé, plus le paiement reçu par le mineur à la suite de la transaction est élevé et, en outre, plus le mineur est susceptible de faire son choix en sa faveur. Ainsi, les mineurs sont libres de choisir quelles transactions ils veulent valider et quelles transactions ils doivent ignorer. Souvent, les mineurs indiquent aux expéditeurs le prix qu'ils doivent fixer pour le carburant afin que les premiers soient prêts à conclure les transactions.

Frais d'utilisation du stockage

Le carburant est utilisé non seulement pour payer certains calculs, mais aussi pour payer l'utilisation du stockage . Le coût total d'utilisation du stockage est de 32 octets utilisés.

La question du paiement facturé pour l'utilisation du stockage a quelques nuances. Par exemple, étant donné qu'une augmentation de l'espace utilisé dans le stockage implique une augmentation de la taille de la base de données d'état Ethereum, et cela s'applique à tous les nœuds, vous êtes incité à ne stocker qu'une quantité relativement faible de données. Ainsi, si l'une des étapes de la transaction implique la suppression de l'enregistrement dans le référentiel, le paiement pour la réalisation de cette opération n'est pas facturé, et en raison de la libération d'espace dans le référentiel, les pertes seront également compensées.

À quoi sert le paiement?

Un aspect important du travail d'Ethereum est que toute opération effectuée par le réseau est également effectuée simultanément par chaque nœud complet . Cependant, toutes les étapes de calcul sur la machine virtuelle Ethereum sont très coûteuses. Ainsi, pour résoudre des tâches simples (par exemple, lancer une logique métier simple, vérifier des signatures, ainsi que d'autres opérations liées à la crypto-monnaie), les contrats intelligents Ethereum peuvent bien convenir, contrairement à ceux où d'autres plus complexes sont nécessaires, tâches: stockage de fichiers ou de courriers électroniques, ainsi que l'exécution de tâches dans le domaine de l'apprentissage automatique, ce qui peut entraîner une charge réseau excessive. L'introduction du paiement empêche les actions des utilisateurs visant à charger inutilement le réseau.

Ethereum utilise un langage complet de Turing. En bref: une machine de Turing est une machine qui simule n'importe quel algorithme informatique. Pour ceux qui entendent parler pour la première fois d'une machine de Turing, je suggère de lire ceci et celaarticles. En raison de cette fonctionnalité, il est possible d'utiliser des cycles dans Ethereum, ce qui le rend vulnérable au problème d'arrêt - un problème, dans le cas où, vous ne pouvez pas déterminer si le programme fonctionnera indéfiniment ou non. Par exemple, si le système de paiement n'était pas fourni dans Ethereum, les attaquants pourraient essayer de perturber le réseau en effectuant un cycle sans fin à l'intérieur de la transaction, sans encourir de pertes. Ainsi, le système de paiement a été introduit spécifiquement pour le protéger des attaques intentionnelles.

Il est probable que vous pensiez: "Mais qu'est-ce que j'ai à voir avec ça?" Pourquoi vais-je payer pour utiliser le stockage? " Eh bien, que puis-je vous dire, l'ensemble du réseau Ethereum prend en charge à la fois l'utilisation informatique et le stockage ... quelque chose comme ça.

Transactions et messages

Plus tôt, j'ai écrit que Ethereum est un système d'état des transactions . En d'autres termes, en raison des transactions qui se produisent entre différents comptes, l'état global d'Ethereum change ou passe d'un état à un autre.

En termes simples, une transaction est une partie signée cryptographiquement d'une instruction qui est d'abord définie par un compte externe, puis rationalisée et transférée vers la blockchain.

Il existe deux types de transactions: l' envoi de messages et la création d'un contrat (en d'autres termes, ces transactions créent de nouveaux contrats sur le réseau Ethereum).

Toutes les transactions contiennent les éléments suivants, quel que soit le type du premier:

• nonce – , .
• gasPrice – Wei, , .
• gasLimit – , . , - .
• to – . , , , .
• value – Wei, . , , .
• v, r, s – , , .
• init – , . EVM-, . init . init , , , .
• Les données sont les données d'entrée (paramètres) pour appeler le message (les données sont un élément facultatif destiné uniquement à appeler des messages). Par exemple, si un contrat intelligent joue le rôle d'un service d'enregistrement de domaine, un appel à ce contrat peut attendre des champs de saisie (par exemple, domaine et adresse IP).

À partir des informations fournies dans la section «Comptes», nous avons découvert que les transactions - à la fois pour les appels de message et pour la création de contrats - sont initiées par des comptes externes puis redirigées vers la blockchain. En d'autres termes, les transactions sont une sorte de pont reliant le monde extérieur et l'état interne de la plate-forme Ethereum.



Mais cela ne signifie pas que certains contrats ne peuvent pas interagir avec d'autres: les contrats situés dans le contexte global de l'état d'Ethereum peuvent interagir les uns avec les autres dans le contexte donné. Leur interaction ou communication se fait par l'envoi de messages ou de transactions internes . La seule différence entre les transactions internes et les transactions ordinaires est que les premières ne sont pas créées par des comptes externes - mais à la suite de la création de contrats. Ce sont des objets virtuels qui, contrairement aux transactions, ne sont pas ordonnés et ne peuvent exister que dans le runtime Ethereum.

Lorsqu'un des contrats envoie une transaction interne à un autre contrat, un certain code est exécuté qui existe dans le compte de contrat du destinataire.



Il convient également de noter que gasLimit n'est pas fourni pour les transactions ou les messages internes , car la limite de carburant est définie par l'initiateur de la transaction d'origine (par exemple, dans certains comptes). La limite de carburant définie par le compte externe doit être suffisamment élevée pour la transaction, y compris toutes les actions supplémentaires qui sont effectuées à la suite de la transaction, par exemple, l'envoi d'un message d'un contrat à un autre. Dans le cas où, dans la chaîne de transactions et de messages, il n'y a pas assez de carburant pour exécuter l'un des derniers, son exécution, ainsi que l'exécution de tous les messages ultérieurs provoqués par l'exécution initiale, seront retournées.

Blocs

Toutes les transactions sont en quelque sorte regroupées en «blocs». La blockchain contient plusieurs de ces blocs interconnectés.

Ces blocs sont constitués de:

• en-tête de bloc
• informations sur la série de transactions incluses dans ce bloc
• série d'autres en-têtes de bloc pour les commandes actuelles

Quels sont les omemers?

Voyons ce qu'est un ommer (de l'anglais «ommer»). Un ommer est un bloc dont le parent est le parent du bloc actuel. Dans ce chapitre, je décrirai brièvement pourquoi les ommers sont généralement nécessaires, ainsi que pour quelles raisons le bloc contient des en-têtes de bloc pour les ommers.

Leur présence, tout d'abord, est justifiée par le fait que le temps de blocage dans Ethereum est beaucoup plus faible (environ 15 secondes) que pour les autres blockchains, par exemple, pour les bitcoins (environ 10 minutes). Grâce à cette fonctionnalité, la vitesse de transaction des transactions augmente. D'un autre côté, l'un des aspects négatifs du temps de blocage plus court est que la lutte des mineurs pour la prochaine solution de bloc ne fait que s'intensifier. Ces blocs concurrents sont également appelés «blocs sans parent» (c'est-à-dire que ces blocs ne sont pas inclus dans la chaîne de blocs principale).

Des Ommers ont été créés afin que les mineurs puissent recevoir une récompense bien méritée pour avoir inclus des blocs sans parents dans la chaîne principale. Les Ommers, inclus par les mineurs dans la chaîne principale, doivent être «valides»: eux, les omemers, doivent être des descendants de la sixième génération ou plus ancienne du bloc actuel. Par exemple, après la sixième génération, ces descendants ne peuvent pas être inclus dans la chaîne principale en tant que blocs sans parent: les transactions ultérieures peuvent nuire au fonctionnement du système dans son ensemble.

Pour les omemers, vous recevrez une récompense inférieure à l'inclusion d'un bloc complet. Cependant, cela ne devrait pas nuire aux tentatives des mineurs d'inclure de tels blocs sans parent et de recevoir leur récompense bien méritée.

En-têtes de bloc

J'ai mentionné plus tôt que chaque bloc avait un en-tête, mais nous ne comprenions vraiment pas ce que c'est?

Un en-tête de bloc fait partie d'un bloc composé de:

• parentHash - est le hachage de l'en-tête du bloc parent (en raison duquel, en fait, le bloc tombe dans la chaîne de blocs)
• ommersHash - hachage de la liste actuelle des blocs ommer
• bénéficiaire - adresse du compte sur lequel le paiement pour l'inclusion de ce bloc est reçu
• stateRoot - hachage du nœud racine de l'état de l'arborescence des préfixes (j'ai écrit plus tôt que l'état de l'arborescence des préfixes est stocké dans l'en-tête, simplifiant ainsi le processus d'approbation de l'état pour les clients légers)
• transactionsRoot – , ,
• receiptsRoot – , ,
• logsBloom – ( ), ,
• difficulty –
• number – ( , ; )
• gasLimit –
• gasUsed – ,
• timestamp - horodatage pour la création du bloc courant
• extraData - données supplémentaires relatives au bloc actuel
• mixHash - un hachage qui, en combinaison avec l'élément nonce, prétend que suffisamment de calculs sont effectués pour le bloc actuel
• nonce - un hachage, qui en combinaison avec l'élément mixHash prétend que suffisamment de calculs sont effectués pour le bloc actuel

Il convient de noter que chaque en-tête de bloc contient trois structures d'arborescence de préfixes pour:

• état ( stateRoot )
• effectuer des transactions ( transactionsRoot )
• recevoir des informations de paiement ( receiptsRoot )

De telles structures de l'arbre de préfixe ne sont rien d'autre que l'arbre de préfixe Merfle, dont nous avons déjà discuté ci-dessus.

De plus, pour cette définition, il existe plusieurs termes que vous devriez probablement trouver intéressants.

Magazines

La plateforme Ethereum offre la possibilité de conserver des journaux dont le but est d'enregistrer des informations sur diverses transactions et messages. De plus, il est également possible pour un contrat de créer ouvertement une entrée dans un tel journal en utilisant l'annonce de «l'événement» à enregistrer.

Une entrée de journal comprend:

• adresse de compte de bureau d'enregistrement
• une série de tâches qui affichent divers événements terminés pour la transaction en cours
• toutes les données pertinentes pour ces événements

Les entrées de journal sont stockées dans le filtre Bloom , ce qui permet de stocker efficacement une quantité infinie de données.

Obtenir des informations de paiement

Les enregistrements stockés dans l'en-tête proviennent des informations contenues dans le journal, qui se rapportent aux données de paiement de transaction (ou chèque). Tout comme vous recevez un chèque lors de l'achat de marchandises dans un magasin, Ethereum crée un chèque similaire pour chacune des transactions. Et comme vous l'avez probablement déjà deviné, chaque chèque contient des informations sur la transaction en cours. Le chèque comprend:

• numéro de bloc
• hachage de bloc
• hachage de transaction
• quantité de carburant utilisée pour la transaction en cours
• la quantité totale de carburant qui a été utilisée pour effectuer la transaction en cours pour un bloc spécifique
• journaux de transactions générés par la transaction
• autres informations

Difficulté de blocage

La complexité des blocs est un concept utilisé pour garantir la cohérence du temps nécessaire à la validation des blocs. Pour le bloc initial, la complexité est de 131 072 unités. Pour calculer la complexité de l'un des blocs, une formule spéciale est utilisée. Dans le cas où la validation de l'un des blocs a eu lieu plus rapidement que, par exemple, la validation du suivant, le protocole utilisé dans Ethereum augmente la complexité de ce dernier.

La complexité du bloc affecte également le non - hachage, dont l 'exécution est nécessaire lors de l' affichage du bloc, alors qu'à cette fin, des algorithmes de vérification de sécurité sont utilisés.

La dépendance d'un paramètre, la complexité du bloc, d'un autre, nonce, est présentée dans cette formule:


où Hd est la complexité du bloc

La seule façon de déterminer le paramètre nonce qui remplira la condition présentée par la formule est d'utiliser l'algorithme de vérification de l'état pour trouver toutes ses valeurs possibles. Le temps attendu pour rechercher toutes les valeurs correspondant à cette condition est la complexité du bloc. Nous pouvons alors conclure: plus la valeur de complexité du bloc est grande, plus il est difficile de trouver le paramètre nonce, et donc, plus il est difficile de valider le bloc, ce qui entraîne à son tour le temps nécessaire pour valider les blocs suivants. Ainsi, en fonction de la valeur obtenue lors de la détermination de la complexité du bloc, le protocole utilisé détermine le temps nécessaire pour valider le bloc courant .

Dans le cas où le temps requis pour valider le bloc est inférieur à celui attendu, le protocole sous-estime la complexité du bloc actuel. Ainsi, le temps requis pour la validation du bloc est réglé automatiquement pour correspondre constamment aux paramètres actuels (en moyenne, un tel temps est de 15 secondes).

Transaction

Eh bien, bien, nous arrivons ici à la partie peut-être la plus complexe des protocoles utilisés dans Ethereum - les transactions. Imaginons que vous ayez configuré une transaction sur le réseau Ethereum. Et que pensez-vous qu'il adviendra de l'état d'Ethereum lors de votre transaction?



Tout d'abord, toute transaction doit répondre à certaines exigences pour que son exécution ne soit pas annulée, à savoir:

• Les transactions doivent répondre aux exigences du RLP. RLP est un préfixe de longueur récursive (de l'anglais Recursive Length Prefix), qui est un format de données utilisé pour coder des tableaux intégrés de données binaires. Le format RLP est utilisé dans Ethereum pour organiser les objets.
• La présence d'une signature de transaction valide.
• La présence d'une valeur nonce valide. Permettez-moi de vous rappeler que nonce est le nombre de transactions envoyées à partir du compte courant. Pour que cette valeur soit valide, elle doit correspondre à la valeur nonce du compte de l'expéditeur.
• La limite de carburant pour une transaction doit être égale ou supérieure à la quantité de carburant spécifiée. La quantité spécifiée de carburant comprend:

1. valeur prédéterminée de 21 000 unités de carburant nécessaires pour conclure la transaction
2. Frais de carburant utilisés pour envoyer les données de transaction (4 unités de carburant pour chaque octet de données ou code égal à zéro, et 68 pour chaque octet de données non nul ou code non nul)
3. 32 000 unités de carburant supplémentaires si la transaction implique la passation de marchés

• Le solde du compte courant de l'expéditeur doit contenir une quantité suffisante d'éther pour couvrir le coût «anticipé» du carburant, que l'expéditeur accepte de payer. Le coût d'avance du carburant est calculé comme suit: la limite du coût du carburant est multipliée par le coût du carburant pour la transaction en cours, à la suite de laquelle nous trouvons le coût maximal du carburant. De plus, la quantité totale de carburant transportée de l'expéditeur au destinataire est ajoutée au coût maximum.

Si vous avez rempli toutes les conditions ci-dessus, vous passez à l'étape suivante.

Tout d'abord, la valeur du coût d'avance du carburant est déduite du compte de l'expéditeur et le nonce de l'expéditeur est augmenté de 1. Après cela, nous pouvons calculer la quantité de carburant restante par la formule suivante: soustraire la quantité spécifiée de carburant de la quantité totale de carburant nécessaire pour effectuer la transaction .



Après cela, la transaction commence. Au cours de la transaction actuelle dans Ethereum, le suivi du «sous-état» a lieu. La sous-déclaration est nécessaire pour enregistrer les informations collectées lors de la transaction en cours. Ces informations seront nécessaires dès la fin de la transaction et contiennent:

• Ensemble d'autodestruction : un ensemble de comptes qui seront supprimés une fois la transaction terminée
• Série de journaux: points d'arrêt archivés et indexés nécessaires pour exécuter le code de la machine virtuelle.
• Solde de remboursement : le montant qui doit être retourné à l'expéditeur à la fin de la transaction. J'ai déjà mentionné plus tôt que l'utilisation du référentiel fourni par Ethereum coûte une certaine somme d'argent, et cet argent est retourné à l'expéditeur après qu'il cesse d'utiliser un tel référentiel. Le système Ethereum stocke des informations sur l'utilisation du magasin et le remboursement de son utilisation à l'expéditeur.

Après cela, les différents calculs nécessaires à la transaction sont effectués.

Une fois toutes les étapes nécessaires à la transaction terminées (à condition que toutes les conditions ci-dessus soient également remplies), le statut de la transaction est terminé et la quantité de carburant inutilisé qui doit être retournée à l'expéditeur est calculée.

Une fois la transaction (réussie) terminée et le carburant retourné à l'expéditeur, les événements suivants se produisent:

• une certaine quantité d'éther utilisée pour acheter du carburant est envoyée au mineur;
• le carburant utilisé pour effectuer la transaction est enregistré dans le bloc pour le calcul du carburant (ce bloc est utilisé pour stocker des informations sur la quantité totale de carburant qui a été utilisée pour effectuer toutes les transactions dans ce bloc; en outre, un tel bloc est utilisé lors de la validation;
• toutes les informations de compte contenues dans la section du jeu d'autodestruction sont supprimées.

Nous sommes donc arrivés à la fin de ce chapitre: nous avons appris ce qu'est un nouvel État et pourquoi nous avons besoin d'un journal pour effectuer des transactions.

Dans le chapitre suivant, nous examinerons de plus près la différence entre les transactions liées à la création de contrats et l'envoi de messages.

Créer des contrats

Vous vous souvenez probablement qu'il n'y a que deux types de comptes dans Ethereum: les comptes de contrat et les comptes externes. Lorsque vous rencontrez le terme «transactions de création de contrat», vous devez savoir que le but d'une telle transaction est de créer un nouveau compte de contrat.

Pour créer un nouveau compte de contrat, nous devons d'abord déclarer l'adresse du compte créé à l'aide d'une formule spéciale. Après cela, un nouveau compte est créé. Pour effectuer cette opération, vous devez effectuer une série d'actions:

• mettre zéro à nonce
• ajuster le solde de votre compte égal au paiement de la transaction (si l'expéditeur est prêt à envoyer une certaine quantité d'éther comme paiement pour la transaction)
• calculer le montant du paiement qui va dans le solde du compte créé à partir du compte de l'expéditeur
• indiquer que le coffre-fort n'est plus utilisé par vous
• configurer le hachage de contrat en tant que hachage de chaîne vide

Au moment où nous avons commencé à créer un nouveau compte, nous l'avons en fait déjà créé en utilisant le code init , qui est automatiquement envoyé au début de la transaction (nous avons oublié quel est le code init - voir la section "Transactions et messages"). Il existe plusieurs options pour le développement d'événements lors de l'exécution du code init (par exemple, cela peut arriver: mettre à jour le référentiel d'un compte, créer un autre compte pour le contrat en cours, envoyer un message, etc.).

Une fois que le système a exécuté le code conçu pour créer un nouveau contrat, le carburant entre en jeu. Vous ne pourrez pas effectuer une transaction si elle nécessite plus de carburant que celui qui est stocké dans votre bilan. Dans le cas où, malgré cette restriction, vous essayez d'effectuer une transaction, vous recevrez un message sur un manque de carburant, après quoi le système s'arrêtera automatiquement. De plus, si l'achèvement de la transaction est dû à un manque de carburant, vous serez transféré à l'étape précédant la transaction. Et surtout: le bénéficiaire ne sera pas remboursé de la quantité de carburant dépensée avant que sa pénurie ne soit découverte .

Ce sont les choses ...

Cependant, si l'expéditeur a alloué une certaine quantité d'éther pour la transaction en cours, ce montant sera restitué même si la création du contrat a échoué.

Si le code d'initialisation a réussi, les fonds nécessaires à la création du contrat doivent être apportés par le créateur. Ce montant comprend également le coût d'utilisation du stockage, qui augmente en proportion directe avec la taille du code créé pour le contrat. Dans le cas où le créateur ne disposerait pas de fonds suffisants pour réaliser cette opération, la transaction est résiliée faute de carburant et les conséquences seront les mêmes que ci-dessus.

Si tout s'est bien passé et que nous n'avons pas reçu de message concernant une pénurie de carburant, tout le carburant qui n'a pas été utilisé pour cette transaction est retourné à l'expéditeur.

Victoire!

Des messages

L'opération d'envoi d'un message, en général, est assez similaire à la création d'un contrat, sans tenir compte de quelques petites différences.

Pour effectuer cette opération, l'utilisation du code init n'est pas du tout requise, car à la suite de son exécution, aucun nouveau compte n'est créé. Cependant, pour une telle opération, vous pouvez avoir besoin de données d'entrée, mais uniquement si ces données ont été transmises par le destinataire à la suite de la transaction. Après l'opération d'envoi du message, un nouveau bloc contenant les informations de sortie devient disponible, dont l'utilisation se produit lorsque l'opération est répétée.

De même que dans le cas de la création du contrat, si l'opération d'envoi d'un message a été interrompue suite à un manque de carburant ou à une transaction invalide (par exemple, en raison d'une erreur de débordement de pile, d'une adresse de saut invalide, d'une commande incorrecte), la quantité de carburant utilisée pour cette opération n'est pas restituée à l'initiateur appeler. Au contraire, tout le carburant inutilisé est également déduit de son bilan et l'état du système revient au point précédant l'opération de transfert de solde.

Jusqu'à récemment, il n'y avait aucun moyen à Ethereum de suspendre ou de suspendre des transactions sans perdre le carburant que vous avez fourni à cette fin. Par exemple, vous pouvez imaginer une situation où vous lancez la création d'un contrat, dont la création a échoué, car l'initiateur de l'appel n'avait le droit d'effectuer aucune des transactions. Ainsi, dans la version précédente d'Ethereum, avant de mettre à jour la plateforme, dans une telle situation, tout le carburant restant sur votre compte serait retiré, tandis que l'expéditeur n'aurait pas non plus récupéré son carburant. Mais avec la sortie de la mise à jour - Byzance - vous avez la possibilité de suspendre l'exécution des opérations de création de contrat et de remettre le système dans son état d'origine sans perdre le carburant restant sur votre compte . Ainsi, si une transaction se termine à la suite de la suspension de son exécution, le carburant non utilisé est retourné à l'expéditeur.

Modèle d'exécution

Dans les sections précédentes, je vous ai expliqué comment les transactions sont exécutées. Maintenant, je vous suggère de gérer ce qui se passe dans la machine virtuelle (à partir de la machine virtuelle anglaise - une machine virtuelle) au moment de la transaction.

Une partie du protocole qui effectue le traitement des transactions dans le système d'exploitation Ethereum est appelée Ethereum Virtual Machine (VME) .

VME est une machine de Turing, comme mentionné plus haut dans cet article. La seule différence entre VME et une machine Turing typique est que la première nécessite un «carburant» virtuel pour fonctionner. Ainsi, tous les calculs qui peuvent être effectués dans le VME sont en quelque sorte limités par la quantité de "carburant" qui y circule, la machine virtuelle.


Source: CMU

De plus, toutes les fonctionnalités de l'architecture de pile sont inhérentes à VME. Une machine empilée est un ordinateur qui utilise l'algorithme LIFO.

La taille de tout élément de pile dans VME est de 256 bits et la taille de pile maximale atteint 1024 bits.

Pour VME, une certaine quantité de mémoire est fournie, qui n'est pas constante. Les éléments y sont stockés sous forme de tableaux d'octets avec accès aux mots.

Une zone de stockage spécifique est également prévue pour les VME. Contrairement à la quantité de mémoire, un tel stockage (ou zone de stockage) ne change pas et fait partie de l'état du système. Dans VME, le code du programme est stocké dans une ROM virtuelle distincte, dont l'accès ne peut être obtenu qu'à l'aide d'instructions spécifiques. De ce point de vue, un tel VME diffère d'une architecture von Neumann typique dans laquelle le code de programme est stocké dans la mémoire de l'ordinateur.



VME a également son propre langage spécial - le bytecode VME. Lorsqu'un programmeur comme vous ou, par exemple, moi, écrit un contrat intelligent qui sera exécuté dans le système Ethereum, cela se produit généralement avec un langage de haut niveau tel que Solidity. Après avoir écrit ce code, nous le compilons en bytecode VME afin que VME puisse comprendre la commande que nous avons écrite.

Nous procédons directement à l'exécution des opérations.

Avant d'effectuer un calcul spécifique, le processeur doit s'assurer que les informations ci-dessous sont valides et disponibles:

• Statut du système
• Informations sur une quantité suffisante de carburant pour effectuer l'opération requise
• Adresse du compte auquel appartient le code exécutable
• Adresse de l'expéditeur de la transaction - initiateur de l'opération en cours
• Adresse du compte - l'initiateur du code exécuté (peut différer de l'adresse de l'expéditeur-initiateur)
• Informations sur la quantité de carburant requise pour effectuer la transaction
• Entrée pour le fonctionnement
• Le montant de Wei qui doit être envoyé sur le compte de ce compte à la suite de la transaction en cours
• Informations sur le code machine exécutable
• Informations d'en-tête de bloc pour le bloc actuel
• Profondeur du message actuel ou de la création du contrat

Immédiatement avant le démarrage du programme, la mémoire système est complètement vide et le compteur de commandes est nul.

PC: 0 STACK: [] MEM: [], STORAGE: {} 

Ensuite, dans VME, une transaction récursive commence: calculer l'état du système et l'état de la machine pour chaque cycle. L'état du système est l'état global d'Ethereum. L'état de la machine comprend:

• quantité disponible de carburant;
• compteur de commande;
• contenu de la mémoire;
• nombre actif de mots en mémoire;
• empiler le contenu.

Les éléments de la pile sont ajoutés ou supprimés du bord gauche de l'extrait de code.

Pour chaque cycle, une certaine partie est prélevée sur la quantité de carburant restante, tandis que le compteur de commandes est augmenté.

Il existe trois options possibles pour terminer le cycle:

1. Les opérations effectuées par la machine atteignent un état exceptionnel (par exemple, en raison du manque de carburant virtuel, d'instructions incorrectes, d'un nombre insuffisant d'éléments de pile, d'une valeur de l'élément de pile dépassant la taille de 1024 bits, d'une affectation JUMP / JUMPI incorrecte) et, ainsi, le processus d'exécution de l'opération est suspendu.
2. Le flux passe au cycle suivant.
3. Les opérations effectuées par la machine arrivent à leur conclusion logique (achèvement du processus)

Si les calculs effectués par la machine aboutissent à une conclusion logique, et non à un état exceptionnel, en conséquence, la machine donne l'état résultant, ainsi que des informations sur le carburant restant et la sortie résultante.

Ce sont les choses. Vous et moi venons d'apprendre la partie la plus complexe et la plus déroutante d'Ethereum. Ne vous inquiétez pas si vous ne comprenez pas complètement quelque chose: vous n'avez pas besoin de vous plonger dans chaque petite chose et de comprendre tous les processus qui se déroulent dans ce système, à moins que vous ne l'étudiiez vraiment complètement et travailliez à un niveau assez profond.

Conception du bloc final

Voyons enfin ce qui arrive aux blocs de transaction lors de leur exécution finale.

L '«exécution finale» peut se produire de deux manières, selon que nous créons un bloc ou qu'il a déjà été créé. Dans le cas où nous ne créons qu'un bloc, la conception finale signifie le processus d'extraction du bloc actuel. En revanche, si un bloc a déjà été créé, alors une telle définition signifie le processus de validation du bloc courant. Dans les deux cas ci-dessus, quatre conditions doivent être remplies pour la conception finale du bloc.

1) Validation (ou, dans le cas de l'extraction, détermination) des omemers: chaque bloc omemer qui se trouve dans l'en-tête de bloc doit avoir un en-tête de bloc valide et être le sixième descendant du bloc actuel.

2) Validation des transactions: la valeur gasUsed pour le bloc courant doit être égale à la valeur de la quantité totale de carburant utilisée pour effectuer toutes les transactions listées dans ce bloc.

3) Objet du paiement (uniquement dans le cas de l'exploitation minière): 5 unités d'éther sont attribuées au bénéficiaire pour l'extraction de chaque bloc (conformément à la proposition EIP-649, ce paiement sera réduit à 3 unités d'éther). De plus, pour chaque ommer, le bénéficiaire du bloc actuel se voit attribuer un paiement sous la forme d'un 1/32 supplémentaire du paiement total pour le bloc actuel. Et le dernier: le bénéficiaire du bloc d'ommers se voit également attribuer un paiement sous la forme d'un certain montant, pour la détermination duquel il existe un chiffre spécial.

4) Vérification des valeurs d'état et de nonce: pour exécuter cette procédure, vous devez vous assurer que toutes les transactions sont terminées, ainsi que changer les états résultants. Après quoi, vous devrez également définir un nouveau bloc après l'envoi du paiement pour ce bloc. Le processus de vérification se produit en comparant l'état final avec l'état de l'arborescence de préfixes stockée dans l'en-tête.

Exploitation minière de preuve

Dans la section «Blocs», nous nous sommes brièvement familiarisés avec un concept tel que la complexité des blocs. L'algorithme, grâce auquel le concept de complexité des blocs est né, est appelé Proof of Work (PoW).

L'algorithme PoW utilisé dans le système Ethereum est appelé Ethash (anciennement, mais appelé Dagger-Hashimoto).

Cet algorithme a la forme suivante:


où m est mixHash; n est nonce; Hn - le titre du nouveau bloc (nonce et mixHash ne sont pas inclus ici, car ces valeurs doivent être calculées); Hn - nonce pour l'en-tête de bloc; d est l'ensemble de données DAG.

Dans la section «Blocs», nous nous sommes également familiarisés avec les différentes valeurs fournies pour l'en-tête de bloc. Ceux-ci, comme vous vous en souvenez, incluent des valeurs telles que mixHash et nonce. Permettez-moi de vous rappeler à nouveau:

• mixHash est un hachage qui, avec une valeur nonce, confirme que suffisamment de calculs ont été effectués pour le bloc actuel.
• nonce est également un hachage qui, avec la valeur mixHash, confirme que suffisamment de calculs ont été effectués pour le bloc actuel.

Par conséquent, PoW est nécessaire pour calculer les valeurs ci-dessus.

Expliquer exactement comment mixHash et nonce sont calculés à l'aide de la fonction PoW est une tâche assez compliquée et, en fait, un article entier peut être consacré à ce point. Mais en bref, ce qui suit se produit:

La valeur «germe» est calculée pour chacun des blocs. Pour compter chacune des graines, il y a son propre «intervalle», chacun des intervalles étant égal à 30 000 blocs. Pour chaque intervalle, la graine est un hachage égal à une série de zéros de 32 octets. Pour chaque intervalle suivant, un hachage spécifique est fourni pour la graine précédente. En utilisant cette graine, le nœud trouve la valeur du "hachage" pseudo-aléatoire.

Un tel hachage joue un rôle très important, car avec son aide, nous pouvons mieux comprendre ce que sont les «nœuds minces», qui ont été discutés dans les articles précédents. Le but des nœuds légers est de permettre à certains des nœuds de vérifier efficacement certaines transactions sans avoir besoin de stocker l'ensemble complet des données de la chaîne de blocs. Un nœud léger peut valider une transaction en utilisant uniquement ce hachage. Cela est dû au fait que ce hachage peut recréer le bloc dont il a besoin pour la vérification.

En utilisant ce hachage, le nœud peut créer un paquet de données DAG dans lequel chaque élément dépend d'un petit nombre de pseudo-éléments de hachage randomisés. Chaque mineur novice doit d'abord créer son propre package de données complet. Un paquet de données distinct est stocké dans le système pour chacun des mineurs, tandis que le volume de ces données augmente constamment.

Par exemple, un mineur peut prendre toutes les parties aléatoires d'un paquet de données et les utiliser dans une fonction mathématique afin de hacher ces parties pour mixHash. Un tel mineur sera en mesure de définir en permanence la valeur de mixHash jusqu'à ce que les données initiales soient reçues sous la forme d'une valeur nonce. Lorsque cette condition est remplie, une telle valeur de nonce sera considérée comme valide et un bloc peut être ajouté au circuit.

L'exploitation minière comme mécanisme de défense

En général, le but de PoW est de prouver cryptographiquement que certains calculs visaient à obtenir un résultat spécifique (valeurs nonce). Il se trouve qu'il n'y a pas d'autre moyen de trouver le nonce, dont la valeur ne dépasse pas une certaine limite, sauf en listant toutes les options possibles, jusqu'à trouver celle qui est requise . La distribution de la sortie pour un hachage de fonction constamment utilisé se produit uniformément. Ainsi, nous savons avec certitude que le temps nécessaire pour trouver la valeur de nonce dépend clairement du seuil de complexité : plus le seuil de complexité est élevé, plus la recherche de la valeur de nonce requise prendra plus de temps. L'algorithme PoW représente le concept de complexité utilisé dans cette blockchain.

Que signifie blockchain sécurisée? La réponse est assez simple: une blockchain sécurisée est une blockchain à laquelle absolument TOUS LES UTILISATEURS feront confiance. Comme je l'ai écrit ci-dessus, s'il y a plus de deux chaînes dans la blockchain, il est logique de supposer que les utilisateurs ne se sentiront pas en confiance en travaillant avec la blockchain, car personne ne peut dire avec précision laquelle des chaînes présentées est valide.

Pour cela, l'algorithme PoW est utilisé: il assure l'unité de la chaîne dans la blockchain, empêchant la création d'autres chaînes de blocs pouvant affecter l'historique des transactions (par exemple, créer de fausses transactions ou supprimer ou modifier des transactions existantes). Ainsi, pour qu'un attaquant puisse d'abord valider ses blocs, il devra constamment déterminer la valeur de nonce, et ce, plus rapidement que tous les autres utilisateurs du réseau (j'espère que vous vous souvenez du protocole GHOST que j'ai décrit précédemment). Bien sûr, pour un attaquant, cette méthode ne sera pas réalisable, à moins qu'il n'ait à sa disposition la plupart des ressources minières du réseau - un tel scénario est connu comme une attaque de 51% .

L'exploitation minière comme moyen de distribution de financement

En plus du fait que l'algorithme PoW assure le fonctionnement sûr de la blockchain, il distribue également la récompense aux utilisateurs dont les calculs ont été utilisés pour garantir la sécurité. J'ai déjà écrit ci-dessus que les mineurs reçoivent une récompense pour avoir miné tel ou tel bloc, ainsi que:

• récompense de 5 unités d'éther pour le bloc "gagnant" (bientôt ce chiffre devrait tomber à 3 unités)
• coût du carburant consommé à la suite d'une transaction dans un bloc
• récompense supplémentaire pour l'inclusion des ommers dans le bloc

Pour garantir la cohérence du fonctionnement de la méthode PoW - qui est nécessaire pour garantir la sécurité - et la distribution des récompenses, Ethereum adhère constamment à deux principes, présentés ci-dessous:

• Tout d'abord, pour attirer le plus d'utilisateurs possible sur la plateforme. En d'autres termes, l'utilisation de cette plateforme ne devrait pas poser de problème à l'utilisateur: il ne doit pas utiliser d'algorithmes très complexes ni utiliser du matériel inconnu. En outre, le processus de distribution de la rémunération devrait également être clair et simple pour quiconque est prêt à dépenser une partie de l'énergie utilisée par son ordinateur pour obtenir plusieurs unités d'éther chéries.
• Deuxièmement, pour empêcher la distribution disproportionnée de récompenses et d'autres ressources pour un nœud particulier: tout nœud de ce type pour lequel une distribution disproportionnée des ressources aura un impact énorme sur la définition de la blockchain canonique, ce qui affecte négativement la sécurité du système dans son ensemble.

Par exemple, dans le système Bitcoin, il y a un problème avec la mise en œuvre des deux principes ci-dessus: son algorithme PoW utilise la fonction de hachage SHA256. Le problème de ce dernier est que sa solution peut être beaucoup plus simple dans le cas de l'utilisation de matériel spécial - ASIC.

Afin d'éviter de telles perforations dans Ethereum, un algorithme PoW spécial avec mémoire série ( Ethhash ) est utilisé. La structure de l'algorithme est construite de telle manière que pour calculer la valeur de nonce, il est nécessaire d'utiliser une grande quantité de mémoire et une bande passante élevée de la connexion. Les conditions requises pour avoir une grande quantité de mémoire signifient qu'il sera très difficile pour un ordinateur avec une quantité normale de mémoire de calculer simultanément plusieurs valeurs de nonce en même temps. En ce qui concerne les exigences de débit élevé, même pour un ordinateur ultrarapide, la détection de plusieurs valeurs nonce en même temps sera une tâche ardue. Ainsi, grâce à de telles caractéristiques de ce système, la probabilité de centralisation des risques est réduite et, de plus, des conditions plus uniformes sont créées pour le fonctionnement des différents nœuds effectuant la vérification.

Soit dit en passant, il n'y a pas si longtemps, j'ai appris qu'Ethereum allait passer de l'algorithme PoW à une certaine méthode appelée Proof-of-pieu (Proof-of-pieu). Cette méthode à elle seule mérite un article séparé pour examen et discussion.

Conclusion

Eh bien, nous arrivons ici à la conclusion logique de notre article.

En fait, cet article donne matière à réflexion. Ne vous inquiétez pas du tout si vous maîtrisez cet article à partir de la deuxième ou de la troisième fois. J'ai personnellement relu plusieurs fois le papier jaune et le papier blanc pour Ethereum avant de commencer à me plonger dans l'essence de la question.

J'espère vraiment que cet article vous a été utile. Si vous trouvez des erreurs, je vous serais très reconnaissant de m'en faire part.

Sources:

github.com/ethereum/yellowpaper
medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369

- Service de promotion ICO n ° 1 pour reddit et bitcoin .