AERGO CHAIN Livre blanc
Dernière mise à jour le 17 juillet 2018, AERGO
AERGO est un nouveau protocole proposé, qui vise à propulser les déploiements de blockchain publics et privés. S'appuyant sur l'expérience de Blocko Inc (Blocko) dans la fourniture d'une blockchain privée à grande échelle et de niveau de production à des entreprises clientes reconnues, AERGO entend être spécialement conçu pour permettre aux architectures d'entreprise basées sur la blockchain d'intégrer à la fois de nouvelles approches innovantes et techniques systèmes de bases de données distribués.
Ce document se rapporte au projet AERGO et devrait être lu conjointement avec le livre blanc disponible à l'adresse https://AERGO.io. Ce document, ainsi que d’autres, peuvent être modifiés ou remplacés à tout moment, sans notification des modifications ni accès à des informations supplémentaires.
Le présent document contient des déclarations prospectives qui reposent sur les convictions d’AERGO Limited, société privée à capital-actions de Hong Kong (CR n ° 2713137) (AERGO Limited), ainsi que sur certaines hypothèses émises et les informations dont dispose AERGO Limited. .
L’AERGO, tel qu’envisagé dans ce livre blanc technique, est en cours d’élaboration et fait l’objet de mises à jour constantes, notamment en ce qui concerne les principales caractéristiques techniques et de gouvernance. Le jeton AERGO natif (AERGO Token) concerne le développement et l'utilisation de plates-formes expérimentales (logiciels) et de technologies susceptibles de ne pas se concrétiser ni d'atteindre les objectifs spécifiés dans le présent livre blanc. Si et quand AERGO est terminé, il peut différer considérablement du réseau décrit dans ce livre blanc. Aucune représentation ou garantie n'est donnée quant à la réalisation ou au caractère raisonnable de plans, projections ou perspectives futures et rien dans le présent document n'est ou ne doit être considéré comme une promesse ou une représentation quant à l'avenir.
Les informations contenues dans ce livre blanc sont fournies à titre privé à certains acheteurs potentiels et ne sont pas destinées à être reçues ou lues par quiconque. L’éligibilité n’est pas garantie et est susceptible d’être soumise à des restrictions.
La plate-forme AERGO, le jeton AERGO ou tout autre jeton qui y est exploité n'est pas destiné à représenter une sécurité ni aucun autre produit réglementé dans quelque juridiction que ce soit. Ce document ne constitue ni une offre ni une sollicitation de valeurs mobilières ou tout autre produit réglementé, ni une promotion, une invitation ou une sollicitation à des fins d'investissement. Les conditions de l'achat ne sont pas censées être un document d'offre de service financier ou un prospectus d'aucune sorte.
AERGO Token ne représente pas les capitaux propres, les actions, les unités, les redevances ou les droits sur le capital, les bénéfices, les revenus ou les revenus de la plate-forme ou du logiciel de la société AERGO Limited, ni aucune propriété intellectuelle ou liée à la plate-forme ou toute autre entreprise ou société , fondation ou autre entité dans toute juridiction
Ce livre blanc technique ne constitue pas un conseil d’achat pour le jeton AERGO. Il ne doit pas être invoqué dans le cadre d'un contrat ou d'une décision d'achat.
L'achat de AERGO Token et sa participation à la vente de AERGO Token comportent des risques importants. Avant d'acheter un jeton AERGO, vous devez évaluer et prendre en compte les risques, y compris ceux énumérés dans tout autre document.
Les points de vue et opinions exprimés dans ce livre blanc technique sont ceux d’AERGO Limited et ne reflètent pas la politique ou la position officielle d’un gouvernement, d’un quasi-gouvernement, d’une autorité ou d’un organisme public (y compris, sans limitation, tout organisme de réglementation de toute juridiction). juridiction. Les informations contenues dans ce livre blanc technique reposent sur des sources considérées comme fiables, mais leur exactitude et leur exhaustivité ne sont pas garanties.
Ce livre blanc technique et les matériaux associés sont publiés en anglais uniquement. Toute traduction est uniquement à des fins de référence et n'est pas certifiée par AERGO Limited ou toute autre personne. Aucune assurance ne peut être donnée quant à l'exactitude et à l'exhaustivité des traductions. En cas d'incohérence entre une traduction et la version anglaise de ce livre blanc technique, la version anglaise prévaut.
Dans ce livre blanc technique, les références à des sociétés et à des plates-formes spécifiques sont fournies à titre indicatif uniquement. L'utilisation de noms de sociétés et / ou de plates-formes et de marques de commerce n'implique aucune affiliation avec, ni aucune approbation de l'une de ces parties.
Vous devez consulter un avocat, un comptable, un professionnel de la fiscalité et / ou tout autre conseiller professionnel, le cas échéant, avant de décider d’acheter un jeton AERGO ou de participer de toute autre manière au projet AERGO.
Ce livre blanc technique n'a été examiné par aucune autorité de réglementation dans aucune juridiction. Dans le présent document, les références à des entreprises, des réseaux et / ou des cas d'utilisation potentiels spécifiques sont uniquement à des fins d'illustration. Hormis les partenaires ou les fournisseurs explicitement mentionnés, tels que Blocko, l’utilisation de noms de sociétés et de marques de plate-forme et / ou de plate-forme n’implique aucune affiliation ni aucune approbation de la part de l’une de ces parties.
Blocko a fourni à plus de 20 entreprises clientes sa propre implémentation privée «Coinstack». (1) Coinstack est basé sur une architecture de Bitcoin modifiée et Ethereum Virtual Machine exécute des contrats intelligents, ressemblant beaucoup à QTUM(2) et RSK.(3). même pour des cas d'utilisation à plus grande échelle tels que l'activation du processus d'authentification pour l'ensemble de la clientèle d'un fournisseur de cartes de crédit comptant des millions d'utilisateurs quotidiens (4), il a également permis de mieux comprendre la limite supérieure de performances du protocole Bitcoin et celle de la machine virtuelle Ethereum. incompatibilité avec l'architecture d'entreprise et les développeurs qui les sous-tendent.
Afin de mieux tirer parti de la chaîne d'outils et de l'architecture applicative de Coinstack prenant en charge les cas d'utilisation réels, Blocko a commencé à travailler sur AERGOSQL et AERGO. AERGOSQL est un nouveau moteur de contrat intelligent innovant capable d'utiliser un modèle de données relationnel et de développer des contrats intelligents à l'aide d'outils et de langages familiers pour les développeurs d'entreprise. Pour une description détaillée d'AERGOSQL, voir le livre blanc technique d'AERGOSQL disponible à l'adresse https://AERGO.io/paper/.
Ce document décrit les défis auxquels sont confrontés les déploiements de chaînes de blocs d'entreprise, ainsi que les nouvelles exigences et l'architecture capables de les résoudre.
(1) http://blocko.io
(2) https://qtum.org/en/
(3) https://www.rsk.co
(4) http://www.blocko.io/news/view/39
Nous pensons que les chaînes de blocs d'entreprise fonctionnent sous des hypothèses et des environnements différents de ceux des chaînes de blocs génériques publiques. Avec le déploiement de Coinstack, Blocko a pu se familiariser avec la réalité des adoptions par les entreprises en blockchain. Nous décrivons un certain nombre de ces hypothèses générales ci-dessous:
Nous explorons ci-dessous un certain nombre d'autres attributs clés qui, à notre avis, font partie intégrante des blockchains axés sur les entreprises.
Etant donné que les utilisateurs de chaînes de blocs d'entreprise ont généralement un meilleur accès au matériel en termes de quantité et de qualité, les implémentations de chaînes de blocs d'entreprise doivent évoluer à la fois horizontalement et verticalement.
Les environnements d'entreprise ont tendance à dépendre de la diversité des technologies accumulées au fil des années. Les implémentations de blockchain d'entreprise doivent fonctionner avec des interfaces standard modernes telles que OAuth et d'anciennes interfaces propriétaires telles qu'Active Directory.
Étant donné que la majorité des projets de développement d’entreprise sont généralement axés sur les projets, il n’ya guère de place pour expérimenter et apprendre de nouveaux langages et outils aux développeurs; au lieu d'obliger les développeurs à apprendre de nouveaux langages pour créer des contrats intelligents, les implémentations d'entreprise doivent permettre aux développeurs d'exploiter leurs connaissances et leur expérience existantes avec une chaîne d'outils familière.
Parallèlement, certaines ressources que les développeurs Web considèrent comme allant de soi, telles que l’accès illimité à Internet, ne sont pas disponibles pour les développeurs d’entreprise. En conséquence, les implémentations d'entreprise de la chaîne de blocs doivent fournir un environnement de développement plus complet avec des IDE, des kits SDK et des architectures de référence que les implémentations publiques de la blockchain.
Les entreprises font face à des pressions pour garantir une sécurité des données stricte en termes d'informations confidentielles et de données personnelles de clients / employés. Le désir de sécurité des données est souvent une considération plus importante que l'immuabilité et l'intégrité des données fournies par blockchain. Un moyen de sécuriser les données sur les chaînes de blocs publiques consiste à implémenter une couche de chiffrement et de déchiffrement au niveau de l'application. les implémentations de blockchain d'entreprise doivent fournir une approche plus robuste et holistique de la sécurisation des données.
Alors que les développeurs Web préfèrent utiliser Vagrant ou Docker sur leurs ordinateurs portables, les services informatiques d'entreprise sont plus à l'aise avec les armes plus volumineuses telles que Tivoli Provisioning Manager, OpenStack ou Kubernetes. Les implémentations de blockchain d'entreprise doivent prendre en charge l'intégration avec la technologie existante pour le provisionnement et la gestion dans l'informatique d'entreprise et fournir une suite de fonctionnalités beaucoup plus riche pour l'administration. L'exportation et l'importation, la sauvegarde des données, la surveillance, la journalisation et la migration des données sont des fonctionnalités généralement négligées par les implémentations de chaînes de blocs publiques, mais importantes dans l'environnement d'entreprise.
Les contrats intelligents constituent la base de la fonctionnalité sur les chaînes de blocs publiques et les chaînes de blocs d'entreprise. Contrairement aux dApps construites sur des chaînes de blocs publiques avec leur accès au stockage en nuage et aux fournisseurs de CDN, les dApps sur des chaînes de blocs d'entreprise doivent être plus autonomes et les implémentations de chaînes de blocs d'entreprise doivent leur permettre de prendre en charge de nombreuses fonctionnalités pour le stockage de données structuré et non structuré.
Figure 1. Architecture AERGO
AERGO est conçu pour être une plate-forme holistique et polyvalente, qui comble le fossé entre les blockchains publics et les blockchains privés. Pour être efficace dans les deux environnements, AERGO se veut compact, tout en restant flexible.
Afin de desservir des charges de travail multi-locataires avec potentiellement des millions d'utilisateurs simultanés accédant au même ensemble de nœuds, AERGO entend emprunter de nombreux concepts issus des conceptions de base de données traditionnelles et de l'informatique distribuée.
Le répertoire distribué (DD) est une fonctionnalité essentielle destinée à être utilisée comme un bloc de construction pour toute la mise en œuvre d'AERGO.
Il est proposé à chaque DD d’un référentiel de gérer un espace de nom indépendant et isolé. Chaque espace de noms contient des informations sur différentes branches et balises résidant dans le référentiel, ainsi que sur la validité de divers identifiants sur la blockchain.
Chaque DD est destinée à être une blockchain à part entière, avec son propre bloc de genèse et le meilleur bloc. Contrairement aux blocs conventionnels, la taille des blocs DD est limitée, avec un intervalle de création relativement long entre eux. Étant donné que les DD sont utilisées pour gérer les métadonnées, elles doivent être compactes.
DD est comparable aux dictionnaires de données des bases de données, à Zookeeper pour Hadoop ou etcd pour CoreOS en ce qui concerne son rôle et ses fonctionnalités.
a. Tree of Life (ToL)
L'espace de noms ToL d'une DD est proposé pour contenir des informations sur toutes les branches du référentiel, ainsi que sur leurs blocs de genèse ou leurs blocs racines. Les informations sur les balises sont également gérées dans l’espace de noms ToL. En conséquence, l’espace de noms ToL contient également des informations sur le meilleur bloc de chaque branche; puisque la balise HEAD garde en permanence le meilleur bloc de chaque branche.
b. Distributed Directory Service (DDS)
Il est proposé que l’espace de noms DDS contienne des entrées pour différentes entités sur la chaîne de blocs; leurs clés publiques et leur validité, ainsi que les rôles et autorisations associés. L'espace de noms DDS est destiné à servir de base au contrôle d'accès pour les référentiels AERGO.
Chaque entité peut représenter un certificat client-acteur ou un certificat de serveur. Pour les entités avec des certificats de serveur, DDS peut servir à la fois de liste de révocation de certificats et de DNS avec informations de routage.
AERGOFS, le composant de système de fichiers distribué proposé par AERGO, est censé dépendre de DDS, car celui-ci assure le suivi des volumes de données constituant chaque instance AERGOFS. AERGOFS peut également être utilisé pour stocker des blocs et des index pour différentes branches du référentiel.
L'espace de noms DDS constitue la base de l'identité des nœuds pour participer également au processus de consensus.
a. CORE Consensus
L'algorithme de consensus de base est destiné à être utilisé pour construire le DDS. L'algorithme de consensus de base et le DDS sont mutuellement dépendants, car l'algorithme de consensus de base doit accéder au DDS dans la DD pour permettre l'extraction de nouveaux blocs.
L'algorithme de consensus de base proposé par AERGO est la preuve déléguée de participation (DPOS) (5). DPOS est le modèle de consensus préféré parce que, en résumé:
b. Consensus défini par l'utilisateur
Par défaut, chaque référentiel utilise le consensus de base. Comme AERGO a l'intention de fournir également une architecture enfichable pour l'algorithme de consensus, différents modules d'algorithme de consensus peuvent être utilisés à la place du consensus de base. Notamment, RAFT (pour le développement) et PBFT (pour le classement strict) sont utiles pour développer et exécuter différents services.
En utilisant la même chaîne d'outils pour créer des contrats intelligents, un algorithme de consensus défini par l'utilisateur peut également être utilisé pour chaque référentiel. La logique définie par l'utilisateur peut régir la manière dont les événements suivants sont survenus et gérés dans la blockchain.
Étant donné que la création et la fusion de blocs peuvent également être perçues comme des événements de réorganisation de blocs, la même stratégie de réorganisation de blocs est également utilisée pour le contrôle de version distribuée. Du point de vue du contrôle de version, la règle de réorganisation de bloc s’appelle "Fusion cohérente".
(5) https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper
AERGO prend en charge une infrastructure de contrat intelligent basée sur des plug-ins à plusieurs paradigmes.
Chaque contrat peut être exécuté ou interrogé par un client-acteur ou une autre instance de contrat intelligent. Comme AERGO fournit une interface permissive offrant une interopérabilité maximale entre les implémentations de contrats intelligents, les contrats écrits pour Ethereum Virtual Machine, Fabric Chaincode ou AERGOSQL peuvent être utilisés les uns avec les autres.
a. AERGOSQL
La manière canonique d'écrire un contrat intelligent pour AERGO est fournie par AERGOSQL. AERGOSQL fournit un modèle de données relationnel pour le stockage et l'accès aux données et un langage de script de type SQL pour la rédaction de contrats intelligents.
Avec AERGOSQL, les contrats intelligents peuvent être écrits en utilisant la syntaxe SQL bien connue.
Figure 2. Extrait du modèle de codage AERGOSQL
Pour des performances maximales, AERGOSQL exploite des technologies telles que LLVM pour utiliser la compilation JIT(6) et des implémentations b-tree hautes performances telles que WiredTiger(7) pour le stockage de données.
(6) https://llvm.org
(7) http://www.wiredtiger.com
b. L'interopérabilité
Grâce à son architecture enfichable, AERGO est conçu pour prendre en charge différentes implémentations de contrats intelligents. AERGO hérite de la compatibilité de la machine virtuelle Ethereum de Blocko Coinstack. Fabric Chaincode est pris en charge via une virtualisation légère telle que Docker.
La première version d’AERGO dépend de la mise en œuvre de l’EVM de go-Ethereum. L'utilisation d'evmjit pour des performances supérieures est prévue dans le futur.
AERGO est favorable à l’intégration de contrats intelligents dans le jardin clos de Blockchain, ainsi que de contrats intelligents tenant compte d’événements et de facteurs externes grâce à la mise en œuvre d’oracles intelligents. Les smart oracles cherchent à fournir les fonctionnalités suivantes:
Du point de vue d'un contrat intelligent, les oracles intelligents sont des facteurs externes associés à un contrat intelligent spécifique. Les smart oracles réagissent aux modifications du contrat intelligent couplé et injectent des données en réponse. Dans certains cas, les smart oracles peuvent déclencher des contrats intelligents de manière autonome.
Du point de vue d’une dApp, les smart oracles implémentent des micro-services exposant les fonctionnalités externes requises par la dApp. Etant donné que smart oracles et dApps peuvent communiquer hors chaîne, les micro-services fournis par smart oracles peuvent être utilisés pour mettre en œuvre une communication hors bande requise par le contrat smart; Un cas d'utilisation courant inclut l'échange d'un jeton d'authentification entre un smart oracle et un dApp.
Contrats isomorphes
La boîte à outils de développement AERGO a pour objectif de prendre en charge l'exécution isomorphique d'un contrat intelligent via la génération automatique de code. Le code isomorphe généré à partir d'un contrat intelligent est accessible à la fois par dApp et par smart oracles, permettant un accès transparent au contrat intelligent et à la structure de données sous-jacente. L'exécution isomorphe d'un contrat intelligent est essentielle à la productivité du développement d'un contrat intelligent et d'applications ou de services basés sur celui-ci.
Figure 3. Architecture conventionnelle de dApp et dApp isomorphe
Tous les langages de contrat intelligents ne prennent pas en charge les contrats isomorphes; la prise en charge des contrats isomorphes est limitée aux contrats écrits pour AERGOSQL.
AERGOFS est un composant essentiel de la plate-forme AERGO, fournissant des fonctionnalités de système de fichiers distribuées.
AERGOFS dépend du DD pour la gestion des métadonnées liées aux fichiers; les métadonnées sur chaque fichier, y compris l'emplacement physique, la valeur de hachage et diverses statistiques, sont stockées dans la DD.
Alors que les contrats intelligents fournissent un stockage de données structuré avec un schéma de données et des index pour une requête plus rapide, AERGOFS entend fournir la capacité de stockage de données non structurée d’AERGO.
AERGOFS fournit une interface HTTP simple, permettant un accès à la fois aux smart oracles s'exécutant sur un environnement de serveur et aux dApps s'exécutant sur des navigateurs Web.
Contrairement aux systèmes blockchain traditionnels, AERGO considère les réorganisations de chaînes et de blocs comme des fonctionnalités essentielles de la blockchain, plutôt que comme des effets secondaires gênants. En adoptant des modèles de données et une structure de commande similaires à ceux de git, AERGO cherche à permettre une collaboration sur des données aussi facile que de collaborer sur un code source.
Figure 4. Dépôts publics et privés
AERGO soutient la création de référentiels publics et privés. Chaque référentiel peut être nommé ou non nommé. Un référentiel nommé a une entité publique associée dans le répertoire distribué du réseau AERGO Public Network. Un référentiel non nommé n'a pas cette association.
Tout comme un référentiel Git public, un référentiel AERGO public est conçu pour être transparent en lecture et en écriture, ou pour permettre de manière sélective différentes autorisations à des utilisateurs anonymes. Une configuration courante consiste à créer un référentiel AERGO public avec un accès anonyme en lecture seule.
Un référentiel privé est destiné à être un référentiel AERGO avec le contrôle d'accès complet activé, à la fois pour la lecture et l'écriture du référentiel. Un référentiel public ou privé est en réalité une blockchain privée dans le sens où il fonctionne indépendamment du réseau public AERGO. En conséquence, AERGO Token ne dispose d'aucun utilitaire dans les référentiels publics ou privés.
Figure 5. Blocs de ramification et de fusion
Dans chaque référentiel, différentes branches pointant vers un instantané différent dans l'état de la chaîne de blocs peuvent être créées. En fait, le concept de «meilleure chaîne» dans AERGO est analogue à celui de la branche principale.
AERGO cherche à fournir une syntaxe et une sémantique conviviales aux utilisateurs habitués aux systèmes de contrôle de version tels que Git. Ces fonctionnalités sont accessibles via le client AERGO CLI, ainsi que les API RPC.
a. Commandes de base
Vous trouverez ci-dessous des illustrations de l’utilisation de base d’AERGO pour le contrôle de version distribuée.
La commande ci-dessus crée une nouvelle branche. Sans un hachage de bloc implicite en tant que paramètre, le meilleur bloc de la branche en cours est utilisé en tant que bloc racine pour la nouvelle branche. La nouvelle branche fonctionne comme une chaîne indépendante, avec la possibilité d’acquérir de nouveaux blocs. Sans les branches créées par l'utilisateur, la branche principale existe par défaut.
La commande ci-dessus crée une nouvelle balise nommée. Sans un hachage de bloc implicite en tant que paramètre, le meilleur bloc de la branche actuelle est utilisé comme bloc racine pour la nouvelle balise. Contrairement à une branche, une balise ne peut pas acquérir de nouveaux blocs.
La commande ci-dessus extrait une branche ou une balise existante pour examen ou manipulation.
Cette commande fusionne les modifications de la branche distante avec la branche de référentiel local. Par conséquent, les transactions à distance sont également appliquées au référentiel local. Dans le processus, les balises nommées sont également synchronisées.
Ce qui précède cherche à fusionner les modifications de la branche locale vers la branche de référentiel distant. En conséquence, les transactions locales sont également appliquées au référentiel distant. Dans le processus, les balises nommées sont également synchronisées.
b. Branchement et fusion
L'un des concepts les plus complexes des systèmes de contrôle de version distribués est le processus de fusion de branches. Pour les chaînes de blocs contenant des données en temps réel, la fusion est encore plus difficile à réaliser. En raison de son processus non destructif, la création de branches est un processus simple et direct.
Cependant, la fusion nécessite deux approches différentes.
Fusion automatique
Par défaut, la fusion automatique est le processus attendu pour la fusion de deux branches. La fusion automatique est similaire au processus de réorganisation de blocs dans les chaînes de blocs. Dans ce cas, les blocs de la source en fusion sont dissous dans les transactions et absorbés dans le pool de fusion de la cible en cours de fusion. En fin de compte, le pool de fusion crée un nouveau bloc associé au meilleur bloc de la cible de fusion. Au cours du processus, les transactions incohérentes pour la branche cible de la fusion sont automatiquement exclues du nouveau bloc.
Fusion cohérente
La fusion cohérente ne se produit que lorsqu'une branche est créée avec une logique de fusion cohérente spécifiée. La fusion cohérente est similaire à la fonctionnalité de fusion fournie par les systèmes de contrôle de version tels que Git. Contrairement à la fusion automatique qui supprime par défaut les transactions incohérentes, la fusion cohérente s'appuie sur la logique de résolution de conflit prédéfinie pour gérer les transactions incohérentes. La logique de résolution de conflit est implémentée en tant que contrat intelligent au niveau du système.
AERGO utilise trois approches différentes pour atteindre l’évolutivité.
Le partitionnement par domaine est la stratégie d'évolutivité la plus élémentaire utilisée par AERGO. Le partitionnement basé sur le domaine est réalisé via la fonctionnalité de contrôle de version distribuée (DVC) d'AERGO.
A la différence des implémentations classiques de la blockchain, AERGO est capable de créer et de fusionner ses données à travers des branches librement. En conséquence, le grand livre distribué peut être partitionné à la fois logiquement et physiquement à travers différents référentiels.
Une telle approche est déjà utilisée avec succès par les contrôles de version distribués tels que Git et Mercurial. Par exemple, un service gigantesque comme GitHub peut héberger des dizaines de millions de référentiels.
Cependant, l'efficacité du partitionnement basé sur le domaine dépend de la structure et de l'utilisation des données. Lorsqu'un référentiel unique doit gérer une expansion illimitée des données, il est très difficile de partitionner les données par la création de branches. En conséquence, AERGO propose deux autres approches en matière d'évolutivité pour la gestion d'une énorme quantité de données pour un seul référentiel.
La stratégie de déploiement d’AERGO dépend de la fonctionnalité fournie par AERGOFS. AERGOFS remplit deux rôles pour parvenir à l'évolutivité :
L’approche la plus directe et la plus simple que AERGOFS cherche à utiliser pour l’évolutivité consiste à optimiser un seul nœud.
Bien que le redimensionnement horizontal fonctionne bien pour une grande quantité de données, il ne répond pas aux critères de référence réalistes. Avec l'avènement de la mémoire peu coûteuse, du stockage rapide tel que le SSD et du débit réseau limité, l'optimisation d'un seul nœud est très efficace pour les systèmes quotidiens. Blocko a beaucoup appris sur cette leçon tout en proposant une implémentation réelle de la blockchain dans le monde des entreprises. AERGO, avec l’aide de Blocko, cherche à emprunter de nombreuses idées et techniques à cet égard.
Afin de rendre chaque nœud aussi efficace que possible, les nœuds AERGO doivent être équipés d'une pile réseau efficace et d'un moteur de stockage optimisé pour des I/O améliorées.
AERGO cherche à fournir deux mécanismes pour la sérialisation des transactions.
Étant donné que chaque branche de blockchain consiste en une série de blocs, les transactions peuvent être sérialisées en les empilant les unes après les autres.
AERGO vise à fournir un contrôle MVCC (Multi Version Concurrency Control) basé sur la hauteur des blocs. En conséquence, avec une hauteur de branche et de bloc spécifiée, il est possible de fournir des [lectures cohérentes] à travers différents nœuds du référentiel.
La fonctionnalité MVCC d’AERGO vise à fournir à la fois une isolation de capture instantanée pour des lectures cohérentes et une forme de verrouillage optimiste par le biais de versions de lignes ou de documents. Cependant, MVCC ne fonctionne que pour la sérialisation au niveau du bloc.
Les clients accédant à des nœuds AERGO peuvent tirer parti de la création déterministe et programmée de blocs par les délégués, caractéristique fournie par DPOS et le consensus central, pour exécuter des transactions de manière synchrone, avec une garantie forte sur la finalité des transactions.
Étant donné que chaque nœud délégué peut appliquer un ordre de sérialisation uniforme pour traiter les nouvelles transactions dans le pool de mémoire et créer de nouveaux blocs, les clients ne doivent pas attendre que l'intervalle de bloc récupère le résultat des transactions. En conséquence, la latence d'exécution d'une transaction diminue de quelques secondes à quelques millisecondes.
Figure 6. Pool Level Serialization
Cependant, avec la réorganisation des blocs et le partitionnement des chaînes en jeu, ainsi que la présence de clients mal intentionnés, la sérialisation au niveau du pool ne fournit qu'un niveau de cohérence probabiliste. D'autre part, avec des charges de travail optimistes, la sérialisation au niveau du pool fonctionne bien pour résoudre les problèmes concrets.
AERGO entend uniquement autoriser les utilisateurs disposant des autorisations appropriées à accéder aux données du grand livre en fournissant des référentiels privés de type git.
En créant une nouvelle branche à partir d'une branche parent distante, les utilisateurs peuvent conserver les blocs nouvellement créés dans une branche privée, de manière à ce qu'ils soient isolés du public. Ce n'est qu'avec l'autorisation du référentiel spécifique hébergeant la branche que vous pouvez accéder aux blocs.
Une branche spécifique peut être synchronisée avec des référentiels distants pour échanger des données. Dans ce cas, les branches privées du référentiel peuvent soit sélectionner les commits pertinents dans le référentiel public, soit fusionner automatiquement l'ensemble des modifications.
Les performances d'une blockchain spécifique dépendent de l'efficacité de la création et du partage de nouveaux blocs et du temps nécessaire à chaque nœud pour valider les nouveaux blocs.
Le processus de création d'un bloc implique la prise en compte de l'ensemble du protocole de blockchain consensuel distribué. Le processus de validation par bloc utilisé dans le cadre de divers protocoles consensuels distribués est parfois mal conçu et mis en œuvre.
Les nœuds sous-performants sont acceptables pour les implémentations blockchain de qualité grand public telles que Bitcoin ou Ethereum, mais les blockchains de niveau entreprise tels qu'AERGO nécessitent des performances très robustes en temps quasi réel. En conséquence, chaque nœud doit être implémenté avec autant d'efficacité que le protocole de consensus lui-même.
AERGO a l'intention d'introduire le concept de parallélisme à différentes étapes du traitement des blocs afin de maximiser les performances.
Le parallélisme implique une analyse minutieuse des dépendances entre les transactions incluses dans chaque bloc et une architecture efficace inspirée de SEDA(8).
(8) https://en.wikipedia.org/wiki/Staged_event-driven_architecture
Afin de garantir la cohérence entre les nœuds, les implémentations de chaînes de blocs utilisent généralement la politique de sérialisation de l'exécution de toutes les transactions et des blocs disponibles.
En conséquence, le taux de blocs qu'un noeud de la chaîne de blocs peut traiter dépend du temps nécessaire au traitement de chaque transaction, quel que soit le nombre d'unités de traitement ou de la mémoire disponible.
Afin de permettre la validation parallèle des transactions et des blocs, AERGO envisage d'effectuer une analyse de dépendance entre les transactions et les blocs et de créer une structure de données appelée Arbre de transaction déterministe.
Arbre de transaction déterministe
Un arbre de transaction déterministe (DTT) peut être considéré comme une représentation formelle de l'ordre d'exécution des transactions afin d'obtenir des résultats déterministes pour les machines d'état affectées par les transactions.
Par conséquent, pour un ensemble de transactions, il peut exister plusieurs DTT viables et correctes.
Chaque branche d'une TNT peut être traitée et appliquée aux machines à états sous-jacentes associées aux transactions en parallèle avec les états résultants déterministes. Une TNT typique aura un certain nombre de branches de différentes longueurs.
Figure 7. Tres transaction déterministe
Selon la taille des blocs, chaque DTT peut avoir des branches de quelques transactions à plusieurs milliers de transactions. De même, une TNT peut avoir un nombre variable de branches.
La validité d'une TNT ne peut être vérifiée qu'en exécutant une TNT sur un ensemble de machines à états. Une version de la TNT peut être optimisée dans une autre version en transformant également l'arbre.
Afin de créer une TNT pour un ensemble de transactions dans un délai réaliste, AERGO utilise une approche basée sur des règles pour analyser les transactions. Des approches plus sophistiquées, notamment l’apprentissage automatique, devraient être testées dans les futures versions d’AERGO.
