L'une des sociétés les plus pro-Bitcoin, le développeur de logiciels américain MicroStrategy, a confirmé avoir récemment acheté 19 452 BTC (environ un milliard de dollars), ce qui porte sa réserve à 90 531 BTC, soit 4,5 milliards de dollars. Dans sa dernière transaction, la société dirigée par Michael Saylor a dépensé 1,026 milliard de dollars (frais et

Wikipedia/World Economic Forum/swiss-image.ch/Photo by Remy Steinegger Bill Gates, le PDG de Microsoft, a rejeté la possibilité d'acheter des bitcoins (BTC), à l’exemple de la stratégie crypto adoptée par son collègue Elon Musk. Mais à plusieurs reprises, il a évoqué une infrastructure de paiement ou de monnaie numérique qui, pour certains partisans de BTC, semble très familière.

Michael Saylor. Source: Youtube/Swan Signal - A Bitcoin Channel La lecture de certains livres peut littéralement changer la façon dont on voit le monde et ce n’est pas Michael Saylor, le PDG de Microstrategy, qui dira le contraire. C’est en effet après avoir lu L’Étalon Bitcoin (The Bitcoin Standard), le livre de Saifedean Ammous que l’investisseur américain a radicalement changé

Elle pendait au nez des investisseurs, cette correction. Et si les mouvements de Bitcoin et d’Ethereum n’ont rien eu de surnaturel ce lundi, cette journée s’est surtout distinguée par une volatilité historique. Ce qui a bien entendu fait d’énormes dégâts du côté des positions leveragées, qui se sont faits liquider au cours du flash crash […]

Ce n’était plus qu’une question de temps. C’est désormais chose faite, Bitcoin est à plus de 50.000 $. Le reste du complexe suit, de nombreuses cryptos ont battu leur record de 2017. Notamment Ethereum, qui devrait bientôt toucher les 2.000 $. Tout ce qui monte devant descendre, quand allons-nous connaître une correction ? Quelle sera son […]

La cryptomonnaie est une monnaie numérique qui peut être utilisée pour acheter des biens et des services. En outre, elle utilise aussi un registre en ligne avec une cryptographie solide pour sécuriser les transactions en ligne. Parce qu’avec la cryptomonnaie, il est possible d’envoyer de l’argent partout dans le monde, quel que soit le récipient, […]

Article de Vitalik Buterin publié sur https://vitalik.ca/general/2021/01/05/rollup.html, traduit par Jean Zundel.

Depuis longtemps, les couches de niveau 2 sont vues comme un moyen de passer à l’échelle, pour augmenter le nombre de transactions par seconde limitant naturellement une blockchain décentralisée comme Ethereum. Les rollups, dont le nom évoque les rouleaux de pièces que l’on peut commodément transporter et stocker, sont rapidement devenus la technologie la plus en vue. Après un bref survol des solutions développées auparavant, Plasma et les channels, Vitalik Buterin expose ici les principes fondamentaux des deux principaux types de rollups ainsi que les avantages et les inconvénients de chacun.

Les rollups font fureur dans la communauté Ethereum, et sont en passe de devenir la solution clé pour le scaling, le passage à l’échelle d’Ethereum dans un avenir proche. Mais qu’est-ce exactement que cette technologie, que peut-on en attendre et comment l’utiliser ? Cet article tentera de répondre à certaines de ces questions.

Contexte : qu’est-ce que le passage à l’échelle des couches 1 et 2 ?

Il existe deux manières de passer à l’échelle l’écosystème d’une blockchain. Premièrement, on peut faire en sorte que la blockchain elle-même ait une capacité de transactions plus élevée. Le principal inconvénient de cette technique est que les blockchains comportant de « plus grands blocs » sont intrinsèquement plus difficiles à vérifier et risquent de devenir plus centralisées. Pour éviter ce risque, les développeurs peuvent soit augmenter l’efficacité du logiciel client, soit, de manière plus durable, utiliser des techniques telles que le sharding pour permettre de répartir le travail de construction et de vérification de la chaîne sur de nombreux nœuds ; le projet connu sous le nom de « eth2 » est actuellement en train de mettre en œuvre cette solution pour Ethereum.

Deuxièmement, on peut changer la façon dont on utilise la blockchain. Au lieu de placer directement toute l’activité sur la blockchain, les utilisateurs effectuent la majeure partie de leur activité hors chaîne dans un protocole dit de « niveau 2 ». Il existe un smart contract ou contrat autonome sur la chaîne, qui n’a que deux tâches : traiter les dépôts et les retraits, et vérifier les preuves que tout ce qui se passe hors de la chaîne respecte les règles. Il existe plusieurs manières de faire ces preuves, mais elles ont toutes en commun le fait que la vérification des preuves sur la chaîne est beaucoup moins coûteuse que le calcul originel hors chaîne.

Comparaison : state channels, Plasma et rollups

Les trois principaux types de mise à l’échelle par une couche de niveau 2 sont les state channels ou canaux d’état, Plasma et les rollups. Il s’agit de trois paradigmes différents, avec des avantages et des inconvénients différents, et à ce stade, nous sommes assez confiants dans le fait que toutes les mises à l’échelle de la couche 2 entrent à peu près dans ces trois catégories (bien que des controverses de dénomination existent à la marge, voir par exemple «validium»).

Comment fonctionnent les channels ?

Voir aussi : https://www.jeffcoleman.ca/state-channels et statechannels.org

Imaginez qu’Alice offre une connexion Internet à Bob, en échange de quoi ce dernier lui verse 0,001 dollar par mégaoctet. Au lieu d’effectuer une transaction pour chaque paiement, Alice et Bob utilisent le système de niveau 2 suivant.

D’abord, Bob met 1$ (ou l’équivalent en ETH ou en monnaie stable) dans un contrat autonome. Pour effectuer son premier paiement à Alice, Bob signe un «ticket» (un message hors chaîne), qui dit simplement «0,001$», et l’envoie à Alice. Pour effectuer son deuxième paiement, Bob signe un autre ticket qui indique «0,002$» et l’envoie à Alice. Et ainsi de suite pour autant de paiements que nécessaire. Lorsque Alice et Bob ont terminé leurs transactions, Alice peut publier le ticket de plus grande valeur à la chaîne, enveloppé dans une autre signature de sa part. Le contrat vérifie les signatures d’Alice et de Bob, verse à Alice le montant indiqué sur le ticket de Bob et renvoie le reste à Bob. Si Alice ne veut pas fermer le channel (pour cause de malveillance ou de défaillance technique), Bob peut déclencher une période de retrait (par exemple, 7 jours) ; si Alice ne fournit pas de ticket dans ce délai, Bob est alors remboursé de tout son argent.

Cette technique est puissante : elle peut être ajustée pour gérer les paiements bidirectionnels, les relations par contrat autonome (par exemple, Alice et Bob passent un contrat financier à l’intérieur du canal) et la composition (si Alice et Bob ont un canal ouvert, tout comme Bob et Charlie, Alice peut interagir sans confiance avec Charlie). Mais les channels ont leurs limites. Les channels ne peuvent pas être utilisés pour envoyer des fonds hors chaîne à des personnes qui ne sont pas encore des participants. Les channels ne peuvent pas être utilisés pour représenter des objets qui n’ont pas de propriétaire logique clair (par exemple, Uniswap). Et les channels, surtout s’ils sont utilisés pour faire des choses plus complexes que de simples paiements récurrents, nécessitent de bloquer un capital important.

Comment Plasma fonctionne-t-il ?

Voir aussi l’article originel sur Plasma et Plasma Cash.

Pour déposer un actif, un utilisateur l’envoie au contrat autonome qui gère la chaîne Plasma. Elle lui attribue un nouvel identifiant unique (par exemple 537). Chaque chaîne Plasma a un opérateur (il peut s’agir d’un acteur centralisé, d’un multisig ou d’un élément plus complexe comme du PoS ou du DPoS). À chaque intervalle (15 secondes, ou une heure, ou entre les deux), l’opérateur génère un «lot» composé de toutes les transactions Plasma qu’il a reçues hors chaîne. Il génère un arbre de Merkle, où à chaque indice X de l’arbre, il y a une transaction transférant l’actif d’ID X s’il en existe une ; sinon cette feuille est à zéro. Ils publient la racine Merkle de cet arbre sur la chaîne. Ils envoient également la branche de Merkle de chaque index X au propriétaire actuel de cet actif. Pour retirer un actif, un utilisateur publie la branche de Merkle de la transaction la plus récente qui lui a envoyé l’actif. Le contrat déclenche une période de contestation, pendant laquelle chacun peut essayer d’utiliser d’autres branches de Merkle pour invalider la sortie en prouvant que (i) l’expéditeur ne possédait pas l’actif au moment où il l’a envoyé, ou (ii) qu’il a envoyé l’actif à quelqu’un d’autre à un moment ultérieur. Si personne ne prouve que la sortie est frauduleuse pendant (par exemple) 7 jours, l’utilisateur peut retirer le bien.

Plasma présente des propriétés plus puissantes que les canaux : vous pouvez envoyer des actifs à des participants qui n’ont jamais fait partie du système, et les exigences en matière de capital sont beaucoup plus faibles. Mais cela a un coût : les chaînes ne nécessitent aucune donnée pour tourner en «fonctionnement normal», mais Plasma exige que chaque chaîne publie une empreinte cryptographique à intervalles réguliers. De plus, les transferts Plasma ne sont pas instantanés : il faut attendre la fin de l’intervalle et la publication du bloc.

En outre, Plasma et les channels partagent une même faiblesse : la théorie des jeux sur laquelle se fonde leur sécurité repose sur l’idée que chaque objet contrôlé par les deux systèmes a un «propriétaire» logique. Si ce propriétaire ne se soucie pas de son bien, il peut en résulter un résultat «non valide» concernant cet actif. Cette situation est acceptable pour de nombreuses applications, mais elle est un facteur de rupture pour beaucoup d’autres (par exemple, Uniswap). Même les systèmes où l’état d’un objet peut être modifié sans le consentement du propriétaire (par exemple, les systèmes basés sur les comptes, où l’on peut augmenter le solde de quelqu’un sans son consentement) ne fonctionnent pas bien avec Plasma. Tout cela signifie qu’il faut beaucoup de «raisonnement spécifique à l’application» dans tout déploiement réaliste de Plasma ou de channels, et qu’il n’est pas possible de mettre en œuvre un système Plasma ou de channels qui se contente de simuler l’environnement complet d’Ethereum (ou «l’EVM»). Pour contourner ce problème, il faut… les rollups.

Rollups

Voir aussi : EthHub sur les optimistic rollups et les ZK rollups.

Plasma et les channels sont des représentations «complètes» de couche de niveau 2, en ce qu’ils tentent de déplacer les données et les calculs hors de la chaîne. Cependant, les questions fondamentales de la théorie des jeux concernant la disponibilité des données signifient qu’il est impossible de le faire en toute sécurité pour toutes les applications. Plasma et les channels contournent ce problème grâce à une notion explicite de propriétaire, mais cela les empêche d’être totalement généraux. Les rollups, en revanche, sont une représentation «hybride» de couche 2. Les rollups déplacent le calcul (et le stockage de l’état) hors chaîne, mais conservent certaines données par transaction sur la chaîne. Dans un souci d’efficacité, ils utilisent toute une série d’astuces de compression pour remplacer les données par du calcul chaque fois que cela est possible. Il en résulte un système dont l’évolutivité est toujours limitée par la bande passante de données de la blockchain sous-jacente, mais dans un rapport très favorable : alors qu’un transfert de jetons ERC20 de la couche de base d’Ethereum coûte environ 45000 gaz, un transfert de jetons ERC20 dans un rollup occupe 16 octets d’espace sur la chaîne et coûte moins de 300 gaz.

Le fait que les données résident sur la chaîne est essentiel (N.B.: le fait de mettre les données «sur IPFS» n’est pas suffisant car IPFS ne permet pas d’obtenir un consensus sur la disponibilité ou non d’une donnée ; les données doivent se trouver sur une blockchain). Le fait de mettre les données sur la chaîne et d’avoir un consensus à ce sujet permet à quiconque de traiter localement toutes les opérations du rollup s’il le souhaite, ce qui lui permet de détecter la fraude, d’initier des retraits ou de commencer personnellement à produire des lots de transactions. L’absence de problèmes de disponibilité des données signifie qu’un opérateur malveillant ou hors ligne peut faire encore moins de mal (par exemple, il ne peut pas causer un retard d’une semaine), ce qui ouvre un espace de conception beaucoup plus grand pour qui a le droit de publier des batches, des lots, et ce qui rend les rollups beaucoup plus faciles à raisonner. Et surtout, l’absence de problèmes de disponibilité des données signifie qu’il n’est plus nécessaire de faire correspondre les actifs aux propriétaires, ce qui explique pourquoi la communauté Ethereum est aussi enthousiaste à l’égard des rollups comparé aux formes précédentes de passage à l’échelle de niveau 2 : les rollups sont totalement génériques, et on peut même faire fonctionner une EVM à l’intérieur d’un rollup, ce qui permet aux applications Ethereum existantes de migrer vers des rollups pratiquement sans avoir à écrire de nouveau code.

Bon, mais comment fonctionne un rollup exactement ?

Il existe un contrat autonome sur la chaîne qui maintient une racine d’état : la racine Merkle de l’état du rollup (c’est-à-dire les soldes des comptes, le code du contrat, etc. qui sont «à l’intérieur» du rollup).

Tout le monde peut publier un lot, un ensemble de transactions fortement compressé avec la racine d’état précédente et la nouvelle racine d’état (la racine Merkle après le traitement des transactions). Le contrat vérifie que la racine d’état précédente du lot correspond à sa racine d’état actuelle ; si c’est le cas, la nouvelle racine d’état devient l’actuelle.

Pour faciliter les dépôts et les retraits, nous ajoutons la possibilité d’avoir des transactions dont l’entrée ou la sortie est «en dehors» de l’état du rollup. Si un lot comporte des entrées provenant de l’extérieur, la transaction qui soumet le lot doit également transférer ces actifs au contrat de rollup. Si un lot a des sorties vers l’extérieur, alors, lors du traitement du lot, le contrat autonome initie ces retraits.

Et c’est tout ! Sauf un détail majeur : comment savoir si les racines post-état des lots sont correctes ? Si quelqu’un peut soumettre un lot avec n’importe quelle racine post-état sans conséquences, il pourrait simplement se transférer toutes les pièces à l’intérieur du rollup. Cette question est essentielle car il existe deux familles de solutions très différentes au problème, et ces deux familles de solutions mènent aux deux saveurs de rouleaux.

Optimistic rollups contre ZK rollups

Les deux types de rollups sont :

1. Les Optimistic rollups, qui utilisent des preuves de fraude : le contrat de rollup conserve une trace de tout son historique des racines de l’état et l’empreinte cryptographique de chaque batch. Si quelqu’un découvre qu’un batch avait une racine post-état incorrecte, il peut publier une preuve sur la chaîne, prouvant que le lot a été mal calculé. Le contrat vérifie la preuve et renvoie ce lot ainsi que tous les lots     suivants. 
2. Les ZK rollups, qui utilisent des preuves de validité : chaque lot comprend une preuve cryptographique appelée ZK-SNARK (par exemple en utilisant le protocole PLONK), qui prouve que la racine post-état est le résultat correct de l’exécution du lot. Quelle que soit l’ampleur du calcul, la preuve peut être très rapidement vérifiée sur la chaîne. 

Les compromis entre les deux types de rollups sont complexes :

Propriété	Optimistic rollups	ZK rollups
Coût fixe du gaz par batch	~40 000 (une transaction légère qui ne fait que changer la valeur de la racine de l’État)	~500 000 (la vérification d’un ZK-SNARK est un travail de calcul assez intensif)
Délai de rétractation	~1 semaine (les retraits doivent être retardés pour donner le temps à quelqu’un de publier une preuve de fraude et d’annuler le retrait s’il est frauduleux)	Très rapide (il suffit d’attendre le prochain lot)
Complexité de la technologie	Faible	Élevée (les ZK-SNARK sont une technologie très nouvelle et mathématiquement complexe)
Possibilité de généralisation	Plus facile (les rollups EVM à usage général sont déjà proches du réseau principal)	Plus difficile (prouver des ZK-SNARK avec une EVM générique est beaucoup plus difficile que de prouver des calculs simples, bien qu’il y ait des efforts (par exemple Cairo) pour améliorer cela)
Coût du gaz par transaction sur la chaîne	Supérieur	Inférieur (si les données d’une transaction ne sont utilisées que pour vérifier, et non pour provoquer des changements d’état, alors ces données peuvent être omises, alors que dans un Optimistic rollup, elles devraient être publiées afin de pouvoir les vérifier lors d’une preuve de fraude)
Coûts de calcul hors chaîne	Inférieurs (bien qu’il soit plus nécessaire de refaire le calcul pour de nombreux nœuds complets)	Supérieurs (un ZK-SNARK s’avère particulièrement coûteux, potentiellement des milliers de fois plus cher que le calcul direct)

D’une manière générale, mon avis est qu’à court terme, les optimistic rollups devraient l’emporter pour le calcul générique sur l’EVM et les ZK rollups sont susceptibles de l’emporter pour les paiements simples, les échanges et d’autres cas d’usage spécifiques aux applications ; mais à moyen et long terme, les ZK rollups l’emporteront dans tous les cas d’usage à mesure que la technologie des ZK-SNARK s’améliorera.

Anatomie d’une preuve de fraude

La sécurité d’un Optimistic rollup repose sur l’idée que si quelqu’un publie un lot non valable dans le rollup, qui que ce soit d’autre qui suit la chaîne et a détecté la fraude peut publier une preuve de fraude, prouvant au contrat que ce lot est non valable et doit être annulé.

Une preuve de fraude prétendant qu’un lot est invalide contiendrait les données en vert : le lot lui-même (qui pourrait être vérifié par rapport à un hachage stocké sur la chaîne) et les parties de l’arbre de Merkle devaient prouver uniquement les comptes spécifiques qui ont été lus et/ou modifiés par le lot. Les nœuds de l’arbre en jaune peuvent être reconstruits à partir des nœuds en vert et n’ont donc pas besoin d’être fournis. Ces données sont suffisantes pour exécuter le lot et calculer la racine post-état (notez que les clients sans état vérifient les blocs individuels exactement de la même manière). Si la racine post-état calculée et la racine post-état fournie dans le lot ne sont pas les mêmes, le lot est frauduleux.

On a la garantie que si un lot a été mal assemblé, et que tous les lots précédents ont été assemblés correctement, il est possible de créer une preuve de fraude montrant que le lot a été assemblé de manière incorrecte. Notez la déclaration concernant les lots précédents : si plusieurs lots non valides ont été publiés dans le rollup, il est préférable d’essayer de prouver que le premier est non valide. Bien entendu, on a également la garantie que si un lot a été assemblé correctement, il n’est jamais possible de créer une preuve de fraude montrant que le lot est invalide.

Comment fonctionne la compression ?

Une simple transaction Ethereum (pour envoyer de l’ETH) prend ~110 octets. Un transfert ETH sur un rollup, en revanche, ne prend que ~12 octets :

Paramètre	Ethereum	Rollup
Nonce	~3	0
Prix du gaz	~8	0-0.5
Gaz	3	0-0.5
Destinataire	21	4
Valeur	~9	~3
Signature	~68 (2+33+33)	~0.5
Depuis	0 (récupéré de sig)	4
Total	~112	~12

Cela provient pour partie d’un meilleur encodage : la RLP d’Ethereum gaspille 1 octet par valeur sur la longueur de chaque valeur. Mais il y a aussi des astuces de compression très bien trouvées qui entrent en jeu :

• Nonce : le but de ce paramètre est d’empêcher les rediffusions. Si le nonce courant d’un compte est de 5, la prochaine opération de ce compte doit avoir un nonce 5, mais une fois l’opération traitée, le nonce du compte sera incrémenté à 6, de sorte que l’opération     ne pourra pas être traitée à nouveau. Dans le rollup, nous pouvons omettre complètement le nonce, car nous nous contentons de récupérer le nonce de l’état antérieur ; si quelqu’un essaie de rejouer une transaction avec un nonce antérieur, la signature ne sera pas vérifiée, car la signature sera comparée aux données qui contiennent le nouveau nonce supérieur.
• Prix du gaz : nous pouvons permettre aux utilisateurs de payer dans une de prix du gaz, par exemple un choix de 16 puissances consécutives de deux. Une autre possibilité serait de fixer un niveau de prix fixe pour chaque lot, ou même d’exclure entièrement le paiement du gaz du protocole de rollup et de faire payer les créateurs de lots par les participants aux transactions pour inclusion par un channel.
• Le gaz : nous pourrions tout aussi bien utiliser la totalité du gaz pour choisir entre des puissances consécutives de 2. On pourrait aussi se contenter d’une limite de gaz uniquement au niveau du lot.    
• To : nous pouvons remplacer l’adresse de 20 octets par un index (par exemple, si une adresse est la 4527e adresse ajoutée à l’arbre, nous utilisons simplement l’index 4527 pour y faire référence. Nous ajoutons un sous-arbre à l’état pour stocker la correspondance des index aux adresses). 
• Valeur : nous pouvons stocker la valeur en notation scientifique. Dans la plupart des cas, les transferts ne nécessitent que 1 à 3 chiffres significatifs.    
• Signature : nous pouvons utiliser les signatures agrégées BLS, qui permettent d’agréger de nombreuses signatures en une seule de ~32-96 octets (selon le protocole). Cette signature peut ensuite être vérifiée par rapport à l’ensemble des messages et des expéditeurs d’un même lot en une seule fois. Le ~0,5 du tableau représente le fait qu’il y a une limite au nombre de signatures pouvant être combinées dans un agrégat qui peuvent être vérifiées dans un seul bloc, et donc de grands lots auraient besoin d’une signature pour ~100 transactions.

Une astuce de compression importante, spécifique aux ZK rollups, est que si une partie d’une transaction est uniquement utilisée pour la vérification et n’est pas pertinente pour le calcul de la mise à jour de l’état, alors cette partie peut être laissée hors chaîne. Cela ne peut pas être fait dans un optimistic rollup car ces données devraient toujours être incluses dans la chaîne au cas où elles devraient être vérifiées ultérieurement dans une preuve de fraude, alors que dans un ZK rollup, le SNARK prouvant l’exactitude du lot prouve déjà que toutes les données nécessaires à la vérification ont été fournies. Un exemple important est celui des rollups de protection de la vie privée : dans un optimistic rollup, le ZK-SNARK d’environ 500 octets utilisé pour la confidentialité dans chaque transaction doit être intégré à la chaîne, tandis que dans un ZK rollup, le ZK-SNARK couvrant l’ensemble du lot ne laisse déjà aucun doute sur la validité des ZK-SNARK «internes».

Ces astuces de compression sont la clé de l’extensibilité des rollups ; sans elles, les rollups ne représenteraient peut-être qu’une amélioration d’un facteur ~10 par rapport à l’extensibilité de la chaîne de base (bien qu’il existe certaines applications spécifiques gourmandes en calculs où même les simples rollups sont puissants), alors qu’avec ces astuces de compression, le facteur d’échelle peut dépasser 100 fois pour presque toutes les applications.

Qui peut soumettre un lot ?

Il existe plusieurs écoles pour déterminer qui peut soumettre un lot dans un optimistic ou un ZK rollup. En général, tout le monde s’accorde à dire que, pour pouvoir soumettre un lot, un utilisateur doit verser un dépôt important ; si cet utilisateur soumet un jour un lot frauduleux (par exemple avec une racine d’état invalide), ce dépôt sera en partie brûlé et en partie donné comme récompense à celui qui a prouvé la fraude. Mais au-delà de cela, il existe de nombreuses possibilités :

• Anarchie totale : tout le monde peut soumettre un lot à tout moment. C’est l’approche la plus simple, mais elle présente des inconvénients importants. En particulier, il existe un risque que plusieurs participants génèrent et tentent de soumettre des lots en parallèle, et qu’un seul de ces lots puisse être inclus avec succès. Cela entraîne un gaspillage important d’efforts pour produire des épreuves et/ou un gaspillage de gaz pour publier les lots à enchaîner.        
• Séquenceur centralisé : un seul acteur, le séquenceur, peut soumettre des lots (à l’exception des retraits : la technique habituelle est qu’un utilisateur peut d’abord soumettre une demande de retrait, puis si le séquenceur ne traite pas ce retrait dans le lot suivant, l’utilisateur peut alors soumettre lui-même un lot à opération unique). C’est la plus «efficiente», mais elle dépend d’un acteur central à vie.
• Vente aux enchères du séquenceur : une vente aux enchères est organisée (par exemple tous les jours) afin de déterminer qui a le droit d’être le séquenceur pour le jour suivant. Cette technique présente l’avantage de permettre de lever des fonds qui pourraient être distribués par une DAO contrôlée par le rollup (voir : enchères MEV)    
• Sélection aléatoire à partir de l’ensemble du PoS : n’importe qui peut déposer de l’ETH (ou peut-être le jeton de protocole propre au rollup) dans le contrat de rollup, et     le séquenceur de chaque lot est choisi au hasard parmi l’un des déposants, la probabilité d’être sélectionné étant proportionnelle au montant déposé. Le principal inconvénient de cette technique est qu’elle conduit à l’immobilisation inutile d’un capital important. 
• Vote DPoS : un seul séquenceur est sélectionné lors d’une enchère, mais s’il n’est pas performant, les détenteurs de jetons peuvent voter pour le jeter dehors et organiser une nouvelle enchère pour le remplacer.    

Fractionnement des lots et fourniture de racines par l’État

Certains des rollups actuellement en cours de développement utilisent un paradigme de «split batch» ou lot éclaté, où l’action de soumettre un lot de transactions de couche 2 et celle de soumettre une racine d’état sont effectuées séparément. Cela présente certains avantages clés :

1. On peut permettre à plusieurs séquenceurs en parallèle de publier des lots afin d’améliorer la résistance à la censure, sans craindre que certains lots soient invalides parce qu’un autre lot a été inclus en premier.    
2. Si une racine d’état est frauduleuse, il n’est pas nécessaire de rétablir l’ensemble du lot     ; on peut rétablir uniquement la racine d’état et attendre que quelqu’un fournisse une nouvelle racine d’état pour le même lot. Cela donne aux expéditeurs de transactions une meilleure garantie que leurs transactions ne seront pas inversées.

Il existe donc un attirail assez complexe de techniques qui tentent de trouver un équilibre entre des compromis compliqués impliquant efficacité, simplicité, résistance à la censure, entre autres objectifs. Il est encore trop tôt pour dire quelle combinaison de ces idées fonctionne le mieux ; le temps nous le dira.

Quelle est l’ampleur du passage à l’échelle apporté par les rollups ?

Sur la chaîne Ethereum existante, la limite de gaz est de 12,5 millions, et chaque octet de données dans une transaction coûte 16 gaz. Cela signifie que si un bloc ne contient qu’un seul lot (nous dirons qu’un ZK rollup est utilisé, dépensant 500k de gaz pour la vérification des preuves), ce lot peut avoir (12 millions / 16) = 750000 octets de données. Comme indiqué ci-dessus, un rollup pour les transferts ETH ne nécessite que 12 octets par opération utilisateur, ce qui signifie que le lot peut contenir jusqu’à 62500 transactions. Avec un temps de bloc moyen de 13 secondes, cela se traduit par ~4807 TPS (contre 12,5 millions / 21000 / 13 ~= 45 TPS pour les transferts d’ETH sur Ethereum lui-même).

Voici un tableau pour d’autres exemples de cas d’utilisation :

Application	Octets dans le rollup	Coût du gaz sur la couche 1	Gain maximal
Transfert d’ETH	12	21 000	105x
Transfert ERC20	16 (4 octets supplémentaires pour préciser quel jeton)	~50 000	187x
Trade Uniswap	~14 (4 octets expéditeur + 4 octets destinataire + 3 octets valeur + 1 octet prix maxi + 1 octet divers)	~100000	428x
Retrait avec confidentialité (Optimistic rollup)	296 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire + 256 octets de preuve ZK-SNARK)	~380 000	77x
Retrait avec confidentialité (ZK rollup)	40 (4 octets d’index de la racine + 32 octets d’annulateur + 4 octets de destinataire)	~380 000	570x

Il convient maintenant de garder à l’esprit que ces chiffres sont trop optimistes. Avant tout, un bloc ne contiendra presque toujours plus d’un seul lot, à tout le moins parce qu’il y a et qu’il y aura plusieurs rollups. Deuxièmement, les dépôts et les retraits continueront d’exister. Troisièmement, à court terme, l’utilisation sera faible, et les coûts fixes domineront donc. Mais même en tenant compte de ces facteurs, des gains d’extensibilité de plus de 100 devraient être la norme.

Maintenant, que faire si nous voulons aller au-delà de ~1000-4000 TPS (selon le cas d’utilisation spécifique) ? C’est ici qu’intervient le sharding d’eth2. La proposition sur le sharding, ou fragmentation, ouvre un espace de 16 Mo toutes les 12 secondes qui peut être rempli avec n’importe quelles données, et le système garantit un consensus sur la disponibilité de ces données. Cet espace de données peut être utilisé par des rollups. Cette capacité de ~1398k octets par seconde est une amélioration de 23x par rapport aux ~60 kB/sec de la chaîne Ethereum existante, et à plus long terme, la capacité en données devrait encore augmenter. Par conséquent, les rollups qui utilisent des données eth2 fragmentées peuvent traiter collectivement jusqu’à ~100k TPS, et même plus à l’avenir.

Quels sont les problèmes non encore résolus dans les rollups ?

Bien que le concept de base d’un rollup soit maintenant bien compris, que nous soyons tout à fait certains qu’il est fondamentalement faisable et sûr, et que de multiples rollups aient déjà été déployés sur le réseau principal, il reste encore de nombreuses zones d’ombre quant à leur conception, ainsi qu’un certain nombre de défis à relever pour amener de grandes parties de l’écosystème Ethereum sur des rollups afin de profiter du passage à l’échelle qu’ils offrent. Voici quelques-uns des principaux défis en question :

• Intégration des utilisateurs et de l’écosystème – peu d’applications utilisent des rollups, ils sont peu connus des utilisateurs et peu de portefeuilles ont commencé à les intégrer. Les commerçants et les associations ne les acceptent pas encore pour les paiements. 
• Transactions croisées – transfert efficace des actifs et des données (par exemple, les résultats d’oracles) d’un rollup à l’autre sans avoir à passer par la couche de base. 
• Audit des incitations – comment maximiser les chances qu’au moins un nœud honnête vérifie effectivement un optimistic rollup afin de pouvoir publier une preuve de fraude si quelque chose tourne mal ? Pour les rollups à petite échelle (jusqu’à quelques centaines de TPS), ce n’est pas     un problème important et on peut simplement compter sur l’altruisme, mais pour les rollups à plus grande échelle, une réflexion plus comlète est nécessaire sur ce sujet.    
• Exploration     de l’espace de conception entre le plasma et les rollups – existe-t-il des techniques permettant de mettre sur la chaîne certaines données pertinentes pour la mise à jour de l’état, mais pas toutes, et y a-t-il quelque chose d’utile qui pourrait en résulter ?     
• Maximiser la sécurité des pré-confirmations – de nombreux rollups fournissent une notion de «pré-confirmation» pour des UX plus rapides, où le séquenceur fournit immédiatement une promesse qu’une transaction sera incluse dans le lot suivant, et le dépôt du séquenceur est détruit s’ils manquent à leur parole. Mais la sécurité économique de ce système est limitée en raison de la possibilité de faire de nombreuses promesses à de très nombreux acteurs en même temps. Ce mécanisme peut-il être amélioré ?
• Améliorer la vitesse de réponse aux séquenceurs absents – si le séquenceur d’un rollup se met soudainement hors ligne, il serait utile de revenir à la normale rapidement et à moindre coût, soit en sortant en masse rapidement et à moindre coût vers un autre rollup, soit en remplaçant le séquenceur.     
• ZK-VM efficiente – génération d’une preuve ZK-SNARK selon laquelle le code de l’EVM générique (ou une autre VM sur laquelle les contrats existants peuvent être compilés) a été exécuté correctement et a donné un certain résultat. 

Conclusion

Les rollups constituent un nouveau paradigme puissant de passage à l’échelle de la couche de niveau 2 et devraient devenir une pierre angulaire du passage à l’échelle d’Ethereum à court et moyen terme (et peut-être aussi à long terme). La communauté Ethereum s’est montrée très enthousiaste car, contrairement aux tentatives précédentes de passage à l’échelle en couche 2, elle peut prendre en charge le code EVM générique, ce qui permet aux applications existantes de migrer facilement. Pour ce faire, ils ont fait un compromis essentiel : ils n’ont pas essayé de se retirer complètement de la chaîne, mais ont laissé une petite quantité de données par transaction sur la chaîne.

Il existe de nombreux types de rollups, et de nombreux choix dans l’espace de conception : on peut employer un optimistic rollup en utilisant des preuves de fraude, ou un ZK rollup en utilisant des preuves de validité (c.à.d. ZK-SNARK). Le séquenceur (l’utilisateur qui peut publier des lots de transactions à enchaîner) peut être un acteur centralisé, ou tout le monde et n’importe qui, ou encore un choix intermédiaire entre ces deux extrêmes. Les rollups sont une technologie encore très jeune et leur développement se poursuit rapidement, mais ils fonctionnent et certains (notamment Loopring, ZKSync et DeversiFi) fonctionnent déjà depuis des mois. On peut s’attendre à ce que des travaux passionnants dans ce domaine émergent dans les années à venir.

The post Un guide incomplet des rollups first appeared on Ethereum France.

Alors que la saga WSB et GameStop se poursuit, le phénomène déborde de la finance traditionnelle pour contaminer les cryptos. D’après les bourses d’échange, de nombreux utilisateurs se sont inscrits récemment afin de participer à ce que l’on ne peut appeler que des excès spéculatifs. Les cas emblématiques de ces derniers jours étant Ripple XRP […]

Les cryptos sont réputées pour être volatiles. Mais ce qu’il se passe sur les marchés traditionnels depuis vendredi est sans comparaison. C’est tout simplement surréaliste. Et c’est tellement vrai qu’on ne parle plus que de ça. On a beaucoup évoqué de l’implication grandissante des investisseurs sur les marchés. Mais à côté des RobinHooders, une nouvelle […]

Jeudi 10 Décembre, Ethereum France a le plaisir de recevoir Justin Drake, chercheur de la Fondation Ethereum et l’un des architectes d’Ethereum 2.

Venez nombreux à l’heure du déjeuner sur Youtube pour découvrir les coulisses du lancement du 1er décembre dernier et en apprendre plus sur les évolutions à venir. Le chat sera ouvert pour toutes vos questions.

Après avoir accueilli Mehdi Zerouali de Sigma Prime à quelques jours du premier bloc d’Ethereum 2, c’est au tour de Justin Drake de venir vous parler en français des efforts qui ont permis la réussite de la semaine dernière et ce à quoi vous devez vous attendre pour les mois à venir. Justin a déjà eu l’occasion de venir plusieurs fois à EthCC et notamment en 2019 pour présenter la phase 0 d’Ethereum 2. Justin a étudié les mathématiques à Cambridge et fait de l’entrepreneuriat autour de Bitcoin de 2014 à 2017 avant de se tourner vers la recherche sur Ethereum 2.0.

Rendez-vous à 12h30 jeudi 10 décembre sur notre chaîne Youtube

The post Live: Retour sur le lancement d’Ethereum 2 et vers son futur avec Justin Drake first appeared on Ethereum France.

FAQ publiée par Vitalik Buterin sur https://notes.ethereum.org/@vbuterin/BkSQmQTS8, traduite par Jean Zundel.

Bien sûr, le lancement réussi d’Eth2 a occupé tous les esprits ces dernières semaines, mais les travaux se poursuivent sur tous les fronts. L’EIP 1559, en discussion depuis plusieurs mois, représente une évolution majeure en changeant fondamentalement le fonctionnement des fees, les frais de transaction.

Qu’est-ce que l’EIP 1559 ?

L’EIP 1559 est une proposition visant à réformer le marché des frais d’Ethereum, avec les changements clés suivants :

• La limite actuelle de 10 millions de gaz est remplacée par deux valeurs : un «objectif moyen à long terme» (10 millions), et un «plafond ferme par bloc» (20 millions) ;
• Il existe un BASEFEE (qui est brûlé) que les transactions doivent payer, qui est ajusté bloc par bloc dans le but de cibler une valeur telle que la consommation moyenne de gaz du bloc reste autour de 10 millions.

En substance, alors que toute la volatilité à court terme de la demande d’espace de transaction à l’intérieur d’un bloc se traduit actuellement par une volatilité des frais de transaction, une partie se traduirait alors par une volatilité de la taille des blocs.

En quoi l’EIP 1559 est-elle bénéfique ?

Pour citer un ancien article :

Le statu quo des marchés des frais de transaction pose trois problèmes majeurs :

• Inadéquation entre volatilité des niveaux de frais de transaction et coût social des transactions : les frais de transaction sur les chaînes de blocs publiques établies, dont l’utilisation est suffisante pour que les blocs soient pleins, tendent à être extrêmement volatils. Sur Ethereum, les frais minimums tournent généralement autour de 2 gwei (10⁹ gwei = 1 ETH), mais ils peuvent parfois monter jusqu’à 20 à 50 gwei, voire 200 gwei en une occasion : https://etherscan.io/chart/gasprice. Il est clair que cela engendre une certaine inefficacité car il est absurde de supposer que le coût supporté par le réseau pour accepter une transaction supplémentaire dans un bloc soit 100 fois plus élevé lorsque le prix du gaz est de 200 gwei que lorsqu’il est de 2 gwei ; dans les deux cas, il s’agit d’une différence entre 8 millions de gaz et 8,02 millions de gaz ;
• Inefficacités des enchères de premier prix : voir https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 pour un compte rendu détaillé. En bref, dans l’approche actuelle, les émetteurs publient une transaction avec une redevance, les mineurs choisissent les transactions les plus rémunératrices et chacun paie ce qu’il offre. Cette approche est bien connue dans la littérature sur les mécanismes d’incitation pour être très inefficace, nécessitant des algorithmes complexes d’estimation des frais ; ces algorithmes finissent souvent par ne pas très bien fonctionner, ce qui entraîne fréquemment des frais excessifs. Voir également https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72, la description par un core développeur Bitcoin des défis entraînés par le statu quo de l’estimation des frais ;
• Instabilité des chaînes de blocs sans récompense en bloc : à long terme, les chaînes de blocs où il n’y aura pas d’émission (y compris Bitcoin et Zcash) ont actuellement l’intention de récompenser les mineurs par les frais des transactions. Toutefois, des résultats connus montrent que cela risque d’entraîner une grande instabilité, en incitant à miner des «blocs frères» pour voler les frais de transaction, ouvrant ainsi des vecteurs d’attaque par minage égoïste beaucoup plus puissants, etc. Il n’existe actuellement aucune mesure efficace d’atténuation de ce phénomène.

L’EIP 1559 présente ces avantages :

• Il atténue les inefficacités économiques dues à l’inadéquation des coûts sociaux en raison de la volatilité des frais. L’argument économique est assez nuancé ; voir en particulier les pages 16 à 20 du document dont le lien figure sur https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838 (bien que je recommande de lire l’ensemble du document) pour une argumentation détaillée sur les raisons de cette situation. Intuitivement, le mécanisme d’ajustement des frais fonctionne comme un frais fixe à court terme et un plafond à long terme, et il s’avère qu’en raison des arguments avancés dans cet l’article de Martin Weitzman (en 1974), des frais fixes sont probablement préférables à un plafond dans les conditions où, fondamentalement, toutes les blockchains publiques sont aujourd’hui en place.
• Il remplace la vente aux enchères par une vente à prix fixe (sauf pendant de courtes périodes où les blocs se remplissent complètement jusqu’à ce que les frais rattrapent leur retard), ce qui élimine les inefficacités de la vente aux enchères au premier prix et rend l’estimation des frais extrêmement simple : calculez les frais f pour le bloc suivant, si vous pouvez vous le permettre, payez-les, sinon ne le faites pas.
• Il crée un mécanisme similaire à une récompense permanente par bloc (le 1/N provenant du pot), ce qui atténue bon nombre des problèmes d’instabilité liés aux chaînes de blocs fonctionnant uniquement sur les frais sans nécessiter de véritable émission permanente.

Un autre avantage sous-estimé de l’EIP 1559 est qu’il permet de mesurer les prix du gaz de manière sûre. Aujourd’hui, le simple fait de regarder les prix du gaz sur la chaîne et de les utiliser comme indice est exploitable, car les mineurs peuvent inclure des transactions fictives à très faible ou très forte redevance, où la redevance se ferait à eux-mêmes. Mais en vertu de l’EIP 1559, le BASEFEE ne peut être manipulé qu’à un coût élevé, car les transactions fictives exigeraient même du mineur qu’il paie des frais (qui sont brûlés).

Les marchés actuels des frais sont-ils vraiment si inefficaces ?

Oui, la différence entre le prix moyen du gaz et le dixième centile du prix du gaz dans un bloc normal est d’environ 3 fois pour la médiane et de 5 à 8 fois pour la moyenne. Les gens paient trop, en masse, inutilement.

Toute personne qui ne paie pas trop subit un retard de 1 à 2 minutes, voire plus, et ce retard ne profite en fait à personne ; la charge totale de la chaîne est la même, qu’une unité de charge donnée atteigne la chaîne au temps N ou au temps N + 60. Il n’y a aucun avantage social réel à favoriser des participants «exprimant une préférence pour la rapidité» dans le mécanisme du marché des frais, du moins dans des conditions normales ; il s’agit d’une perte parfaitement inutile. Il vaudrait mieux pour nous tous que davantage de transactions soient incluses immédiatement, ce que permet l’EIP 1559.

Pourquoi ne pas simplement utiliser la deuxième enchère (ou une k-ième enchère) pour résoudre les inefficacités de la meilleure enchère ?

Les enchères au k-ième prix (où chacun paie un prix de gaz égal au prix le plus bas qui était inclus dans le bloc) sont effectivement «efficaces» dans une analyse économique traditionnelle*, mais elles ont le défaut d’être vulnérables à la collusion.

* Oui, bien sûr, techniquement, il faut utiliser le prix du gaz le plus élevé qui n’est pas inclus dans le bloc ; mais en pratique, étant donné que la plupart des blocs Ethereum comportent des centaines de transactions, la différence serait négligeable.

L’EIP 1559 pourrait-elle faire courir le risque de surcharger les nœuds et les mineurs pendant les périodes de forte utilisation ?

EIP 1559 peut tout au plus multiplier par 2 la taille des blocs, même à court terme. Chaque «bloc complet» (c’est-à-dire un bloc dont le gaz est 2x la TARGET) augmente le BASEFEE de 1,125x, donc une série de blocs complets constants augmentera le prix du gaz par un facteur 10 tous les ~20 blocs (~4,3 min en moyenne). Par conséquent, les périodes de forte charge sur la chaîne ne dureront pas plus de 5 minutes.

Notez qu’actuellement, les périodes de doublement de la charge durant 5 minutes se produisent déjà aléatoirement environ une fois tous les ~63888 blocs (~10 jours) en raison de la variance du taux de production des blocs. L’introduction de l’EIP 1559 n’entraînerait donc pas un niveau de charge sans précédent dans le système.

En outre, la limite de gaz de 10 millions, pas plus, est justifiée dans une large mesure non par des limites strictes du réseau (les taux d’oncles sont proches des plus bas niveaux historiques, bien que les risques pour les nœuds non-mineurs tels que les nœuds de bootstrap puissent être plus élevés), mais par des préoccupations fondamentalement long terme :

• Risque de centralisation par des taux d’oncles un peu plus élevés : si les taux d’oncles grimpaient jusqu’à 20%, cela profiterait de manière disproportionnée aux grands bassins bien connectés ;
• Limites en taille de l’état ;
• Difficulté de synchronisation après une courte période hors ligne.

Dans ces trois cas, ce qui importe n’est pas la limite supérieure de la capacité dans une fenêtre de temps très courte, mais plutôt la capacité moyenne à long terme. Le fait que les taux d’oncles soient de 2% pendant les heures impaires et de 18% pendant les heures paires aurait le même effet sur les trois cas précités, car les taux d’oncle sont toujours de 10%. Étant donné que l’EIP 1559 limite toujours la consommation de gaz à long terme à une moyenne d’environ 10 millions par bloc, il n’affecte pas la moyenne à long terme.

À quoi ressemblerait un pic de consommation élevée avec l’EIP 1559 par rapport au statu quo ?

Considérons un «pic mathématiquement idéal» (par exemple, cela pourrait se produire dans la vie réelle en raison d’un événement soudain sur le marché conduisant à de nombreuses possibilités d’arbitrage sur les DEX, à des offres sur les CDP liquidés, etc.), où N * 10 millions de transactions de gaz, chacune avec un prix du gaz très très élevé, sont toutes diffusées.

Actuellement, cela conduirait à la situation suivante :

• Les prochains blocs N seraient exclusivement remplis de nouvelles transactions à prix élevés ;
• Ensuite, les autres transactions, ainsi que celles que les gens enverraient après le pic, seraient incluses dans l’ordre décroissant du prix du gaz.

Un «utilisateur normal» moyen devrait attendre plus de N blocs.

Examinons maintenant la situation avec l’EIP 1559 :

• Les blocs N/2 suivants seraient remplis exclusivement de nouvelles transactions «d’heure de pointe», chacune avec une quantité de gaz deux fois plus importante que la normale ;
• Si toutes les autres transactions sont envoyées avec un plafond de prix du gaz égal à l’ancien prix du gaz, les blocs N/2 suivants seraient vides, et après cela les choses reviendraient à la normale. Mais de manière réaliste, les transactions prioritaires fixeraient des plafonds de prix du gaz plus élevés et seraient incluses en premier, et les autres transactions plus tard.

Un «utilisateur normal» moyen devrait attendre quelque part entre N/2 et plus de N blocs.

Par conséquent, même en incluant la «période de récupération» après la période de pointe pendant laquelle la capacité des blocs serait inférieure à la normale, la plupart des transactions seraient incluses plus tôt.

Voici une simulation très grossière (il y a beaucoup d’hypothèses étranges ici, mais il est difficile de modéliser un système complet qui couvre à la fois les courbes de l’offre et de la demande et les temps d’attente) ; le tableau source est ici.

Statu quo :

EIP 1559 :

Que ferait l’EIP 1559 en cas de pics plus importants et plus prolongés (p. ex. pics d’une journée) ?

Pas beaucoup. Le BASEFEE augmenterait et il y aurait une courte période au début où quelques transactions seraient plus rapides, mais après cela, le marché des frais fonctionnerait comme dans des conditions «ordinaires», à un niveau de frais plus élevé. Le principal avantage de l’EIP 1559 en matière de pics est que les dommages causés par l’inefficacité des marchés de frais ordinaires sont amplifiés lorsque les frais sont élevés, de sorte qu’il devient plus important d’avoir un marché des frais qui fonctionne.

Pourquoi limit = cible * 2 ? Pourquoi pas 4 ? Ou 8 ?

Plus le rapport limite / cible est élevé, plus les avantages de l’EIP 1559 en termes d’efficacité du marché des frais sont importants. Cela dépend de l’amplitude des pics à court terme que nous sommes prêts à accepter ; 2x est assez prudent. Nous pourrions même lancer l’EIP 1559 avec un rapport limite / objectif de 2 pour commencer, et l’augmenter au fil du temps si nous voyons que le réseau fonctionne bien même en cas de pics à court terme.

Pourquoi les mineurs incluraient-ils des transactions ?

L’EIP comprend un «pourboire» que les émetteurs de transactions peuvent inclure pour le mineur. Ce pourboire sert à deux choses : premièrement, s’il y a subitement beaucoup plus de transactions que prévu, les mineurs incluront d’abord les transactions avec un pourboire plus élevé, de sorte que le mécanisme de priorisation basé sur les frais reste finalement actif. Deuxièmement, il compense le risque d’oncles pour les mineurs (le risque accru que leur bloc ne soit pas inclus dans la chaîne principale parce que l’ajout d’une transaction supplémentaire le ralentira).

Le calcul du niveau de pourboire qui compense le risque d’oncle donne environ 0,8 gwei (les blocs oncles obtiennent en moyenne une récompense de 1,67 ETH au lieu de la base de 2 ETH, ce qui représente une perte de ~0,33 ETH = 330m gwei, 10 millions de blocs de gaz ajoutent ~0,025 au taux d’oncles par rapport aux blocs vides, donc le coût prévu du gaz est = 330m / 10m * 0,025 = 0,825 gwei) et les mineurs se fixent effectivement cette valeur lorsque la chaîne est vide.

Ce niveau de pourboire est indépendant du BASEFEE, de sorte que les clients peuvent en toute confiance fixer 1-1,5 gwei et s’attendre à ce que leurs transactions soient acceptées.

Comment les portefeuilles peuvent-ils choisir les pourboires ? Y a-t-il un risque de guerre des enchères pour les pourboires ?

Les portefeuilles pourront simplement choisir les pourboires en examinant quels pourboires ont été acceptés dans le passé sur la chaîne et en augmentant leur pourboire s’ils constatent qu’une transaction qu’ils envoient n’a pas été acceptée immédiatement. Notez que dans des «conditions normales», il n’y a aucune raison de fixer un pourboire supérieur au strict minimum.

En cas de congestion soudaine, les pourboires se transforment en guerre d’enchères ; les portefeuilles peuvent détecter la congestion et, dans ce cas, ils peuvent offrir aux utilisateurs la possibilité de fixer une priorité faible ou élevée pour leur transaction.

Qu’est-ce que le mécanisme d’escalator ? Comment peut-il être combiné avec le PEI 1559 ?

Le mécanisme d’escalator est une proposition de réforme différente des frais de transaction dans laquelle, au lieu de spécifier des frais uniques, les utilisateurs spécifient leurs frais comme une fonction, généralement avec un début, une augmentation par bloc et un maximum, par exemple «5 gwei si cette transaction est incluse dans le bloc 10123456, ajouter 1 gwei pour chaque bloc suivant (par exemple 8 gwei si inclus dans le bloc 10123459), jusqu’à un maximum de 100 gwei».

Il s’agirait de quatre paramètres : frais de début, bloc de début, incrément par bloc, frais maximum.

L’objectif est d’être «plus sécurisé» envers les erreurs d’estimation des frais, car si les frais s’avèrent trop bas, ils augmenteront naturellement au fil du temps jusqu’à ce que la transaction soit incluse. Dans le contexte de l’EIP 1559, cela pourrait être utilisé pour fixer le pourboire. Le fait que le pourboire se situerait généralement dans une fourchette constante signifie que même un portefeuille n’utilisant que des paramètres fixes pour l’escalator donnerait des résultats assez corrects aux utilisateurs.

Les mineurs ne seront-ils pas incités à s’associer pour faire baisser le BASEFEE en limitant le remplissage de leurs blocs à moins de la moitié ?

En général, l’efficacité ce genre de stratégies est limitée, car à moins que presque tout le monde ne soit de connivence, une transaction non incluse dans un bloc sera incluse dans le bloc suivant ; l’effet de cette action sur le BASEFEE à long terme sera donc négligeable.

Toutefois, les mineurs peuvent mettre en place une sorte de «tarification monopolistique». Supposons que les émetteurs de transactions soient prêts à payer des frais supplémentaires pour éviter d’être retardés d’un bloc. Les mineurs peuvent refuser d’inclure les transactions qui ne comportent pas un pourboire minimum T ; ils perdent une partie de leurs revenus, mais gagnent à ce que les émetteurs augmentent leurs frais s’ils évaluent la probabilité supplémentaire que vous soyez le prochain mineur et qu’ils incluent leur transaction de manière suffisamment élevée. Cette stratégie est fortement défavorable au mineur : il subit le coût total de la perte de revenus, mais ne gagne qu’une petite partie de l’augmentation des frais de transaction que d’autres envoient.

Notez que même si un mineur réussit avec cette stratégie, il augmentera les revenus des autres mineurs plus qu’il n’augmentera ses propres revenus (car les autres mineurs profitent des pourboires plus élevés en raison de vos actions), et il ne s’agit donc pas d’un vecteur de centralisation.

Cela ne ramènera pas le BASEFEE à zéro, mais permettra d’atteindre un équilibre où le BASEFEE constituera toujours la majeure partie des frais et les pourboires le complétant. En effet, à moins que les mineurs ne soient tous de connivence (auquel cas nous avons des problèmes plus importants), les mineurs subissent la totalité des coûts, hors transactions, mais ne bénéficient que partiellement des avantages liés à l’augmentation des pourboires.

Si le risque que les mineurs déploient une telle stratégie reste inacceptable, nous pouvons affecter une partie (par exemple 50%) des recettes de l’EIP 1559 à un fonds commun dont un petit pourcentage est prélevé sur chaque bloc pour être ajouté à la récompense de bloc des mineurs ; cela garantit que les mineurs bénéficient d’un BASEFEE élevé, ce qui réduit encore les gains d’une telle attaque.

Voici, schématisée, une proposition de modification de l’EIP allant dans ce sens :

• Définir le compte 0x35 comme FEE_SMOOTHING_BUFFER, et définir FEE_SMOOTHING_CONSTANT = 8192 ;
• Ajouter un terme supplémentaire à la récompense en bloc (ajouté en même temps que la récompense en bloc de base et les récompenses oncle+neveu). Soit smoothing_reward = FEE_SMOOTHING_BUFFER.balance // FEE_SMOOTHING_CONSTANT. Transférer smoothing_reward wei de FEE_SMOOTHING_BUFFER vers block.coinbase ;
• Après l’application des récompenses du bloc, la moitié des frais EIP-1559 de ce bloc (arrondis à l’inférieur) est ajoutée au solde de FEE_SMOOTHING_BUFFER. Le reste (c’est-à-dire la moitié arrondie à l’unité supérieure) est brûlé.

Notez que dans un contexte de preuve d’enjeu, il serait souhaitable de mettre en place des élections à bulletins secrets des dirigeants ainsi que des sanctions en cas de révélation prématurée, afin d’empêcher les validateurs d’acquérir la réputation de n’accepter que des pourboires élevés et d’en tirer eux-mêmes tout le bénéfice, car les émetteurs de transactions sauraient quels validateurs vont bientôt créer des blocs.

Autres ressources

Le document original : https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410

Thread de ethresear.ch sur les simulations de Barnabe : https://ethresear.ch/t/eip-1559-simulations/7280

The post FAQ EIP 1559 first appeared on Ethereum France.

Guide détaillé de A à Z de mise en place d’un validateur sur Ethereum 2.

Prérequis et implications

Devenir un validateur sur Ethereum 2 n’est pas quelque chose à prendre à la légère. Vous allez devoir bloquer 32 ETH (ou plus), sans pouvoir les retirer pendant un certain moment, et devoir vous assurer que votre validateur continue à être actif sur toute cette période, sans quoi vous perdrez une partie de vos ETH placés.

De grands pouvoirs impliquent de grandes responsabilités

Avant de vous jeter à l’eau, assurez-vous de pouvoir répondre à l’affirmatif à ces questions:

• Avez-vous 32 ETH ou plus à séquestrer pendant 3 ans ?
• Pourrez-vous accorder du temps à vos validateurs pendant 3 ans (mettre à jour les logiciels, s’assurer que le validateur fonctionne etc…)
• Avez-vous un minimum de connaissances en anglais (pour les mises à jour, les débats etc…)
• Avez-vous accès à un interpreteur de commande (parfois appelé Terminal, ou Console de commande)
• Avez-vous lu notre poste d’introduction à la preuve d’enjeu ?

Mise en place de la machine

Première étape : mettre en place une machine qui servira de validateur.

Deux options s’offrent à vous: vous pouvez utiliser une machine chez vous, ou bien un serveur hébergé ailleurs. Les deux ont leurs avantages et inconvénients : facilité d’accès, stabilité de la connexion à internet, taille du disque dur, confiance en l’hébergeur… je vous laisse faire votre choix. Dans ce guide, je vais utiliser un hébergeur (aucun lien d’affiliation, c’est juste celui que j’utilise personellement), afin de montrer cette étape aussi. Si vous avez déjà un ordinateur chez vous (ou votre serveur est déjà mis en place), vous pouvez procéder à l’étape « Mise en place des logiciels » directement !

Cette partie va vous montrer comment:

• Louer un serveur chez un hébergeur (ici netcup.eu)
• Configurer le pare-feu
• Configurer les clés d’accès (ssh) et s’y connecter

Louer un serveur

Allez c’est parti ! Rendons-nous chez netcup.eu (ce guide n’est en aucun cas affilié ! C’est simplement l’option que j’utilise personellement).

Sélectionnez « Server », et cherchez l’option VPS 6000 G9.

Une fois votre offre sélectionnée, vous devrez procéder à la création de compte. Retenez bien les informations que vous entrez : une fois la demande effectuée, vous recevrez un appel de netcup.eu en anglais (ils sont allemands) et ils vous demanderont de bien confirmer : votre nom / prénom, votre adresse, votre code postale. C’est tout à fait normal (bien que déroutant je vous le concède !).

Une fois ces informations confirmées par téléphone, ils vous enverront vos identifiants de connexion par e-mail : les e-mails sont en allemand et en anglais, donc il faudra scroller jusqu’en bas pour trouver la version anglaise !

Connectons-nous d’abord à notre espace client. Comme écrit dans le mail, le lien est celui-là : https://www.customercontrolpanel.de . Vos identifiants figurent aussi dans le mail (en orange sur la photo).

La première étape à suivre est de sécuriser notre compte client mettant en place le 2FA : un méchanisme de sécurité qui vous demandera d’entrer un code fournit par votre téléphone lors de vos prochaines connexions. Pour ce faire, cliquez sur Master Data en bas à gauche.

Là vous pouvez cliquer sur le bouton « Enable two factor authentication ».

Bien maintenant que votre compte est sécurisé, vous pouvez procéder au règlement. La facture devrait être à peu près égale à trois fois le montant mensuel : pas de panique, cela suit une période de facturation trimestrielle.

Une fois le règlement effectué, vous devriez recevoir de nouvelles informations par e-mail : un e-mail intitulé « Access data for SCP » et un autre intitulé « Ihr vServer bei netcup ist bereit gestellt.

D’abord par mesure de sécurité, rendez-vous sur le servercontrolpanel (https://www.servercontrolpanel.de/SCP), connectez-vous avec les identifiants contenus dans le mail, et changez votre mot de passe (menu déroulant en haut à droite, puis Option).

Sur ce paneau de contrôle, vous avez accès à vos machines, et si vous cliquez sur l’une de vos machines, vous aurez un détail de l’utilisation de celle-ci.

Vous pouvez maintenant vous connecter à la machine !

Connexion à la machine

Fini la rigolade ! On passe aux choses sérieuses ! Pour ce faire, nous allons utiliser ssh ! ssh est un programme qui permet de se connecter de façon sécurisée à un serveur.

Pour l’utiliser, rien de plus simple : depuis le terminal de votre machine, tapez ceci (en remplaçant « adresseip » par l’adresse IP de votre propre machine, qui vous a été communiquée dans le deuxième e-mail)

ssh root@adresseip

Le mot de passe demandé est celui qui apparaît dans l’email que netcup vous a envoyé. Ensuite, vous devriez avoir un message vous signalant que l’authenticité de la machine ne peut pas être prouvée… c’est normal, tapez « yes » !

Première étape…. changer de mot de passe ! Et oui, sécurité, sécurité, sécurité !

Entrez simplement :

passwd

Et choisissez un mot de passe solide (différent des autres mot de passe que vous utilisez habituellement !)

Création d’un utilisateur

Nous sommes actuellement connecté en tant que l’utilisateur « root« . C’est en quelque sorte le superman de votre ordinateur : il a tous les droits. C’est une très mauvaise habitude, et un grand risque de sécurité d’être connecté en tant que root, c’est pourquoi nous allons créer un utilisateur !

La commande a entrer est celle-ci (en changeant utilisateur pour le nom d’utilisateur que vous désirez créer).

adduser utilisateur

Suivez les instructions du terminal (soyez sûrs de choisir un mot de passe solide !). Puis, ajoutez cet utilisateur à la liste des « sudoers » : c’est la liste des utilisateurs qui sont autorisés à effectuer des actions en tant qu’administrateur (parfois). Tapez la commande ci-dessous (en remplaçant utilisateur par votre nom d’utilisateur choisi, évidemment).

usermod -aG sudo utilisateur

Pour être sûr que cela fonctionne correctement, déconnectez-vous de la machine en tappant :

exit

Puis connectez-vous cette fois-ci en utilisant votre nom d’utilisateur :

ssh utilisateur@adresseip

Sécurisation de la machine

La sécurité, c’est important ! C’est pourquoi nous allons procéder à la mise en place de trois mesures de sécurité : l’authentification par clé, le changement de port SSH, et l’installation d’un pare-feu.

Je vais tenter d’expliquer simplement à quoi servent ces deux mesures.

1. L’authentification par clé : pour vous connecter à votre machine vous avez utilisé un mot de passe. Mais si votre mot de passe se fait hack, ou bien si vous avez choisi un mot de passe trop fragile, un hacker pourra facilement se connecter à votre machine. C’est pourquoi nous allons utiliser l’authentification par clé : vous allez créer une clé SSH sur votre ordinateur, et c’est grâce à la présence de cette clé (et non le mot de passe) que vous serez autorisé à vous connecter.
2. Changer le port SSH : Le port par défaut pour se connecter en SSH sur n’importe quelle machine est le 22. Cela veut dire qu’un hacker essaiera par défaut de vous attaquer par le port 22. En le changeant à un autre port, il sera obligé de deviner quel port vous avez choisi pour essayer de s’y connecter. Cela complique nettement la tâche !
3. Installer un pare-feu : Par défaut, tous vos ports sont ouverts. Un attaquant peut donc essayer de vous attaquer sur beaucoup de ports différents. Un pare-feu résoud ce problème : il réduits les ports ouverts, et donc rend la surface d’attaque beaucoup plus petite.

Authentification par clé

Nous allons créer votre clé SSH qui vous servira à vous connecter au serveur. Commencez par vous déconnecter de votre serveur (exit). Ensuite, tappez cette commande :

ssh-keygen -t ed25519

Ensuite suivez les instructions sur votre console. Une fois terminé, il vous faudra ajouter cette clé à la liste des clés autorisées par votre serveur :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisatur@adresseip

Et voilà le travail ! Votre clé apparaît désormais parmi les clés autorisées sur votre serveur. Cependant, le serveur autorise toujours à se connecter en fournissant le mot de passe de l’utilisateur : nous allons modifierons cela quand nous effectuerons le changement de port SSH.

Changer de port SSH

Commençons par mettre à jour notre système.. Je ne vais pas détailler ces commandes mais en gros, elles mettent à jour le système, retirent les logiciels dont on ne se sert pas et installent UFW

sudo apt update && sudo apt upgrade
 sudo apt dist-upgrade && sudo apt autoremove
 sudo apt install -y ufw

Maintenant nous pouvons changer le port SSH. Vous n’avez qu’à choisir un numéro de port entre 1024 et 49151, et vous assurez qu’il ne sort pas en rouge lorsque vous tapez cette commande (en remplaçant numerodeport par le numéro de port que vous avez choisi) :

sudo ss -tulpn | grep numerodeport

S’il sort en rouge, c’est qu’il est déjà utilisé par votre ordinateur. Choisissez en un nouveau et recommencez !

Ensuite, mettez à jour votre fichier de configuration SSH. Lancez l’editeur de nexte nano:

sudo nano /etc/ssh/sshd_config

Ici vous aurez 4 lignes à modifier :

• Remplacer la ligne « Port 22 » par « Port NUMERODEPORT » en remplaçant NUMERODEPORT par le numéro que vous avez choisi (spécifie le port utilisé pour SSH).
• Enlever le « # » devant la ligne « #PubkeyAuthentication yes » (spécifie que nous acceptons la conneixon par clé).
• Remplacer la ligne « PasswordAuthentication yes » par « Password authentication no » (spécifie que nous voulons désactiver la connexion par mot de passe).
• Remplacer la ligne « PermitRootLogin yes » par « PermitRootLogin no » (spécifie que nous voulons interdire de se connecter en tant que root).

Appuyez ensuite sur CTRL+o (la touche contrôle et la touche o en même temps), puis Entrer, puis CTRL+x (la touche contrôle et la touche x en même temps). C’est la suite à tapper si l’on veut enregistrer un fichier et le fermer avec Nano.

Voici un GIF du déroulé de l’opération (avec comme exemple de port 39889).

Maintenant, nous pouvons redémarrer le service SSH. Il suffit d’entrer cette commande :

sudo systemctl restart ssh

Attention, à compter de maintenant, pour vous connecter au serveur, la commande ne sera plus « ssh utilisateur@ip » mais « ssh -p NUMERODEPORT utilisateur @ip ».

Pour vous déconnecter, tapez:

exit

Puis reconnectez-vous :

ssh -p numerodeport utilisateur@adresseip

Installation du pare-feu

Maintenant faisons en sorte de rejeter les connexions par défaut :

sudo ufw default deny incoming

Acceptons les connections sur notre port SSH choisi :

sudo ufw allow numerodeportssh/tcp

Puisque nous allons utiliser Geth et Lighthouse, nous allons ouvrir les ports 30303 et 9000 (respectivement)

sudo ufw allow 30303
 sudo ufw allow 9000

Mettons maintenant en marche ces pare-feu :

sudo ufw enable

Maintenant, en tapant « sudo ufw status verbose« , vous devriez avoir un rendu similaire (mon port choisi pour SSH est le 38998) :

Et voilà ! Votre machine est désormais installée et sécurisée. Nous pouvons passer à la prochaine étape : créer les clés des validateurs.

Créer les clés de validateurs

Rendez-visite à ce site : https://github.com/ethereum/eth2.0-deposit-cli/releases/ et trouvez la version du logiciel pour linux : elle devrait se terminer par « linux-amd64.tar.gz« .

Voici à quoi elle ressemble au jour de création de ce guide :

Ensuite copiez-en le lien :

Maintenant, reprenez le terminal et tapez ces commandes (en remplaçant le lien « https:// » par le contenu de votre presse-papier (le lien que vous avez copié lors de l’étape précédente)).

cd ~
 sudo apt install -y curl
 curl -LO https://github.com/ethereum/eth2.0-deposit-cli/releases/download/v1.1.0/eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz

Vous venez de télécharger la version compressée du logiciel qui va vous servir à créer les clés de vos validateurs. Pour le décompresser, il vous suffit de taper :

tar xvf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 rm -rf eth2deposit-cli-ed5a6d3-linux-amd64.tar.gz
 cd eth2deposit-cli-ed5a6d3-linux-amd64

Les noms des fichiers pourraient différer sur votre machine : ici c’est eth2deposit-cli-ed5q6d3 car c’est la version actuelle, mais elle pourrait changer dans le futur. Pour l’afficher, lancez simplement la commande ls.

Vous pouvez maintenant créer vos clés ! Entrez cette commande (en changeant nombredevalidateurs par le nombre de validateurs que vous comptez lancer) :

./deposit new-mnemonic --num_validators nombredevalidateurs --mnemonic_language=english --chain mainnet

Première étape : créer un mot de passe. Choisissez-en un (de préférence au hasard), de bonne qualité, et notez le sur le bout de papier. Ensuite lisez le bout de papier, et tapez-le ici. Soyez sûrs que ça correspond à ce que vous avez noté sur le bout de papier !

Ensuite vous verrez apparaître une liste de mots : c’est ce que l’on appelle votre mnemonic. Notez-le précieusement, en faisant bien attention à l’orthographe des mots (ils sont en anglais, attention aux faux amis!).

Vous devrez ensuite entrer, dans l’ordre, le mnemonic (suite de mots) que vous venez de noter. Soyez sûrs de taper ce que vous avez écrit sur votre papier !

Si vous tapez la commande ls, vous devriez avoir le même rendu :

Dans le dossier validator_keys se trouvent plusieurs fichier : un fichier deposit_data…json, et autant de keystore-m…json que vous avez entré de numéro de validateurs. Le fichier deposit_data est un fichier unique qui contient des informations nécessaires pour pouvoir déposer des ETH pour staker : les fichier keystore-m sont des fichiers représentants vos clés de validateur. Ils seront utilisés par la suite !

Vous avez créé vos clé de validateur (ainsi que le fichier de deposit associé, nous y reviendrons plus tard). Maintenant il est temps d’installer les logiciels !

Mise en place des logiciels

Troisième étape: mettre en place les logiciels nécessaires au staking.
Ces instructions sont écrites pour Ubuntu (Linux). Si vous utilisez une autre machine, il faudra probablement adapter quelques commandes !

Petit récapitulatif

Il y a trois logiciels principaux qui vont être exécutés par votre machine:

• Le client Ethereum 1 : Oui, cela peut paraître étonnant mais la chaîne Ethereum 2 a besoin de connaître l’état de la chaîne Ethereum 1 afin de fonctionner correctement.
• Le Beacon Node (BN) : C’est le logiciel qui s’occupe de communiquer avec les autres nœuds du réseau, de la gestion de la base de donnée de la chaîne: bref c’est lui qui fait le gros du travail.
• Le Validator Client (VC) : C’est le fameux « validateur » qui revient à toutes les sauces. C’est un logiciel relativement simple, qui ne s’occupe de faire qu’une seule chose: signer des transactions. Périodiquement, il doit signer des transactions, grâce à sa clé privée (clé qui doit rester secrète, bien cachée sur l’ordinateur). Il demande au BN quels messages il doit signer, s’assure que les informations renvoyées par le BN sont correctes, puis signe le message et le transmet au BN, qui lui le transmettra aux autres nœuds du réseau.

Ce qui est intéressant, c’est que plusieurs VC peuvent se connecter au même BN: en effet, on peut faire tourner des centaines de validateurs, qui se connectent tous au même BN. Un VC ne consomme pas beaucoup (rappelez-vous, c’est le BN qui fait la majorité du travail), en lancer plusieurs sur la même machine permet donc d’augmenter un peu la rentabilité.

Une question devrait vous traverser l’esprit : est-il possible de connecter son VC a un BN sur une autre machine ? La réponse est oui ! Vous pourriez très bien connecter vos VCs au BN d’un ami, ou d’une entreprise, si vous leur faites confiance. Vous n’êtes donc pas OBLIGE de faire tourner un BN, si vous faites confiance à un autre BN. Attention cependant : si le BN dans lequel vous avez confiance se met à mal agir (se déconnecter, être piraté…), vous pourriez en faire les frais ! C’est pourquoi il est recommandé de faire tourner son propre BN.

Le paragraphe précédent s’applique tout aussi bien au nœud Ethereum 1 que vous devez lancer: vous pouvez décider de ne pas en lancer, et de vous remettre à un ami / une entreprise (par exemple Infura). Cependant, comme pour le BN, c’est déconseillé, car on n’est jamais mieux servi que par soi-même !

Les clients

Il y a plusieurs implémentations de clients pour Ethereum 2 : les plus connus sont Lighthouse, Prysm, Teku, et Nimbus. Chaque client a ses spécificités (que ce soit l’équipe derrière, l’histoire, les buts recherchés, le langage utilisé, les caractéristiques techniques, la communauté etc…). Dans cet article, nous allons utiliser l’implémentation Lighthouse, de l’équipe Sigma Prime.

Nous avons deux possibilités pour lancer notre client :

1. Classique : Nous téléchargeons les code source des clients, nous les compilons (ou téléchargeons directement le binaire), puis nous lançons les logiciels un par un (geth, BN et VC). Cette technique est standarde, fonctionne correctement et permet de personnaliser des paramètres.
2. Docker-compose : C’est une technique qui repose sur l’utilisation d’un logiciel (docker-compose) qui fera tout ça à notre place. Voyez-ça comme un logiciel qui gère les autres logiciels : nous lui disons simplement « lance-moi une instance de geth, un BN, un VC, et connecte-les ensemble), et tada, le tour est joué !

J’ai personellement opté pour l’utilisation de docker-compose : ça rend la tâche très simple à utiliser, installer, et mettre à jour.

Docker et Docker-Compose

Afin de nous faciliter la tâche, nous allons utiliser un logiciel qui s’occupera de lancer les autres logiciels à notre place. Je vous présente : Docker !

Pour installer Docker sur Ubuntu, c’est tout simple :

sudo apt install -y docker.io

Assurons-nous que Docker a bien été installé en lançant cette commande en la comparant au screenshot en-dessous.

sudo docker run hello-world

Si cette commande ne fonctionne pas, c’est probablement que docker n’a pas été correctement installé. Dans ce cas, veuillez suivre les instructions d’installations officielles.

Profitons-en pour aussi installer Docker-Compose

sudo apt install -y docker-compose

Maintenant que nous avons installé le logiciel docker-compose, il ne nous reste plus qu’à lui dire ce que nous voulons lui faire faire (lancer geth, un BN et un VC). Ca tombe bien : l’équipe de lighthouse a un dossier avec tout de déjà préparé !

Assurons-nous d’abord d’être dans le bon répertoire :

cd ~

Puis téléchargeons le dossier de configuration

git clone https://github.com/sigp/lighthouse-docker/

La commande ls (qui liste les fichier du répertoire) devrait ressembler à cela maintenant :

Allez maintenant éditer le fichier de configuration. Déplacez-vous dans le bon répertoire :

cd lighthouse-docker

Faites une copie du fichier de configuration :

cp default.env .env

Et allez éditer le fichier de configuration : (n’oubliez pas, pour quitter c’est CTRL+O, Enter, CTRL+X)

nano .env

Voici la liste des paramètres à éditer. Si le paramètre n’apparaît pas dans cette liste, c’est qu’il doit être laissé à sa valeur par défaut. Attention, si vous voulez vous mettre sur le réseau de test, alors le paramètre NETWORK ne sera pas mainnet mais le nom du testnet (par exemple pyrmont).

NETWORK=mainnet
 START_VALIDATOR=YES
 VALIDATOR_COUNT=2
 START_GETH=YES
 ENABLE_METRICS=YES

Bien entendu je vous laisse éditer VALIDATOR_COUNT pour être égal au nombre de validateurs que vous avez choisi de créer.

Si vous avez une machine puissante, vous pouvez aussi mettre SLASHER=YES afin de mettre en route un slasher.

Maintenant notre fichier de configuraiton prêt, nous devons importer les validateurs. Pour ce faire, copiez d’abord les clés de validateurs dans le fichier courant.

cp -r ../eth2deposit-cli-ed5a6d3-linux-amd64/validator_keys/ .

Bien entendu il se peut que le nom de votre dossier varie : comme précisé au-dessus le mien est eth2deposit-cli-ed5a6d3-linux-amd64 mais je vous laisse adapter la commande à votre machine.

Puis initialisez les clés grâce à cette commande :

sudo docker run -it -v $(pwd)/lighthouse-data:/root/.lighthouse -v $(pwd)/validator_keys:/root/validator_keys sigp/lighthouse lighthouse --network mainnet account validator import --directory /root/validator_keys

Nous sommes fin prêts ! Nous allons ouvrir un gestionnaire de fenêtre, afin de conserver notre fenêtre ouverte (plus d’info dans l’encart juste en-dessous).
D’abord installons tmux :

sudo apt install -y tmux

Puis lançons-le !

tmux

Et maintenant, la commande finale :

sudo docker-compose up

Et voilà ! Vous devriez voir plein de messages fuser dans tous les sens. Ces messages sont des « logs », c’est-à-dire des messages qui décrivent le statut des différents logiciels (rappelez-vous, geth, BN et VC) qui tournent.

Si ces logs ne vous conviennent pas et vous voulez isoler seulement les logs du BN ou du VC, tappez :

sudo docker container ls --format '{{.Names}}'

Vous devriez avoir cela en sorite (peut-être deux lignes en plus si vous avez déjà lancé grafana / prometheus).

Pour suivre seulement les logs du validateurs par exemple :

sudo docker logs lighthouse-docker_validator_client_1 --follow

Et pour suivre le BN :

sudo docker logs lighthouse-docker_beacon_node_1

Ces commandes est lançable même si vous n’êtes pas dans tmux, et vous pouvez les quitter à tout moment en appuyant sur CTRL+c .

Vous pouvez quitter cet écran en appuyant sur CTRL+b puis d. Cela « détache » l’écran tmux et vous renvoie vers l’écran de départ. Les logiciels continuer donc de tourner en tâche de fond. Pour retourner sur l’écran de tmux, tappez :

tmux a

Si vous voulez arrêter complètement les logiciels : appuyez sur CTRL+c, puis entrez :

sudo docker-compose down

Maintenant que nous avons nos logiciels qui tournent, il ne nous reste plus qu’une étape : effectuer le(s) dépôt(s) d’ETH sur le réseau ! Rendez-vous sur le site officiel : https://launchpad.ethereum.org/overview (vous pouvez préfixer le nom du testnet désiré, par exemple : https://pyrmont.launchpad.ethereum.org/overview pour le testnet de pyrmont).

Lisez attentivement les 10 étapes (un récapitulatif ne fais jamais de mal), et vous devriez arriver sur cette page:

Vous pouvez choisir les logiciels que l’on utilise : geth, puis Lighthouse

Maintenant indiquez le nombre de validateurs que vous voulez lancer (dans mon cas, 2)

Puis cochez la case qui certifie que vous avez copié vos mnemoniques et votre mot de passe, et cliquez sur Continue.

Sur la page suivante, vous allez uploader votre fichier deposit_data dont on a parlé à tout à l’heure. Mais comment faire ? Le fichier se trouve sur mon serveur, pas du mon ordinateur ! Pas de panique ! J’ai la solution : scp !

scp est un programme qui permet de copier des fichiers depuis un serveur vers votre ordinateur (ou dans l’autre sens) de façon sécurisé.

D’abord créons un dossier pour stocker nos fichiers :

cd ~
 mkdir validateurs
 cd validateurs

Sur votre terminal, déconnectez-vous de votre machine (tapez exit), puis entrez simplement (en remplacant, comme d’habitude…) :

scp -r -P numerodeport utilisateur@adresseip:lighthouse-docker/validator_keys .

Et voilà le travail ! Vous devriez maintenant pouvoir cliquer sur le gros bouton + présent sur la page, et aller chercher le fichier deposit_data qui se trouve dans le dossier validateurs, dans votre répertoire d’utilisateur (home directory).

Maintenant vous devriez pouvoir uploader le fichier deposit_data :

Et vous devriez voir cet écran ! (si vous ne vous êtes pas trompés de réseau !)

Maintenant il faut faire le dépôt. Je vous laisse suivre le tutoriel d’installation de Metamask (vous pouvez y connecter votre Ledger si jamais c’est cela que vous utilisez)

Une fois Metamask installé, soyez sûrs d’être sur la bonne chaîne : Ethereum Mainnet pour un dépôt sur le mainnet, et Goerli pour un dépôt sur un testnet.

Vous n’avez plus qu’à lancer la transaction… et tada ! Votre dépôt aura été effectué ! Vous pouvez désormais suivre l’état de vos validateurs : dans metamask, cliquez sur la transaction que vous venez d’effectuer.

Puis cliquez sur la flèche qui vous mènera à l’explorateur de block :

Et ici vous pouvez voir les clés publique associées ! Vous pouvez consulter l’état de votre validateur en cliquant dessus.

Ici nous utilisons le site beaconscan. Un autre explorateur connu est beaconcha.in. Dans cette photo, mon dépôt n’a pas encore été inclus : en effet, une votre dépôt effectué, il faut du temps afin qu’il soit « inclus » et que votre validateur apparaisse dans la liste « officielle » des validateurs. Plus d’info sur ce procédé.

Monitoring

Cette partie est optionelle : il s’agit de mettre en place un système de monitoring (afin de garder un oeil sur sa machine !). Nous allons utiliser Grafana et Prometheus : Prometheus va se charger de récupérer des données de nos logiciels (mémoire utilisée etc), et Grafana se chargera de les afficher.

Encore une fois, docker va nous sauver ! Nous allons cloner le repo lighthouse-metrics qui a déjà tout de préparé pour nous :

cd ~
 git clone https://github.com/sigp/lighthouse-metrics
 cd lighthouse-metrics

Ensuite, nous allons lancer grafana et prometheus grâce à la commande… docker-compose ! Notez l’utilisation de -d, qui permet de le lancer en tâche de fond.

sudo docker-compose up -d

Maintenant nous pouvons passer à la dernière étape : visualiser les données ! Déconnectez-vous du serveur (tappez exit), et tappez la commande suivante (en remplacant, comme d’habitude):

ssh -p numerodeport -L 127.0.0.1:3000:127.0.0.1:3000 utillisateur@adresseip

Et maintenant, sur votre navigateur, tapez cette URL : localhost:3000 ! Vous devriez arriver sur un panneau de configuration ! Le nom d’utilisateur est admin et le mot de passe changeme. Ensuite, vous devrez cliquer sur le bouton Manage

Puis cliquez sur le bouton Import

Maintenant vous devez visiter cette page et en copier le contenu, et le coller le contenu dans la box « Import panel via JSON »

Puis cliquez sur Load et Import et… tada !!

C’est un panneau de monitoring global, il vous est bien sûr possible de modifier et l’adapter à vore convenance !

Aller plus loin

Des améliorations sont toujours possibles ! Vous pourriez créer des services qui se relancent automatiquement, avoir un système de sauvegarde, avoir un meilleur système de logging… cependant ce guide n’est là que pour couvrir les bases. Il ne faut vraiment pas hésiter à aller chercher de l’aide et poser des questions, voici donc quelques recommandations de site / communautés qui pourraient vous intéresser :

https://reddit.com/r/ethstaker/ : Le subreddit d’une communauté de staker (je vous recommande de rejoindre le Discord, c’est un des meilleurs endroits pour poser des questions)
https://reddit.com/r/ethereum : Le subreddit officiel d’Ethereum
https://lighthouse-book.sigmaprime.io/ : La documentation officielle de Lighthouse
https://docs.prylabs.network/docs/getting-started/ : La documentation officielle de Prysm
https://docs.teku.consensys.net/en/latest/ : La documentation officielle de Teku
https://status-im.github.io/nimbus-eth2/ : La documentation officielle de Nimbus

Pour se renseigner sur le protocole en général il y a bien entendu :
– La spécification officielle : https://github.com/ethereum/eth2.0-specs
– Cet article que j’ai particulièrement apprécié : https://ethos.dev/beacon-chain/
– Les spécifications commentées de Vitalik et de Ben Edgington

Appendice

Détails sur les pénalités

Il y a deux grosses catégories de pénalités que vous pourriez encourir :

1. Slashing : une grosse partie de vos ETH sont retirés instantanément, et votre validateur se fait exclure (il ne peut plus staker). Cela pourrait se produire si vous lancez deux fois le même validateur, ou si vous utillisez une version malicieuse d’un client. Cela pourrait aussi se produire dans le cas ou vous perdez votre base de donnée de protection (voir l’encart juste au-desus).
2. Leaking : C’est le fait d’avoir une « fuite » d’ETH dû à une absence. Si votre validateur n’est pas en ligne, il subit des pertes. Ces pertes sont proportionelles au nombre de validateurs qui sont hors-ligne en même temps que vous. Si vous êtes tout seul, les pénalités sont minimes (de l’ordre de 0.3% par semaine, ce qui vous laisse LARGEMENT le temps de revenir en ligne), mais si la moitié du réseau en hors-ligne en même temps, alors les pénalités augmentent très rapidement. Il y a donc un risque à avoir votre machine chez un hébergeur type AWS ou netcup.eu : s’ils tombent en panne, vous ne serez pas le seul à être hors-ligne et encourerez donc des peines plus élevées…

Se connecter via l’interface de Netcup.eu

Rendez-vous sur le servercontrolpanel et cliquez sur votre machine. Ensuite cliquez sur la « Console » en haut à droite de l’écran (entouré en rouge sur la photo).

Une fenêtre pop-up devrait s’ouvrir (si elle ne s’ouvre pas vérifiez les paramètres de votre navigateur). Ici, il vous suffit de vous connecter en entrant d’abord le nom d’utilisateur, puis le mot de passe de votre utilisateur. Si vous n’avez pas encore d’utilisateur, utilisez les identifiants de root.

Cela vous donne accès à un shell classique : à vous de résoudre les problèmes afin de pouvoir vous reconnecter depuis votre interprêteur ! (Probablement un problème de port SSH / pare-feu…)

Infura et autres ETH1 endpoints

Si votre machine est peu performante, une solution possible est d’utiliser un « fournisseur » d’accès à ETH1 plutôt que de faire tourner votre propre instance de geth. C’est plus risqué (car vous devez faire confiance à votre fournisseur plutôt que de lancer un client par vous-même), mais cela devrait réduire les ressouces utilisées par votre machine.

Infura

Je vais ici donner un exemple de mise en place avec Infura. Si vous avez déjà votre fournisseur d’accès à Ethereum 1, vous pouvez passer cette étape.

Rendez-vous sur le site infura.io et créez un nouveau compte.

Une fois votre compte créé, cliquer sur l’onglet Ethereum dans la barre de gauche.

Créez ensuite un nouveau projet en cliquant sur « Create New Project » (il se peut que l’interface soit différente si c’est votre premier projet)

Ensuite cliquez sur votre projet et allez dans l’onglet Settings.

En bas de la page vous trouverez les informations qui nous intéressent : le menu déroulant vous permet de choisir le réseau (mainnet pour le réseau officiel, Görli pour les testnets). Puis vous pouvez copier l’URL (entouré en rouge) qui vous servira dans l’étape suivante.

Modifications à apporter

Grâce à docker-compose, cette modification est un réel jeu d’enfant : il n’y a que deux lignes à modifier !

nano .env

Ensuite les deux lignes à modifier sont : START_GETH qui doit être vide, et VOTING_ETH1_NODES qui doit être mis à l’URL du fournisseur d’accès à ETH1 (celui que vous avez copié si vous avez suivi le tutoriel Infura).

START_GETH=
 VOTING_ETH1_NODES=urldufournisseur

Les autres paramètres sont à laisser comme dans décrit plus haut dans le guide.

Et voilà le travail ! Maintenant lorsque vous lancerez vos logiciels (sudo docker-compose up), vous passerez par votre fournisseur plutôt que par geth ! Vous pouvez donc supprimer le dossier geth maintenant pour libérer de la place sur votre machine :

sudo rm -rf ~/lighthouse-docker/geth-data

Migrer vos validateurs

La migration de validateurs d’un serveur à un autre est une opération facile mais qui nécessite une attention particulière. Le dossier important à copier se trouve dans lighthouse-data/mainnet/validators (ou /testnet/ si sur testnet).

Attention, cette migration ne sert que si vous changez de machine mais comptez utiliser le meme client (Lighthouse). En attendant l’EIP-3076, changer de client n’est PAS recommandé.

De plus nous copierons aussi le dossier secret afin d’éviter de devoir importer les validateurs de nouveau.

Ok première étape : s’assurer que nos validateurs sont éteints. Pour ça :

tmux a

Puis CTRL+c et ensuite

sudo docker-compose down

Nous allons devoir autoriser la connexion en tant que root. Oui c’est une mauvaise pratique, et nous ne le ferons que temporairement, car les fichiers qui se trouvent dans validators appartiennent à root.

Pour ce faire, il faut aller éditer le fichier /etc/ssh/sshd_config et changer la ligne « PermitRootLogin no » en « PermitRootLogin yes« . Pour que cette modification ait lieu, il faut ensuite redémarrer le service ssh : sudo systemctl restart ssh.

Maintenant vous pouvez vous déconnecter de la machine (exit), et vous déplacer dans le dossier Validateurs que nous avions créé précédemment.

cd ~/validateurs

De là il ne nous reste plus qu’à copier le dossiers validators ainsi que les dossiers secrets et wallets (les derniers ne sont pas nécessaires mais ils son pratiques). Bien sûr il vous faut remplacer numerodeportssh, utilisateur, et adresseip (et mainnet si vous utilisez un testnet).

scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators .

scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets .

scp -r -P numerodeportssh root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets .

Une fois cette opération effectuée, vous pouvez retourner sur le serveur et retirer le login en tant que root (PermitRootLogin).

Maintenant il faut faire le chemin inverse : c’est à dire envoyer vos dossiers validators et secrets sur votre nouvelle machine, dans le bon répertoire. Je pars du principe ici que la nouvelle machine est déjà crée, et que vous avez déjà cloné les repo lighthouse-docker (que vous avez suivi ce tuto quoi !). Assurez-vous aussi que PermitRootLogin est mis sur yes. La manipulation est simple :

scp -r -P numerodeportssh validators root@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/validators

scp -r -P numerodeportssh wallets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/wallets

scp -r -P numerodeportssh secrets utilisateur@adresseip:/home/utilisateur/lighthouse-docker/lighthouse-data/mainnet/secrets

Enfin nous allons copier le dossier validator_keys afin qu’il soit sur notre serveur aussi :

scp -r -P numerodeport ~/validateurs/validator_keys utilisateur@adresseip:lighthouse-docker/validator_keys

Et voilà ! Le tour est joué ! Vous pouvez commencer à valider sur cette nouvelle machine ! Assurez-vous de bien avoir remis PermitRootLogin no, et assurez-vous de bien avoir éteint votre ancienne machine !

Mettre à jour les logiciels

Eh oui, en tant que validateur sur le réseau, il vous faudra vous assurer d’être à jour !

D’abord éteindre grafana et prometheus :

cd ~/lighthouse-metrics
 sudo docker-compose down

Puis éteindre le BN, geth et les VC en attachant tmux

tmux a

Puis en l’interrompant (CTRL+c), puis en le stoppant :

sudo docker-compose down

Quittez votre session tmux en appuyant sur CTRL+d.

Maintenant vous pouvez mettre à jour les paquets :

sudo apt update && sudo apt upgrade

Puis mettre à jour les logiciels :

cd ~/lighthouse-metrics && git checkout . && git pull origin stable && sudo docker-compose pull
 cd ~/lighthouse-docker && git checkout . && git pull && sudo docker-compose pull

Maintenant il faut retourner à l’étape de création du fichier .env (en haut de cette page !), puis vous pourrez relancer les logiciels : d’abord tmux, puis sudo docker-compose up, puis CTRL+b, puis d, ensuite cd ~/lighthouse-metrics, puis sudo docker-compose up -d !

The post Guide pour débutants : staker sur Ethereum 2 ! first appeared on Ethereum France.

Mardi 24 Novembre, Ethereum France a le plaisir de recevoir Mehdi Zerouali, cofondeur et directeur de Sigma Prime pour une présentation de Lighthouse.

Venez nombreux à l’heure du déjeuner sur Youtube pour découvrir ce client Ethereum 2 et poser toutes vos questions à Mehdi, notamment sur les aspects pratiques de la participation à la preuve d’enjeu (Proof of Stake) sur Ethereum.

Alors que la génération du premier bloc de la beacon-chain est prévue au plus tôt pour le mercredi 2 décembre 2020, il est urgent de se préparer à ce changement.

Après avoir accueilli Mamy Ratsimbazafy (développeur du client Ethereum 2 Nimbus chez Status) la semaine dernière, c’est au tour d’un autre français de venir vous parler du client Lighthouse que développe sa société Sigma Prime. Mehdi a déjà eu l’occasion d’exposer ses travaux à EthCC en 2019 (vous pouvez retrouver son intervention ici).

Rendez-vous à 12h30 mardi 24 novembre sur notre chaîne Youtube.

The post Ethereum France Live: Se préparer à Ethereum 2 avec Mehdi Zerouali first appeared on Ethereum France.

Toutes les blockchains sont fondamentalement des réseaux déterministes actualisés par des transactions. Le consensus est le processus qui permet de statuer sur un ordre déterminé des transactions et filtrer les transactions invalides. Il existe de nombreux algorithmes qui peuvent produire des ordres de transactions équivalentes. Cependant, la DPoS (Deleguate Proof of Stake) ou la preuve d’enjeu déléguée s’est montrée particulièrement robuste, sécurisée, et efficiente ces dernières années à travers son usage dans de multiples blockchains.

Une autogestion de la communauté

Comme pour tous les autres consensus, la plus grande menace que peuvent présenter un tiers malveillant est la censure. Tous les blocs doivent être validés en accord avec un ordre logique déterminé par l’algorithme.

Le consensus DPoS est divisé en deux parties : choisir un groupe de producteurs de blocs et programmer leur production dans le temps. Le processus d’élection par vote permet d’assurer que les parties prenantes (détenteurs) de la monnaie soient en définitive au pouvoir car ce sont eux qui seront en perte si le réseau perd en fluidité et en efficacité. En effet les validateurs sont choisis par vote au prorata du nombre de jetons que chaque membre détient. Ainsi si j’ai 1 jeton j’aurais par exemple 10 votes, l’utilisateur ayant 10 jetons en auraient 100. La manière dont les validateurs sont élus à un petit impact sur comment le consensus performe chaque minute. On s’intéresse ici à comment le consensus est atteint sur le réseau après que les producteurs de blocs aient été déterminés. Lors de la production de nouveaux blocs on parle de forgeage.

Par le biais d’exemples, nous allons déterminer comment la DPoS fonctionne sous plusieurs conformations du réseau. Ces exemples servent à illustrer en quoi la DPoS est robuste et difficile à briser malgré les forks qui peuvent survenir.

Opération normale

Pendant un fonctionnement normal, les producteurs de blocs produisent tour à tour un bloc toutes les 3 secondes. Considérant qu’aucun ne rate son tour, ils vont ainsi fournir la chaîne la plus longue possible. Si les producteurs échouent à produire un bloc durant l’intervalle de temps qui leur est consacré, tout autre bloc fournit en dehors de cet intervalle sera invalidé.

Fork minoritaire

Jusqu’à 1/3 des nœuds peuvent être malicieux ou dysfonctionnés créant ainsi un fork (bifurcation) minoritaire. Dans ce cas, le fork minoritaire produira seulement un bloc toutes les 9 secondes alors que le fork majoritaire produira 2 blocs toutes les 9 secondes. Une fois de plus, les 2/3 des nœuds, à savoir les nœuds honnêtes, aura toujours la chaîne la plus longue donc la chaine majoritaire.

Double production par des chaines minoritaires

La minorité peut tenter de produire un nombre illimité de forks, mais tous ces forks seront plus courts que la chaine majoritaire car la minorité est limité dans l’agrandissement de la chaine minoritaire.

Fragmentation du réseau

Il est tout à fait possible que le réseau soit fragmenté/déconnecté et dans ce cas, aucun fork n’aura une majorité de producteurs de blocs (supérieur à 2 personnes dans cet exemple). Dans ce cas, la chaine la plus longue sera alors la chaine de la plus grande minorité. Quand la connexion au réseau est restaurée, les plus petites minorités vont naturellement adopter la chaine la plus longue et l’ambiguïté du consensus sera levée.

Il est possible dans ce cas qu’il y ait 3 forks avec des chaînes les plus longues de tailles similaires. Dans ce cas, les producteurs du troisième (plus petit fork) vont briser l’indécision quand ils se reconnecteront au réseau. Il y a un nombre impair de producteurs de blocs donc il est impossible de maintenir durablement une indécision (il n’y aura jamais de 50/50).

Plus tard nous verrons que le shuffling (brassage) des producteurs de bloc qui permet de rendre pseudo-aléatoire l’ordre de passage des producteurs assure le tie breaking même si deux forks disposent du même nombre de producteurs de blocs. En effet, les forks grandiront avec des vitesses différentes permettant ainsi à un fork de prendre le dessus sur l’autre.

Le dernier bloc irréversible

Dans le cadre d’une fragmentation / déconnexion du réseau, il est possible pour de multiples forks de continuer à grandir pour une période de temps prolongé. Dans la durée, la chaîne la plus longue gagnera, mais les observateurs requièrent un moyen de savoir avec certitude quand un bloc fait absolument parti de la chaîne grandissant le plus vite. Cela peut être déterminé par confirmation de 2/3 + 1 des producteurs de bloc.

Dans le diagramme ci-dessous, le bloc B a été confirmé par C et par A qui représente 2/3+1 des producteurs, nous pouvons ainsi en déduire qu’aucune autre chaine ne seraient possiblement plus longue si au moins 2/3 des producteurs sont honnêtes.

Cette règle est similaire à la règle des 6 blocs de confirmation pour le Bitcoin (BTC). Des individus intelligents peuvent provoquer une séquence d’événements ou deux nœuds auraient deux blocs irréversibles terminaux différents. Ce cas de figure nécessite que l’attaquant dispose d’un contrôle total du délai de communication entre nœuds et d’utiliser ce contrôle pas une fois, mais avec deux minutes de différences. Les chances qu’une attaque se produise sur un réseau de DPoS sont proches de 0 et les conséquences économiques insignifiantes.

Absence de Quorum chez les producteurs

Dans le cas rare où le quorum (nombre de producteurs exigés) de producteurs ne serait pas satisfait, il est possible pour la minorité de continuer à produire des blocs. Dans ces blocs, les partis prenants peuvent inclure des transactions pour changer leurs votes. Ces votes peuvent désigner un nouveau set de producteurs et restaurer la participation à la production de blocs à 100%. Quand cela arrive, la chaîne de la minorité peut éventuellement prendre le dessus sur toutes les autres chaînes opérant avec moins de 100% de participation.

Durant tout ce processus, tous les observateurs auront connaissance que l’état du réseau est en train d’évoluer avant qu’une nouvelle chaîne émerge avec 67% de participation. Ceux qui choisissent d’effectuer une transaction sous ces conditions, et ainsi changer leurs votes, encourent un risque similaire à ceux qui acceptent avec moins de 6 confirmations. Ils agissent ainsi en connaissance de cause et savent qu’il demeure une faible probabilité que le consensus puisse ultimement opter pour un fork différent. En pratique, cette situation est beaucoup plus sécurisante que d’accepter des blocs avec moins de 3 Bitcoin confirmations.

Corruption de la majorité des producteurs

Si la majorité des producteurs de blocs deviennent corrompus, ils peuvent ainsi produire un nombre illimité de forks. Chacun de ces forks sembleront progresser avec la confirmation de la majorité 2/3. Dans ce cas, l’algorithme du dernier bloc inaltérable reviendra à l’algorithme de la chaine la plus longue. La chaine la plus longue sera celle approuvé par la majorité la plus large qui sera décidé par la minorité des nœuds honnêtes restants.

Ce genre de comportement ne pourrait pas durer car les stakeholders remplaceraient rapidement leur vote vers ces producteurs honnêtes.

TaPoS (Transaction as Proof of Stake), transaction à la place de la preuve d’enjeu

Quand des utilisateurs signent une transaction, ils le font avec une certaine supposition de l’état de la blockchain. Cette hypothèse est basée à partir de leur perception des blocs récents. Si le consensus de la chaine la plus longue change la chaîne majoritaire, cela pourrait éventuellement invalider l’hypothèse faite par le signeur lorsqu’il a consenti à la transaction.

Avec le TaPoS, toutes les transactions incluent un hash d’un block récent et sont ainsi considérées comme invalide si ce block n’existe pas dans l’historique de la chaine. Tous ceux qui signent une transaction sur un fork orphelin verront leur transaction invalide et incapable de migrer sur la chaîne principale.

Un effet secondaire de ce processus est la sécurité avec les attaques longues distances qui tentent de générer une chaîne alternative. Les stakeholders en cause confirment directement la blockchain à chaque fois qu’ils réalisent une transaction. Au fil du temps tous les blocs sont confirmés par les stakeholders et ceci est quelque chose qui ne peut être reproduit dans une chaine forgée.

Le brassage de producteurs déterminé

Dans tous les exemples que nous avons illustrés, nous avons montré une planification aléatoire des producteurs de blocs. En réalité, l’ordre de production est brassé tous les N blocs où N est le nombre de producteurs de blocs. Cette randomisation assure que le producteur B n’ignore pas toujours le producteur A et qu’à chaque instant il n’y ait pas de multiples forks avec le même nombre de producteurs et ainsi permettre la prise de décision par tie breaking.

La DPoS, la solution parfaite ?

La DPoS est robuste sous toutes les formes de perturbations du réseau et d’autant plus sécurisé face aux tentatives de corruption d’une large minorité des producteurs. Contrairement à des consensus compétitifs, DPoS peut continuer à fonctionner malgré qu’une majorité de producteurs échouent. Durant ce processus, la communauté peut voter pour remplacer les producteurs défaillants jusqu’à retrouver une participation de 100%. Ainsi, la DPoS est très robuste face à l’échec.

Finalement, DPoS obtient une sécurité grâce à l’algorithme choisit pour déterminer les producteurs de blocs et vérifier que les nœuds sont de hautes qualités et des personnes uniques. En utilisant le processus d’approbation par vote, le réseau assure que même quelqu’un disposant de 50% dans la quantité actuelle du pouvoir de vote est incapable de choisir un producteur unique par lui-même. DPoS est conçue pour optimiser la performance de la condition nominale des 100% de participation des nœuds honnêtes avec une bonne connexion. Cela concède à la DPoS le pouvoir de confirmer les transactions avec 99,9% de certitude en une moyenne de 1,5 secondes. Tant d’arguments qui font de la DPoS, un des consensus les plus performants de l’écosystème blockchain.

The post La DPoS le consensus qui semble mettre tous le monde d’accord appeared first on TheCoinTribune.

OKEx (OKB) lance une campagne promotionnelle visant à remercier ses clients de leur fidélité. Il a élaboré de nombreuses formules en fonction notamment des données historiques de chaque utilisateur sur la plateforme. Certains utilisateurs peuvent bénéficier de réduction jusqu’à 1 000 Tethers (USDT) sur les commissions.

OKEx remercie ses clients

L’exchange OKEx qui est l’un des leaders du marché des produits dérivés de cryptomonnaies, a annoncé le lancement d’un programme de récompenses estimé à plusieurs millions de dollars.

L’exchange basé à Malte organisera plusieurs campagnes pour remercier ses clients de leur fidélité.

L’évènement « Happy Friday Giveaway » inclura la distribution hebdomadaire à tous les utilisateurs et à compter du 4 décembre 2020, de 20% des revenus totaux de la plateforme, les revenus provenant des frais de transaction sur les contrats à terme et les swaps perpétuels.

Les nouveaux clients et ceux de longue date sont éligibles et peuvent recevoir des récompenses proportionnelles à la valeur de leurs actifs et à leur volume de transactions.

Des récompenses sur-mesure

Un paiement unique sera effectué à destination des utilisateurs qui auraient effectué des dépôts ou des transactions entre le 16 octobre 2020 et le 26 novembre 2020.

Cette opération sera réalisée depuis un fonds spécial où sont placés 20% des revenus d’OKEx.

Les détenteurs du token OKB verront leur récompense doublée. Lors du calcul de la valeur effective des actifs, la valeur de l’OKB lors de sa conversion en Tether.

Les utilisateurs dont la valeur des actifs a dépassé 10 000 USDT avant le 23 novembre à 16 heures UTC, recevront une carte de réduction sur les commissions d’une valeur de 100 USDT à 1 000 USDT en fonction de leurs actifs nets.

L’obtention de cette carte n’affectera pas le calcul des récompenses pour les futurs évènements.

Quant aux nouveaux utilisateurs, ceux qui achètent leurs premiers actifs pour un montant de 100 USD, peuvent bénéficier de 80 USD de bonus ainsi que de l’aide des communautés éducatives sur Telegram et d’OKEx Academy.

20% des revenus en cadeau aux clients : la plateforme a toutes les raisons de les remercier, vu les désagréments que la perte des clés privées chez OKEx leur a occasionnés. Il aura fallu du temps avant que la situation ne revienne quasi totalement à la normale. Il devrait augmenter le nombre de nouveaux utilisateurs, le taux de rétention et le volume moyen de transactions par utilisateur de la plateforme.

The post OKEx lance un des plus grands programmes de rewards et de fidélité ! appeared first on TheCoinTribune.

Vous aimez les petits monstres mignons et les cryptomonnaies ? Si oui, vous avez dû entendre parler d’Axie Infinity, un jeu sur la blockchain Ethereum qui existe depuis quelques années ! Mêlant RPG et collectible, Axie ne se résume pas qu’à une arène de 3 créatures qui s’affrontent mais à bien plus que ça.

En résumé, Axie Infinity, c’est quoi ?

Axie Infinity a été lancé en 2018 par l’entreprise Sky Mavis et dès le départ, toutes les actions du jeu étaient enregistrées sur la blockchain Ethereum (ETH). Chaque Axie est un petit monstre qui a des caractéristiques qui lui sont propres comme des traits physiques mais aussi des compétences de combat.

Très vite, le jeu a su trouver son public tant pour l’aspect “collectible” que le gameplay relativement simple en apparence. Une communauté s’est constituée autour du jeu pour initier les nouveaux joueurs ainsi que les aider à bien choisir leur Axie devant servir à constituer leur équipe de combattant.

Lorsque la vente des LAND eut lieu fin 2018, l’annonce qu’un univers plus grand qu’une simple arène sur navigateur web a été faite à la communauté. La possibilité d’un univers complet dans lequel pourraient évoluer ces petits monstres les uns avec les autres ouvrait un champ des possibles qui semblait encore inaccessible à ce moment-là.

Mais sans mettre la charrue avant les bœufs, le jeu a continué à se développer doucement mais sûrement notamment avec la publication de l’alpha sur smartphone. Cette application permet aux joueurs d’accéder au mode aventure afin de pouvoir faire monter en niveau ses Axies et récupérer des Small Love Potions (SLP).

En Novembre 2020, Axie Infinity a rejoint le Launchpad de Binance, promettant tout d’abord un développement de toute l’économie du jeu mais pas seulement : ce soutien de taille a permis pour la première fois dans l’histoire des cryptos à un projet NFT d’accéder à une plateforme d’échange centralisée.

Le gameplay

Au début, il n’y avait que le PvP de disponible dans Axie Infinity. Depuis que la “Community Alpha” est sortie, le PvE s’est ajouté mais le gameplay des batailles est resté le même à la différence d’avoir des vagues d’ennemis plutôt qu’une seule équipe adverse.

Il va donc falloir constituer une équipe de trois Axies pour les faire combattre contre d’autres joueurs. En théorie, cela a l’air simple mais en pratique, il y a de nombreuses subtilités à prendre en compte comme les faiblesses liées aux éléments ainsi que la complémentarité des Axies entre eux.

Selon la classe de votre Axie, il sera donc plus ou moins fort contre ses adversaires. Mais pas seulement ! Pour améliorer vos chances de victoire, il vaut mieux constituer une équipe  équilibrée entre les différentes classes pour être préparé à tout type d’adversaire plutôt que mettre tous ses Axies dans le même panier et risque de tomber sur une équipe qui vous écrasera à coup sûr.

Mais ce qui va faire la réelle force de ces petits monstres, ce sont les parties de leur corps comme la bouche, la queue, la partie dorsale et la corne.

En effet, ces traits physiques ont une incidence particulièrement importante dans le jeu : ils permettent non seulement de déterminer les statistiques de l’Axie (vitesse, santé, moral…) mais aussi les compétences que vous pourrez utiliser en combat.

Le système de combat s’effectue au tour par tour et là encore, plusieurs éléments sont à prendre en compte : 

• Chaque compétence est représentée par une carte tirée au hasard au début de tour
• Ces cartes sont attribuées à l’Axie correspondant et ont un coût en énergie
• L’énergie disponible pour les compétences se régénère partiellement à chaque tour

Les compétences ont un champ d’effet assez large, elles ont évidemment un impact sur la santé de vos adversaires, peuvent leur donner un malus (par exemple faire baisser la vitesse ou briser l’armure)  mais aussi voler des points d’énergie à votre adversaire. 

Heureusement, elles peuvent aussi vous faire bénéficier d’armure ou de bonus ! De plus, en remplissant certaines conditions il est possible d’enchaîner un combo ou d’infliger un coup critique.

Tournois et partenariats

Chaque saison, Axie Infinity organise des tournois entre les joueurs pour leur permettre de gagner des prix plutôt généreux. Au-delà de l’aspect récompense sonnante et trébuchante attendant les meilleurs du classement, c’est aussi une opportunité pour l’équipe de nouer des partenariats avec d’autres acteurs crypto. 

Le premier tournoi est apparu peu de temps après la publication de l’Alpha sur smartphone et ce fut MakerDAO qui en fut un sponsor officiel. Une récompense de 1000 DAI était promise à la clé de cette première saison. Deux autres acteurs, Kyber Network et Klaytn se sont prêtés au jeu pour proposer des récompenses de leur cru pendant ces tournois mais majoritairement, ce sont des récompenses en DAI qui sont proposées.

Aujourd’hui, c’est Aave qui a pris le relais des récompenses depuis la saison 13 des tournois.

Au-delà des tournois, l’univers d’Axie Infinity arrive à s’exporter sur bien d’autres plateformes. C’est par exemple le cas de Coingecko qui lui ont fait la part belle sur leur site… en créant toute une page dédiée à leur univers.

Le site au lézard n’en est pas à son coup d’essai avec Axie : déjà en 2019 lors de la vente des Lands il était possible de retrouver des NFTs aux couleurs de Coingecko dans les coffres. 

Plus tard, en octobre 2019, un nom majeur de l’industrie des smartphones allait allonger la liste des partenariats : Samsung. L’entreprise ayant développé tout un hub blockchain pour l’intégrer dans ses téléphones compatibles, il était maintenant possible de retrouver Axie Infinity dans la liste des jeux disponibles dans le store du Samsung Blockchain Wallet.

En juin 2020, une autre nouvelle et pas des moindres fut annoncée : un partenariat entre Axie Infinity et Ubisoft (ou plus précisément l’Ubisoft Entrepreneur Labs). Peu d’informations ont transpiré concernant les modalités de ce partenariat mais avoir une institution majeure du jeu vidéo accueillant l’univers d’Axie Infinity en son sein a placé le jeu encore à un autre niveau de crédibilité.

Les jetons de l’univers Axie Infinity

Aujourd’hui Axie Infinity repose sur trois jetons ethereum : les Axies qui sont des Non-Fungible Tokens, les SLP et les AXS qui sont des jetons ERC-20. 

Tout d’abord, les Small Love Potions ont une seule utilité : permettre aux Axies de faire un bébé. Le breed des Axies est l’un des piliers du concept du jeu car le bébé Axie pourra hériter de certains traits physiques et donc de certaines compétences de ses parents.

Mais pas de magie, pour y parvenir, un certain nombre de filtre d’amour est nécessaire ! Sa manière de fonctionner est relativement simple : Plus votre Axie s’est reproduit avec d’autres, plus le coût en $SLP sera élevé.

La possibilité d’acquérir des SLP hors-ligne a probablement été la fonctionnalité la plus adaptée aux frais de transactions délirant qu’a connu Ethereum durant l’été 2020. En effet, même si l’utilisation de la sidechain LOOM permet d’éviter les frais de transactions sur leur marketplace, pour synchroniser les Potions obtenues dans le jeu ou déclencher le breed l’envoi d’une transaction sur Ethereum est nécessaire… 

Avec Loom ayant annoncé son retrait de l’univers du gaming plus tôt dans l’année, Axie ayant basé tout son marketplace sur cette sidechain, l’équipe risquait de se retrouver donc sans Layer 2 pour couvrir toutes les transactions du jeu. Mais qu’à cela ne tienne, l’équipe n’est pas restée les bras croisés et a décidé de créer leur propre sidechain : Ronin.

Cette solution est encore en développement et devrait être annoncée prochainement, l’équipe se concentrant sur un nombre de validateurs relativement réduit pour la gouvernance de cette sidechain.

Lorsqu’Axie Infinity a été accepté au Launchpad de Binance, deux jetons y ont été listés : les SLP mais aussi les AXS peu de temps après. 

Les Axie Infinity Shards (AXS) sont la pierre angulaire de l’écosystème et ont une tout autre utilité : ils serviront notamment pour la gouvernance du projet mais pourra aussi être mis sous séquestre pour générer d’autres AXS ou encore participer à des ventes spéciales sur le marketplace.

Et après ?

Si tout l’espace NFT est aussi enthousiaste avec Axie Infinity, c’est probablement parce que le jeu n’en est encore qu’au stade de l’alpha et promet de nombreuses fonctionnalités dans les temps à venir.

La première d’entre elles concernera la migration des différents assets sur la sidechain Ronin, d’abord en commençant avec les Lands d’ici la fin de l’année puis les Axies en début 2021.

S’ensuivra la mise à jour en Beta du système de bataille pour ouvrir cet univers à toujours plus de joueurs et la phase suivante est probablement l’une des plus attendue : le lancement Alpha du gameplay autour des Lands.

Ce mode de jeu est particulièrement attendu car il permettra de se balader dans toute la carte des Lands d’Axie Infinity pour miner, cultiver des matériaux ou encore l’agrémenter de décorations. Chaque élément du décor aura une conséquence directe sur vos Axies comme une augmentation de l’expérience obtenue ou d’autres bonus de combat !

Bien que le monde de Lunacia ait l’air d’apparence tranquille, différents événements viendront perturber la vie qui s’y déroule. Il y sera possible d’y affronter des Lunacians, monstres maléfiques jouant les trouble-fêtes dans vos activités journalières.

Peu d’informations circulent sur ces monstres mais certains seraient plus forts que les autres… Peut-être qu’il sera possible de coopérer pour les abbatres afin d’en partager la récompense qui n’en sera que plus grande ?

Une fois cet univers mis en place, les dernières ambitions présentes sur la roadmap pour 2021 sont la publication officielle de l’application sur IOS et Android puis le SDK d’Axie Infinity pour permettre à d’autres projets d’utiliser leur univers dans le leur.

Conclusion

Vous l’aurez compris, Axie Infinity est tout de même bien avancé dans le développement de leur univers ainsi que leur communauté. Comparé à d’autres projets lancés à la même période, le chemin parcouru s’est jusque là déroulé sans accrocs et le jeu va continuer d’évoluer sur une base solide.

Depuis quelques mois le prix en $ETH des Axies a fortement augmenté et combiné avec la hausse en dollars de l’Ethereum, le jeu est devenu aujourd’hui bien moins accessible pour les petites bourses.

Bien qu’il soit possible de demander un “scholarship”  afin qu’un mentor puisse vous former et vous conseiller sur le choix de votre première équipe d’Axie, les places sont devenues chères avec le temps.

Cependant, Axie a toujours vu son développement dans une perspective de démocratisation de leur univers à un public toujours plus large. Le joueur a toujours été au centre de leur préoccupation depuis le début et si on regarde comment a été pensé l’économie du jeu, il est possible de générer des Axies à l’infini.

Même si certains d’entre eux sont plus rares et donc plus chers, la réelle valeur du jeu réside dans la constitution de l’équipe d’Axie que vous enverrez au combat ainsi que le rythme auquel vous allez les faire se battre contre vos adversaires.

Grâce aux mises à jour de cet univers à venir, d’autres formes de gameplay viendront continuer d’enrichir le jeu pour permettre de rendre toujours plus accessible ces petits monstres au plus grand nombre.

Merci à Axie France pour la relecture et les corrections !

The post Axie Infinity, un univers gaming complet ! appeared first on TheCoinTribune.

Echanger du Bitcoin (BTC) en Afrique n’a rien de nouveau. Récemment il s’est révélé que Bitcoin était plus populaire en Afrique que partout dans le monde. En fait, ce regain d’intérêt pour bitcoin est accéléré par la dévaluation des monnaies locales. Pour se protéger, les africains se tournent de plus en plus vers des valeurs réfuges et bitcoin en fait partie. 

Préambule

C’est pourquoi la question de savoir sur quelles plateformes acheter du Bitcoin en Afrique est donc fondamentale. Nous allons tenter d’y répondre dans cet article sans pour autant vous décourager d’effectuer vos propres recherches.

Les plateformes que nous allons vous présenter sont triées selon la capacité à offrir les services dans plusieurs pays, les moyens de paiement acceptés, la facilité d’utilisation et la réputation qu’elles ont dans la cryptosphère. Attachez donc vos ceintures, on y va !

Paxful

Paxful est une place de marché Peer-to-Peer (P2P) bien connue dans l’écosystème crypto. Elle offre ses services un peu partout dans le monde y compris dans des régions blacklistées comme le Congo.

L’un des avantages d’utiliser Paxful c’est le fait qu’il prend en charge plus de 300 moyens de paiements comme les cartes cadeaux, le mobile money, Paypal, Western Union et même le règlement en espèces.

Cependant, il est important de vérifier si le vendeur applique un taux qui vous convient et s’il est bien coté. Cela va vous éviter de tomber sur un utilisateur mal intentionné.

LocalBitcoins

Comme Paxful, LocalBitcoins est présent presque partout dans le monde et bien réputé. Il s’agit d’une plateforme (P2P) qui met en relation vendeurs et acheteurs. LocalBitcoins est bien présent dans la plupart de pays africains et reste facile à utiliser.

Il prévoit une procédure de sécurité comprenant une authentification à deux facteurs ainsi qu’une imposition KYC (Know Your Customer) avant toute opération. Ce qui leur permet d’avoir des vraies informations sur les utilisateurs, ce qui est important sur une place de marché P2P.

Binance

Première plateforme d’échange au monde, Binance a récemment ajouté le Naira (Nigeria) aux monnaies supportées par son service P2P.

Sur son blog, la crypto-bourse annonçait avoir l’intention d’étendre cette possibilité à d’autres devises africaines parmi lesquels le KES (Shilling Kenyan) et le ZAR (Rand Sud-Africain).

Binance reste donc l’une des plateformes les plus envahis par les utilisateurs africains et pour preuve ce récent rapport de Chainalysis qui le place bien en avant  face à tous ses concourants.

Cette liste n’est pas exhaustive vu la pluralité de plateformes qui opèrent en Afrique. Dans nos prochains articles vous allez découvrir plusieurs autres plateformes qui œuvrent plus localement ou juste dans quelques pays. Aujourd’hui nous avons juste pris le temps de vous présenter les plateformes les plus populaires. N’hésitez pas à nous partager vos avis sur le sujet.

The post Les meilleures plateformes pour acheter du Bitcoin (BTC) en Afrique appeared first on TheCoinTribune.

Alors que le Japon vient d’annoncer le lancement de sa cryptomonnaie souveraine en 2021, il est temps de se poser ensemble et de faire le tour des initiatives menées à travers le monde en la matière depuis quelques années. Il faut dire que le phénomène est assez récent, et on a du mal à se dire s’il s’est créé en pleine défiance des Banques centrales face au projet Libra de Facebook qui a fait grand bruit dans les couloirs de nos financiers, ou bien si ces vieux dinosaures se sont dit qu’il fallait passer la seconde pour atterrir dans le nouveau monde et tenter de faire un pied de nez à Bitcoin (BTC) en créant leur propre monnaie digitale.  On a enquêté pour vous sur ce phénomène en pleine expansion : CBDC, MDBC, de quoi parle-t-on ? Quels ont été les épisodes marquants de cette montée en puissance des Banques centrales sur le sujet ? Qu’en dirait Satoshi Nakamoto ?  Au pays de la souveraineté, on vous emmène avec nous à travers le monde explorer ces initiatives sorties tout droit de la crypte.

Prélude : au commencement était la monnaie

On ne pouvait commencer un tel article sans rappeler succinctement l’histoire accélérée de la monnaie, outil de souveraineté à travers l’histoire. Il faut dire que depuis l’Antiquité, la monnaie a connu plusieurs évolutions de taille : d’abord outil de troc pour devenir monnaie fiduciaire, elle a progressivement traversé les âges pour devenir une monnaie scripturale puis numérique. Considérée depuis la nuit des temps comme un instrument de pouvoir, la monnaie est également devenue un puissant vecteur de lien social expliquant ainsi que la stabilité de sa valeur soit un élément essentiel à l’équilibre des sociétés. Mais d’instrument politique, elle a depuis longtemps permis aux Etats d’avoir le monopole sur la levée d’impôts et la production monétaire. 

En 1944, les accords de Bretton Woods viendront assurer une stabilité monétaire à travers le monde, que le FMI et la Banque Mondiale continuent de suivre dans ses principes fondateurs. 

Enfin, avec l’avènement de nouveaux acteurs dans les années 2000, la monnaie prend le virage du digital et se dématérialise, avec le passage sulfureux de Paypal, Paylib, Apple Pay ou encore AliPay. Un nouveau paradigme monétaire s’installe à peine que survient déjà la dernière révolution en date dans l’ère monétaire : la révolution blockchain et les cryptomonnaies, fortement popularisées par la publication du White Paper de Bitcoin par le mystérieux Satoshi Nakamoto. La monnaie bifurque ainsi sur une logique de Token Based Money, autrement dit, de jeton contenant une valeur monétaire, avec l’idée révolutionnaire de supprimer tout tiers de confiance et d’ouvrir un réseau complètement décentralisé de pair à pair sans aucune intervention de l’Etat ou de quelconque régulateur. 

Là, les autorités s’enflamment, le token digital et le Bitcoin font trembler les salles de marché et font tourner la tête aux hauts fonctionnaires européens et internationaux qui ne savent plus sur quel pied danser. On s’en va sur les routes de la fabuleuse histoire de la monnaie à travers le bouleversement idéologique causé par Bitcoin jusqu’à l’émergence aujourd’hui de CBDC par les Banques Centrales. Qui en sortira gagnant ?

“La difficulté n’est pas de comprendre les idées nouvelles, mais d’échapper aux idées anciennes.”

John Meynard KEYNES

Episode 1 : le tsunami Bitcoin vient bouleverser le statu quo des Banques Centrales et la philosophie même de la monnaie 

Le 31 octobre 2008, un vent de révolution souffla dans le monde, annonçant la création de la cryptosphère et l’avènement du Bitcoin, cette nouvelle monnaie digitale, libérale, reposant sur un fonctionnement complètement décentralisée qui amène avec elle tout un nouveau paradigme monétaire. Beaucoup n’y ont pas cru, et pourtant, 12 ans plus tard le Bitcoin plafonne avec les 20 000$ et fédère de plus en plus d’investisseurs institutionnels comme particuliers.

Il faut dire que l’atterrissage ne s’est pas fait en douceur. Rappelez vous le contexte de crise financière liée aux subprimes, la désapprobation des Etats et le sentiment que notre argent nous glisse entre les doigts au profit de régulations monétaires pas toujours très transparentes.

C’est ainsi qu’un certain Satoshi Nakamoto, pseudonyme porté par le célèbre créateur de Bitcoin, publie son White Paper, élément ô combien fondamental du mouvement en marche.

Basé sur la blockchain et totalement décentralisé, le Bitcoin se présente alors comme une solution à la crise financière et économique de 2008. Le Bitcoin promet alors une alternative aux monnaies Fiats contrôlées par les gouvernements et les banques centrales. 

Théories anarchistes et fruit de la lubie d’utopistes, voilà ce que diront les premiers, les plus contestataires ; avant-gardiste diront les autres qui ont bien envie de croire en ce nouveau chapitre de l’histoire monétaire.

Ce tournant tant technologique que idéologique vient alors bouleverser la position de maître des banquiers, des Banques Centrales, et des Etats qui voient émerger un sérieux concurrent sur leur chemin. En tout cas, l’objectif est clair, Bitcoin sonne la fin de la mainmise de l’Etat sur la monnaie et invente un nouveau système décentralisé de pair à pair et chacun est désormais à même de devenir un émetteur de monnaie. C’est de ce constat que les GAFAM et notamment Facebook vont s’inspirer pour entrer à leur tour dans la course à la monnaie digitale.

Episode 2 : Libra, un premier essai raté pour celle qui menaçait la souveraineté des Etats ?

En juin 2019, Facebook annonce avoir créé Libra, une monnaie unique universelle indexée sur un panier de monnaies. Conçue comme une stablecoin (cryptomonnaie stable) afin d’éviter toute spéculation puisque adossée à un panier de réserves, Libra provoque dans les minutes qui suivent sa révélation, une levée de boucliers de la majorité des gouvernements qui voient bien venir la menace du géant américain. A l’inverse de Bitcoin qui s’inscrit clairement à l’encontre du système actuel, Libra prend le contrepied et propose une monnaie globale promue par un acteur avec un réseau planétaire. 

Les gouvernements, très méfiants face à cette initiative de taille, voient tout de suite pointer un risque pour leur souveraineté monétaire en raison de la possible adhésion des 2,7 milliards d’utilisateurs du réseau social le plus connu de l’histoire. Face à l’hostilité extrême des gouvernements, Libra revoit sa copie et présente à nouveau son projet sous un autre oeil en Avril 2020 en se concentrant sur deux principaux axes de valeur : 

• Une monnaie stable entièrement indexée sur la monnaie locale lorsque la monnaie locale est également disponible en version digitale
• Une monnaie stable globale comme dans sa version initiale indexée sur un panier de monnaies s’il n’y a pas de monnaie locale digitale disponible

La différence cruciale avec la Libra résidant dans le fait qu’elle agisse avec permission, à l’inverse de Bitcoin. Cela signifie que la validation des transactions n’est possible que par des participants autorisés, c’est-à-dire membres de l’association Libra. Avec ce revirement de situation face à la pression exercée par les Etats, la Libra est-elle si libre que cela ? Facebook a fini par abandonner son projet initial de devenir une véritable cryptomonnaie. Alors, le projet Libra, un échec dans la cryptosphère ou le signe que les Etats n’ont pas dit leur dernier mot ?

 « L’attribut de la souveraineté des États doit rester aux mains des États, et pas des entreprises privées, qui répondent à des intérêts privés. »

Bruno Le Maire, Ministre de l’Economie et des Finances français

Episode 3 : les Banques Centrales ripostent et se rêvent à imaginer leur cryptomonnaie souveraine 

Lucides face aux effets de réseau important qui caractérisent un système de paiement, les autorités financières ne pouvaient raisonnablement pas laisser passer l’occasion de concourir aussi dans le ring de la monnaie digitale 3.0.

Christine Lagarde, présidente de la BCE s’empare du sujet et annonce vouloir créer un euro digital. Elle insiste sur l’importance d’avoir un cadre réglementaire pas trop restrictif et d’y voir l’occasion d’optimiser le secteur financier en améliorant et en sécurisant les systèmes de paiement internationaux. Dans le même temps, l’Empire du Milieu, toujours très stratégique dans ses approches tactiques, annonce officiellement le lancement en pionnier de la première monnaie digitale basée sur la Blockchain (la DCEP – Digital Currency Electronic Payment). A noter que la Chine ne crée pas tout à fait un stablecoin puisque sa monnaie digitale est uniquement adossée au renminbi onshore, un moyen pour eux de protéger leur précieux de toute instabilité exogène.

Avec l’avènement des CBDC, les Banques Centrales ambitionnent ainsi de ralentir la fulgurante appropriation par les GAFAM des cryptomonnaies, et la déferlante de Bitcoin qui menace sérieusement leur emprise. 

En clair, une CBDC (Central Bank Digital Currency) ou MDBC (Monnaie digitale de banque centrale), est une forme numérique de monnaie fiduciaire, émise et réglementée par une banque centrale.  Tantôt un mode de paiement, une réserve de valeur ou une unité de compte, la CBDC tente donc de faire un pied de nez au Bitcoin et à Libra , mais est-ce pour autant à considérer que ces initiatives s’inscrivent encore dans l’acception libertaire de son ancêtre ? pas sûr.

A la manière des politiques monétaires, chaque CBDC lancée ou envisagée dans les pays à travers le globe concourt à des objectifs divers : les pays développés y voient une alternative au cash tandis que les pays en développement y voient l’occasion de démocratiser l’accès aux systèmes financiers et réduire les coûts pour les clients “non bancarisés”. Il faut dire qu’en la matière, chacun y va à son rythme, et alors que des géants comme la Chine sont déjà en phase de déploiement, d’autres sont encore à la phase de maturation ou de conception de leur CBDC. Au total, selon la BRI, plus de 70 pays prépareraient aujourd’hui leur monnaie du futur.

Mais alors que la philosophie d’origine de Bitcoin et des cryptomonnaies était de décentraliser et créer un nouveau monde, voilà que les Banques Centrales s’approprient le sujet pour recentraliser un concept décentralisé, puisqu’elles agissent par preuve d’autorité. Et la première à avoir imposé sa vision et son objectif de dominer le nouveau monde est l’Empire du milieu qui avait couvé son projet son CBDC depuis 2014.

Dès lors, la CBDC se révèle être un véritable projet de domination mondiale à travers un marché émergent qui relance la guerre économico-numérique et une nouvelle bataille des nations !

Episode 4 : la Chine ouvre un nouveau champ de bataille géopolitique dans la course à la création d’une monnaie digitale de référence

Avec le lancement de son cryptoyuan, la Chine se place clairement en leader avant-gardiste dans sa guerre commerciale avec les Etats-Unis grâce à la création de la première monnaie numérique de banque centrale. Adossé au yuan, le cryptoyuan sera d’abord proposé aux résidents chinois afin d’encourager et de faciliter les échanges quotidiens. Alibaba, Tencent ou encore UnionPay, les géants du numérique chinois sont bien sûr de la partie.

Mais leur stratégie se regarde à long terme, puisqu’à terme, la Chine entend bien terrasser la domination américaine permise grâce au dollar, notamment en ayant des ambitions internationales pour sa cryptomonnaie nationale. Xi Jinping l’a clairement rappelé, son objectif est de faire du crypto yuan une nouvelle monnaie de réserve internationale, juste ça.

Au-delà même de la suprématie chinoise à la fois technologique, monétaire et idéologique, ce qui se cache derrière ne devrait pas vous surprendre : le yuan numérique a bien une vocation de surveillance de masse puisque instaurer une telle monnaie numérique contrôlée directement par l’Empire afin de continuer d’alimenter les notes de crédit social accordées aux citoyens. En effet, en ayant la possibilité d’empêcher certaines transactions ou de réclamer des justificatifs pour effectuer telle ou telle transaction, on perd toute la valeur d’une blockchain décentralisée. 

En attendant, le yuan 3.0 est déjà en test dans 4 villes chinoises et devrait être déployé à grande échelle lors des Jeux olympiques d’hiver à Pékin en 2022.

Mais au-delà de la Chine, quels pays sont sur le point de dérouler le tapis rouge aux CBDC ?

Panorama des initiatives lancées à travers le monde

Si la Chine s’est montrée pionnière en la matière notamment par sa rapidité d’exécution, d’autres pays ont depuis longtemps lancé des concertations voire même le déploiement de monnaies digitales, à l’image du Venezuela qui était précurseur avec le Petro, sa crypto monnaie nationale adossée aux réserves de pétrole et de minerais du pays.

Il est à noter qu’en fonction des Banques Centrales, les motifs de lancement de ces cryptomonnaies souveraines varient : du développement d’une société cashless en Suède, à la lutte contre le blanchiment aux Bahamas, jusqu’à l’inclusion financière dans les pays émergents, chacun s’y donne à coeur joie. Pour l’Afrique, la monnaie numérique de banque centrale représente avant tout un outil d’émancipation pour un territoire qui, jusqu’à il y a peu, vivait du Franc CFA, marqueur temporel de la période post-coloniale française. Banque Centrale des États d’Afrique de l’Ouest (BCEAO) a d’ailleurs adopté l’ECO en mai 2020 mettant fin au Franc CFA.

“La monnaie numérique de banque centrale est un outil très efficace, et pourrait être utile pour certaines économies, où il y a un manque notable en termes d’outils et d’accès aux banques justement. Ces aspects n’ont pas grand chose à voir avec les raisons pour lesquelles les pays européens, entre autres, travaillent sur la MNBC, mais ce sont des considérations possibles”

Lorenzo POCCHI.

En complément, la BRI (Banque des Règlements Internationaux) travaille étroitement avec 7 banques centrales et notamment la Réserve Fédérale américaine (Fed), la Banque d’Angleterre (BoE), la Banque Centrale européenne (BCE), la Banque Nationale Suisse (BNS) et la Banque du Japon (BoJ). Leur réflexion avance notamment sur les caractéristiques intrinsèques qu’elles veulent imposer aux Banques Centrales : la résilience, une disponibilité large pour un coût faible ou nul, des normes appropriées et un cadre juridique clair, tout en laissant un rôle approprié au secteur privé. Enfin, nouveau champs de bataille des pays technologiquement avancés, la course aux CBDC révèle une fois de plus la concurrence que représente la monnaie numérique sur la scène internationale : un document du think tank dGen annonçait d’ailleurs que d’ici 2030 trois à cinq pays dans le monde pourraient lancer leur propre monnaie numérique en remplacement de leur devise nationale.

Zoom sur les initiatives à l’étude ou déjà lancées à travers le monde pour émettre des cryptomonnaies souveraines :

Apparues dès les années 1990, les monnaies numériques ont été popularisées par le célèbre Bitcoin avant de créer un engouement sans précédent parmi les Etats et les Banques Centrales. Désormais arme fatale au service d’une guerre technologico-économique, la course aux CBDC ou MDBC ne fait que commencer et quelques gagnants semblent déjà se dessiner, mais jusqu’où iront-ils ? Parviendront-ils à détroner l’indétrônable ? Arriveront-ils à produire une monnaie sécurisée, inclusive, afin d’embarquer les citoyens dans une nouvelle ère du digital ? Affaire à suivre.

The post Les cryptomonnaies souveraines (CBDC) : nouvelle arme des Etats pour assurer leur souveraineté monétaire ? appeared first on TheCoinTribune.

Le patron de Pantera Capital fait partie des PlanB-istes qui croient en 1 Bitcoin (BTC) à 100 000 USD. La société va procéder très prochainement à une levée de fonds. Bien qu’aucun détail n’ait filtré sur les projets de Pantera, les discours de Dan Morehead donnent certaines pistes sur le chemin que l’entreprise devrait emprunter.

Un 4ème round pour Pantera

Pantera Capital procèdera d’ici peu à une levée de fonds. La société a effectué un dépôt auprès de la SEC pour une offre d’actions allant jusqu’à 134 millions de dollars.

Créé en 2013, Pantera Capital est l’un des premiers fonds dédiés à Bitcoin. La société avait procédé à une 1ère levée de fonds de 13 millions de dollars, puis une 2ème de 25 millions de dollars.

En 2018, une 3ème levée de fonds a abouti à la création de Venture Fund III qui a attiré 164 millions de dollars entre 2018 et 2020.

Alors que le marché des cryptomonnaies entre dans une nouvelle phase haussière, ce dépôt auprès de la SEC est révélateur des ambitions de Pantera.

Des discours et des indices

Aucun détail n’a filtré pour le moment sur les projets exacts de la société : cette levée de capitaux pourrait se traduire par la création d’un nouveau fonds ou par une extension de la portée de Venture Fund III.

Les derniers commentaires des responsables exécutifs de Pantera pourraient contenir des informations sur les stratégies de développement de la société.

Le CEO de Pantera Capital, Dan Morehead, avait déclaré que le potentiel de croissance de la DeFi était supérieur à celui du Bitcoin.

Certains se souviennent pourtant des prédictions particulièrement optimistes de Morehead sur le cours du Bitcoin.

En 2019, il avait indiqué que celui-ci pourrait atteindre les 356 000 USD d’ici 2022. Morehead a souligné que la société concentrait ses efforts sur un développement financier vertical.

Pantera semble enfin s’intéresser aux marchés dérivés des cryptomonnaies, comme le suggère son investissement dans la plateforme de produits dérivés Globe.

Un Bitcoin à 20 000 USD devrait encourager les fonds dédiés au BTC à se lancer dans des projets de développement. Les institutionnels dopent le prix de Bitcoin, le BTC nourrit les institutionnels : le cycle classique des investissements, la mayonnaise financière en train de tourner et de se lever pour gagner en volume. C’est parti pour un 4ème round pour Pantera Capital : le BTC lui, a entamé son dernier round pour conquérir de nouveaux ATH.

The post Pantera Capital a de fortes ambitions alors que le Bitcoin (BTC) augmente appeared first on TheCoinTribune.