EOSIO Dawn 3.0 est maintenant disponible (French)

eosnation (49)in #eos • 6 years ago (edited)

dawn3.0

Languages

Block.one est heureux d'annoncer la première préversion complète de Dawn 3.0 d’EOSIO. Le lancement de cette préversion représente un jalon important sur la feuille de route d’EOSIO 1.0 dont la sortie est prévue en juin 2018. Notre équipe mondiale de développeurs travaille sans relâche pour faire d'EOSIO la plate-forme la plus puissante sur le marché pour la création d'applications sur la blockchain. Il y a plus de quatre mois que nous avons lancé EOSIO Dawn 2.0, et nous avons beaucoup de choses à vous montrer depuis ce dernier lancement.

Construire l’architecture d’une blockchain à la fine pointe de la technologie est un processus en constante évolution où les possibilités de conception changent au fur et à mesure que nous apprenons et découvrons différentes alternatives. La plupart des fonctionnalités que nous avons complétées dans Dawn 3.0 n'étaient même pas envisagées dans le livre blanc original de l'EOSIO. Elles ont été découvertes au cours du processus de développement de cette plate-forme qui est performante, flexible et facile à développer.

Caractéristiques évolutives

L'évolutivité signifie la capacité à évoluer afin de répondre à la demande du marché. À chaque étape, notre équipe a pris en compte des besoins futurs à grande échelle dans sa conception. Cela dit, Dawn 3.0 ne met en œuvre qu'une fraction des optimisations potentielles qui permettront à EOSIO d'évoluer à travers le temps. Nous avons conçu EOSIO pour que les implémentations futures puissent utiliser le calcul en parallèle afin d’accélérer le débit sans devoir remédier à un Hard Fork.

Communication interblockchain

La communication interblockchain est la caractéristique d'évolutivité ultime - le Saint- Graal - que l'industrie a recherchée avec des propositions telles que les chaînes latérales, Plasma et le Sharding. La communication interblockchain permet à une blockchain de vérifier l'authenticité d'un événement sur une autre blockchain de manière sécurisée et vérifiable. L'objectif est que la communication interblockchain soit aussi efficace que la communication intra-chaîne entre les contrats intelligents, et nous pensons avoir atteint cet objectif.

De notre point de vue, la communication interblockchain n'est rien d'autre que la capacité à implémenter un client léger comme un contrat intelligent. Un client léger est capable de valider des transactions à partir d'une blockchain sans avoir à traiter l’entièreté de la blockchain. Cela signifie donc la construction d'une blockchain Proof of Stake avec une validation sécurisée et efficace du client léger. La validation du client léger doit donc être prise en compte dans la conception du protocole, car il est presque impossible de l'appliquer après coup.

Vérification de l'en-tête fragmenté

Les clients légers traditionnels doivent traiter chaque tête de bloc, puis valider les preuves relatives à ces têtes de bloc. Maintenant que EOSIO peut générer deux blocs par seconde, une blockchain nécessiterait au moins 2 transactions par seconde pour traiter chaque en-tête de bloc. Cela ne s'applique pas aux scénarios où la communication interblockchain est relativement peu fréquente. Pour résoudre ce problème, nous avons créé la première blockchain avec la validation clairsemée de la tête de bloc pour la tolérance de faute byzantine. Spécifiquement, il faut plus du 2/3 (par exemple 15+ sur 21) des producteurs de blocs qui soient corrompus afin de tenter de tromper un client léger. De plus, les clients légers ont seulement besoin de traiter les têtes de bloc où l'ensemble de producteurs de blocs actifs change ainsi que ceux qui incluent des messages interblockchain pertinents. Cela réduit considérablement les frais généraux pour le maintien d'un client léger résistant aux tolérances de fautes byzantines, et augmente considérablement l'efficacité de la communication interblockchain.

Actions sans contexte

Les actions sans contexte sont l'une des caractéristiques clés qui permettent une communication interblockchain efficace. Ce sont des actions spéciales dans le sens qu'elles peuvent être incluses dans une transaction, mais ne dépendent pas de l'état de la blockchain. Elles sont donc "sans contexte". Un exemple d'action sans contexte est la validation d’une preuve Merkle ou d'une signature. Parce que ces calculs sont sans contexte, ils peuvent être trivialement validés en parallèle et le calcul peut être élagué de sa relecture.

Chaque action sans contexte peut également faire référence à une section élaguée des données spéciales d'une transaction. Cela signifie que les grandes preuves de Merkle peuvent être élaguées et que leur calcul intensif peut être ignoré pendant la relecture de la blockchain.

Les actions sans contexte nous permettent de paralléliser la grande majorité des frais généraux associés à la communication interblockchain. Ils nous permettent également de paralléliser et d'élaguer la surcharge des techniques de confidentialité coûteuses en matière de calcul telles que les transactions confidentielles, les preuves pare-balles et les zkSNARKs.

Afin d'encourager l'utilisation d'actions sans contexte, les producteurs de blocs ne facturent aux utilisateurs qu'une fraction de l'utilisation des CPU lorsqu'un calcul est effectué dans le cadre d’action sans contexte comparativement à une transaction traditionnelle.

Actions sans contexte en ligne en tant qu'événements

L'une des fonctionnalités recherchées par les développeurs d'EOSIO Dawn 2.0 était de trouver un moyen efficace de générer des événements traités par des sources externes.

Dans Ethereum, ces événements sont utilisés afin de signaler des informations structurées sur le fonctionnement interne d'un contrat. Avec l'ajout d'actions contextuelles, nous avons également la possibilité de réaliser des actions en ligne sans contexte. Une action en ligne est une action générée par un code de contrat et exécutée dans le cadre de la transaction en cours. Une action en ligne sans contexte peut être traitée à moindre coût et en parallèle. Comme toutes les actions en ligne sont également incluses dans la racine Merkle, il est possible d'utiliser ces actions comme preuves de notifications pour les services externes et les autres blockchains.

Compression de transaction

Il y a énormément de transactions qui ont beaucoup de données compressibles. L'un des exemples des plus incontournables est le code de contrat WebAssembly. D'autres exemples incluent eux aussi la spécification ABI et le contrat Ricardian qui est associé à un compte / contrat. Certaines applications, telles que les médias sociaux, peuvent également inclure du contenu compressible généré par les utilisateurs de la blockchain. En utilisant la compression des transactions, la blockchain peut stocker et transmettre plus efficacement un grand nombre de transactions tout en facturant moins les utilisateurs pour les transactions faites avec des données compressibles comparativement aux transactions faites avec des données incompressibles.

Interprète et compilation juste à temps

L'un des plus grands changements de Dawn 2.0 est l'abstraction de notre environnement d'exécution WebAssembly. Dawn 3.0 utilise désormais l'interpréteur Binaryen WebAssembly par défaut plutôt que le compilateur JIT (Just-in- Time) plus rapide. Cette décision réduit les performances, mais augmente la stabilité et la conformité aux normes tout en nous permettant d'échanger de manière triviale dans l'environnement JIT le plus performant lorsque cela est souhaité. L'interprète a également résolu l'un des plus grands défis auxquels nous avons été confrontés avec Dawn 2.0: le retard causé par la rédaction d'un contrat. À l'avenir, nous pouvons utiliser l'interpréteur pour obtenir une exécution plus lente, mais à plus faible latence des contrats fraîchement déployés en même temps que nous compilons et optimisons le contrat en arrière-plan. Cette double implémentation signifie que tous nos essais unitaires sont testés à la fois par rapport au code compilé et interprété, et de façon à ce que nous puissions découvrir un comportement potentiellement non déterministe ou non conforme avant que nous déployions l'approche hybride.

Limitation du débit de comptage de ressources

Avec Dawn 3.0, nous avons maintenant un tout nouveau système de limitation du débit des ressources. Le plus grand changement est peut-être l'introduction d'un algorithme de comptage d'instructions objectives. Lorsque nous avons entrepris de construire EOSIO, nous avions pour objectif d'utiliser une limitation et une application des taux entièrement subjectives. Ce que nous avons découvert, c'est que le coût de l'application subjective était presque identique à une approche plus objective. Nous utilisons maintenant une solution hybride où les utilisateurs sont facturés pour une utilisation objective, mais les producteurs de bloc imposent également des limites de temps de travail subjectives aux contrats. Ces limites subjectives empêchent les abus de variance dans la facturation objective.

L'une des principales raisons pour lesquelles nous avons adopté cette approche c’était de permettre à des transactions individuelles d'effectuer beaucoup plus de calculs que ce qui était auparavant possible. Il est maintenant théoriquement possible pour un bloc d'inclure une transaction unique qui prend 100 ms à exécuter, alors que sous l'ancien modèle, chaque transaction devait fonctionner en moins de 1 ms.

Un autre changement à la limitation de débit est la séparation des limites de la nécessité de définir un jeton. Cela permet à EOSIO d'être utilisé dans des blockchains privées et autorisées sans utiliser de jeton. La blockchain publique peut adopter un contrat systémique qui implémente les limites via l’empilement, et la communauté peut dynamiquement mettre à niveau comment les ressources sont allouées indépendamment de la façon dont l'allocation est appliquée.

Intervalle de bloc de 500 ms et DPOS BFT

Avec Dawn 3.0, nous sommes passés d'un intervalle de 3 secondes à un intervalle de 0,5 seconde. Cela réduit considérablement la latence jusqu'à la confirmation. Combinés avec BFT DPOS, les transactions peuvent être irréversiblement confirmées en moins d'une seconde. La latence jusqu'à l'irréversibilité a des implications majeures pour la communication interblockchain, car une autre blockchain doit attendre l'irréversibilité avant d'incorporer une preuve provenant d'une chaîne étrangère. Deux blockchain basées sur EOSIO devraient être en mesure d'effectuer une communication aller-retour en moins de 3 secondes. Un schéma de communication similaire sur Ethereum prendrait 9 minutes, et sur Bitcoin cela prendrait 3+ heures. BFT DPOS n'a pas encore été implémenté, car il s'agit d'une optimisation non-Hard- Forking. Nous mettrons en œuvre le DPOS BFT avant le lancement de EOSIO 1.0.

Architecture du BIOS

L'architecture du BIOS est l'un des plus grands changements architecturaux d'EOSIO Dawn 2.0. Sous EOSIO Dawn 3.0, la grande majorité de la logique métier de la blockchain s'est déplacée vers un contrat intelligent qui peut être mis à jour dynamiquement par la communauté sans avoir à effectuer un Hard Fork. EOSIO est désormais à la base une blockchain à producteur unique sans jeton, sans vote, ni preuve de participation déléguée. La seule chose implémentée dans le code de la blockchain principale est le système d'autorisation qui inclut la possibilité de créer des comptes, de déployer des contrats et d'appliquer des quotas de ressources. Tout ce qui rend la blockchain Delegated Proof of Stake, y compris le jeton, le vote, l'implantation et l'allocation des ressources, est maintenant défini par le système contrat basé sur WebAssembly.

Avec cette nouvelle architecture, nous avons été en mesure de concentrer le développement sur les parties statiques non-WebAssembly de la blockchain. Ce sont les parties les plus critiques pour la stabilité – et les plus difficiles à améliorer. Entre la sortie de EOSIO Dawn 3.0 et EOSIO 1.0, nous allons travailler sur les derniers détails du système contrat, de l’empilement et le vote.

Fonctions de sécurité

La sécurité est cruciale pour tout système informatique, et nous avons conçu EOSIO comme étant la blockchain la plus sécurisée sur le marché. La sécurité est un problème multidimensionnel qui doit prendre en compte le risque de piratage informatique, de défaillance matérielle, de la perte de matériel et de la perte des mots de passe. Les portefeuilles électroniques protègent efficacement contre le piratage, mais pourraient néanmoins vous empêcher d’utiliser de votre compte en cas d'échec. De plus, les sauvegardes papier des portefeuilles matériels peuvent aussi être perdues ou volées.

Transactions retardées de sécurité

L'une des caractéristiques les plus significatives d'EOSIO Dawn 3.0 est l'ajout d'un délai configurable par l'utilisateur pour différentes actions. Avec ce retard, une transaction doit être diffusée à la blockchain pendant un certain nombre d'heures ou de jours avant qu'elle puisse être appliquée. Pendant ce délai, l'utilisateur peut prendre des mesures pour réinitialiser son compte avec des niveaux d'autorisation plus élevés, puis annuler la transaction. C'est une amélioration significative par rapport aux autres blockchains où vous ne savez pas que vous avez été piraté jusqu'à ce qu'il soit trop tard pour faire quoi que ce soit à ce sujet.

Recouvrement de mot de passe perdu

Chaque compte a au moins deux niveaux d'autorisation: "propriétaire" et "actif". Le niveau d'autorisation du propriétaire doit être un N de M Multisig où il n'y a pas de N qui n'inclut pas la ou les clés du propriétaire. Le niveau d'autorisation du propriétaire peut réinitialiser l'autorisation active chaque fois que la clé active est perdue ou volée. Si vous perdez la clé du propriétaire ou si vos partenaires Multisig ne sont pas coopératifs, l'autorisation active du compte peut demander une réinitialisation de l'autorisation du propriétaire après 30 jours d'inactivité du propriétaire. L'autorité propriétaire dispose alors de 7 jours pour contester la demande en mettant à jour l'autorité active.

Selon ce modèle, une autorisation de propriétaire de compte contrôlée par un ou plusieurs portefeuilles informatiques sera protégée contre le piratage et la défaillance de l'appareil. Si l'appareil était un iPhone d'Apple avec des clés privées sécurisées par empreinte digitale / Identification faciale, alors l'attaquant aurait besoin de compromettre vos partenaires multi-utilisateurs, de voler votre téléphone et de voler votre empreinte digitale ou votre visage. Idéalement, vos partenaires Multisig utilisent également des périphériques matériels sécurisés par biométrie.

Système de proposition de transaction

Multisig devient plus facile lorsque les utilisateurs peuvent ajouter et supprimer leurs autorisations indépendamment, et ce, dans leur propre temps, plutôt que d'avoir à rassembler toutes les signatures au cours de la fenêtre d'expiration limitée des transactions traditionnelles. Avec le système de proposition, n'importe qui peut proposer une transaction, et les parties impliquées dans la transaction peuvent tout simplement l'approuver. À tout moment entre l'ajout de votre approbation et l'obtention du seuil requis, votre approbation peut être supprimée.

Pour implémenter ce système, nous avons ajouté de nouvelles API qui permettent aux contrats d'évaluer si l’ensemble d'autorisations de compte est suffisant pour autoriser une transaction. Cela nous permet de mettre à niveau le processus Multisig en déployant WebAssembly plutôt que d'avoir besoin d'un Hardfork.

Développement de contrat simplifié

L'un de nos nombreux objectifs avec EOSIO est de rendre le développement de contrats aussi simple et indolore que possible. Si un développeur sait écrire une classe C ++ avec des méthodes, il doit être capable d'écrire un contrat intelligent avec la plus petite complexité possible.

Nous sommes heureux d'avoir simplifié notre contrat "hello world" à quelques lignes de code très simples. Notre chaîne d'outils a automatisé le processus de génération de contrats ABI et d'envoi d'actions utilisateur aux méthodes définies sur votre classe. Développer des contrats n'a jamais été aussi facile.

Support du point flottant

Une partie de la simplification du développement de contrats intelligents facilite la mise en œuvre des algorithmes mathématiques dont les développeurs ont besoin. L'un des aspects les plus difficiles du développement de la blockchain a été le manque de mathématique à point flottant et de puissance relative, de racine, et de fonctions Trig. De nombreux algorithmes, tels que Bancor, sont beaucoup plus faciles à implémenter en termes de point flottant plutôt que de forcer tous les calculs en point fixe qui est sujet aux erreurs et à la mémoire.

Nous avons résolu la nature non déterministe du matériel flottant en intégrant une bibliothèque de logiciels à point flottant utilisé de manière transparente par les contrats WebAssembly. Avec le logiciel à point flottant, nous obtenons les avantages du déterminisme et d’une facilité de développement à un coût qui n'est pas beaucoup plus élevé que le point fixe dans les cas complexes. Dans de nombreux cas, le point fixe est plus sujet aux erreurs ou plus gourmand en mémoire que la représentation déterministe en point flottant.

Support de bibliothèque de modèles standard C ++

Pour EOSIO Dawn 3.0, nous avons déployé des efforts considérables pour ajouter le support de la majorité de la bibliothèque de modèles standard C ++. Cela signifie que les développeurs peuvent utiliser les outils, les bibliothèques et les algorithmes qui leur sont familiers, tout en éliminant le risque de bogues causés par des implémentations non standard de ces algorithmes. Transactions planifiées

Avec les développeurs de transactions programmées, vous pouvez désormais écrire des contrats qui fonctionnent pour toujours – à condition que le contrat ait une bande passante par empilement suffisante. D'autres plates-formes exigent des solutions hors chaîne pour réactiver un contrat à un moment approprié. Avec les transactions planifiées, nous gagnons en efficacité et en facilité d'utilisation sans que les développeurs aient besoin d'héberger leurs propres serveurs pour maintenir un contrat en cours d'exécution.

Détection automatique de la portée

Sous EOSIO Dawn 2.0, chaque transaction était nécessaire afin de déclarer les plages de données auxquelles elle accéderait. C'était une erreur sujette et verbeuse pour les développeurs. Sous Dawn 3.0, les producteurs de blocs sont chargés de déterminer quelles plages de données sont accessibles et d’éviter les conflits. Cela réduit toutes les transactions et déplace le temps de planification vers le producteur de bloc plutôt que de le renvoyer à utilisateur, le développeur ou les nœuds principaux.

Cas théorique - 8 000 TPS

Si nous supprimons le code réseau de l'équation et que nous nous concentrons uniquement sur ce que le processeur est capable de faire avec la vérification de signature désactivée et en utilisant le JIT, alors nous pouvons atteindre 8 000 transactions par seconde single-threaded. Pour aller plus haut que cela sur une seule chaîne, il faudrait implémenter l'exécution parallèle de WebAssembly, et un planificateur plus avancé. Dans ce même scénario, en utilisant l'interpréteur plutôt que le JIT, on peut avoir 2700 TPS. Ceci suggère que le changement relativement simple de l'activation de JIT nous donnera environ 3 fois plus d'augmentation de performance pour les transferts. Ces mesures ont été faites sur un MacBook 2.8Ghz i7.

Transactions illimitées par seconde

La définition d'une "transaction par seconde" est souvent une comparaison entre des pommes et des oranges. Avec la communication interblockchain, nous pouvons diviser la charge de travail entre autant de blockchains que nous voulons. Les jetons peuvent être transférés de manière fiable et sécurisée entre les différentes chaînes. Avec 1000 chaînes exploitées en parallèle par les mêmes (ou différents) producteurs de blocs, nous pouvons voir des millions de transactions par seconde. Ceci représente une réalisation pratique des propositions d'échelle théoriques présentées par d'autres blockchains.

Nous encourageons fortement les producteurs de blocs de réseaux publics basés sur EOSIO à exploiter autant de chaînes que nécessaire afin de répondre à la demande des utilisateurs. Toutes les chaînes peuvent utiliser le même jeton comme base pour l’empilement et l'allocation des ressources. Cela permettra de créer effet de réseau maximalement possible autour d'un seul jeton, et tirera parti de la confiance et de la sécurité des incitations économiques créées par la capitalisation élevée du marché de ce jeton.

Les applications telles que les plateformes d’échanges, les devises et les médias sociaux peuvent équilibrer de façon triviale leurs charges sur de nombreuses chaînes parallèles.

La route à suivre

Avec EOSIO Dawn 3.0, l'accent était mis sur la stabilité de la plate-forme centrale. Au cours du mois prochain, nous préparerons le contrat de système final qui implémente tous les mécanismes d’empilement, de vote et de gouvernance. Nous allons également finaliser notre norme concernant les jetons.

Une fois le contrat de système mûri à notre satisfaction, nous lancerons un nouveau réseau d’essai public. Jusque-là, nous avons grandement simplifié le processus de démarrage de votre propre réseau essai, et du développement de vos propres applications. Nous fermons le réseau d’essai public actuel pour les deux prochaines semaines pendant que nous préparons le nouveau réseau d’essai afin de minimiser la confusion des développeurs.

Résumé

EOSIO Dawn 3.0 est une version développeur conçue pour être « complète » avec des API stables. Nous pensons que la plate-forme est maintenant suffisamment stable pour permettre aux développeurs d'applications sérieuses de commencer à développer leurs applications. EOSIO est devenu beaucoup plus puissant et facile à développer que ce que nous avions conçu il y a un an.

Notre équipe est en croissance et le développement se déroule à un rythme record. Notre référentiel a été l'un des 10 premiers dépôts C ++ les plus actifs de tous les Github au cours du mois dernier. Tout est sur la bonne voie pour une sortie publique de haute qualité d'EOSIO 1.0 en juin!