La préhistoire d’Ethereum

Cet article écrit par Vitalik Buterin revient sur la genèse d’Ethereum et les atermoiements de la petite équipe d’origine autour de certains concepts qui constituent aujourd’hui la base du protocole. Traduction en français par Simon Polrot avec relecture et (nombreuses) corrections par Jean Zundel, Nathan Sexer, Johan Massin et Vincent le Gallic.
Même si les idées derrière le protocole Ethereum n’ont pas beaucoup changé pendant les trois dernières années, Ethereum n’a pas émergé d’un seul coup sous sa forme actuelle. Avant que la blockchain ne soit lancée, le protocole a subi un certain nombre d’évolutions et de changements de conception. L’objectif de cet article est de revenir sur la période entre les débuts et le lancement. Le travail incessant qui a été réalisé sur les implémentations du protocole telles que Geth, cppethereum, pyethereum et EthereumJ, ainsi que l’historique des applications et entreprises de l’écosystème sont délibérément hors du champ de cet article.
Casper et la recherche sur le sharding sont également en dehors du champ de cet article. Il est possible d’écrire de nombreux articles sur les idées diverses que Vlad, Gavin, moi-même et bien d’autres ont discutées et abandonnées, y compris la « proof of proof of work », les chaînes hub-and-spoke (en étoile), les « hypercubes », les shadow chains (qui peuvent être considérées comme des précurseurs de Plasma), les chain fibers, et plusieurs itérations de Casper, ainsi que les réflexions en constante évolution de Vlad sur les motivations des acteurs dans les protocoles de consensus et leurs propriétés, mais le tout constitue une histoire bien trop complexe pour l’explorer en un seul article et sera laissé de côté pour l’instant.
Commençons donc par la toute première version de ce qui deviendra Ethereum, à un moment où ce n’était même pas appelé Ethereum. En octobre 2013, pendant que je visitais Israël, j’ai passé beaucoup de temps avec l’équipe Mastercoin. Je leur ai même suggéré de nouvelles fonctionnalités. Après avoir réfléchi un moment à ce qu’ils étaient en train de faire, j’ai envoyé une proposition à l’équipe pour rendre leur protocole plus généraliste, afin qu’il puisse supporter plus de types de contrats sans ajouter un trop grand nombre de fonctionnalités complexes.
https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html

Notez qu’il s’agit d’une proposition très éloignée de la plus tardive et plus large vision d’Ethereum : elle se concentrait spécifiquement sur le domaine dans lequel Mastercoin tentait déjà de se spécialiser, c’est à dire des contrats bipartites où la partie A et la partie B mettent tous deux en consignation leur argent et reçoivent ensuite une somme dépendamment d’une formule spécifiée dans le contrat (par exemple un pari dans lequel « si X arrive alors donne tout l’argent à A, sinon donne tout l’argent a B »). Le langage de programmation n’était pas « Turing-complete ».
Les contributeurs de Mastercoin, bien qu’impressionnés par la proposition, n’étaient pas prêts à abandonner tout leur travail pour aller dans cette direction, alors que j’étais de plus en plus convaincu que c’était le choix le plus intéressant. Et voici comment est née la version 2, vers décembre de la même année :
https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html

Ici on peut voir les résultats d’une restructuration du concept qui résulte largement d’une longue marche à travers San Francisco faite en novembre, lorsque j’ai réalisé que les smart-contracts pouvaient être complètement généralisés. Au lieu de créer un langage de script simple permettant de décrire les termes d’une relation entre deux parties, les contrats seraient eux-mêmes des comptes à part entière sur la blockchain, qui auraient la capacité de détenir, d’envoyer et de recevoir des actifs, et même de gérer un stockage permanent de données (à cette époque, le stockage permanent était appelé « mémoire » (memory) et la seule « mémoire » temporaire résidait dans les 256 registres). Le langage utilisé a aussi changé d’une machine à pile à une machine à registres, à mon initiative. J’avais peu de raisons objectives pour justifier ce choix, sinon que cela semblait plus sophistiqué.
Notons également la présence d’un mécanisme de fees, de frais de transactions intégré au système :

L’ether était alors littéralement le gas d’aujourd’hui ; après chaque étape de calcul le solde du contrat qu’une transaction appelait diminuait un peu, et si le contrat n’avait plus de fonds l’exécution s’arrêtait. Notez que ce mécanisme du « receveur payeur » signifiait que le contrat lui-même devait s’assurer que les vendeurs payaient les frais au contrat et s’arrêter automatiquement si les frais n’étaient pas présents. Le protocole prévoyait spécifiquement 16 étapes d’exécution gratuites pour permettre aux contrats de rejeter les transactions qui ne contenaient pas ces frais.
À ce stade, le protocole Ethereum était entièrement ma création. À partir de ce moment, de nouveaux participants rejoignirent le projet. Le plus important, de très loin, fut Gavin Wood, qui me contacta par un message sur about.me en décembre 2013:

Jeffrey Wilcke, développeur principal du client Go (alors appelé “ethereal”) me conctacta également et commença à coder à peu près au même moment, même si ses contributions se concentraient sur le développement du client plutôt que sur la recherche autour du protocole.

« Salut Jeremy, ravi d’apprendre que tu t’intéresses à Ethereum… »
Les contributions initiales de Gavin étaient de deux ordres. D’une part, vous avez peut être remarqué que le modèle d’appels des contrats dans l’idée initiale était asynchrone : même si le contrat A pouvait créer une « transaction interne » au contrat B (« transactions internes » est un terme inventé par Etherscan, a l’origine elles étaient juste appelées « transactions », puis « appels de messages » (message calls) ou « appels »), l’exécution de ladite transaction interne ne démarrait pas tant que l’exécution de la première transaction n’était pas complètement terminée. Par conséquent, il était impossible d’utiliser ces transactions internes pour récupérer une information depuis d’autres contrats ; la seule façon de le faire était en utilisant l’opcode EXTRO (un peu comme un SLOAD qu’on pourrait utiliser pour lire le stockage d’autres contrats), et cette dernière méthode a été supprimée par la suite grâce à Gavin entre autres.
Lorsqu’il a mis en œuvre mes spécifications initiales, Gavin a naturellement choisi d’implémenter les transactions internes sur un mode synchrone, sans même réaliser que l’intention était différente ; autrement dit, dans la mise en œuvre de Gavin, la transaction interne était exécutée immédiatement, et lorsque cette exécution était finalisée, la machine virtuelle reprenait l’exécution du contrat initial à l’opcode suivant. Cette approche nous a semblé à tous les deux supérieure et est donc devenue partie intégrante des spécifications.
D’autre part, une discussion entre lui et moi (pendant une balade à San Francisco, dont les détails sont par conséquents perdus à jamais dans les vents de l’histoire, avec peut être une copie ou deux dans les archives de la NSA) a conduit à restructurer le modèle de frais de transactions, en s’éloignant de l’approche « contrat payeur » pour aller vers une approche « envoyeur payeur ». Dans le même temps, nous avons pivoté vers l’architecture « gas » d’aujourd’hui. Plutôt que chaque transaction individuelle s’exécute immédiatement en consommant une partie des ether, l’envoyeur de la transaction paye pour son exécution et se voit allouer du « gas » (grosso modo, un compteur d’étapes de calcul), les étapes de calcul piochant dans ce gas alloué. Si la transaction est à court de gas, le gas est perdu mais l’exécution de la transaction est entièrement annulée ; ce qui semblait la solution la plus sûre puisque cela faisait disparaître toute la problématique des attaques liées à l’exécution partielle des contrats qui nous posait de nombreux problèmes. Une fois l’exécution de la transaction arrivée à son terme, les frais correspondant au gas non consommé sont remboursés.
Il faut également attribuer à Gavin une évolution progressive, depuis la vision initiale d’Ethereum en tant que plateforme de création de monnaie programmable avec des contrats basés sur la blockchain pouvant détenir des actifs et les transférer sur la base de règles prédéfinies, vers une plateforme de calcul à usage générique. Cela a commencé avec de subtils changements en terme d’emphase et de terminologie, puis l’influence est devenue plus forte avec la mise en avant du « Web3 » qui voyait Ethereum comme l’une des pièces d’un ensemble de technologies décentralisées, les deux autres étant Whisper et Swarm.

D’autres changements sont arrivés en 2014, suggérés par d’autres contributeurs. Nous en sommes finalement revenus à une architecture à piles (stack-based) selon une suggestion d’Andrew Miller, entre autres.
 
Charles Hoskinson suggéra un changement depuis le SHA256 de Bitcoin vers le plus récent SHA3 (ou, plus précisément keccak256). Après un long débat, des discussions avec Gavin, Andrew et d’autres permirent de conclure que la taille des valeurs devait être limitée à 32 octets ; l’autre option, des entiers de taille illimitée, rendait trop complexe le calcul du gas requis pour une addition, une multiplication ou une autre opération.
L’algorithme de minage que nous avions initialement en tête, en Janvier 2014, était un système appelé Dagger :
https://github.com/ethereum/wiki/blob/master/Dagger.md

Le nom de Dagger provient du « directed acyclic graph » (DAG) ou graphe orienté acyclique, la structure mathématique utilisée dans l’algorithme. L’idée était qu’à chaque bloc N, un nouveau DAG serait généré pseudo-aléatoirement depuis une graine (seed), et que la couche inférieure du DAG serait une collection de nœuds qui prendrait plusieurs gigaoctets à stocker. Cependant, la génération d’une valeur individuelle dans le DAG ne requiert le calcul que de quelques milliers d’entrées. Un « calcul Dagger » impliquait de générer un certain nombre de valeurs dans des positions aléatoires de cette couche inférieure pour les hasher ensemble. Cela signifiait qu’il y avait une façon rapide de réaliser un calcul Dagger – avoir préchargé les données en mémoire – et une façon lente, mais peu gourmande en mémoire – regénérer chaque valeur depuis le DAG qu’il faut reprendre de zéro.
L’idée derrière cet algorithme était d’avoir la même « résistance mémoire » (memory hardness) que d’autres algorithmes courants à ce moment-là, comme Scrypt, mais tout en permettant la création de clients légers (light clients). Les mineurs utiliseraient la méthode rapide, et leur minage serait donc contraint par la bande passante de leur mémoire (la théorie étant que la RAM grand public est déjà très fortement optimisée et qu’il serait difficile de l’optimiser davantage avec des ASIC), mais les clients légers pourraient utiliser la méthode de vérification sans mémoire mais plus lente. La méthode rapide se compte en microsecondes et la méthode sans mémoire en millisecondes, ce qui reste tout à fait viable pour un client léger.
De ce point de départ, l’algorithme devait changer de nombreuses fois pendant le développement d’Ethereum. L’idée suivante était la « preuve de travail adaptive » (adaptive proof of work) ; ici la preuve de travail impliquait d’exécuter des contrats Ethereum sélectionnés aléatoirement. Nous avions de bonnes raisons de croire que cela rendait l’algorithme davantage résistant aux ASICs. Si un ASIC était développé, des mineurs concurrents auraient tout intérêt à déployer des contrats que cet ASIC ne saurait pas exécuter efficacement. Comme il n’existe pas d’ASIC pour les calculs génériques – cela s’appelle un CPU – il était simplement possible de mettre en place ces mécanismes d’incitations antagonistes pour créer une preuve de travail qui était en pratique une exécution de calculs génériques.
Cette idée a été abandonnée pour une simple raison : les attaques à longue portée (long-range attacks). Un attaquant pouvait commencer une chaîne depuis le bloc 1, la remplir avec uniquement des contrats simples pour lesquels il pouvait créer un matériel spécialisé, et rapidement dépasser la chaîne principale. Donc… retour à la case départ.
L’algorithme suivant était appelé Random Circuit, décrit dans ce document, proposé par Vlad Zamfir et moi-même et analysé par Matthew Wampler-Doty et d’autres. L’idée était également de simuler des calculs génériques dans un algorithme de minage, mais cette fois en exécutant des circuits générés automatiquement. Il n’existait aucune preuve que quelque chose basé sur ces principes ne pourrait pas fonctionner mais les experts en matériel informatique contactés en 2014 avaient des avis assez pessimistes à ce sujet. Matthew Wampler-Doty lui-même suggéra une preuve de travail basée sur la résolution de problèmes SAT mais cette idée fut également rejetée en fin de compte.
Enfin, nous sommes presque revenus au point de départ avec un algorithme appelé « Dagger Hashimoto ». « Dashimoto », comme il était parfois abrégé, a beaucoup emprunté à Hashimoto, un algorithme de preuve de travail conçu par Thaddeus Dryja qui a exploré en premier la notion de « preuve de travail liée aux entrées / sorties » (I/O bound proof of work), dans laquelle le facteur limitant principal de la vitesse de minage n’est pas le nombre de hashs par secondes mais plutôt le nombre de mégaoctets par seconde d’accès RAM. Cependant, nous avons combiné cette idée avec la notion d’ensembles de données générées par DAG compatibles avec les clients légers qu’apportait Dagger. Après de nombreuses séances de peaufinage par Matthew, Tim, moi-même et d’autres, les idées ont finalement convergé vers un algorithme que nous appelons dorénavant Ethash.

A l’été 2014, le protocole était globalement stabilisé, à l’exception significative de l’algorithme de preuve de travail qui ne devait pas atteindre sa phase « Ethash » avant le début de 2015, même si une spécification semi-formelle existait sous la forme du « Livre Jaune » (yellow paper) de Gavin.

En août 2014, je développais le concept d’oncle (uncle), permettant à la blockchain Ethereum d’avoir un temps de bloc plus court et une meilleure capacité générale en réduisant les risques de centralisation, formellement introduit dans le PoC6.
Des discussions avec l’équipe de Bitshares nous ont conduit à évaluer la pertinence d’ajouter des « tas » (heaps) comme structure de données principale mais nous avons finalement abandonné cette idée par manque de temps, et des audits de sécurité puis des attaques par DoS ont ensuite montré que ces structures sont bien plus difficiles à mettre en œuvre de façon sécurisée que nous ne le pensions à l’époque.
En septembre, Gavin et moi planifièrent les deux prochains changements majeurs dans la conception du protocole.
En premier lieu, en plus de l’arbre de l’état (state tree) et et de l’arbre des transactions (transaction tree), chaque bloc contiendrait également un arbre des reçus (receipt tree). L’arbre des reçus inclurait les hashs des logs créés par une transaction, ainsi que les racines d’états intermédiaires. Les logs permettent aux transactions de créer des « sorties » qui sont sauvegardées dans la blockchain, et sont accessibles pour les clients légers mais pas pris en compte pour le calcul des états futurs. Les applications décentralisées peuvent ainsi faire des requêtes relatives à des événements comme des transferts de tokens, des achats, des ordres créés et remplis, des débuts d’enchères, et ainsi de suite. D’autres idées avaient été explorées, comme la création d’un arbre de Merkle à partir de la trace de l’exécution complète des transactions pour pouvoir les prouver ; les logs ont été choisis car ils présentaient un compromis acceptable entre perfection et simplicité.
Le second changement concernait les fonctions précompilées (precompiles), qui résolvaient la problématique de permettre l’utilisation des fonctions cryptographiques complexes sans surcharger l’EVM. Nous avons également exploré beaucoup d’autres idées plus ambitieuses sur les « contrats natifs » (native contracts), où lorsque les mineurs mettaient en œuvre une version optimisée de certains contrats ils pouvaient « voter » pour que le prix de ces contrats spécifiques soit réduit, donc les contrats que les mineurs pouvaient exécuter plus rapidement auraient eu naturellement un prix en gas moins élevé ; cependant nous avons rejeté ces idées car elles ne laissaient pas entrevoir une façon crypto-économiquement sûre de les mettre en œuvre. Un attaquant pouvait toujours créer un contrat exécutant une version faussée d’une opération cryptographique, distribuer cette version faussée à eux-mêmes et leurs amis pour leur permettre d’exécuter ce contrat beaucoup plus vite, puis de voter un prix en gas minimum avant de l’utiliser pour attaquer le réseau par DoS (déni de service). Nous sommes donc parti sur une approche beaucoup moins ambitieuse qui consistait à définir un petit nombre de fonctions pré-compilées dans le protocole pour des opérations communes comme les hashs et les mécanismes de signature.
Gavin fut également une des premières voix importantes en faveur de l’idée d’« abstraction du protocole » (protocol abstraction) : il s’agissait de déplacer le plus possible d’éléments du protocole comme les soldes en ether, les algorithmes de signature de transaction, les nonces, etc. dans des contrats, dans le but théorique d’atteindre la situation où tout le protocole ethereum pouvait être décrit comme un appel de fonction dans une machine virtuelle se trouvant dans un état pré-initialisé. Nous n’avions pas assez de temps pour implémenter ces idées dans la première version d’Ethereum (Frontier). Mais ces principes doivent être progressivement intégrés par les modifications apportées par Constantinople, le contrat Casper et la spécification du sharding.
Tout ceci fut mis en oeuvre dans le PoC7 ; après celui-ci, le protocole n’a pas vraiment changé, à l’exception de détails le plus souvent (mais pas toujours) mineurs révélés par les audits de sécurité…
Début 2015, les audits de sécurité de pré-lancement organisés par Jutta Steiner et d’autres inclurent tant des audits de code informatique que des audits académiques. Les audits de code furent principalement réalisés sur les implémentations en C++ et en Go, menés respectivement par Gavin Wood et Jeffrey Wilcke, même si il y eut également un audit de plus faible envergure sur l’implémentation pyethereum. Les deux audits académiques furent réalisés par Itaay Eyal (bien connu pour l’idée du « minage égoïste » (selfish mining) et par Andrew Miller et d’autres de Least Authority. L’audit d’Eyal conduisit à un changement mineur dans le protocole : la difficulté totale de la chaîne n’inclurait pas les oncles. L’audit de Least Authority était davantage tourné vers les smart contracts et les principes économiques du gas, ainsi que l’arbre Patricia. Cet audit engendra plusieurs changements dans le protocole, dont l’utilisation de sha3(addr) et sha(key) comme clés de trie au lieu d’employer directement les adresses et les clés ; cela rend plus difficile une attaque sur le trie.

Et un avertissement qui était peut-être un peu en avance sur son temps…
Un autre aspect significatif remis en cause fut le mécanisme du vote sur la limite en gas par bloc. À ce moment, nous étions déjà inquiets du manque de progrès réalisé dans le débat sur la taille des blocs dans l’écosystème bitcoin et nous voulions un fonctionnement plus souple pour Ethereum qui pourrait s’ajuster avec le temps lorsque nécessaire. Mais le challenge était de déterminer la limite optimale. Mon idée initiale était de mettre en œuvre une limite dynamique, avec pour stratégie de vote par défaut 1,5 fois la moyenne mobile exponentielle de l’utilisation réelle du gas, pour qu’à long terme en moyenne les blocs soient pleins à 2/3. Cependant Andrew montra que ce fonctionnement était exploitable de plusieurs façons : par exemple, les mineurs qui voudraient augmenter la limite n’auraient qu’à inclure dans leurs blocs des transactions qui consomment un très gros montant de gas mais prennent très peu de temps à être traités, et donc créer des blocs pleins sans coût particulier pour eux. Le modèle de sécurité était donc, au moins dans le sens de l’augmentation, d’avoir simplement un vote des mineurs sur la limite de gas.
Nous ne sommes pas arrivés à concevoir une stratégie de limite de gas moins susceptible de défaillir et la recommandation d’Andrew fut simplement de faire voter explicitement les mineurs sur la limite de gas, avec la stratégie par défaut fixée selon la règle des 1,5x de la moyenne mobile exponentielle. Le raisonnement était que nous étions encore très loin de connaître la bonne approche pour définir la limite de gas maximum, et le risque qu’une approche échoue semblait plus importante que celle de voir les mineurs abuser de leur pouvoir de vote. Par conséquent, il valait mieux laisser les mineurs voter sur la limite de gas et accepter le risque que cette limite aille trop haut ou trop bas, en bénéficiant de la souplesse et de la possibilité pour les mineurs de collaborer pour réduire ou augmenter la limite de gas rapidement si nécessaire.

Après un mini-hackathon entre Gavin, Jeff et moi, le PoC9 était lancé en mars et devait être la dernière version en preuve de concept. Un réseau de test, Olympic, fonctionna pendant quatre mois en utilisant le protocole prévu pour le réseau principal. Le plan à long terme pour Ethereum fut alors établi. Vinay Gupta écrivit à cette époque un article de blog appelé « Le processus de lancement d’Ethereum » (The Ethereum Launch Process) décrivant les quatre étapes prévues pour le lancement d’Ethereum : Frontier, Homestead, Metropolis et Serenity.
Olympic tourna pendant quatre mois. Pendant les deux premiers mois, de nombreux bugs furent trouvés dans les implémentations existantes, des échecs de consensus se produisirent entre autres soucis et, finalement, vers juin, le réseau s’était stabilisé de façon notable. En juillet la décision était prise de geler le code existant et de réaliser le lancement, qui intervint le 30 juillet.

La Semaine d’Ethereum – 101

La semaine d’Ethereum (Week in Ethereum) est une newsletter préparée chaque semaine avec amour par Evan Van Ness, un passionné de l’écosystème. Après le succès du numéro 100, voici le numéro 101 en français. Les liens en gras sont ceux qui ont eu le plus de succès dans la newsletter d’origine. Vous pouvez vous abonner à l’original ici. La newsletter est sponsorisée par Status et ConsenSys.
Week in Ethereum n°101 – sortie de Counterfactual
Actualités et liens
Protocole

Vitalik a proposé un plan en trois étapes pour les chaînes phares. Pour rendre le développement plus incrémental, il y aurait un set de validateur fixe en stage 1, puis une transition dynamique en stage 3.
Preuve de concept de Sharding p2p utilisant libp2p
Boneh, Bünz, Fisch: étude de deux VDFs
Dernier call Casper
Casper vs. Ouroboros en deux parties
Dernier call ewasm
Fichter : Pourquoi utiliser l’EVM sur Plasma est-il difficile ? (également: EVM sur EVM de Parsec)
Thread sur le coût de verification sur Plasma Cash
Dernier call des core devs. Les notes de Lane
Tout ce que vous avez besoin de savoir sur le client Ethereum Trinity – historique, pourquoi Python et pourquoi c’est utile pour prototype la recherche
Introduction au client Nimbus Ethereum 2.0 de Status

Pour développeurs

Liam Horne : presentation de certaines applications de Counterfactual, un projet open-source de state channels. Github
Connext sur l’application au monde réel du concept de canaux virtuels (virtual channels) ; en production sur le mainnet Spankchain pour tests
Etherlime v0.6 – un framework de développement basé sur ethers.js, compliation plus rapide et tests
“Une démonstration rapide sur comment installer Truffle et Ethers.js avec experimentalABIEncoderV2”
Nick Johnson et Zachary Williamson parlent de Ethereum gas golf
whisper-tools, wrapper API autonome sur les appels RPC ssh
Comment preparer votre dApp aux standards d’identité de uPort
Implementation en Go du code STARK de Vitalik par Sourabh Niyogi
Code de ring signatures « Mobius »
La raison pour laquelle les langages de programmation classiques ne sont pas faits pour pour programmer des smart-contracts par Vitalik Buterin
TheGraph est maintenant open-source
Bref tutoriel pour EthQL
AnalyseEther – “analyse de données en temps réel” dans le navigateur
Péter Szilágyi avertit sur de potentielles attaques sur dappen utilisant des service workers en sommeil et localhost
Boîte à outils ENS, et une séance de FAQ avec Nick Johnson
Orion: gestionnaire de transactions privées pour EEA, spécifications en Java par PegaSys
Tutoriel video pour comprendre le debugger KLab de Dapphub dans le framework K

Sorties

Geth v1.8.13 avec Swarm v0.3.1 – version de miantenance. A partir de maintenant, geth et swarm seront mis à jour ensemble.

Live sur le réseau principal

L’ERC1155 de Enjin est déployé sur le mainnet pour tokéniser des actifs de jeux vidéos

Ecosystème

Appel à speakers, organisateur d’ateliers et hôtes pour salles de travail pour la Devcon4.
La théorie des jeux derrière FoMo3d et spéculation sur des scenarios de sortie
Call entre développeurs d’explorateurse de blocs en Open Source #10
Environnements d’exéution sécurisés (Trusted execution environments) pour nodes Ethereum, par Sanjay Bakshi d’Intel et Andreas Freund de ConsenSys
imToken 2.0
Gnosis Safe – et une video expliquant comment interagir avec une dapp en utilisant Gnosis Safe

Gouvernance et standards

Eric Conner : plaidoyer pour une réduction de la récompense par bloc d’Ethereum. Un vote sur la blockchain à un ether une voix (coinvote) a été organisé par Etherchain (imparfait, obligation d’utiliser MyCrypto/MEW) sur le sujet . 50k ETH ont voté quasi unanimement pour réduire la récompense par bloc pour les mineurs. Il y a aussi des variations de proposition, par exemple 1276 (supprimer la bombe de difficulté, réduction de la récompense à 2 ETH) et 1277 (2 ETH, sans toucher à la bombe de difficulté). Il y a un large support de la communauté pour réduire l’émission monétaire, la question étant l’amplitude de cette réduction, de combien de temps la bombe de difficulté doit être repoussée, et faut-il ou non y inclure des dispositifs anti-ASIC.
D’après Dean Eigenmann le processus de prise de décision sur propositions d’amélioration d’Ethereum ne devrait pas être formalisé
EIP1285 : augmenter le coût de Gcallstipend dans l’OPCODE CALL de 2 300 à 3 500 gas
EIP1283 : changement de mode de calcul du coût en gas pour SSTORE : coût fixe sans utiliser de « dirty map » (cf. EIP 1087)
ERC1271: Méthode de validation de signature standard pour les contrats
ERC1288 : Récupérer les valeurs renvoyées par le contrat directement dans les reçus (receipts) de la transaction
Suivi des progrès du prochain hardfork

Mises à jour de projets

Golem v0.17.0. Egalement, un guide sur les Trusted Computations, première partie
Les 365 jours de la plateforme Iconomi – illustration sympa pour résumer l’année écoulée
Le concept d’Underwriters (assurances de prêts) dans le protocole Dharma
DopeRaider est lancé sur le POANetwork et explique comment déplacer des actifs
Dappos – enregistrement de points de vente en Eth pour mobile
Reporter.chat salue les standards de reporting d’Augur
Structure de gouvernance des risques de MakerDAO, partie 2
La lettre de Jarrad à Status
Digix mène actuellement un coinvote pour déterminer combien de tokens Digix sont requis pour modérer des propositions et quelle sera la rémunération du modérateur

Interviews, Podcasts, Videos, Interventions 

Vidéos du Swarm Orange Summit
Lane Rettig parle de governance et de montée en charge sur BlockCrunch
Interview de Dmitry Buterin dans un podcast
Eric Tang de Livepeer parle de calculs hors-chaîne sur Zero Knowledge
Chris Brown and Will Dias de Modular dans Hashing It Out
Davantage de vidéos de la Dappcon sont disponibles, y compris l’intervention de Evan sur la gouvernance
Vidéos de l’événement de Binary District sur les state channels

 Tokens 

Neufund a maintenant une newsletter sur les security token – avec un focus sur les plateformes d’échange pour ce numéro
La période ouverte de Livepeer a commencé. Payez le gas à MerkleMine pour le compte d’autres et recevez une récompense en échange
Idées de Alex Van de Sande pour tokéniser des communautés sur Reddit
Slides sur une meilleure information avec les marchés de curation

Général

Valider sur Polkadot POC2quand tout le monde a été puni (slashed)
Liste des projets sur Cosmos et Tendermint
Le langage de programmation de Zilliqa, Scilla, est maintenant open source
Binance achète Trust Wallet
Interview de Hester Peirce, Commissionnaire à la SECpar EthNews, sur son opinion dissidente sur l’ETF et l’ouverture à l’innovation
L’utilisation de Bitcoin dans les transactions commercialesa baissé de plus 80 % en 9 mois
Publication du Forum Blockchain de l’Union Européenne sur l’innovation blockchain en Europe.

Dates à retenir

7 août – Vague 2 des tickets de la Devcon4
7 août – début de deux mois de hackathon distribué parfrom Giveth, Aragon, Swarm City and Chainshot
10-12 août – hackathon EthIndia (Bangalore)
10-12 août – ENS workshop et hackathon (Londres)
22 août – vote sur la ‘Foundation Proposal’ de Maker DA
24-26 août – hackathon Loom (Oslo, Norway)
6 septembre – Security unconference (Berlin)
7-9 septembre – hackathon EthBerlin
7-9 septembre – WyoHackathon (Wyoming)
8 septembre – Ethereum Industry Summit (Hong Kong)
15-16 septembre – hackathon de DappDev (Kiev)
5-7 octobre – TruffleCon (Portland)
5-7 octobre – hackathon EthSanFrancisco
11 octobre – Crypto Economics Security Conf (Berkeley)
22-24 octobre – Web3Summit (Berlin)
26-28 octobre – hackathon Status (Prague)
29 octobre – Decentralized Insurance D1Conf (Prague)
30 octobre – 2 novembre – Devcon4 (Prague)
7-9 décembre – conférence dGov sur la gouvernance distribuée (Athènes)
Décembre – hackathon EthSingapore

Week in Ethereum, n°101
@evan_van_ness
Sponsorisé par Status et ConsenSys

Ethereum a trois ans !

Le premier bloc de la version publique d’Ethereum fut miné le 30 juillet 2015, il y a un peu plus de trois ans. Depuis, contredisant les prédictions des oiseaux de mauvaise augure, le protocole ne s’est jamais arrêté. Ces trois années n’ont pas été de tout repos, loin de là. Ethereum a vécu de nombreux événements, parfois traumatisants, parfois enthousiasmants. Des attaques, des piratages de smart-contracts, des hard forks en urgence ou planifiés… et un développement parfois peu lisible. mais jamais la vision initiale d’une monnaie programmable et d’un monde plus décentralisé ne s’est perdue. Les objectifs que la Fondation s’étaient fixés à la création sont toujours ceux qu’elle poursuit aujourd’hui.
Pour être honnête, les promesses du départ se font attendre. Le sharding et le protocole en preuve d’enjeu Casper, récemment fusionnés en Shasper, ne devraient pas arriver avant 2019 au plus tôt – dans l’intervalle la blockchain reste lente, coûteuse et énergivore. La gestion de l’identité sur blockchain n’existe pas. Il est encore difficile d’acquérir des ether pour utiliser une dApp, encore plus difficile d’acquérir des tokens. La « hype » aux ICO de l’année dernière a fait des dégâts en terme d’image, entre arnaques, projets trop ambitieux ou simplement tokens mal pensés. La mise à jour Metropolis qui devait être l’ouverture de la blockchain au grand public ne contient finalement « que » des améliorations de protocole critiques et a la seconde partie, initialement attendue pour janvier 2018, sera au mieux déployée en octobre. Bref, tout s’est avéré plus compliqué que prévu et il est normal que beaucoup aient perdu confiance au projet.
Photo de groupe d’une partie des développeurs sur le « sharding » d’Ethereum, Taipei
Et pourtant, beaucoup de choses ont changé depuis le lancement. La Fondation s’est professionnalisée, avec notamment la nomination de Aya Miyaguchi comme directrice exécutive en février dernier. D’autres acteurs fondamentaux sont apparus ; grâce notamment aux montants que la Fondation attribue à des acteurs privés et à l’Ethereum Community Fund qui joue le même rôle, de nombreuses équipes travaillent aujourd’hui sur le futur du protocole.
A ceci s’ajoutent de nombreux acteurs privés qui se sont créés et ont contribué, contribuent aujourd’hui, à la croissance et aux progrès du réseau au sens large, au delà du protocole. Citons en vrac Parity, ConsenSys, MyCrypto, Etherscan, State of the dApps, Infura, MetaMask, Truffle, Cipher, Status, Embark, etc. Ces outils permettent aux premières dApps d’émerger. Nous sommes loin encore d’une adoption grand public – et même d’une adoption du monde crypto. Mais AirSwap, IDEX, Augur, OmiseGo, CryptoKitties, Maker, Decentraland et bien d’autres ont tous lancé leurs applications, avec plus ou moins de traction. Il est probable que celles-ci payent les pots cassés des prochains – ou de leurs propres version 2 – qui vont bénéficier de leurs expériences.
La route est encore longue. Mais Ethereum compte aujourd’hui et de loin la plus importante communauté de développeurs blockchain, que ce soit sur le protocole ou sur les applications. Près de 1800 dapps sont recensée à ce jour sur State of the Dapps. MetaMask a été téléchargé plus d’un million de fois. 82 % des ICO se réalisent sur Ethereum et l’essentiel des projets financés sont prévus pour cette plateforme. Infura traite 6 milliards de requêtes par jour. Des hackathons spécialisés (https://ethglobal.co/) sont organisés dans le monde entier tous les mois. Les communautés locales ne sont pas en reste : l’Asseth notamment compte plus de 300 membres actifs et organise des conférences, réunions… et d’autres surprises à venir.
Finissons sur une anecdote : le meme le plus suivi dans la communauté n’est pas HODL (conserver ses cryptomonnaies), mais BUIDL : l’idée que tout reste à construire mais que la communauté de créateurs, développeurs, entrepreneurs qui a été créée autour du projet est le meilleur gage de son futur succès.
Je souhaite donc à Ethereum et sa communauté un excellent anniversaire !

La Semaine d’Ethereum – numéro 100

La semaine d’Ethereum (Week in Ethereum) est une newsletter préparée chaque semaine avec amour par Evan Van Ness, un passionné de l’écosystème. A l’occasion du numéro 100, nous avons pris la plume pour vous la traduire en français. N’hésitez pas à nous faire un retour sur l’utilité de cette traduction : si cela vous intéresse, nous pouvons la réaliser sur un mode régulier. Vous pouvez vous abonner à l’original ici. La newsletter est sponsorisée par Status et ConsenSys.

Week in Ethereum n°100 – Les contrats de iExec, Melon et Gnosis DutchX sont en production
Actualités et liens
Protocole (avec l’assistance de l’équipe de Recherche d’Ethereum)

Shasper chain, version 2.1.
Mise à jour bihebdomadaire de Prysmatic sur la transition vers Eth 2.0 avec une base de code séparée en Go.
Les VDFs ne sont pas du Proof of Work par Danny Ryan. Les « Verifiable Delay Functions » ont certaines propriétés qui requièrent une puissance de calcul significative pour être calculés mais relativement peu pour être vérifiés, ce qui serait utile pour améliorer les générations de chiffre aléatoire basés sur RANDAO. Cela ressemble à du Proof of Work, mais Danny explique dans cet article les différences significatives entre VDF et PoW
STARKs, Part 3: Into the Weeds par Vitalik Buterin: Dans cette troisième partie, Vitalik explique comment réellement implémenter un STARK avec un exemple très vivant.
Dernier call Casper.
Vitalik Buterin toujours : Epoch-less Casper FFG liveness/safety argument
Pourquoi Shasper a plus de sens que le précédent Friendly Finality Gadget, et une roadmap du sharding.
LearnPlasma devient une excellent ressource pour apprendre à utiliser Plasma
Une introduction à Plasma Cash par Simon de la Rouviere
Jinglan Wang: qu’est-ce que Plasma ? Plasma Cash ?
Raiden est live sur le testnet Ropstenet ouvert aux tests

Pour développeurs

Benchmarking entre Mythril, Manticore et Oyente par ConsenSys Diligence
A quoi l’« exit scam » de FoMo3d pourrait réellement ressembler, mais pourquoi ne pas se couvrir avec Augur ?
Péter Szilágyi: How to PWN FoMo3D, a beginners guide
Pipeline– une vidéo décrivant un POC d’une une interface utilisateur visuelle pour explorer les fonctions existantes déployées sur Ethereum
Tutoriel d’Airswap sur comment construire avec leur serveur API
Comment ajouter ENS à votre dapp (tutorial)
Comment utiliser le Parity Secret Store, un générateur de clés multipartites
IDEO sur comment gérer le gaz dans l’interface utilisateur (UX)
ethereum-to-graphql : générer automatiquement le schéma et le résolveur
Alpha d’EthQLalpha par PegaSys et Infura
Aragon Package Manager – possibilité de mettre à jour des organisations sur Aragon
Zeppelin: Exploring upgradeability governance in ZeppelinOS with a Gnosis MultiSig
Connecteur Apache Camel pour Ethereum en enterprise en utilisant web3j
Le nouveau centre de contrôle Infura – les tokens d’authentification existants doivent migrer aux clés d’authentification et points de livraison (endpoints) v3

Sorties

Trinity v0.1.0-alpha.12, meilleures synchronisation et performances générales. Sortie également du nouveau site.
web3j v3.5
js 0.20.7 et web3.js 1.0.0-beta.35. changement de rupture sur le provider http
EthereumJS VM v2.4.0 (et leur récapitulatif mensuel)

En production sur le mainnet (réseau principal)

iExec est en production sur le mainnet pour tests de rendu. 80% des tâches sont réalisées.
Melonport est live sur le mainnet avec une version légèrement limitée, Paros
Les contrats de l’exchange DutchX par Gnosis sont live sur le mainnet pour la fin de leur concours (pour gagner 100k USD) encourageant à développer dessus

Ecosystème

Le multisig Gnosis Safe est sorti sur Rinkeby
Thibaut Sardan de Parity: qu’est-ce qu’un light client et pourquoi s’en soucier ?
Quelqu’un a réussi à créer beaucoup de confusion sur Etherscan en utilisant un popup javascript 1337 dans leurs commentaires Disqus.
Nathan Sexer de VariabL: State of stablecoins
Post mortem de Metamask sur la suppression de leur application sur le Chrome store cette semaine. Egalement, comment ils vont se rendre compatibles avec plus de réseaux.
Une version lisible des 100+ interviews de développeurs Etherement par EthPrize

Gouvernance et standards

EIP1227 (supprime la difficulty bomb, retour à une récompense par blocs de 5 ETH) vs EIP1234 (repousse la difficulty bomb, réduit à 2 ETH la récompense par bloc) vs EIP1240 (supprime la difficulty bomb, laisse la récompense par bloc à 3 ETH). Les résultats du sondage de Afri sur twitter correspondent aux échos perçus de la communauté.
ERC1257 : standard de preuve de paiement
ERC1238 : des badges en token non-transférables
ERC1261 : un token de vérification de statut de membre
Ajouter des bottom-up composables à ERC998
ERC1263 : index de NFT

Nouvelles de projets

Comme prévu, Augur a détruit la « trappe d’évacuation » (escape hatch), et l’ensemble du code est maintenant décentralisé.
Messari achète OnchainFX et dévoile sa stratégie de contenus
Status s’affiche maintenant en pleine résolution sur les tablettes, et plus de Mixpanel
Maker va voter pour augmenter le frais de stabilité des Dai (Dai stability fee) à 2.5%

Interviews, Podcasts, Vidéos, Interventions 

Les vidéos de la Dappcon arrivent
Andy Tudhope parle des interviews de développeurs d’EthPrize sur Smartest Contract
CoinTelegraph a sorti quelques bonnes interviews : Jutta Steiner et Joe Lubin
Jez San de Funfair interviewé en podcast
Call sur Open Source Web3 Design
Jay Rush parle de The Dao et comment Quickblocks est une réponse à ces événements dans le stream hebdomadaire de Gitcoin
Dan Boneh sur Bitcoin Podcast
Ethan Buchman parle de testnets sur Zero Knowledge
Dan Finlay sur MetaMask et Mustekala dans Smartest Contract
Interview de Rune Christensen de Maker où il dévoile que Maker développe son propre langage de développement pour améliorer la sécurité
Martin Becze sur Epicenter

Tokens 

Il faut maintenant des tokens Santiment pour accéder à certains de leurs marchés et données.
Tutoriel sur comment récupérer vos Livepeer tokens gratuits.
Donner des motivations au nouveaux utilisateurs de TCRs (token curated registeries) par la gamification.
Mike Maples: Slow money crypto

Général

Zilliqa dévoile sont langage Scilla « avec formalisation de sa sémantique et son intégration dans Coq.” Intéressant également, Etheremon aura son gameplay sur Zilliqa mais utilisera Ethereum comme son support de valeur.
Première parachain Polkadot déployée en PoC2
Raul Jordan fait une intro aux algos de hashing
NYTimes sur l’art et la blockchain
Péter Szilágyi: TOR depuis GO. Nombreux sont les lecteurs de cet article qui vont immédiatement commencer à utiliser les onglets TOR dans le navigateur Brave
Ethereum est déployé sur le cloud Google
John Backus nous livre les leçons du partage de fichier p2p

Dates à retenir

7 août – Début de deux mois de hackathon distribué par Giveth, Aragon, Swarm City et Chainshot
10-12 août – hackathon EthIndia (Bangalore)
10-12 août – ENS workshop et hackathon (Londres)
22 août – vote sur la ‘Foundation Proposal’ de Maker DAO
24-26 août – hackathonLoom (Oslo, Norway)
6 septembre – Security unconference (Berlin)
7-9 septembre – hackathon EthBerlin
7-9 septembre – WyoHackathon (Wyoming)
8 septembre – Ethereum Industry Summit (Hong Kong)
5-7 octobre – TruffleCon (Portland)
5-7 octobre – hackathon EthSanFrancisco
11 octobre – Crypto Economics Security Conf (Berkeley)
22-24 octobre – Web3Summit (Berlin)
26-28 octobre – hackathon Status (Prague)
29 octobre – Decentralized Insurance D1Conf (Prague)
30 octobre – 2 novembre – Devcon4 (Prague)
7-9 décembre – conférence dGov sur la gouvernance distribuée (Athènes)
Décembre – hackathon EthSingapore

Week in Ethereum, n°100
@evan_van_ness
Sponsorisé par Status et ConsenSys

Nicehash: Attaquer une blockchain

Un site web a récemment mis en lumière le coût d’une attaque à 51% sur les blockchains utilisant la preuve de travail (Proof of Work – PoW en anglais). Cet article expose plusieurs éléments sur ce que cela signifie pour les blockchains concernés, à savoir ce qu’est une attaque à 51%, ce qu’est le site de location de puissance de calcul NiceHash et ce que l’on peut en conclure.

(Léonidas aux Thermopyles) — Jacques-Louis David, 1814. En 480 av. J.-C., une armée de 7 000 Grecques a tenté de barrer le passage à une force de 100 000 à 150 000 soldats Perses… id est une contre-attaque à 5,6% plutôt réussie car elle a permis de gagner assez de temps pour que reste de la Grèce s’organise contre l’invasion.
Attaque à 51%, de quoi parle-t-on ?
Avant tout il est nécessaire de comprendre comment le consensus en preuve de travail fonctionne. Si cette notion n’est pas claire pour vous, vous trouverez ci-dessous une vidéo (sous-titrées en français!) qui vaut vraiment les 26 minutes de détour, la section sur l’attaque à 51% commence à 18’58:

 
Voici un résumé inanimé:
Les noeuds dans le réseau d’une blockchain sont libres de participer s’ils le souhaitent à la création de nouveaux blocs. On parle alors de minage et les mineurs sont en compétition pour la résolution d’un problème pour lequel il n’y a pas de meilleure approche que la force brute. Une bonne image de ce problème est le cadenat à combinaison, pour ouvrir le cadenat il n’y a pas de meilleure stratégie que d’essayer toutes les combinaisons. Une fois la bonne combinaison trouvée tout un chacun peut vérifier rapidement que cette combinaison fonctionne. Le problème est donc difficile au sens où stratégiquement on ne peut que l’approcher par la force brute et en même temps il est très rapide d’en vérifier la résolution.
Après avoir assemblé des nouvelles transactions dans un bloc, les mineurs s’attaque au problème qui est propre à leur bloc. La combinaison qu’il cherche s’appelle le “nonce” et sa validité repose sur le fait que lorsque l’on applique une fonction cryptographique dite “de hachage” à l’ensemble des informations du bloc (nonce compris), le résultat est un nombre inférieur à un seuil communément admis au sein du réseau. Ce seuil est la “difficulté” du bloc. Le résultat d’une fonction de hachage étant imprévisible, l’activité de minage consiste à tester des milliards et des milliards de nonce jusqu’à en trouver un qui soit valide.
Devant la “difficulté” de la tâche, un nonce valide représente une preuve que le mineur a effectué une quantité considérable de calcul, dit autrement, qu’il a effectué un travail considérable. Vérifier que le travail a bien été effectué est aussi simple que de vérifier la combinaison d’un cadena. Fournir cette combinaison constitue une preuve de travail car le cadena est nécessairement généré sans sa solution.
Le nombre d’exécution de la fonction de hachage qu’est capable de produire un mineur est appelé son hashrate (nombre de hachage par seconde). Selon l’analogie du cadena, il s’agit du nombre de tours de roues du cadena qu’est capable d’actionner le mineur. La somme des hashrates des mineurs est le hashpower du réseau et statistiquement la part d’un mineur dans le hashpower du réseau correspond à son espérance de trouver le prochain bloc.

Les noeuds sont constamment à l’écoute des nouveaux blocs propagés sur le réseau. Parmi les informations contenues dans un bloc, on trouve une référence au bloc qui le précède d’où le fait que les noeuds stockent en fait une chaîne de blocs car chaque bloc se fait successivement référence jusqu’au premier bloc.
Parfois 2 ou 3 blocs différents sont diffusés sur le réseau de façon rapprochée dans le temps et faisant référence au même bloc comme précédent. Dans ce cas, les noeuds conservent ces blocs et attendent que de nouveaux blocs sont construits au dessus de ces blocs qui se font concurrence. Les blocs à venir ne peuvent faire référence qu’à un seul de ces blocs concurrents et nécessairement l’un des blocs devient la référence principale. Ce processus continue jusqu’à ce qu’une chaîne se distingue comme la plus longue et deviennent la chaîne canonique.
Remarque: le comportement par défaut des noeuds n’est seulement de suivre la chaîne la plus active (en terme de rythme de d’apparition de nouveaux blocs) mais aussi de stocker les chaînes orphelines. Certains noeuds choisissent d’être sélectif dans ce qu’ils conservent et de graduellement supprimer les données qu’ils n’ont pas obligatoirement besoin pour fonctionner.
En effet par exemple, lorsqu’un noeud vérifie qu’une transaction est valide, il vérifie que cette transaction est valide avec un état qu’il a précédemment vérifié mais il ne vérifie pas à nouveau la validité de cet état. Cela peut sembler aller à l’encontre du principe de “garder l’ensemble du registre” mais cela peut permettre de gagner beaucoup d’espace disque.
La règle de “suivre la chaîne la plus longue” a des implications profondes sur la notion de “finalité” d’une transaction: quand peut on considérer qu’une transaction a été finalisée, i.e. définitivement dans la chaîne canonique? Alors que la transaction est inscrite dans un bloc il se peut qu’une suite blocs ne l’incluant pas existe quelque part dans le réseau, le basculement des noeuds vers cette autre version peut remettre en cause l’existence de la transaction. En théorie il n’existe pas de seuil absolu à partir duquel la chaîne de blocs ne peut plus être réorganisée. En pratique, plus le bloc référençant la transaction est enfoui sous un grand nombres de blocs moins il y a de chances de réorganisation.
Historiquement sur Bitcoin il n’y a quasiment jamais eu de scission de la chaîne de plus de 6 blocs, à la notable exception d’Août 2010 où 53 blocs ont été abandonnés après la correction d’un bug d’overflow. Ceci explique pourquoi les places de marché pour les cryptomonnaies attendent en général 6 blocs avant de confirmer le crédit de bitcoin sur le compte de leurs utilisateurs. Ces 6 blocs correspondent en moyenne à un délai de 1 heure, cette règle des 1 heure est souvent aussi appliqués aux autres crypto-actifs.
Néanmoins en théorie, quelqu’un (l’attaquant) ayant un accès à une source considérable de puissance de hachage pendant pourrait générer une version alternative du registre et tenter de l’imposer au réseau. Pour se faire, l’attaquant doit posséder plus de la moitié du hashrate du réseau. Cette éventualité justifie les débats et les craintes face au regroupement des mineurs dans des coopératives (les mining pool) qui pèsent déjà un poids significatif dans l’ensemble et dépassent facilement 50% prisent en consortium.
 

Hashrate par pool de mining sur Bitcoin en juin 2018; source: https://blockchain.info/pools. Prisent ensemble, les 3 plus grosses mining pools (BTC.com, AntPool, et Slushpool) dépassent les 50% du hashrate de Bitcoin
Attaquer sans prendre le contrôle d’une partie du hashrate existant est néanmoins plutôt difficile car cela nécessite de déployer plus que l’ensemble du hashrate.
 
Pour se figurer cette difficulté on peut considérer le coût économique à l’abandon d’un bloc. Lorsqu’un mineur parvient à trouver un bloc valide le protocole de la blockchain émet une récompense pour le travail effectué et le compte du mineur est crédité de nouveau token. Dans le cas de bitcoin actuellement cette récompense s’élève à 12.5 BTC. En compétition pure et parfaite un mineur serait indifférent à l’idée de dédier sa puissance de calcul à la découverte de nouveau bloc celle de la dédier à la un attaquant fortuné. Avec une récompense de 12.5 BTC cela représente environ 90,000$ toutes les 10 minutes (au cours de juin 2018). Ce coût de la compromission des mineurs fait l’objet de nombreuses analyses académique, notamment celle-ci par Joseph Bonneau.
Qu’est-ce que NiceHash
NiceHash est une place de marché pour louer ou proposer à la location du hashrate: moyennant finance quiconque peut ainsi donner un coup de fouet à son operation de minage en toute discrétion. Besoin d’un coup de main pour prendre le contrôle de DogeCoin? NiceHash est là. Heureusement l’offre de hashrate est très faible comparé au hashpower total de la plupart des blockchains de référence (DogeCoin inclus).
Pour vous en convaincre, jetez un oeil à la colonne “NiceHash-able” sur https://www.crypto51.app . Par exemple, seulement 1% de la puissance nécessaire pour attaquer Bitcoin est disponible, de même 4% pour Ethereum (chiffres de juin). En revanche, des blockchain comme Ethereum Classic (102%), Bytecoin (115%), Bitcoin Gold (218%) ou Bitcoin Private (867%) sont dans une situation beaucoup plus préoccupante.

Les Serments des Horaces  — Jacques-Louis David, 1785. Autour de 650 av. JC, Rome était en guerre contre la cité rival d’Alba Longa. Les trois frères Horace firent le serment de défendre Rome et de provoquer en duel les trois frère Curatii. Un seul des Horaces revint en vivant de la confrontation et emporta la victoire sa cité, soit une contre-attaque à 50% réussie.
On peut se demander pourquoi des individus avec une capacité de minage à leur disposition choisissent de la proposer à la location sur NiceHash plutôt que de miner pour leur propre compte. Est-ce parce que le coût de l’électricité est trop haut ? Dans ce cas, pourquoi ne pas revendre le matériel de minage?
Une partie de l’explication repose peut être dans le facteur de  “flottement moral” des mineurs (pour en savoir plus sur ce concept rdv ici). A quel prix les mineurs acceptent ils de devenir des mercenaires et de mettre de côté leur moral. Sur le site crypto51, les prix d’une heure d’attaque à 51% sont extrapolés à partir du prix de location. La comparaison de ces prix avec les récompenses espérées du minage donne une estimation de ce facteurs sur les différentes blockchain.
Est-ce à dire que les blockchain ne sont pas sécurisé après tout?
Répondre à cette question est compliqué par la polysémie aussi bien du terme sécurité et que du terme blockchain. On peut faire référence indifféremment sous le terme blockchain au registre que constitue la blockchain, au réseau qui réplique le registre voire à l’unité de compte qui est inscrite dans le registre. C’est particulièrement le cas avec Bitcoin où la convention commence à s’instituer d’utiliser Bitcoin pour KKKK et bitcoin pour YYYYY. Ainsi la sécurité de chacun des aspects de la blockchain peut être considérée de manière spécifique.
Une attaque à 51% ravage toutes les dimensions d’une blockchain sauf son réseau. Un attaquant avec 51% du hashpower peut réécrire l’historique canonique de l’ordre des transactions de la blockchain à partir de n’importe quel bloc, les transactions passées et futures en sont censurés et les soldes des comptes modifiés. Certes l’attaquant ne peut pas contrefaire les signatures des transactions mais il peut retirer du registre de référence les transactions qui abondaient les comptes de son choix tout en refusant d’inclure les transactions émisent par ces comptes.
Malgré tout le réseau peut encaisser une telle attaque et permettre à l’historique original des blocs de se survivre. Cette résistance repose sur les noeuds qui conservent l’ensemble du registre. Un opérateur de noeud observant que le nombre blocs abandonnés est anormalement élevé peut lancer l’alerte qu’une attaque en cours a été détecté. Cette alerte permet aux développeurs de s’organiser pour proposer un réponse, notamment en changeant la Preuve de Travail afin de limiter l’impact du hardware utilisé par l’attaquant présumé, ou encore en abandonnant la Preuve de Travail pour une autre forme de consensus. En avril dernier, la blockchain Monero a changé son algorithme de Preuve de Travail pour éviter la concentration de la puissance de calcul après la mise sur le marché d’un hardware spéficique au minage sur Monero: l’Asic Antminer X3. De même, les développeurs de la blockchain Verge ont dû intervenir après l’exécution réussie d’une attaque à 51%.

Les licteurs rapportent à Brutus les corps de ses fils — Jacques-Louis David, 1789. En 509 av. JC, deux des fils de Brutus ont conspiré contre la République et Brutus alors consul les condamna à mort. Cette décision fut accueillie comme un acte remarquable de vertue civile et de dévotion à Rome… Caveant Consules!
Est-ce vos crypto-actifs risquent d’être affectés pour une telle attaque?
Non, surtout sur Ethereum et Bitcoin vos actifs sont sans aucun doute à l’abris d’une attaque à 51%. Contentez vous d’attendre quelques confirmations et tout ira bien!

Souffrez-vous de la migraine? Voilà comment arrêter la douleur en 3 minutes!

Ceux qui souffrent de la migraine un type de céphalée chronique, fréquente et invalidante sont toujours peur de son apparition. Plusieurs fois, la douleur peut être tellement insupportable qui peut vous empêcher de faire vos tâches quotidiennes.Le pire des cas est si la migraine est chronique, parce que ces gens doivent prendre des analgésiques très souvent.

(adsbygoogle = window.adsbygoogle || []).push({});

Essayer cette méthode alternative 100% naturelle et de faire votre propre traitement chez vous  au lieu de dépenser de l’argent sur ces analgésiques sur lequel votre corps peut être résistant après une certaine période sans oublier ses effets secondaires néfastes pour la santé.
Ingrédients:

Le jus de citron
Sel de l’Himalaya
Zeste de citron

Préparation:
Lire la suite dans la page suivante:
Cet article Souffrez-vous de la migraine? Voilà comment arrêter la douleur en 3 minutes! est apparu en premier sur Protège ta santé- Les actualités du web.

Annonce: Blockchain Game Summit – Les 25 et 26 Septembre 2018 au Musée des Confluences de Lyon

Le Blockchain Game Summit, soutenu par Ubisoft, réunira les experts internationaux du jeu vidéo et de la technologie blockchain les 25 et 26 Septembre 2018 au Musée des Confluences de Lyon.

Deux jours dédiés au jeu vidéo et la blockchain
Cette première édition est conçue pour 400 participants afin d’offrir une expérience à taille humaine et propice au réseautage.
Elle s’adresse aux professionnels du jeu vidéo et de la blockchain dans la perspective de:

Générer des opportunités de business et des partenariats;
Apprendre et/ou partager un savoir-faire avec les experts internationaux;
Construire le devenir du secteur du jeu vidéo & la blockchain avec les pionniers d’aujourd’hui: les faiseurs et les penseurs des deux industries.

L’espace d’exposition accueillera une trentaine d’entreprises, dont Ubisoft, accompagnées de studios de développeurs de jeux ainsi que des prestataires de services spécialisés dans la technologie de la blockchain. Cet espace sera enrichi d’une scène de démonstration. Les entreprises viendront y partager leur savoir-faire en direct.
L’Auditorium proposera deux jours de conférences et de panels dont le contenu de haut niveau sera partagé par des experts internationaux sur les thèmes suivants: Open standards, wallets pour les joueurs, les solutions de scalabilité, outils et librairie pour le développement de jeux, game design avec la blockchain, advocacy…
Une salle spécifique offrira des espaces dédiés au réseautage: Business lounge, Media & speakers lounge, Play zone (concevoir, tester et évaluer les jeux et les technologies). L’accueil des participants se veut personnalisé, qualitatif et festif avec des soirées exclusives, et une scénographie originale.
L’initiative
B2Expand, société lyonnaise à l’initiative de cet événement est le développeur du jeu “Beyond the Void” dont la monétisation est construite sur la Blockchain Ethereum. B2expand a réussi avec succès une ICO en novembre 2016 et est devenu un acteur majeur de la blockchain dans le jeu vidéo. La société souhaite désormais fédérer et faciliter la réflexion sur la construction de meilleures pratiques de l’industrie.
Ubisoft, sponsor majeur de l’événement, apporte son expertise du secteur du jeu vidéo notamment sur la curation du contenu proposé.
Site web de l’événement: http://blockchaingamesummit.com/

Compte rendu: 1ère DAPP (Dapps Adoption Paralelni Polis)

Le samedi 30 juin 2018 à Prague a eu lieu la « DAPP, UX & Adoption unconference ». Comme son nom l’indique, cette conférence porte sur l’évolution des infrastructures et des habitudes de consommation des applications décentralisées sur le réseau Ethereum.
Photo prise le samedi 30 juin 2018: Josef et la mangeoire. Pour mémoire, Josef avait présenté ce projet à EthCC (cf. la vidéo ici: https://www.youtube.com/watch?v=WBlyrbOgRAM)
La première édition de cet événement était organisée par le développeur Solidity Josef Jelacic. Josef est très actif. Parmi les projets les plus marquants de Josef, nous pouvons notamment citer la mangeoire pour oiseau sur Ethereum « Birdy » et le token de Gratitude.
La conférence a eu lieu à Paralelni Polis, l’épicentre de la monnaie digitale et de la Cryptoanarchy en République Tchèque. Paralelni Polis est un centre créé par le groupe artistique Ztohoven.  
Pedro Gomes a présenté Walletconnect, un projet de standardisation de l’intégration d’Ethereum sur les navigateurs de téléphones portables.
Will Harborne a fait une présentation sur la plateforme d’échange décentralisée Ethfinex. Les plateformes d’échanges décentralisées sont les projets en développement avec le plus de hype. La première question de l’audience portait sur la nature des relations entre Bitfinex et Ethfinex, la plateforme d’échange centralisée Bitfinex étant un investisseur de Ethfinex. Will a confirmé que les deux entités sont bien séparées et indépendantes.
Jérôme de Tychey, président de l’Asseth et directeur de ConsenSys Solutions en France, a présenté les statistiques sur l’évolution des habitudes de consommation sur le réseau Ethereum. Jérôme conseille aux débutants et aux utilisateurs confirmés de passer du temps sur https://cryptozombies.io/ pour améliorer leurs connaissances sur Solidity. Jérôme souligne le désalignement entre la forte activité des développeurs Ethereum et le manque d’utilisateurs des DAPPs.

Nik Page, un vétéran de UX, a répondu à la question posée par Jérôme en disant que la gratuité est omniprésente sur internet et qu’il va falloir trouver de nouvelles motivations pour que les utilisateurs s’approprient les DAPP. Il a dit qu’il fallait susciter les émotions des potentiels utilisateurs pour élargir la base d’utilisateurs.
Patrick Bowen de Status a préconisé l’éducation des utilisateurs avec un nouveau vocabulaire afin d’utiliser efficacement les DAPP. Il a recommandé les rencontres en face à face et les études qualitatives sur les habitudes des consommateurs.
Makoto Inoue de ENS a proposé d’acheter notre nom pour personnifier les paiements Ethereum et d’une certaine manière nous approprier le réseau.
Josef a conclu la journée en donnant à l’audience un devoir. Lors d’une rencontre familiale, expliquez à vos parents ce que sont les crypto monnaies et les DAPP et laissez-les trouver un terme pour ces nouveaux concepts. Partagez leurs découvertes sur twitter en utilisant #DAPPUXA.
Photo du devoir :

Un grand merci à Josef pour avoir réuni sa communauté Ethereum à Prague pour cet évènement. Vous pouvez regarder la conférence en replay sur YouTube. Si vous visitez Prague, n’hésitez pas à prendre un café à Paralelni Polis. La prochaine conférence Ethereum à Prague sera le DevCon 4 du 30 Octobre au 2 Novembre 2018.
Victor Notaro pour l’Asseth.

Le tueur de l’obésité : une cuillère à café par jour de cette épice vous fera perdre jusqu’à 15 kg en 3 mois!

Le moyen le plus efficace pour perdre du poids est d’augmenter le taux de votre métabolisme. Par conséquent, vous n’avez pas besoin de modifier votre régime alimentaire ou de garder un régime d’une façon strict. Tout ce que vous devez faire est d’ajouter cette épice pour votre repas préféré.

(adsbygoogle = window.adsbygoogle || []).push({});

Cette méthode est tout à fait plus efficace que la famine, car il permettra d’accélérer le taux métabolique toute en fournissant tous les nutriments essentiels que vous entrez par la nourriture.
Il y a une étude récente menée à l’Université des sciences médicales de l’Iran qui a impliqué deux groupes de femmes en surpoids avec 44 participants.
Chacun de ces groupes fait un contrôle sur l’alimentation saine dans un délai de trois mois. Ils avaient un menu du jour qui ne contient pas plus de 500 calories.
Lire la suite dans la page suivante:
Cet article Le tueur de l’obésité : une cuillère à café par jour de cette épice vous fera perdre jusqu’à 15 kg en 3 mois! est apparu en premier sur Protège ta santé- Les actualités du web.

Avec ce remède, mon grand-père a traiter définitivement le diabète en seulement 7 jours

Aujourd’hui, nous allons vous présenter un remède naturel pour résoudre les problèmes liés au diabète et maintenir le taux du sucre sanguin sous contrôle. Certainement, le diabète est difficile à traiter et peut affecter votre qualité de vie à différents niveaux, mais le remède que nous avons pour aujourd’hui a montré un grand effet et il est considéré comme l’un des meilleurs remèdes naturels pour traiter cette maladie.

(adsbygoogle = window.adsbygoogle || []).push({});

Le diabète est une maladie chronique survenant lorsque le pancréas ne peut pas produire suffisamment d’insuline ou lorsque le corps ne peut pas l’utiliser correctement. Le manque d’insuline dans votre corps est un gros problème et peut causer certains déséquilibres qui affecteront vos fonctions de base.
Bien que le traitement du diabète nécessite pilules ou des injections d’insuline pour le reste de votre vie . Ce remède naturel contrôlera vos niveaux d’insuline et guérira efficacement tous les problèmes de diabète.
Recette:
Lire la suite dans la page suivante:
Cet article Avec ce remède, mon grand-père a traiter définitivement le diabète en seulement 7 jours est apparu en premier sur Protège ta santé- Les actualités du web.