Framework: analyse des systèmes DLT

Ce travail vise à déterminer si l'objet analysé est un système DLT. Les résultats obtenus sont bien adaptés à l'analyse comparative de différents projets, allant de la structure de gestion à la définition des liens auxquels se réfèrent les transactions.

La technologie du grand livre distribué est une technologie de stockage de l'information dont les principales caractéristiques sont le partage et la synchronisation des données numériques selon l'algorithme de consensus, la distribution géographique de copies équivalentes à différents points du monde, l'absence d'administrateur central.

Analyse technique

Niveau de protocole

Genesis

Au niveau du protocole, se réfère aux processus qui doivent être développés et exécutés avant le démarrage du réseau.

Dépendance à l'égard d'autres réseaux.

La dépendance à l'égard d'autres protocoles dépend des limites du projet analysé. Cela détermine si le système peut fonctionner comme un système indépendant (pour être autosuffisant) ou s'il dépend d'un autre réseau.

Tableau 1. Dépendance à l'égard d'autres systèmes



Code de programme

Le code peut être basé sur un framework existant ou écrit à partir de zéro. Les frameworks les plus populaires sont les bases de code des systèmes open source (Bitcoin / Ethereum). Il existe également des bases de données de sources fermées pour les plates-formes fermées fournies par des projets tels que Digital Asset / Clearmatics et SETL.

Tableau 2. Code de programme



Définition des règles

L'introduction de règles fait référence à la définition d'un ensemble de règles sur lesquelles un système DLT doit fonctionner. Ce processus peut être effectué par différents participants et est individuel pour un système DLT particulier.

Mise à jour du protocole

Les mises à jour de protocole s'appliquent aux processus existants qui vous permettent de modifier les règles système. La mise à jour du protocole peut inclure l'élimination des erreurs techniques (bogues), l'amélioration de la sécurité et des fonctionnalités du système, ainsi que l'extension ou la limitation des règles de protocole existantes.

Gestion de protocole

La gestion de protocole fait référence à un ensemble de processus décisionnels qui vous permettent de modifier un protocole de manière ordonnée et légale. Il s'agit d'un sous-ensemble d'une gestion de projet plus large, qui couvre un ensemble complet de processus et de normes qui décrivent et définissent la coordination et les actions, mais qui ne peuvent pas être formellement intégrés dans le système DLT.

Un élément important de tout changement proposé au protocole est la façon dont il est adopté et ratifié - ou, en d'autres termes, la manière dont la légitimité est fournie à la suggestion des participants au réseau. Étant donné que la légitimité dans ce contexte est un concept social, il semble raisonnable d'identifier certaines des relations «socio-politiques» possibles trouvées dans les systèmes DLT.

Tableau 3. Gestion des protocoles



La gestion des protocoles prend de nombreuses formes et n'est souvent pas claire. Initialement, les systèmes DLT sont caractérisés par un pouvoir anarchiste (gratuit), il n'y a pas d'entreprises ou de groupes de personnes responsables de prendre des décisions. Surtout, ils sont similaires aux processus de gestion du trafic open source. Un exemple de discussion sur les changements de protocole peut être la communication des développeurs dans un chat / GitHub / conférence. Dans des conditions dictatoriales, le processus de discussion des changements peut être exactement le même, mais la décision finale sera prise par une seule personne. Dans certains cas, un formulaire de gestion de protocole peut être défini par plusieurs types de cartes. Par exemple, la blockchain EOS agit comme une fédération de fabricants de blocs sélectionnés par les utilisateurs qui possèdent un actif EOS. Le poids du vote est déterminé par le nombre de jetons détenus sur l'adresse. Ce type de gouvernement divise le protocole en deux partis: les utilisateurs "élites" et "ordinaires", reprenant les caractéristiques d'un système hiérarchique: fédération, démocratie et ploutocratie.

La gestion en chaîne implique l'inclusion de fonctions de gestion au niveau des données. L'objectif est de formaliser la gouvernance, augmentant ainsi la légitimité et évitant la fragmentation du réseau en raison de litiges ou de mises à jour de protocole incohérentes. Un ensemble diversifié de systèmes de vote en chaîne a été développé pour les systèmes DLT, allant d'un baromètre de l'humeur communautaire aux référendums. Cependant, les fonctions de gestion en chaîne, en règle générale, ne sont qu'un ajout à d'autres formes de gestion.

Changement de protocole

Le processus réel de mise à jour du protocole implique:

1. mettre à jour le code sur GitHub s'il s'agit d'un projet open-source;
2. mise à jour du client s'il s'agit d'un protocole source fermé;
3. Les clients travaillant sur l'ancien code de programme peuvent être considérés comme non pertinents et mis sur liste noire;
4. Les clients fonctionnant sur l'ancien code du programme forment un fork, ce qui conduit à la création d'une version alternative du protocole.

Tableau 4. Formulaire de modification du protocole



Différents systèmes DLT utilisent différentes méthodes pour mettre à jour le réseau. Par exemple, Ethereum accepte les dons pour financer le développement et met également à jour le réseau à l'aide de logiciels de développeurs financés par des subventions.

Niveau réseau

Le réseau de protocole DLT est le résultat direct de la mise en œuvre des règles de protocole. Le réseau consiste en un travail coordonné de participants et de processus qui adhèrent à une norme technologique (protocole) et sont activement impliqués dans l'échange de données et d'informations sur des canaux de communication spécifiques.

Processus de communication

Processus de transfert de données entre les participants d'un système DLT.

Accès réseau

L'accès au réseau implique la possibilité de se connecter au protocole, il peut être limité ou illimité.

• Accès illimité - tout utilisateur peut se connecter / se déconnecter librement à tout moment;
• Accès limité - seuls certains utilisateurs peuvent se connecter au réseau, généralement contrôlé par l'entité désignée.

En règle générale, les systèmes à accès illimité n'ont pas de restrictions sur le nombre de participants, tandis que les réseaux fermés peuvent définir un nombre limité de participants.

Habituellement, les participants obtiennent un accès direct au réseau en lançant des nœuds complets: ils sont considérés comme une «élite» avec un large ensemble de droits, car ils peuvent envoyer / vérifier et transférer des données d'enregistrement. Les participants au réseau peuvent également obtenir un accès indirect au réseau en exécutant des «clients légers» qui demandent des données à des nœuds complets en se connectant via un service spécial (API).

Tableau 5. Formulaire d'accès au réseau



En règle générale, plus le système est ouvert, plus il est sensible aux attaques. En particulier, ces systèmes sont vulnérables à l'attaque de Sibyl, lorsque l'attaquant crée de nombreuses fausses identités pour augmenter son influence sur le réseau.

L'attaque Sibyl est un type d'attaque lorsqu'un attaquant accède ou masque un changement dans le protocole, créant de nombreuses fausses identités.

L'identification étant une propriété exogène (c'est-à-dire «réelle»), le système DLT ne peut pas empêcher ces attaques, il doit s'appuyer sur des participants externes (système de certification) ou des mécanismes qui réduisent la probabilité d'une attaque (PoW / PoS).

Envoi de données

Le transfert de données est le processus de distribution de données aux nœuds connectés. Les données peuvent être brutes / non formatées ou normalisées dans un format spécifique (par exemple, sous la forme d'une transaction ou d'un enregistrement). Les données peuvent être transmises à chaque nœud (diffusion universelle), ou seulement à un sous-ensemble spécifique de nœuds (diffusion multicanal). Dans ce dernier cas, la diffusion des données est généralement limitée aux participants à la transaction. Cela vous permet de créer un "canal" pour le transfert de données, généralement par cela signifie sharding / Lightning Network.

Les premiers systèmes DLT (par exemple Bitcoin, Litecoin) utilisent un modèle de distribution de données universel, qui reste la méthode de distribution de données la plus populaire.

Afin de maintenir l'anonymat et la confidentialité des entreprises, les systèmes ultérieurs ont un modèle de diffusion multicanal (par exemple, Hyperledger Fabric, Corda). D'autres systèmes, tels que Cosmos, sont conçus pour servir de concentrateurs afin que les systèmes DLT indépendants puissent être interconnectés via le sharding.

Tableau 6. Formulaire de soumission des données



Un exemple de diffusion de données multicanaux est que tous les participants au réseau ne doivent pas participer à un consensus sur l'état du canal: seuls les participants au canal doivent parvenir à une cohérence sur les données stockées dans ce canal (consensus «local»). Ceci est très différent des systèmes avec diffusion globale des données, car chaque nœud individuel doit parvenir à un consensus sur l'état global du système (consensus «global»); l'incapacité à atteindre un consensus de certains nœuds peut conduire à leur déconnexion, ou à la création d'un fork.

Création de transaction

Le processus de création de transaction contient un ensemble d'instructions qui seront exécutées après l'ajout d'une transaction au réseau. La création de transactions peut être illimitée (c'est-à-dire accessible à tous) ou limitée à certains participants. Les transactions sont créées par les utilisateurs qui signent le message avec leur clé privée. Diverses interfaces sont disponibles pour permettre aux utilisateurs de créer et d'envoyer des transactions au réseau (par exemple, des PC et des portefeuilles mobiles).

Traitement des transactions

Le traitement des transactions décrit l'ensemble des actions requises pour ajouter une transaction non confirmée à la liste des transactions confirmées. Une transaction est considérée (provisoirement) valide après l'ajout («confirmé») à la liste, ce qui conduit à l'exécution des instructions intégrées dans la transaction. Cependant, la confirmation seule ne suffit pas pour que cette transaction devienne la base des opérations ultérieures; avant que les sorties de transaction puissent être utilisées par le système.

Figure 1. Traitement des transactions dans un système DLT



Les enregistrements obéissent à un algorithme de consensus spécifique utilisé dans le système DLT. Cela comprend le processus de détermination de la validité de l'enregistrement proposé, ainsi que le rejet des entrées non valides (par exemple, les entrées défectueuses ou incompatibles) et le choix entre des entrées différentes mais également valides.

Enregistrer le candidat

Les enregistrements qui peuvent être déplacés vers la liste des transactions confirmées à l'avenir sont envoyés par les créateurs des blocs, qui les sélectionnent dans la liste des transactions non confirmées et les combinent pour former des candidats à l'écriture dans la liste des enregistrements confirmés. Deux propriétés déterminent le droit d'envoyer un enregistrement et sa future inclusion dans la liste des enregistrements confirmés.

Tableau 7. Formulaires d'enregistrement



Étant donné que les enregistrements font l'objet d'un consensus, ils doivent respecter les règles de protocole. Tout d'abord, ils doivent être formatés correctement et ne doivent pas contenir de transactions non valides ou non valides. De plus, chaque entrée doit inclure un lien / pointeur vers l'entrée précédente et, si nécessaire, utiliser PoW ou toute autre méthode qui rend difficile la conduite d'une attaque Sibyl.

L'algorithme de consensus peut être classé en fonction de son niveau de complexité (coûts électriques / monétaires). Les algorithmes d'une complexité illimitée sont mesurés dans les ressources nécessaires pour parvenir à un consensus. Par exemple, dans le cas du calcul de Bitcoin PoW, la difficulté de trouver la bonne solution augmente avec la complexité des données de hachage. Bien au contraire, d'autres algorithmes fonctionnent (par exemple, la tâche Généraux byzantins / BFT) ne nécessitent pas de coûts de calcul importants et ont une complexité limitée.

Dans les systèmes ouverts, un algorithme doit être fourni pour réduire les risques d'une attaque Sybil. Les systèmes privés (fermés) vérifient chaque participant avant de lui permettre d'accéder à la connexion réseau, ce qui empêche la possibilité d'une attaque. Dans les systèmes fermés, un groupe de nœuds a tendance à choisir un nœud qui créera des blocs.

Résolution des conflits

Un conflit peut être causé pour plusieurs raisons:

1. les participants ne s'entendent pas sur la version du protocole pertinente;
2. les participants ne sont pas d'accord sur les transactions vérifiées.

En cas de situation du premier point du réseau Bitcoin, le réseau sélectionne la plus longue chaîne de blocs comme valide et ignore la plus courte. Dans Tezos, la validité d'un bloc est déterminée avec un «poids de bloc» différent, le poids ici est le nombre d '«approbations» des validateurs qu'il reçoit au hasard des jalonneurs.

Tout algorithme de consensus comporte un certain nombre de compromis

Tableau 7. Formes de motivation pour le traitement des transactions



Validation

La validation fait référence à l'ensemble des processus nécessaires pour garantir que les sujets parviennent indépendamment à la même conclusion concernant un ensemble de documents approuvé. Cela comprend: la vérification des transactions envoyées / la vérification des données enregistrées / la vérification de l'état général du réseau. Il s'agit d'une distinction importante par rapport aux systèmes non DLT, car elle offre aux participants la possibilité de réaliser un audit indépendant du système.

Vérification des transactions

La vérification d'une transaction consiste à s'assurer qu'un enregistrement individuel est conforme aux règles de protocole avant de le transférer à d'autres entités. Cela comprend: l'exactitude du format de la transaction, la présence d'une signature appropriée et le respect de la condition que la transaction n'entre pas en conflit avec une autre. Certains systèmes peuvent utiliser un système qui interdit les transactions jusqu'à un moment précis ou pour une autre raison. En règle générale, ces conditions sont remplies par des contrats intelligents.

Une attaque de 51% est le cas lorsqu'un participant ou plusieurs participants combinent leur puissance de calcul (voix) et traitent les transactions sur le réseau plus rapidement que le reste du protocole. Ces attaques vous permettent d'effectuer des transactions non valides et de les enregistrer comme valides. Un système utilisant PoW est particulièrement vulnérable

Vérifier les enregistrements

La vérification de l'enregistrement envoyé vous permet de vous assurer que l'enregistrement est conforme aux règles du protocole. Si l'entrée proposée est reconnue comme valide, elle est ajoutée à la liste des entrées confirmées et relayée à tous les nœuds connectés du réseau. Bien que ce processus soit différent dans chaque système, mais, en règle générale, selon les principes généraux, il est similaire partout, par exemple, en vérifiant que le travail PoW a été effectué sur une transaction. La combinaison de la vérification des transactions envoyées et de leur enregistrement ultérieur par les validateurs fournit un audit indépendant de l'ensemble du système.

Dossier de transaction

Une transaction / un enregistrement confirmé n'est pas nécessairement irréversible. L'irréversibilité de l'écriture peut être probabiliste (par exemple, un système basé sur PoW dans lequel il n'est pas pratique de recalculer toutes les transactions enregistrées), ou des systèmes qui incluent des «points de contrôle» qui doivent être affectés à chaque transaction. Les enregistrements confirmés peuvent être appelés immuables, mais ceux qui ont été «pré-confirmés» peuvent être annulés. Les enregistrements pré-confirmés deviennent inchangés après avoir surmonté l'état de transition de «pré-confirmé» à «confirmé».

Figure 2. Traitement des transactions dans les systèmes DLT



La figure 2 décrit une description schématique du processus qui se produit pendant le traitement des transactions. Tout d'abord, l'utilisateur crée une transaction et l'envoie au réseau. Chaque nœud vérifie si la transaction est conforme aux règles de protocole. S'il est considéré comme correct, le nœud ajoute la transaction à sa liste (mempool), où toutes les transactions non confirmées sont stockées en attente d'être ajoutées à la liste des transactions confirmées.

Au stade du traitement des transactions, les nœuds sélectionnent au hasard les transactions non confirmées dans leur mempool puis les combinent ensemble dans une liste de transactions «pré-approuvées». Ensuite, les transactions seront vérifiées conformément à l'algorithme de consensus pour proposer ces transactions à tous les autres participants du réseau. Les nœuds afficheront les transactions reçues et leur contenu; si la transaction réussit la vérification, la transaction est ajoutée à la liste du nœud. Les listes des transactions de chaque nœud sont finalement envoyées à une liste unique et la plus importante de transactions confirmées et seront considérées comme terminées.

Cependant, les transactions confirmées peuvent être «annulées» en raison d'une transaction alternative, ce qui signifie qu'au stade du règlement, les transactions peuvent être annulées - dans ce cas, elles retournent aux nœuds en tant que transactions non confirmées, en attendant de créer une nouvelle liste de transactions. Le temps de traitement des transactions à l'étape «Règlement» dépend des paramètres d'un seul système. Certains systèmes implémentent l'enregistrement instantané des transactions et leur irrévocabilité, mais certains protocoles ont un achèvement «probabiliste», en ce sens que les transactions peuvent théoriquement être annulées. En pratique, cependant, la probabilité de cette action diminue avec chaque nouvelle transaction ajoutée, car les coûts des nœuds associés à PoW peuvent devenir élevés. Bien que les transactions soient au stade du «règlement», elles ne peuvent pas être considérées comme «terminées».Le processus de règlement des transactions améliore la garantie que les transactions sont répertoriées avec précision sur tous les nœuds participants et non stockées uniquement sur les nœuds locaux, ce qui permet d'éviter les attaques à double dépense.

Certains systèmes mettent en œuvre un système de «point de contrôle» pour limiter la possibilité d'attaques à longue portée. Dans le cas de cette attaque, le nœud crée une chaîne alternative avec ses transactions personnelles (qui ne sont stockées que par lui), ces transactions n'apparaissent pas sur le réseau, mais sont immédiatement envoyées aux nœuds au stade du «règlement» pour forcer d'autres nœuds à les remplacer par ses transactions locales. Les «points de contrôle» sont des blocs qui ne seront jamais annulés ou remplacés. Du fait des points de contrôle, la «portée» de l'attaque est réduite. Cependant, les jalons augmentent le risque de fourche.

Tableau 8. Propriétés de transaction confirmées

Niveau de données

Le niveau de protocole détermine le fonctionnement du système et les règles à suivre. La couche réseau met en œuvre les principes sous-jacents du protocole. Ensemble, la couche de protocole et le réseau forment la base de la couche de données, qui s'accumule au fil du temps à mesure que les transactions sont écrites dans la liste des enregistrements confirmés.

Opérations

Le composant opérations comprend tous les processus par lesquels les participants interagissent avec le système.

Sources de données

Le processus d'entrée concerne une source ou une méthode d'obtention de données pour un protocole. Les sources de données peuvent être internes ou externes, ce qui peut refléter l'interaction active des utilisateurs avec le système, un changement de l'état du protocole provoqué par un processus système interne ou reçu de l'extérieur (par exemple, une transaction envoyée à partir d'un autre protocole) ou un contrat intelligent.

Nous définissons les sources d'entrée internes comme tout enregistrement ou transaction créé par l'utilisateur ou en raison du résultat de l'interaction de l'utilisateur avec le protocole. Les sources d'entrée externes, en revanche, sont le résultat de l'entrée d'autres systèmes qui interagissent avec le protocole, mais qui, en principe, sont séparés de la plate-forme sous-jacente (c'est-à-dire qu'ils sont dépendants ou interagissent). Les protocoles hybrides permettent aux utilisateurs de transférer des transactions en utilisant les «canaux de paiement - canal d'État» à tout moment, cependant, le développement de ces méthodes est encore au stade initial.

Tableau 9. Transactions exécutables du logiciel des formulaires de saisie de données





Tous les changements de niveau de données ne sont pas le résultat direct d'une entrée interne ou externe. Certains changements dans le système se produisent en raison de l'exécution d'instructions de code. Un exemple frappant est celui des contrats intelligents. Lors de l'exécution du code de programme intégré, l'état du réseau change dans le protocole, par exemple, une transaction se produit, qui est enregistrée dans la liste des confirmées. Certains systèmes DLT ne prennent en charge que le langage de script (script). Par exemple, Bitcoin Script, il fonctionne dans un langage de script simple qui vous permet de créer des programmes simples et limités. Ces systèmes sont appelés - sans état. Ethereum (Solidity), Tezos (Michelson) et EOS (WebAssembly) - ces systèmes prennent en charge les langages de programmation Turing-complets pour développer des contrats intelligents complexes, tandis que Bitcoin et Monero utilisent un langage de script,ce qui permet des opérations limitées.

Tableau 10. Propriétés des transactions exécutées par logiciel L'



exécution réelle des calculs L'

endroit où le programme s'exécute détermine l'endroit où les calculs ont lieu. En règle générale, le lieu d'exécution peut être à l'intérieur du réseau - en chaîne ou hors chaîne (en dehors du réseau). Des calculs en chaîne sont effectués à chaque nœud. Cet environnement peut varier d'une simple machine virtuelle, en tant que langage de script, ou être complexe (EVM - machine virtuelle Ethereum), ce qui garantit l'exécution de programmes Turing-complete. Les contrats intelligents dans la chaîne sont lancés par chaque nœud du réseau et, par conséquent, sont souvent appelés «auto-exécutables».

Le calcul hors chaîne est effectué dans un environnement externe au protocole. L'événement qui exécute le code du programme se produit en chaîne et les calculs ont lieu dans un autre système, sans charger le réseau principal. Il existe également un système de lancement d'applications hybride (hybride), par exemple Plasma in Ethereum. Ou, par exemple, Cosmos, où le réseau principal sert de «centre», mais les calculs eux-mêmes ont lieu dans les réseaux subsidiaires.

Tableau 11. Propriétés d'exécution des transactions logicielles

Composant de journal

Les références

À partir du moment où les utilisateurs commencent à interagir avec le système DLT, le journal est mis à jour au fil du temps. Cependant, un magazine est une abstraction. Tous les processus qui se produisent dans le système DLT sont liés à un protocole spécifique. Par exemple, un protocole axé sur les paiements électroniques devrait contenir des informations sur les actifs détenus par des utilisateurs spécifiques. D'un autre côté, un système DLT, qui inclut des contrats intelligents, doit avoir sa propre machine virtuelle qui implémente l'exécution du code du programme. Le concept de magazine est donc une abstraction.

Types de liens

Il existe quatre types de données sources: les données endogènes, exogènes, hybrides et auto-référencées.

Les liens endogènes (internes) renvoient à des données qui suivent les informations sur les variables «natives» du système. Par exemple, dans Bitcoin, une variable de référence endogène est utilisée pour suivre le nombre de bitcoins que les utilisateurs ont à un moment donné. Cette variable interne est mise à jour lorsque l'utilisateur envoie et reçoit des bitcoins vers d'autres adresses. Un lien exogène (externe) fait référence aux données qui suivent les informations sur les variables qui existent en dehors du système. La référence hybride fait référence aux données qui ont des caractéristiques à la fois endogènes et exogènes. Il existe encore un quatrième type, qui n'est ni endogène, ni exogène, et non hybride: c'est un type de données neutre ou vide - c'est un lien autoréférentiel. Par exemple, un contrat intelligent n'est qu'un morceau de code,qui peut être effectuée sous certaines conditions. Bien qu'un contrat intelligent puisse nécessiter des informations sur des variables système externes ou internes, le code lui-même n'a pas de lien interne vers quoi que ce soit en dehors de lui (un «lien vide»).

Tableau 12. Types de liens et leur signification

Conclusion

Ce travail vise à déterminer si l'objet analysé est un système DLT. Les résultats obtenus sont bien adaptés à l'analyse comparative de différents projets, à partir de la structure de gestion, pour finir par la définition des liens auxquels se réfèrent les transactions.