(1) Justification de la conception
Cardano a été conçu comme une blockchain résiliente et durable en utilisant les principes fondamentaux de sécurité, d’évolutivité et d’interopérabilité. Fondamentalement, il a été conçu comme un système de preuve de participation, ce qui signifie qu’il est sans aucun doute plus efficace, par ordre de grandeur, que la preuve de travail. Surtout, notre protocole révolutionnaire de consensus de preuve de participation Ouroboros s’est avéré avoir les mêmes garanties de sécurité que la preuve de travail.
Les méthodes formelles, telles que les spécifications mathématiques, les tests basés sur les propriétés et les preuves, sont le meilleur moyen de fournir des systèmes logiciels à haute assurance et de donner confiance aux utilisateurs pour la gestion des fonds numériques. Cardano a été construit en utilisant des méthodes formelles pour obtenir de solides garanties sur l’exactitude fonctionnelle des composants de base du système.
La sécurité est l’un des principes fondateurs de notre blockchain. Cardano est écrit en Haskell, un langage de programmation fonctionnel sécurisé qui encourage la construction d’un système utilisant des fonctions pures. Cela conduit à une conception où les composants sont facilement testables isolément. De plus, les fonctionnalités avancées de Haskell nous permettent d’utiliser toute une gamme de méthodes puissantes pour garantir l’exactitude du code, telles que la base de l’implémentation sur des spécifications formelles et exécutables, des tests approfondis basés sur les propriétés et l’exécution de tests en simulation.
Pour que Cardano fournisse une infrastructure résiliente à l’échelle mondiale, elle doit pouvoir évoluer au même niveau que les systèmes financiers existants. Même si nous avons conçu Cardano en gardant à l’esprit l’efficacité des ressources, la mise à l’échelle reste un problème fondamental pour les systèmes de blockchain de toutes sortes. Pour trouver une solution au problème de mise à l’échelle, nos chercheurs ont inventé notre solution de scalabilité Hydra, un protocole qui peut être exécuté sur Cardano, permettant le traitement des transactions et des contrats intelligents en dehors de la chaîne principale. Cela multipliera la capacité du système global par une multitude.
L’ingénierie des performances a été utilisée pour évaluer si les décisions de conception nous aidaient à nous rapprocher des objectifs de résilience, de performance et d’évolutivité. L’ingénierie des performances des systèmes distribués a été appliquée pour anticiper et atténuer les problèmes associés aux opérations à long terme, continues et évolutives dans un environnement ouvert réel.
Un autre objectif majeur de la conception de Cardano est de réduire la centralisation tout en travaillant activement contre les incitations économiques qui conduiraient le système vers la centralisation. Dès que vous avez des pools de participations, vous avez une incitation économique pour que ces pools se développent, il était donc important de rendre moins attrayant qu’un pool de participations devienne trop grand. Il est plus rentable d’avoir un petit nombre de grandes piscines, qu’un grand nombre de petites piscines. Cardano a été conçu pour aller à l’encontre de l’incitation économique où les grands pools dominent le système, en rendant moins attrayant le fait qu’un pool devienne trop grand. Ceci a été réalisé en modifiant la formule de récompense. Dans un système naïf, les récompenses totales d’un pool seraient proportionnelles à sa mise, donc plus il grossit, mieux c’est. À Cardano, si un pool attire plus de mises qu’un certain seuil (1/k, où k est un paramètre configurable), sa récompense n’augmentera plus. Donc, si tout le monde agit dans son propre intérêt pour maximiser ses récompenses, vous vous attendez à k pools de taille à peu près égale.
La capacité d’interagir avec d’autres systèmes, ou l’interopérabilité, est une caractéristique de conception fondamentale de Cardano. L’une des innovations de conception actuelles de Cardano est l’utilisation de sidechains, ce qui signifie que vous pouvez compartimenter le système et permettre l’interopérabilité au sein de la plate-forme blockchain. Les données peuvent être conservées hors de la chaîne principale dans ce qu’on appelle une sidechain. Plusieurs sidechains peuvent s’exécuter simultanément, donc si une partie échoue, le reste du système n’échoue pas, car il est maintenu séparément. Cela se traduit par une plus grande assurance et fiabilité au sein de la blockchain. En utilisant des sidechains, vous pouvez transférer des actifs entre des blockchains parallèles qui fonctionnent selon différentes règles, mécanismes ou langages et façons d’utiliser le réseau.
La gouvernance est également au cœur de la conception de Cardano pour assurer la durabilité et l’adaptabilité du système. Une stratégie de gouvernance bien développée permettra un financement efficace et démocratique du développement à long terme de Cardano. Le système de trésorerie de Cardano est actuellement conçu comme un mécanisme de financement durable pour maintenir Cardano. Il sera contrôlé par la communauté et permettra un processus décisionnel décentralisé et collaboratif pour soutenir le développement et la maintenance de Cardano. Diverses sources de financement potentielles seront utilisées pour remplir la trésorerie de manière constante, telles que l’agrégation de pièces nouvellement frappées, un pourcentage des récompenses du pool de mises, des frais de transaction et des dons ou des œuvres caritatives. Les fonds étant accumulés dans un processus itératif, il sera possible de financer le développement du projet et de payer les propositions d’amélioration. En outre, des propositions d’amélioration de Cardano (CIP) seront également fournies pour favoriser et formaliser les discussions autour des nouvelles fonctionnalités et de leur développement au sein de la communauté.
Au cœur de la trésorerie se trouve un mécanisme de vote démocratisé où les détenteurs d’ADA décideront eux-mêmes de la manière dont les fonds sont alloués en votant sur les propositions de financement. Cela garantira que les décisions sont prises par un vote démocratique plutôt que par une poignée de parties prenantes. Ce système de vote influencera les décisions telles que les initiatives de financement, l’autorisation des mises à jour du protocole et le déploiement de toutes les mises à jour constitutionnelles telles que les modifications du processus de prise de décision ou la frappe de nouveaux jetons.
(2) Phases et époques de développement sur Cardano
Le développement de Cardano suit une feuille de route bien définie et clairement communiquée. Solidement basé sur des recherches universitaires et des tests rigoureux, ce processus a abouti à une chaîne sans panne.
Cardano a traversé plusieurs phases et époques de développement rendues possibles par les événements de combinateur hard fork. Les concepts suivants sont expliqués ci-dessous :
- Phase de développement - une collection de haut niveau de fonctionnalités décrites sur la feuille de route Cardano.
- L’ère du grand livre - une collection de fonctionnalités de grand livre introduites avec un hard fork. À partir d’Alonzo, il est prévu que les époques portent le nom de mathématiciens et d’informaticiens dans l’ordre a, b, c.
- Hard fork intra-ère - un petit changement sémantique ciblé du grand livre nécessitant un hard fork.
- Mécanisme de consensus - une collection de fonctionnalités de consensus introduites avec un hard fork. Historiquement, ceux-ci ont porté le nom « Ouroboros ».
- Protocole de grand livre - une collection de fonctionnalités de grand livre entre la couche de consensus et la couche de grand livre, caractérisée grossièrement par la validation d’en-tête de bloc.
Phases de développement
Les phases de développement de Cardano incluent Byron, Shelley, Goguen, Basho et Voltaire - tous nommés d’après des poètes à l’exception de Goguen, un informaticien.
Byron s’est concentré sur l’établissement de la fondation, Shelley sur la décentralisation. Goguen a introduit des contrats intelligents et un support d’actifs natif, Basho - des améliorations d’évolutivité, et, enfin, Voltaire concerne la gouvernance et la prise de décision décentralisées.
Ères du grand livre
Il y a plusieurs époques dans l’évolution de Cardano. Chaque époque se réfère aux règles du grand livre. Par exemple, quels types de transactions et quelles données sont stockées dans le grand livre, ou la validité et la signification des transactions.
- Époques Byron et Shelley
L’évolution du réseau principal Cardano a commencé avec les règles du grand livre Byron. Le réseau principal a subi un hard fork fin juillet 2020 pour passer des règles de Byron aux règles du registre Shelley. Il s’agissait d’une réimplémentation complète de Cardano, qui a permis deux changements fondamentaux : la prise en charge de plusieurs ensembles de règles de grand livre et la gestion du processus de hard fork consistant à passer d’un ensemble de règles à l’autre. En d’autres termes, la nouvelle implémentation pouvait prendre en charge à la fois les règles Byron et les règles Shelley, ce qui signifiait que, lorsqu’elle était déployée sur le réseau principal au début de 2020, l’implémentation était entièrement compatible avec les règles Byron. Cela a permis une transition en douceur de l’ancienne à la nouvelle implémentation. Une fois que tous les utilisateurs de Cardano ont mis à niveau leurs nœuds vers la nouvelle implémentation, il est devenu possible d’invoquer l’événement de combinateur hard fork et de passer aux règles Shelley.
- Époques Allegra, Mary et Alonzo
Les époques Allegra, Mary et Alonzo font toutes partie de la phase de développement de Goguen.
En commençant par Goguen, l’équipe du grand livre a introduit la notion d’ère dans le code du grand livre. Les règles du registre Shelley sont alors devenues «l’ère Shelley».
Étant donné que les fonctionnalités de Goguen ont été implémentées par étapes, chaque ensemble de fonctionnalités a été introduit avec un hard fork différent, il y a donc eu plusieurs époques de grand livre :
Allegra : introduction de la prise en charge du verrouillage des jetons
Mary : a apporté des jetons natifs et des fonctionnalités multi-actifs à Cardano
Alonzo : introduction de la prise en charge des contrats intelligents
Les noms Allegra et Mary ont été choisis pour leur lien avec le poète Percy Shelley et n’étaient destinés qu’à être utilisés comme noms de variables pour une abstraction très spécifique utilisée dans le code du grand livre.
Goguen, la phase de développement du contrat intelligent, était la seule phase qui ne porte pas le nom d’un poète. Ainsi, le nom de l’ère du grand livre qui a introduit les contrats intelligents a été nommé d’après Alonzo Church - la personne qui a inventé le calcul lambda (Plutus Core utilise une variante du système F).
À l’avenir, les équipes ont décidé d’utiliser des noms dans l’ordre a, b, c, d’après les personnes qui ont contribué aux mathématiques et à l’informatique. Un manque de cohérence à remarquer est que les époques peuvent utiliser à la fois le prénom et le nom de famille. Ceci est motivé par la concision.
- L’ère Babbage
L’ère du grand livre Babbage a introduit des fonctionnalités telles que les données en ligne, les scripts de référence et les entrées de référence. Cependant, la publication est également connue sous le nom de Vasil, nommé en l’honneur du regretté mathématicien bulgare et ambassadeur de Cardano Vasil Dabov.
hard forks Intra-ère
Une nouvelle ère doit être introduite avec un hard fork, mais le grand livre peut également changer de sémantique lors d’un hard fork contrôlé avec un autre mécanisme - un hard fork intra-ère. Il s’agit d’un détail de mise en œuvre qui implique de remplacer la version principale du protocole mais de ne pas créer une nouvelle ère de grand livre. L’ère Alonzo, par exemple, a connu un hard fork intra-ère en passant de la version majeure du protocole 5 à 6.
Conclusion :
Il est important de comprendre que toutes les modifications sémantiques du réseau Cardano n’impliquent pas le grand livre. Les modifications apportées au protocole de consensus ou à la couche réseau peuvent également nécessiter un hard fork. Il existe également une abstraction entre les couches consensus et grand livre, appelée protocole. La distinction entre les protocoles du grand livre et les ères du grand livre correspond à peu près à la façon dont les en-têtes de bloc sont validés (protocole) par rapport à la façon dont les corps de bloc sont validés (ère). L’ère Shelley utilisait le protocole “Praos transitionnel” (TPraos), qui consistait en Praos combiné à un système de transition pour s’éloigner d’Ouroboros BFT. L’ère Babbage a remplacé TPraos par Praos.
Notez que la version du protocole n’est pas liée aux versions de protocole nœud à nœud et nœud à client. La couche consensus maintient un schéma de gestion des versions pour les requêtes de nœud qui ne correspond pas nécessairement à la version du protocole décrite dans cette présentation.
La version de protocole est également incluse dans chaque en-tête de bloc indiquant la version de protocole maximale que le producteur de bloc est capable de prendre en charge (voir la section 13, Mises à jour logicielles, de la spécification du registre Shelley).
(3) Architecture Cardano
Cette section décrit l’architecture de haut niveau de Cardano, en fournissant des détails sur les composants de base et leurs interactions.
Architecture de haut niveau de Cardano
Composants du système
L’implémentation actuelle de Cardano est hautement modulaire. Il comprend les composants suivants (différents cas d’utilisation de déploiement utiliseront différentes combinaisons de composants) :
- Nœud
- Interface de ligne de commande (CLI)
- Portefeuille Dédale
- Synchronisation de la base de données Cardano
- Serveur API GraphQL (Apollo)
- Serveur SMASH
Nœuds et nœuds distants
Un système de blockchain consiste en un ensemble de nœuds répartis sur un réseau qui communiquent entre eux pour parvenir à un consensus sur l’état du système.
Les nœuds sont responsables de :
- Exécution du protocole Ouroboros
- Valider et relayer les blocs
- Production de blocs (certains nœuds)
- Fournir des informations sur l’état de la blockchain à d’autres clients locaux
Vous ne pouvez faire confiance qu’aux nœuds gérés par vous ou votre organisation. C’est pourquoi Daedalus exécute un nœud en arrière-plan.
Processus de nœud
Le cardano-nœud est le niveau supérieur du nœud et se compose des autres sous-systèmes, dont les plus importants sont le consensus, le grand livre et la mise en réseau avec configuration auxiliaire, CLI, journalisation et surveillance.
Protocole IPC nœud à nœud
L’objectif du protocole de communication inter-processus nœud à nœud (IPC) est de permettre l’échange de blocs et de transactions entre nœuds dans le cadre de l’algorithme de consensus Ouroboros.
Le protocole nœud à nœud est un protocole composite, composé de trois « mini-protocoles » :
- chain-sync : utilisé pour suivre la chaîne et obtenir les en-têtes de bloc.
- block-fetch : utilisé pour obtenir des corps de bloc.
- tx-submission : utilisé pour transférer les transactions.
Ces mini-protocoles sont multiplexés sur une seule connexion TCP (Transmission Control Protocol) de longue durée entre les nœuds. Ils peuvent être exécutés dans les deux sens sur la même connexion TCP pour permettre les paramètres peer-to-peer (P2P).
Le protocole global - et chaque mini-protocole - est conçu pour un environnement sans confiance où les deux parties doivent se protéger contre les attaques par déni de service (DoS). Par exemple, chaque mini-protocole utilise un flux de contrôle piloté par le consommateur, de sorte qu’un nœud ne demande plus de travail que lorsqu’il est prêt, plutôt que d’avoir du travail poussé dessus.
La conception du protocole est modulaire et évolutive : la négociation de version permet de s’accorder sur l’ensemble des mini-protocoles à utiliser, ce qui permet d’ajouter au fil du temps des mini-protocoles supplémentaires ou mis à jour sans causer de problèmes de compatibilité.
IPC nœud-client
L’objectif du protocole IPC nœud-client est de permettre aux applications locales d’interagir avec la blockchain via le nœud. Cela inclut des applications telles que les backends de portefeuille ou les explorateurs de blockchain. Le protocole nœud-client permet à ces applications d’accéder aux données brutes de la chaîne et d’interroger l’état actuel du grand livre. Il offre également la possibilité de soumettre de nouvelles transactions au système.
Le protocole nœud à client utilise la même conception que le protocole nœud à nœud, mais avec un ensemble différent de mini-protocoles et en utilisant des canaux locaux plutôt que des connexions TCP. En tant que tel, il s’agit d’une interface étroite de niveau relativement bas qui n’expose que ce que le nœud peut fournir de manière native. Par exemple, le nœud donne accès à toutes les données brutes de la chaîne mais ne permet pas d’interroger les données sur la chaîne. La tâche de fournir des services de données et des API de niveau supérieur plus pratiques est déléguée à des clients dédiés, tels que cardano-db-sync et le backend du portefeuille.
Le protocole nœud-client se compose de trois mini-protocoles :
- chain-sync : utilisé pour suivre la chaîne et obtenir des blocs
- local-tx-submission : utilisé pour soumettre des transactions
- local-state-query : utilisé pour interroger l’état du grand livre
La version nœud-client de la synchronisation de chaîne utilise des blocs complets, plutôt que de simples en-têtes de bloc. C’est pourquoi aucun protocole séparé de récupération de blocs n’est nécessaire. Le protocole local-tx-submission est similaire au protocole de soumission tx nœud à nœud mais plus simple, et il renvoie les détails des échecs de validation des transactions. Le protocole de requête d’état local fournit un accès de requête à l’état actuel du grand livre, qui contient de nombreuses données intéressantes qui ne sont pas directement reflétées sur la chaîne elle-même.
Interface de ligne de commande (CLI)
L’outil CLI du nœud est le “couteau suisse” du système. Il peut presque tout faire, mais il est assez bas et pas très pratique car il est basé sur du texte et n’a pas d’interface utilisateur graphique (GUI).
L’outil CLI peut :
- Interroger le nœud pour obtenir des informations
- Soumettre des transactions
- Créer et signer des transactions
- Gérer les clés cryptographiques
Portefeuille Dédale
Daedalus est un portefeuille de nœuds complet qui aide les utilisateurs à gérer leur ada et peut envoyer et recevoir des paiements sur la blockchain Cardano. Daedalus se compose d’un frontend de portefeuille et d’un backend. L’interface est l’application graphique que les utilisateurs voient et avec laquelle ils interagissent. Le backend est un processus de service qui surveille l’état du portefeuille de l’utilisateur et effectue tout le « gros du travail », comme la sélection des pièces, la construction des transactions et la soumission. Le backend interagit avec un nœud local via le protocole IPC nœud-client et interagit avec le frontend via une API HTTP. Le backend fournit également une CLI qui permet l’interaction avec le portefeuille. Le backend du portefeuille peut également être utilisé seul - sans Daedalus - via son API. C’est un moyen pratique pour les développeurs de logiciels d’intégrer Cardano à d’autres applications et systèmes.
Nous conseillons aux utilisateurs les plus avancés ayant l’intention d’utiliser Cardano de commencer par Daedalus.
cardano-db-sync
Le nœud cardano ne stocke que la blockchain elle-même et les informations associées nécessaires pour valider la blockchain. Ce principe de conception consiste à minimiser la complexité du code et à réduire les coûts de calcul et l’utilisation des ressources, afin de maintenir les interfaces locales du nœud aussi minimes que possible et d’utiliser des clients externes pour fournir une variété d’interfaces pratiques et de fonctionnalités supplémentaires. En particulier, le nœud ne fournit pas d’interface de requête pratique pour les informations historiques sur la blockchain. Ce service de données est fourni par un composant distinct utilisant une base de données SQL (Structured Query Language).