BlockChain et Ethereum sont présentés

Il est originaire:https://jysperm.me/2016/05/blockchain-slides/

Cet article est une compilation d'un partage technique que j'ai effectué sur LeanCloud à la fin du mois de mars, en supposant que le lecteur ait déjà des connaissances de base en cryptographie et une compréhension préliminaire de la mise en œuvre de Bitcoin.

La blockchain, également appelée blockchain, peut être considérée comme une sorte de HashTree (arbre de hash), ce qui lui confère certaines caractéristiques similaires:

Les images sont dehttp://happypeter.github.io/bitcoin_basics/book/017_merkle_tree.html

C'est-à-dire que dans une structure arborique, chaque nœud terminal a une valeur de parallèle, tandis que les valeurs de parallèle des nœuds non terminaux proviennent de la parallèle de toutes les valeurs de parallèle de tous ses nœuds directs, de sorte que chaque nœud contient directement ou indirectement les informations de tous ses nœuds. Par conséquent, chaque fois que la valeur de parallèle de n'importe quel nœud terminal change, les valeurs de parallèle de tous ses nœuds parentaux changent.

Je peux citer une application de HashTree: " 100% de preuve de réserve ", qui appartient à la catégorie des " preuves de connaissance zéro ". Nous pouvons envisager un scénario dans lequel le détenteur de Bitcion doit envoyer du Bitcoin à un échange pour effectuer une transaction, et en théorie l'échange peut déplacer cet argent (le solde de tous les comptes enregistrés par les utilisateurs), ce que les utilisateurs ne veulent pas voir, et l'échange souhaite également être transparent: l'échange publie d'abord une adresse Bitcoin qu'il détient, tout le monde confirme que l'échange détient autant de Bitcoin en réserve, mais comment prouver que cet argent est en fait plus grand que la somme exacte de tous les utilisateurs? En d'autres termes, comment chaque utilisateur peut-il accepter d'être inclus dans son solde total sans divulguer le solde de chaque utilisateur (qui révélerait la vie privée de l'utilisateur)?

Les images sont dehttp://blog.bifubao.com/2014/03/16/proof-of-reserves

Nous pouvons construire un HashTree où tous les nœuds d'extrémité représentent un utilisateur et contiennent le solde de l'utilisateur.ΣUn ensemble d'identifiants d'utilisateur (par exemple, adresse de boîte aux lettres)hLe résultat de l'analyse est le résultat de l'analyse de l'ensemble des nœuds.sum) et les fractions de toutes les informations des sous-nœuds)))hashPour chaque utilisateur, il suffit de lui montrer ses propres nœuds terminaux et ses nœuds frères, tous ses nœuds parents et les nœuds frères de ses nœuds parents, car l'utilisateur peut confirmer que son solde est inclus dans le nœud père et finalement inclus dans le nœud racine en remontant progressivement vers le nœud père.

Ainsi, l'information présentée à chaque utilisateur n'est que sa propre information et une partie de l'information agrégée, et chaque utilisateur peut confirmer que son propre solde est contenu dans le nœud racine sans être informé des autres soldes utilisés.hPoure4df9d12Le nœud de l'application ne devrait pas être un nœud de fin représentant l'utilisateur, mais un nœud d'information agrégé (ce nœud peut contenir un utilisateur avec un solde de 3333, et un utilisateur fictif avec un solde de 0) afin d'éviter de divulguer les informations privées d'un utilisateur.

La prochaine fois, nous allons voir Git, qui est en fait une application blockchain très typique:

Les images sont dehttp://gitbook.liuhui998.com/1_2.html(GPL v2)

Dans Git, un fichier, qu'il s'agisse d'un bloc, d'un arbre ou d'un engagement, a un Hash déterminé par son contenu, et si deux objets ont le même contenu, ils ont le même Hash. Dans Git, l'histoire de l'ensemble du référentiel est une Blockchain, chaque engagement est équivalent à un bloc.

Git utilise la Blockchain pour définir un historique unique pour le référentiel. Eh bien, si un Commit est modifié, tous les Hashs de Commits qui le suivent seront modifiés. Bien sûr, comme Git n'est qu'un outil de contrôle de version, cela ne vous empêche pas de modifier l'historique.push --forceIl y a aussi un article sur les modifications apportées par les auteurs de l'ouvrage.

Une autre application classique de la Blockchain est Bitcoin, qui a diffusé le mot Blockchain (ce concept existe depuis toujours):

Les images sont dehttps://commons.wikimedia.org/wiki/File:Bitcoin_Block_Data.png(CC-BY-SA-3.0)

Dans Bitcoin, chaque bloc contient une série de transactions et le Hash du bloc précédent, tandis que l'ensemble de la blockchain constitue un seul registre décentralisé. Comme un nouveau bloc n'est créé qu'une fois tous les dix minutes, et que le bloc une fois créé reste sur la blockchain pour toujours, la blockchain fixe l'ordre des transactions, maintient l'ordre précédent des transactions et détermine si un compte a suffisamment de solde pour lancer une transaction.

Le Bitcoin

La première partie de ce partage est une simple revue de Bitcoin.

La génération de blocs dans Bitcoin est réalisée par une "proof of work", c'est-à-dire que tous les "mineurs" impliqués dans la "mine" effectuent un calcul partiel, lié à la puissance de calcul, de nature aléatoire, jusqu'à ce qu'un nombre aléatoire répondant à certaines conditions soit calculé, pour obtenir le droit de publier un bloc.

Par défaut, chaque mineur va toujours faire confiance à la "chaîne la plus longue" pour calculer le prochain bloc sur la base de la chaîne la plus longue connue et qui respecte les règles, sinon votre puissance de calcul sera gaspillée en blanc.

Bitcoin est conçu pour générer un nouveau bloc toutes les 10 minutes, ce qui est réalisé en observant ensemble le temps d'intervalle entre les blocs précédents pour ajuster la difficulté de la génération du prochain bloc. Lorsque les blocs précédents sont générés plus rapidement que prévu, les gens pensent que le prochain bloc devrait avoir une difficulté plus élevée.

Normalement, chaque nœud de Bitcoin a besoin de stocker une base de données Blockchain complète pour confirmer si une transaction est légitime. Il est nécessaire de vérifier si l'initiateur de la transaction a suffisamment de solde pour lancer la transaction. Mais maintenant, la blockchain complète est de 66G et augmente à un rythme d'environ 0.1G par jour.

Les images sont dehttps://github.com/ethereum/wiki/wiki/White-Paper

• Blockchain Logiciels Logiciels Logiciels de changement de statut
• Transaction Boucle de transaction Boucle de changement d'état
• Le blocage est un "consensus" sur l'état actuel.

En fait, nous pouvons imaginer la Blockchain de Bitcoin comme une "machine d'état", la Blockchain entière est un "livre" de l'état dans lequel sont stockés les enregistrements de chaque transaction, à partir desquels nous pouvons déduire l'état de l'ensemble du livre à un moment donné. Eh bien, chaque transaction est une modification de l'état, tandis que chaque bloc est un "consensus" des mineurs de l'ensemble du réseau Bitcoin sur l'état actuel, car Bitcoin génère un nouveau bloc toutes les 10 minutes, ce qui équivaut à un consensus sur le solde de tous les comptes toutes les 10 minutes, et entre ces dix minutes, l'état du compte est en fait un "état de chaos".

Coins alternatifs

Beaucoup d'autres crypto-monnaies, souvent appelées " alt coins ", ont également été dérivées du bitcoin.

Le premier est d'utiliser son propre réseau, indépendant de Bitcoin, ce qui permet à la crypto-monnaie de concevoir ses propres protocoles et règles avec une grande flexibilité, mais la défense contre les attaques malveillantes sera très faible car le nombre d'utilisateurs est difficile à atteindre.

La seconde est d'utiliser le réseau de Bitcoin pour mettre en œuvre le "méta-protocole" qui implique des informations personnalisées sur les transactions de Bitcoin pour réaliser sa propre logique. Les avantages sont de pouvoir utiliser la taille de la puissance de calcul de Bitcoin pour résister aux attaques, mais en même temps, comme tous les mineurs ne respectent pas les règles de Bitcoin, ils ne peuvent pas empêcher les blocs non conformes d'entrer dans la Blockchain, ne peuvent filtrer que les transactions non conformes sur le client et ne peuvent pas utiliser la fonction de confirmation simplifiée fournie par Bitcoin mentionnée ci-dessus.

Pour ces monnaies, Bitcoin peut fournir une blockchain avec une grande participation de mineurs, capable de résister à des attaques malveillantes à grande échelle, et peut également contenir des données personnalisées sur les transactions de Bitcoin, ce qui laisse une certaine marge de manœuvre pour la mise en œuvre des monnaies.

Bitocin fournit également uneScénario BitcoinIl est utilisé pour réaliser des transactions plus complexes, mais comme ce n'est pas une fonctionnalité centrale de Bitcoin, il ne peut effectuer que des opérations relativement simples, ne peut lire que des données très limitées sur la Blockchain, et il est difficile d'écrire une logique universelle complète Turing en raison de l'absence de mécanisme de cycle.

Éthereum

Les images sont dehttps://www.ethereum.org/assets(CC 3.0)

Ethereum est une plate-forme d'applications décentralisée basée sur la blockchain, qui combine l'infrastructure de Bitcoin et la technologie de la blockchain basée sur la cryptographie pour créer une plate-forme universelle et compléter certaines fonctionnalités manquantes du réseau Bitcoin afin que les développeurs puissent exécuter leurs propres applications décentralisées sur la blockchain.

Avant d'entrer dans le détail de l'Ethereum, je vais d'abord vous présenter les deux grands fondements de ce que je considère comme des réseaux décentralisés: la cryptographie et les jeux. Bien sûr, il est inutile de dire que la cryptographie ne fait que garantir la sécurité mathématiquement avec des algorithmes de cryptage à clé publique, de signature numérique, d'assemblage et d'extraction.

Cependant, dans le monde numérique, la publication d'un élément de données n'est pas coûteuse, il n'y a pas de "bénéfice" et de "perte", il faut donc établir un lien avec le monde physique pour définir "bénéfice". Par exemple, dans le réseau Bitcoin, si un attaquant souhaite modifier artificiellement la direction de Blcokchain, il doit disposer d'une puissance de calcul supérieure à celle de tous les autres mineurs.

Ainsi, dans un réseau décentralisé, tous les problèmes ne sont pas résolus par la "technologie", et les parties hors de portée de la technologie doivent être résolues par des bénéfices, par des incitations économiques. En raison de la nécessité des "incitations économiques", Ethereum dispose également d'un système de portefeuille (l'unité monétaire s'appelle "Ether") où chaque utilisateur a une adresse de portefeuille comme unique identité, ce qui est assez similaire à Bitcion à ce point.

Contract est le concept le plus important introduit par Ethereum. Dans Bitcoin, toutes les adresses appartiennent à un utilisateur. Quand nous disons "utilisateur", nous parlons en fait d'une paire de clés publiques et privées. Mais dans Ethereum, en plus de l'adresse détenue par une clé, il y a une adresse détenue par le "code", le contrat.

• Le calcul est donc répétable. Les résultats des calculs ne doivent pas être stockés sur la blockchain car ils peuvent être recalculés à tout moment.
• Vous pouvez appeler des fonctions dans d'autres contrats (le code et les données des autres contrats sont également présents sur la blockchain).
• Dans le processus d'exécution, de nouvelles transactions peuvent être créées (manipuler le solde de votre portefeuille) qui peuvent être utilisées pour exécuter d'autres contrats.

Pour commencer, voici un exemple de portefeuille partagé, qui permet de créer des portefeuilles multijoueurs dans le client officiel d'Ethereum:

Comme illustré ci-dessous, cette fonction permet de créer une adresse de portefeuille partagée avec 2 autres personnes, dont chacune utilise jusqu'à 100 Ether par jour. Si cette limite est dépassée, le consentement de l'autre personne est requis.

Cette fonctionnalité crée en fait un contrat, et la logique ci-dessus est décrite par le code dans le contrat. Lorsque vous souhaitez dépenser de l'argent dans ce portefeuille partagé, vous devez envoyer un message à ce portefeuille partagé (une transaction est un message, le montant de la transaction peut être nul et ne peut contenir que des données), puis le code du portefeuille partagé est exécuté, si la demande de dépense est conforme à la logique ci-dessus, une véritable transaction de dépense est lancée, sinon la demande de dépense est rejetée sans une véritable dépense.

Un autre exemple est le "contrat de couverture", qui a toujours été critiqué pour la volatilité de Bitcoin en tant que monnaie numérique (et le taux de change de la monnaie légale), qui est souvent doublé ou décroché en une journée, mais qui peut être résolu dans une certaine mesure si un contrat de couverture est mis en œuvre avec un contrat.

Nous appellerons les personnes qui souhaitent maintenir la valeur de la monnaie inchangée " les risqueurs " et les autres personnes qui sont prêtes à prendre le risque de fluctuation de la monnaie et à en tirer profit " les risqueurs ", afin qu'elles puissent s'entendre sur un montant (par exemple, 1000 CNY) et une fenêtre de temps (par exemple, un mois) et créer un contrat qui exécute la logique suivante:

• Les épargnants envoient 1000 CNY d'Ether à l'adresse du portefeuille du Contract, et les épargnants envoient 1000 CNY (ou plus) d'Ether au Contract en échange d'un contrat (si personne n'engage, les épargnants peuvent récupérer leur Ether).
• Un mois plus tard, l'épargnant peut récupérer de son contrat 1000 éthers CNY, et l'éther restant est récupéré par l'épargnant, quel que soit le taux de change entre l'éther et le CNY.

Si la valeur de l'éther augmente, les preneurs de risque gagnent, si la valeur de l'éther diminue, les preneurs de risque perdent, mais les évitants de risque ne perdent pas. Bien sûr, les évitants et les preneurs de risque peuvent s'entendre à l'avance sur un "frais d'assurance" que les évitants de risque doivent payer, ou bien ils peuvent s'entendre sur le fait que les preneurs de risque doivent fournir plusieurs fois plus de 1 000 CNY ("le plus élevé le taux de multiplication, le plus grand est le risque à supporter").

Dans l'exemple ci-dessus, il y a un autre problème qui n'est pas très bien résolu: comment déterminer le taux de change entre l'éther et la devise, comme nous l'avons mentionné précédemment, Contract n'a accès qu'aux données de la blockchain, alors que la devise est une donnée qui existe dans le monde physique et non dans le monde cryptographique, et nous devons introduire ce type de "données du monde non cryptographique" dans la blockchain via un mécanisme.

Nous pouvons concevoir un autre contrat pour spécifier la logique suivante pour obtenir le taux de change entre l'Ether et la monnaie légale dans le monde physique, dans chaque fenêtre de temps (par exemple, une heure):

• Tout le monde peut verser une caution à Contract et fournir un taux de change.
• À la fin de la fenêtre de temps, Contract calcule et publie la moyenne des taux de change offerts par tous (en fonction du montant du cautionnement).
• Le montant de la caution collectée sera réparti entre les 25% de la population qui se rapprochent le plus de la moyenne (en fonction de la caution pondérée).

Pour n'importe quel participant, le fait de soumettre un taux de change réel est plus susceptible d'obtenir une récompense, car il ne connaît pas les offres des autres, alors que le fait de soumettre un taux de change déroutant est plus susceptible de perdre la garantie.

Bien sûr, il y a quelques failles dans cette règle, par exemple, si une personne a une très grande quantité de garantie, elle peut tirer la moyenne à un prix supérieur ou inférieur au taux de change réel tout en obtenant une récompense, et faire perdre la garantie à d'autres personnes qui fournissent le taux de change exact. Mais en réalité, dans le monde physique, si vous avez beaucoup d'argent, vous pouvez également augmenter ou réduire le prix d'un produit, mais la taille de l'argent électronique est faible par rapport au monde physique et cela ne nécessite pas beaucoup d'argent.

L'autre faille est que " tout le monde peut verser des garanties sur le contrat et fournir une devise ". Cette étape est réalisée en créant une transaction, et toutes les transactions sont écrites sur la blockchain, de sorte que la devise que vous soumettez est en fait visible par d'autres personnes, créant ainsi une opportunité pour les attaquants malveillants.

Comme nous l'avons mentionné précédemment, Contract peut lire les données de la Blockchain, mais les données de la Blockchain sont déterminées, et si nous voulons réaliser une application similaire au jeu, d'où vient un nombre aléatoire?

Une source de nombres aléatoires que l'on peut imaginer est le Hash du prochain bloc, et dans la plupart des cas, ce degré de hasard est suffisant. Mais en réalité, le mineur peut manipuler ce nombre aléatoire dans une certaine mesure, en supposant qu'un mineur participe à un pari et que le gain du pari est supérieur à celui de l'extraction d'un bloc, alors si ce mineur extrait un bloc qui lui fera perdre le pari, il est évident que le mineur choisira de ne pas publier le nouveau bloc, ce qui est plus évident dans le cas d'un mineur individuel.

Nous avons donc besoin d'introduire un mécanisme similaire à celui de la collecte de devises pour collecter un nombre aléatoire de graines, puis utiliser ces graines pour calculer un nombre aléatoire à la fin de chaque fenêtre de temps. Mais comme la collecte de devises, puisque les participants créent des transactions pour réaliser le taux de soumission, les nombres aléatoires soumis par chacun sont donc visibles pour les autres entre les deux fenêtres de temps, de sorte qu'une personne qui a déjà participé à un pari peut soigneusement sélectionner un nombre aléatoire de graines pour que le nombre de graines déjà soumises par d'autres personnes plus le nombre de nouvelles graines aléatoires produites correspondent à ses attentes.

Il est donc nécessaire de diviser la fenêtre de sélection en deux pour obtenir un nombre aléatoire que personne ne peut prédire et intervenir:

• Première étape: tout le monde peut verser une caution au Contract et fournir "la valeur de l'échantillon d'une graine choisie au hasard".
• Deuxième étape: les participants à la première étape fournissent des graines non séquencées au Contract.
• Fin de la phase 2: Le contrat sépare toutes les graines légitimes, génère un ensemble de nombres aléatoires et les publie; retour de la phase 2: garantie de la personne qui a fourni la bonne graine.

Dans la première étape, vous ne connaissez que les valeurs de la série de semences soumises par d'autres personnes, mais vous ne connaissez pas les semences réelles et vous ne pouvez donc pas construire une semence pour intervenir; dans la deuxième étape, tout le monde ne fait que confirmer les semences soumises dans la première étape, ne peut pas soumettre de nouvelles et ne peut pas empêcher les autres de soumettre des semences.

Comme nous l'avons mentionné précédemment, Bitcoin Script n'offre pas la possibilité de faire des cycles, des récursions, des sauts, etc. Peut-être que Bitcoin est un moyen de contrôler le temps d'exécution de Bitcoin Script, car, selon le "théorème d'arrêt" de Turing, les programmes écrits par un langage de programmation complet Turing ne peuvent pas toujours être jugés uniquement du point de vue de l'analyse statique pour déterminer s'ils s'arrêteront après des étapes limitées, de sorte que les attaquants malveillants peuvent construire une transaction qui provoquera un cycle mortel pour perturber le fonctionnement normal des mineurs.

L'Ethereum, quant à lui, contourne le problème en utilisant une "incitation économique" qui consiste à exécuter le contrat sous forme d'opcode (code d'opération) sur une machine virtuelle appelée EVM (Ethereum Virtual Machine), une machine virtuelle dotée d'un "compte", qui définit, dans la norme de l'EVM, la quantité de gaz consommée par chaque opcode en fonction de la mémoire et du temps de traitement nécessaires à l'opération, une ressource de calcul achetée par Ether.

Puis nous revenons sur le problème de l'intervalle de consensus, mentionné précédemment, Bitcoin un nouveau bloc apparaît toutes les 10 minutes, c'est-à-dire que le réseau entier arrive à un "consensus" toutes les 10 minutes, donc une transaction Bitcoin normale prend une dizaine de minutes pour être confirmée, et peut-être une heure avant que la transaction soit considérée comme fiable.

Un temps de consensus nettement plus court est une meilleure expérience pour les utilisateurs, pourquoi Bitcoin ne réduit-il pas le temps de blocage? C'est parce que l'intervalle de consensus plus rapide augmente dans une certaine mesure les avantages d'un "pool de mines centralisé".

Quand un mineur A creuse un nouveau bloc, il diffuse ce bloc, et les autres commencent immédiatement à travailler sur ce nouveau bloc dès qu'ils reçoivent ce message; tandis que d'autres calculent que le temps entre "A creuse un nouveau bloc" et "A reçoit un message de diffusion" est effectivement gaspillé, tandis que les autres mineurs du pool centralisé n'ont pas ce problème, car ils peuvent obtenir plus rapidement l'information sur le nouveau bloc généré et commencer à travailler sur le nouveau bloc immédiatement.

La durée de cette diffusion peut être d'une dizaine de secondes, ce qui n'est pas très important pour 10 minutes, mais si l'on réduit l'intervalle de consensus, les avantages d'un pool de mines centralisé seront de plus en plus évidents. Mais Ethereum a résolu ce problème en introduisant le concept de "Uncle Block", réduisant l'intervalle de consensus à 15 secondes, ce qui est une grande amélioration par rapport au Bitcoin dans la vitesse de confirmation des paiements.

Dans la blockchain de Bitcoin, un bloc ne peut avoir qu'un seul bloc-mère et un seul bloc-fils. Mais dans Ethereum, un bloc nouvellement créé peut avoir un seul bloc-mère et plusieurs blocs-fils. Revenons à l'exemple ci-dessus. Si un nouveau bloc est extrait à A, mais que d'autres n'ont pas encore reçu la diffusion, si quelqu'un extrait un nouveau bloc, mais que la diffusion n'a pas été acceptée à la fin de la diffusion, il est possible que ce bloc devienne le "bloc-mère" du bloc suivant.

Les images sont dehttps://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time

Problèmes non résolus

Dans la section suivante, je vais vous présenter quelques problèmes qui n'ont pas encore été résolus par Ethereum.

Tout d'abord, le consensus actuel d'Ethereum est que, comme pour Bitcoin, il est toujours garanti par POW (proof of work) et que seuls les nœuds qui ont terminé une certaine quantité de travail peuvent participer à la production de blocs. Le problème avec la preuve de travail est que cela gaspille beaucoup de puissance de calcul pour assurer la sécurité du réseau, bien que cela soit basé sur l'idée de " stimulation économique " mentionnée précédemment, mais cela peut être amélioré. Ehtereum pense qu'un meilleur moyen est de remplacer la preuve de travail par POS (prove de propriété), ce qui peut considérablement améliorer l'efficacité du réseau.

Puisque l'éther est une valeur en soi, pourquoi ne pas l'utiliser comme une incitation économique? Le POS est une garantie que chaque nœud qui souhaite participer à la production d'un bloc (minage au sens traditionnel) (appelé vérificateur) doit payer un montant de garantie au système (ce système signifie que tous les nœuds considèrent que le montant de la garantie est "gelé") et que chacun paie son propre montant de garantie pour le bloc qui pourrait devenir le prochain bloc.

Ce modèle est en fait très similaire à POW, dans lequel les mineurs " parient " avec leur propre puissance de calcul, et s'il y a une chaîne plus longue, il est nécessaire de passer à cette chaîne pour continuer à miner. Eh bien, car plus il y a de chaînes impliquées, plus il est probable que la chaîne soit correcte, et finalement un consensus est atteint.

Les POS augmenteront certainement le débit de l'ensemble du réseau. Il n'y aura plus besoin de consensus sur le fait de faire des calculs inutiles, le nombre d'opérations par nœud sera proche du nombre d'opérations d'exécution du code dans le contrat et de vérification des données.

Bien sûr, le POS n'a pas encore été adopté car il y a encore des problèmes non résolus, dont l'un est le problème de l'attaque à 51% comme dans le POW. Dans le POW, la puissance de calcul de 51% du réseau entier est centralisée avec une certaine limitation physique.

Un autre sujet est le " fragmentation ", que ce soit Bitcoin ou Ethereum, où toutes les transactions sont actuellement confirmées sur la même Blockchain, ce qui limite considérablement la capacité de calcul d'un réseau distribué.

Ethereum souhaite donc introduire un mécanisme de " fragmentation " dans le futur, pour diviser le réseau en plusieurs parties, afin de vérifier les transactions indépendamment les unes des autres. Cependant, les fragmentations peuvent se référer aux données des autres fragments à travers la structure des pointeurs, influencer les autres fragments par des appels asynchrones, de sorte que le réseau reste un tout pour l'utilisateur, mais la capacité de traitement du réseau sera très étendue.

Le contrat

Dans cette partie, je vais vous montrer quelques codes contractuels réels et fonctionnels. Contract peut être écrit dans de nombreux langages de paradigmes différents, qui seront finalement compilés en opcode et exécutés sur EVM.

contract Test {
  uint storedData; // State variable

  struct Voter { // Struct
    uint weight;
    bool voted;
    address delegate;
    uint vote;
  }

  event HighestBidIncreased(address bidder, uint amount); // Event

  function func() { // Function
    if (msg.sender.balance < 10 finney) {
        msg.sender.send(10 finney);
    }

    sha256("...");

    address nameServer = 0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2;
    nameServer.delegatecall("isAvailable", "MyName");
    nameServer.call("register", "MyName");
  }
}

Voici une démonstration de quelques syntaxes de base dans lesquelles vous pouvez déclarer des variables d'état dans Solidity.uint storedData;Les valeurs de ces variables sont conservées à jamais sur la blockchain.structIl peut également définir des fonctions qui sont exécutées lors de la réception d'une transaction, et l'initiateur de la transaction peut choisir quelles fonctions exécuter, de sorte qu'un contrat peut fournir plusieurs fonctions pour effectuer des jugements logiques, des cycles, des modifications de valeurs dans les fonctions.

Le langage est doté de fonctionnalités utiles, comme les algorithmes de cryptographie courants.sha256Je ne suis pas d'accord avec vous.10 finneyVous pouvez aussi écrire l'adresse de votre portefeuille.0x72ba7d8e73fe8eb666ea66babc8116a41bfb10e2Je ne sais pas.msgLes contrats sont des variables globales intégrées qui permettent de lire les informations relatives à cette transaction, telles que l'initiateur, le montant, etc. Contract peut être appelé de deux manières:delegatecallL'exécution d'un autre contrat dans le contexte actuel est comme l'introduction d'une fonction de bibliothèque.callLa logique est de lancer une nouvelle transaction pour déclencher une autre Contract.

Alors, comment les contrats lisent-ils et écrivent-ils des données à partir de la blockchain? Cette tâche complexe est abstraite pour les " variables d'état " et les données stockées sont des variables d'état. En fait, les modifications apportées aux variables d'état lors de l'exécution d'un contrat ne sont pas stockées dans la blockchain, car le contrat est exécuté par un calcul de certitude.

Je vais ensuite vous montrer un contrat vraiment utilisable pour émettre son propre jeton basé sur le réseau Ethereum:

contract Coin {
    // The keyword "public" makes those variables
    // readable from outside.
    address public minter;
    mapping (address => uint) public balances;

    // Events allow light clients to react on
    // changes efficiently.
    event Sent(address from, address to, uint amount);

    // This is the constructor whose code is
    // run only when the contract is created.
    function Coin() {
        minter = msg.sender;
    }
    function mint(address receiver, uint amount) {
        if (msg.sender != minter) return;
        balances[receiver] += amount;
    }
    function send(address receiver, uint amount) {
        if (balances[msg.sender] < amount) return;
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        Sent(msg.sender, receiver, amount);
    }
}

Le code provient dehttp://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#subcurrency-example(MIT)

Ce contrat, appelé Coin, déclare deux variables d'état.minterLes créateurs de ce jeton sont en train de créer une fonction ().function Coin()La valeur de l'initiateur de la première transaction utilisée pour créer le contrat est attribuée à cette variable; une feuille de calcul de l'adresse du portefeuille est également déclarée.balancesLe nombre de personnes qui possèdent le jeton est calculé en fonction de l'adresse de chaque détenteur du jeton.

mintDans cette fonction, on détermine si l'initiateur de la transaction est le créateur du jeton, et si c'est le cas, on ajoute un certain nombre de jetons à l'adresse indiquée selon les paramètres de la fonction.sendCette fonction, qui peut être appelée par tout le monde, déduit une certaine quantité de solde de l'adresse de l'initiateur de la transaction (s'il y a suffisamment de solde) et l'ajoute à l'adresse de destination, ce qui équivaut à une fonction de transfert.

Nous avons aussi annoncé un appel à l'action.SentL'événement n'a en fait aucun rôle réel, mais il est simplement facile d'imprimer des événements critiques lors du débogage, ce qui facilitera l'implémentation future du client léger (le client léger accepte uniquement les événements et n'exécute pas réellement le contrat).

Ethereum fournit un IDE appelé Mix pour déboguer ce code, sur le côté droit du Mix, vous pouvez créer des blocs et des comptes pour tester votre contrat, et voir comment la valeur de chaque variable d'état change au cours de l'exécution. Il est à noter que le contrat ne peut pas être modifié une fois publié, son fonctionnement est déclenché uniquement par les transactions d'autres personnes, ce qui est très ennuyeux pour les programmeurs qui écrivent des bugs tous les jours.

Une fois que nous aurons terminé la rédaction, nous pourrons publier ce contrat sur le web avec le portefeuille Ethereum:

Vous pouvez suivre ce contrat après sa sortie en pointant vers l'interface détaillée du contrat:

Sur la gauche, vous pouvez voir les valeurs des deux variables d'état.minterLa valeur est mon adresse personnelle.balancesComme il s'agit d'une feuille de calcul, vous pouvez entrer une adresse pour demander son solde. Sur le côté droit, vous pouvez lancer une nouvelle transaction sur ce contrat, il y a un menu déroulant à choisir.sendoumintVous pouvez remplir le paramètre de transmission au contrat. Comme ici nous envoyons une transaction pour transmettre un message, et non pas pour transmettre de l'éther, nous n'avons pas à définir le montant de la transaction.

Je vais maintenant vous présenter un contrat très intéressant, qui a un effet de "Ponzi", c'est-à-dire que vous pouvez payer 1 Ether pour ce contrat pour vous joindre au jeu, et ensuite trois personnes qui se joignent à ce contrat paient 3 Ether à la première personne qui se joint à eux, dans l'ordre suivant:

contract Pyramid {
    struct Participant {
        address etherAddress;
    }

    Participant[] public participants;

    uint public payoutIdx = 0;

    // events make it easier to interface with the contract
    event NewParticipant(uint indexed idx);

    // fallback function - simple transactions trigger this
    function() {
        enter();
    }

    function enter() {
        if (msg.value < 1 ether) {
            msg.sender.send(msg.value);
            return;
        }

        if (msg.value > 1 ether) {
            msg.sender.send(msg.value - 1 ether);
        }

        uint idx = participants.length;
        participants.length += 1;
        participants[idx].etherAddress = msg.sender;

        NewParticipant(idx);

        // for every three new participants we can
        // pay out to an earlier participant
        if (idx != 0 && idx % 3 == 0) {
            // payout is triple, minus 10 % fee
            uint amount = 3 ether;
            participants[payoutIdx].etherAddress.send(amount);
            payoutIdx += 1;
        }
    }

    function getNumberOfParticipants() constant returns (uint n) {
        return participants.length;
    }
}

Le code est simplifiéhttps://ethereumpyramid.com/contract.html

Le code est assez simple, ce contrat déclare une chose.participantsL'arithmétique est utilisée pour stocker les adresses de portefeuille de tous les participants dans l'ordre, ou pour déclarer unpayoutIdxPour enregistrer le nombre de participants ayant déjà reçu 3 Ether.enterLa fonction principale de ce contrat est d'abord de vérifier certains paramètres, de garantir que chaque participant a payé 1 Ether, puis de placer le nouveau participant sur le marché.participantsÀ la fin de l'arithmétique, si le nombre de participants actuels est un multiple de 3, 3 Ether sont envoyés à la fin de l'arithmétique.payoutIdxLes participants sont invités à participer.payoutIdxIl est possible que les participants aient un lien vers le prochain article.

Liens de référence

HashTree:

• Le mot clé est Merkle Treehttp://happypeter.github.io/bitcoin_basics/book/017_merkle_tree.html
• 100% de réservehttp://blog.bifubao.com/2014/03/16/proof-of-reserves
• Modèle d'objet Githttp://gitbook.liuhui998.com/1_2.html

Bitcoin:

• (Alt Coin) NomCoinhttps://namecoin.info/
• Scénario Bitcoinhttps://en.bitcoin.it/wiki/Script
• Vérification simplifiée des paiementshttps://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification

Problème d'arrêt:

• Les limites du calcul (II): l'auto-indication et l'indéterminationhttp://songshuhui.net/archives/75957

Pour Ethereum:

• Éthereumhttps://www.ethereum.org/
• Le livre blanchttps://github.com/ethereum/wiki/wiki/White-Paper
• Vers un temps de blocage de 12 secondeshttps://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time

Réseau Ethereum:

• https://ethstats.net/
• https://etherchain.org
• https://live.ether.camp

Suivant de Ethereum:

• Casper, le petit génie bienveillanthttp://ethfans.org/posts/introducing-casper-friendly-ghost
• Comprendre la sérénité - Partie 2: Casperhttp://ethfans.org/posts/understanding-serenity-part-ii-casper
• (Papier sur l'évolutivité) Notes sur les protocoles blockchain évolutifshttps://github.com/vbuterin/scalability_paper
• Merkling dans Ethereumhttps://blog.ethereum.org/2015/11/15/merkling-in-ethereum/

Le contrat:

• ÐAPPShttp://dapps.ethercasts.com/
• Solitudehttps://solidity.readthedocs.org
• Ethereum et les oracleshttps://blog.ethereum.org/2014/07/22/ethereum-and-oracles
• Le contrat de la pyramide Ethereumhttps://ethereumpyramid.com/
• Un DAO travaillant comme RNG pour Ethereumhttps://github.com/randao/randao

Définition de l'appareil:

• Mélangehttps://github.com/ethereum/mix
• IDE du webhttps://chriseth.github.io/browser-solidity
• Développement virtuelhttp://etherscripter.com/

Plus de