Évolution de Kadena, la première véritable blockchain privée

George Samman est un consultant et conseiller en blockchain et en Cryptomonnaie qui a récemment co-écrit un rapport fondateur sur l'architecture blockchain avec KPMG.

Ici, Samman explique comment l'algorithme de consensus obtenu par Raft a finalement été corrigé par son parent éloigné, Kadena.

Cet article traite de la blockchain de Kadena. Elle utilise ScalableBFT pour offrir des performances élevées (8 000 à 12 000 transactions par seconde) avec une réplication et une distribution complètes à des échelles auparavant impossibles (capacité de plus de 500 nœuds participants).

Ceci, associé au modèle de sécurité multicouche et au hachage incrémental, permet de créer une blockchain véritablement robuste. Basé sur Raft et Juno, Kadena intègre un langage de contrat intelligent complet (Pact) dans sa blockchain, qui peut être exécuté sous forme de transactions publiques (texte brut) ou privées (chiffrées à double cliquet).

Il s’agit d’un grand pas en avant dans le domaine de la blockchain, représentant peut-être une nouvelle génération de Technologies blockchain entièrement par son introduction de l’idée de « déterminisme omniprésent ».

Tout comme Bitcoin, la blockchain de Kadena est étroitement intégrée. Comprendre ses capacités et leurs implications nécessite un travail considérable. C'est pourquoi j'ai divisé cet article en trois parties : 1) Introduction et Radeau, 2) Les prédécesseurs de Kadena –Tangaroa&Junon, et 3) Blockchain de Kadena – ScalableBFT, Pact et Déterminisme Pervasive.

Partie 1 : Introduction et algorithme de consensus Raft

L’histoire derrière Kadena est une étude de cas intéressante dans le nouveau domaine des algorithmes de consensus blockchain et de l’informatique distribuée.

Kadena est un « parent éloigné » du Algorithme de consensus RaftLe mécanisme de consensus Raft a été suivi parTangaroa(un radeau tolérant aux failles byzantines (BFT)) et le projet JP MorganJunon(une branche de Tangaroa), dont aucun n'est plus en développement actif.

Le nouveau Quorum blockchain de JP Morgan

est très différent de Juno et utilise une fusion d'idées issues des chaînes latérales et Ethereum : les contrats intelligents publics sont autorisés sur la blockchain en plus des contrats privés, qui sont représentés sous forme de hachages cryptés et répliqués via des canaux secondaires.

Kadena est le Juno nouvelle génération. Il utilise un nouveau protocole, apparenté à celui-ci, appelé ScalableBFT, issu du code open source du projet Juno et développé par les deux développeurs clés de Juno. Avant de plonger dans le vif du Kadena, un bref historique et une description de Raft et de ses prédécesseurs Kadena .

Consensus sur le radeau

L'algorithme de consensus Raft est un système basé sur un leader unique pour la gestion d'un journal répliqué. Il utilise une architecture de machine à états répliquée et produit un résultat équivalent à Paxos, mais structurellement différent.

L'algorithme de consensus assure la cohérence du journal répliqué. Dans ce modèle, le leader effectue la majeure partie du travail : il met à jour le journal, valide les transactions et gère le cluster. Le consensus Raft garantit un ordre et une réplication stricts des messages, quel que soit leur contenu.

Un nouveau leader est élu à l'aide de délais d'expiration aléatoires, déclenchés si un suiveur ne reçoit aucune communication de sa part avant le déclenchement du délai. Ces délais sont appelés « pulsations ».

Si le suiveur ne reçoit aucune communication pendant cette période, il devient candidat et lance une élection. Le candidat qui obtient les votes de la majorité de l'ensemble du cluster (nœuds du réseau) devient le nouveau leader. Les leaders fonctionnent généralement jusqu'à leur extinction. Des pulsations sont envoyées pour s'assurer que le leader est toujours là ; en l'absence de réponse, une nouvelle élection a lieu.

Les étapes suivantes permettent à Raft de parvenir à un consensus :

• Un cluster de serveurs Raft est démarré, chaque nœud étant lancé en tant que « suiveur ». À terme, un nœud expire, devient candidat, obtient la majorité des voix et devient leader.
• Chaque nœud stocke un journal contenant les commandes. Le rôle du leader est d'accepter les nouvelles commandes, de les classer rigoureusement dans son journal, de les répliquer auprès de ses suiveurs et enfin d'indiquer à ces derniers quand valider les journaux qu'ils ont répliqués. L'algorithme de consensus garantit ainsi que les journaux de chaque serveur sont dans le même ordre.
• Les journaux sont validés lorsqu'ils ont été répliqués sur la majorité des nœuds. Le leader collecte le nombre de réplications et, lorsqu'une majorité est détectée, valide ses propres entrées de journal et informe ses suiveurs de faire de même.
• Lors de la validation, la commande de chaque entrée de journal est évaluée par une machine à états. Comme Raft est indifférent au corps de la commande, toute machine à états peut traiter les entrées validées. De plus, le consensus garantit que l'exécution des commandes se déroule toujours dans l'ordre d'apparition des commandes dans le journal, qui est strictement ordonné.
• Les machines d’état resteront cohérentes tant que les exécutions de commandes seront déterministes.
• Lorsqu'un client envoie une commande à ONEun des serveurs, ce dernier la transmet au serveur leader ou en devient le leader. Ce dernier collecte la nouvelle commande, lui attribue un index de journal, l'encapsule dans une entrée de journal et l'ajoute à la partie non validée de son journal.
• Chaque fois que le leader possède des entrées non validées, il réplique cette partie du journal vers ses suiveurs. Lorsqu'il est informé de la réussite de la réplication par la majorité du cluster, il valide les nouvelles entrées et ordonne à ses suiveurs de faire de même.
• Chaque fois qu'une nouvelle entrée de journal est validée, un consensus est atteint. Elle est ensuite évaluée par la machine d'état de chaque serveur.
• À partir de ce point, Raft est terminé et les implémenteurs peuvent décider comment gérer les réponses ; répondre au client ou attendre que le client demande le résultat.

Les réponses au client sont généralement asynchrones.

Le protocole de consensus Raft est simplement un algorithme de consensus. Il n'a aucune notion de consensus et est, par défaut, entièrement ouvert à tout client émettant des commandes. La seule restriction de participation qu'il impose concerne les nœuds existants à un instant T.

De plus, le leader dispose d'une autorité absolue sur le cluster et ordonne à ses suiveurs de se répliquer et de valider. Il ne prend pas en compte les attaques byzantines ; il doit uniquement gérer les pannes, car les nœuds sont supposés altruistes.

Partie 2 : Les prédécesseurs de Kadena – Tangaroa et Juno

Tangaroa : Le premier pas vers un BFT Raft

Tangaroa est une variante tolérante aux pannes byzantines (BFT) de l'algorithme de consensus Raft inspiré de l'algorithme Raft original et de l'algorithme de tolérance aux pannes byzantines pratiques (PBFT).

La tolérance aux pannes byzantines fait référence aux défaillances de classe causées par des nœuds malveillants attaquant le réseau. Si certains nœuds tombent en panne, il est impératif que le réseau continue de fonctionner sans interruption.

Dans Raft standard, vous devez répliquer une entrée de journal sur la majorité des nœuds du cluster avant de la valider. Pour les algorithmes de consensus BFT, dont Tangaroa, la taille de cluster requise est d'au moins 2f + 1, où f est le nombre de pannes tolérées (nœuds plantés et compromis inclus). Le consensus est obtenu par un vote majoritaire du cluster ; si f <= 3, alors la taille du cluster est de 7 et le nombre de nœuds non byzantins est de 4. Certains protocoles BFT peuvent même exiger 3f + 1.

Un leader byzantin peut décider d'augmenter arbitrairement l'index de validation d'autres nœuds avant que les entrées de journal ne soient suffisamment répliquées, provoquant ainsi des violations de sécurité en cas de défaillance ultérieure des nœuds. Tangaroa transfère la responsabilité de la validation au leader, et chaque nœud peut vérifier lui-même qu'une entrée de journal a été répliquée en toute sécurité sur un quorum de nœuds et que ce quorum s'accorde sur un ordre.

Tangaroa permet aux clients d'interrompre le leadership actuel en cas d'échec, de la même manière que d'autres algorithmes de consensus BFT permettent au client de se comporter comme un oracle de confiance pour destituer certains nœuds. Cela permet à Tangaroa d'empêcher les dirigeants byzantins d'affamer le système, tout en faisant entièrement confiance au client.

Élection du chef et étapes

Tangaroa utilise Raft comme base de consensus ; il n'y a donc qu'un seul leader. Dans Tangaroa, comme dans Raft, chaque nœud est dans ONEun des trois états suivants : leader, suiveur ou candidat.

Comme pour Raft, chaque nœud démarre en tant que suiveur, dont ONEun expirera et déclenchera une élection. Le vainqueur de l'élection occupera le poste de leader pour le reste du mandat ; les mandats prendront fin avec l'élection d'un nouveau leader. Il arrive qu'une élection aboutisse à un vote partagé, et le mandat se terminera sans leader. Dans ce cas, un suiveur expirera à nouveau (les délais d'expiration sont réinitialisés lors d'un vote ou d'une élection) et le processus de vote recommencera.

Pour lancer une élection, un follower incrémente son terme actuel et envoie RequestVote (RV)Appel de procédure à distance (RPC)En parallèle, chaque nœud du cluster sollicite son vote. Les RPC utilisés par Tangaroa sont similaires à ceux de Raft, à la différence que chaque RPC est signé et validé via des signatures PPK.

Les RPC permettent un échange de données entre différents ordinateurs résidant sur un réseau et les signatures permettent aux nœuds récepteurs de vérifier quel nœud a envoyé le RPC en plus de permettre à n'importe quel nœud de transmettre le RPC de n'importe quel autre nœud à tout moment.

Lorsqu'un nœud Tangaroa reçoit un RPC RV avec une signature valide, il accorde immédiatement un vote, uniquement s'il n'a pas de leader (uniquement au démarrage). Sinon, il lance le processus que Tangaroa appelle « LazyVote ».

L'objectif d'un vote différé est d'empêcher les adeptes non byzantins d'élire un nouveau leader lorsque celui-ci n'est pas défectueux ; sans vote différé, un nœud byzantin pourrait déclencher des élections répétées à tout moment et affamer le système. Lorsqu'un adepte reçoit un nouveau vote différé, il l'enregistre et attend que toutes les conditions suivantes soient remplies :

a) Le déclencheur d'expiration de l'élection du suiveur se déclenche avant qu'il ne reçoive un signal de son leader actuel. Si un signal est reçu, le vote différé est annulé.

b) La nouvelle durée du VR est supérieure à sa durée actuelle.

c) L'expéditeur de la Request est un candidat éligible (signature PPK valide et le client n'a T banni le nœud).

d) Le nœud recevant le RV n’a pas voté pour un autre leader pour le mandat proposé.

e) Le candidat partage un préfixe de journal avec le nœud contenant toutes les entrées validées. Un nœud rejette systématiquement la Request s'il reçoit encore des messages de pulsation du leader actuel, et ignore le RPC RequestVote si le terme proposé a déjà commencé.

Si un RequestVote est valide et pour un nouveau mandat, et que le candidat dispose d'un journal suffisamment à jour, mais que le destinataire reçoit toujours des pulsations du leader actuel, il enregistrera son vote localement, puis enverra une réponse de vote si le nœud lui-même subit un délai d'expiration d'élection ou entend d'un client que le leader actuel ne répond pas.

Avec le vote paresseux, un nœud n'accorde de vote à un candidat que s'il estime que le leader actuel est fautif. Cela empêche les nœuds qui lancent des élections inutiles d'obtenir les votes nécessaires pour devenir leader et de priver le système de ressources.

Les nœuds attendent d'estimer qu'une élection est nécessaire avant de voter. Une fois le vote envoyé, le nœud met à jour son numéro de mandat. Cependant, il ne présume pas que le nœud pour lequel il a voté a remporté l'élection et rejette les RPC AppendEntries (AE) du candidat si aucun d'entre eux ne contient de votes prouvant sa victoire. Les AE servent à la fois de signaux de pulsation et de transporteurs de nouvelles entrées de journal à répliquer. Le candidat reste dans cet état jusqu'à ce que ONEun des trois événements suivants se produise :

a) Il remporte l'élection en recevant la majorité des voix du groupe. Un candidat doit conserver ces votes – RequestVoteResponse (RVR) RPC – pour une distribution ultérieure.

b) Un autre nœud s'établit comme leader

c) Une période de temps s'écoule sans vainqueur (c'est-à-dire qu'il y a un autre délai d'attente pour les élections)

Un candidat qui remporte l'élection se promeut alors au rang d'État leader et envoie un message de pulsation AE contenant les votes qui l'ont élu et le numéro de mandat mis à jour afin d'asseoir son autorité et d'empêcher de nouvelles élections. Les votes signés empêchent efficacement un nœud byzantin de se promouvoir arbitrairement comme chef d'un mandat supérieur. De plus, chaque partisan effectue un recomptage du vote majoritaire susmentionné, validant et comptant chaque vote transmis par le nouveau leader afin de vérifier indépendamment la validité de l'élection.

Gouvernance

Comme Raft, Tangaroa utilise des délais d'expiration aléatoires pour déclencher l'élection des chefs. Le chef de chaque mandat envoie périodiquement des messages de pulsation (RPC AE vides) pour maintenir son autorité. Si un membre ne reçoit aucune communication d'un chef pendant une période aléatoire (le délai d'expiration de l'élection), il devient alors candidat et lance une nouvelle élection.

Outre les élections spontanées déclenchées par les suiveurs, Tangaroa permet également l'intervention du client : lorsqu'un client constate l'absence de progression avec un leader pendant une période appelée « timeout », il diffuse des RPC UpdateLeader à tous les nœuds, leur demandant d'ignorer les prochains messages de pulsation provenant de ce que le client considère comme le leader actuel du terme en cours. Ces suiveurs ignoreront les messages de pulsation du terme en cours et expireront comme si le leader actuel avait échoué, déclenchant ainsi une nouvelle élection.

Données reçues

Les données (nouvelles commandes) proviennent des clients du cluster Raft, qui envoient des requêtes au leader. Ce dernier réplique ces requêtes vers le cluster et répond au client lorsque le quorum est atteint dans le cluster pour cette Request.

La nature d'une « Request» dépend du système. Le mode de stockage des données dépend également du système. Il est important que l'état persiste sur le disque, afin que les nœuds puissent récupérer et mémoriser les informations validées (nœuds pour lesquels ils ont voté, entrées de journal validées, ETC). Sans cela, le protocole ne fonctionnera pas.

Tangaroa ajoute BFT à l'évolution de Raft

Junon

Le projet JP Morgan Juno est un fork de Tangoroa et était une preuve de concept qui a pu faire évoluer Tangaroa pour inclure jusqu'à 50 nœuds et augmenter la vitesse de transaction jusqu'à 5 000 transactions par seconde.

L'équipe JPM derrière Juno a vu le potentiel que représentait une approche de type Tangaroa – une blockchain privée haute performance. Ils ont itéré sur l'idée pendant un an et ont ouvert le projet en février 2016. Ils ont ajouté un langage de contrat intelligent, corrigé quelques erreurs de conception et ont réussi à obtenir une augmentation de performance de 10 fois, ce qui a permis de voter pour changer le nombre de nœuds pendant que le système était en cours d'exécution. Juno permettait l'ajout et la suppression de nœuds, et était un système distribué autorisé dans lequel tous les nœuds du réseau étaient connus.

Les étapes du mécanisme et le processus d'élection du leader sont identiques à ceux de Tangaroa (voir ci-dessus). De même, une transaction est considérée comme active une fois entièrement répliquée et enregistrée dans le journal.

Le leader décide de l'ordre des commandes et chaque nœud valide. Chaque nœud décide indépendamment du moment où il doit valider une entrée de journal, en fonction des preuves reçues des autres nœuds. Chaque entrée de journal est validée individuellement et hachée progressivement par rapport à l'entrée précédente. Il faut environ 5 ms pour qu'une entrée de journal passe de la réception de l'entrée par le leader à l'obtention d'un consensus complet et à la latence réseau.

Partie 3 : La blockchain de Kadena – ScalableBFT, Pact et déterminisme omniprésent

Cryptographie

Contrairement à Raft, chaque réplique d'un système BFT Raft (une famille d'algorithmes incluant Tangaroa, Juno et ScalableBFT de Kadean) calcule un hachage cryptographique à chaque ajout d'une nouvelle entrée à son journal. Le hachage est calculé sur le hachage précédent et sur la nouvelle entrée de journal ajoutée.

Un nœud peut signer son dernier hachage pour prouver qu'il a répliqué l'intégralité d'un journal, et les autres serveurs peuvent le vérifier rapidement grâce à la signature et au hachage. Les nœuds et clients BFT Raft signent toujours avant d'envoyer des messages et rejettent ceux qui ne contiennent pas de signature valide.

Les radeaux BFT utilisent le hachage incrémentiel, ce qui permet aux nœuds de s'assurer que le contenu et l'ordre des journaux des autres nœuds correspondent aux leurs. Grâce à ces informations, les nœuds peuvent valider indépendamment et en toute sécurité des entrées de journal, car le contenu et l'ordre des journaux des autres nœuds sont attestés par des hachages incrémentiels correspondants.

BFT Rafts utilise largement les signatures numériques pour authentifier les messages et vérifier leur intégrité. Cela empêche un leader byzantin de modifier le contenu des messages ou de les falsifier, et protège le cluster contre un grand nombre d'attaques byzantines.

Consensus

Dans Raft, un leader est élu via des délais d'expiration aléatoires qui incitent un suiveur à se proposer comme candidat et à Request des votes. ScalableBFT effectue la même opération, mais de manière cryptographiquement sécurisée. Par exemple, si un leader devient inaccessible, un délai d'expiration déclenche une nouvelle élection, mais le processus électoral est robuste face aux nœuds byzantins déclarant des élections. ScalableBFT corrige les problèmes rencontrés par Juno et Tangaroa concernant le vote paresseux.

Les seules capacités uniques du leader sont : 1) l'ordonnancement des nouvelles transactions avant leur réplication et 2) la réplication des nouvelles transactions vers les nœuds suiveurs. À partir de ce moment, tous les nœuds prouvent indépendamment la validité du consensus et l'intégrité des transactions individuelles.

La suppression de la participation anonyme est une exigence de conception des blockchains privées, ce qui a permis de remplacer le minage par un mécanisme de consensus BFT haute performance. Le principal atout de ScalableBFT pour la famille des Rafts BFT est sa capacité à évoluer jusqu'à des milliers de nœuds sans réduire le débit du système.

Chaque transaction est répliquée sur chaque nœud. Lorsqu'une majorité de nœuds a répliqué la transaction, celle-ci est validée. Les nœuds collectent et distribuent des informations (hachage incrémentiel) sur ce qu'ils ont répliqué et les utilisent pour décider indépendamment du moment de la validation (plus de 50 % des autres nœuds leur envoient des hachages incrémentiels pour les transactions non validées qu'ils acceptent).

Le principe repose sur un vote majoritaire sur les transactions à valider. Valider une transaction ne signifie T qu'elle sera exécutée, mais simplement qu'elle a été répliquée définitivement par la majorité du cluster. Les transactions erronées, comportant des erreurs ou des signatures incorrectes, sont également répliquées, et le consensus a pour mission d'assurer une réplication parfaitement ordonnée.

La validation d'une transaction permet à chaque nœud d'évaluer chaque transaction de manière indépendante (analyse, déchiffrement, validation du Crypto, exécution, ETC). Chaque transaction est associée à une sortie, allant d'une « mauvaise Crypto» à la sortie de la couche de contrat intelligent (qui peut également être une erreur).

Enfin, outre le fait que le leader réplique les nouvelles transactions sur chaque nœud, les nœuds sont plus ou moins indépendants. Au lieu de se « synchroniser », ils diffusent le message « J'ai répliqué jusqu'à l'index de journal N et il a un hachage incrémentiel de H » au cluster et collectent ces informations auprès des autres nœuds. En fonction des résultats des autres nœuds, chaque nœud peut décider indépendamment si le cluster a répliqué au-delà de la barre nécessaire à la validation (une réplication majoritaire pour certains index de journal N non encore validés).

Voici la subtilité : le hachage incrémentiel implique la réplication de toutes les transactions précédentes. Si le leader réplique 8 000 nouvelles transactions (ce qu'il fait actuellement), chaque nœud n'a plus qu'à distribuer et collecter les preuves de la dernière transaction de ce lot, car cela implique une réplication correcte des transactions précédentes. Au lieu d'envoyer 8 000 messages (un pour chaque transaction) attestant d'une réplication correcte, les nœuds ne discutent que de la dernière transaction.

C'est pourquoi Kadena avait besoin de tant de pipelines, car l'équipe a compris comment valider 8 000 transactions à la même vitesse que la validation d'une seule transaction.

ScalableBFT représente une avancée majeure dans le domaine du consensus BFT. Il s'agit du premier et unique mécanisme de consensus BFT déterministe capable de s'étendre à des centaines de nœuds grâce à une réplication et un chiffrement complets. ScalableBFT propose également un modèle de sécurité unique, appelé déterminisme omniprésent, qui assure la sécurité non seulement au niveau des transactions, mais également au niveau du consensus, tout en chiffrant chaque transaction grâce au protocole Noise (voir ci-dessous).

Kadena utilise le consensus déterministe

Le mécanisme de consensus est déterministe si le processus de consensus est entièrement spécifié dans le protocole et qu'il n'utilise pas d'aléatoire. Comme indiqué précédemment, Raft, par exemple, utilise des délais d'expiration aléatoires pour déclencher des élections lorsqu'un leader tombe en panne (étant donné que le leader ne peut T communiquer « Je vais planter », un délai d'expiration se déclenche pour demander à un nœud de vérifier si le leader est en panne). Cependant, l'élection ne fait T partie du consensus au niveau de la transaction ; il s'agit plutôt d'un moyen de trouver un nœud pour orchestrer le consensus.

ScalableBFT est déterministe et renforcé de telle sorte que :

• Les nœuds ne s'engageront que lorsqu'une majorité du cluster sera d'accord avec eux
• La preuve de l’accord doit être entièrement vérifiable à tout moment
• En l’absence de preuve d’accord, ne faites rien.

Kadena est spécialement conçu pour les réseaux autorisés et suppose donc que certaines attaques (comme un déni de service) sont peu probables et hors de son contrôle. Si une ONE attaque se produisait, le système se bloquerait (tous les nœuds finiraient par expirer, mais une élection serait impossible) ou resterait inactif.

Une fois un tel événement terminé, les nœuds reviendront au consensus et les choses reviendront à la normale. Cependant, dans un réseau autorisé, les administrateurs auraient le contrôle total et couperaient la connexion à l'origine du problème.

L'élection du leader est très similaire à Raft dans le sens où n'importe quel nœud peut être élu leader, chaque nœud obtient un vote par mandat et les élections sont déclenchées lorsque le délai d'attente aléatoire de ONEun des nœuds se déclenche (le minuteur est réinitialisé chaque fois qu'un nœud entend le leader).

La plus grande différence est que dans Raft, un nœud qui obtient suffisamment de votes assume le leadership, tandis que dans ScalableBFT, un nœud qui obtient la majorité des votes distribue ces votes à tous les autres nœuds pour démontrer (à la manière de BFT) qu'il a été élu leader par le cluster.

Le mécanisme de ScalableBFT corrige les problèmes observés dans Juno et Tangaroa, comme un « candidat en fuite » où un nœud non byzantin a expiré en raison d'une partition réseau mais, parce que son terme a été incrémenté, il ne peut T revenir au consensus et continue à expirer puis incrémente son terme (« Runaway »).

Le consensus Raft garantit un ordre et une réplication stricts des messages ; le contenu de chaque message T aucune importance et peut aller de nombres aléatoires à des contrats intelligents en texte clair, en passant par du texte chiffré. Kadena exploite la couche de journalisation comme service de messagerie lorsqu'il s'exécute dans un contexte chiffré, tout comme Signal peut exécuter le chiffrement du protocole Noise sur SMS. ScalableBFT exécute Noise sur une blockchain.

ScalableBFT ajoute la robustesse du consensus, que la couche chargée d'interpréter les messages considère comme une garantie, ainsi que des hachages incrémentiels qui assurent une réplication parfaite des messages. Le protocole Noise se positionne entre le consensus et l'exécution des contrats intelligents, chiffrant/déchiffrant les messages selon les besoins. Comme les messages sont chiffrés, seules quelques astuces classiques permettant d'éviter une explosion cartésienne des tests en direct sont nécessaires pour exécuter chaque message sans fuite d'informations.

Modèle de sécurité/déterminisme omniprésent

Kadena utilise le terme « déterminisme omniprésent » pour décrire « l'idée d'une blockchain qui utilise la cryptographie basée sur PPK-Sig pour les garanties d'auteur (comme Bitcoin) et est composée d'une couche de consensus entièrement déterministe en plus d'une couche de contrat intelligent à affectation unique et incomplète de Turing.

Les implications d’une blockchain « omniprésente et déterministe » sont assez profondes, car elle permet d’étendre une classe d’auditabilité de type registre Bitcoin en profondeur dans la couche de consensus en enchaînant plusieurs couches de confiance cryptographique.

Prenons l'exemple d'une transaction qui charge un nouveau module de contrat intelligent appelé « prêts ». Supposons que « prêts » importe un autre module appelé « paiements », déjà présent dans la chaîne. L'importation réussie de « paiements » implique à elle seule les conditions suivantes (chacune étant entièrement vérifiable par des moyens cryptographiques) :

• Qui a signé la transaction qui a chargé les « paiements »
• Quels nœuds de consensus étaient présents dans le cluster au moment du chargement
• Quels nœuds de consensus ont convenu que la transaction était valide
• Quels nœuds ont voté pour le leader actuel au moment du chargement
• Qui était le leader
• Qui était le précédent dirigeant ?
• ETC.

Un système déterministe généralisé permet aux nouvelles transactions de tirer parti non seulement de la confiance cryptographique inhérente à l'enchaînement des transactions dans une blockchain, mais aussi de la confiance quant à la manière dont ces transactions ont été intégrées au registre. Ce faisant, vous pouvez créer un système plus sûr que Bitcoin , car le processus de consensus devient tout aussi fiable, vérifiable et intriqué sur le plan cryptographique, les exécutions au niveau des transactions impliquant la survenue Événements de consensus spécifiques, chaque implication étant cryptographiquement vérifiable.

Cela fournit un BFT non seulement pour la couche consensus, mais aussi pour la couche transactionnelle (Bitcoin le fait déjà). Ceci diffère, par exemple, du PBFT qui suppose que les transactions envoyées depuis le serveur du client sont valides, ce qui les rend vulnérables à la compromission. De plus, les BFT non-Raft confient généralement au client la possibilité de démettre/interdire des nœuds. Le déterminisme omniprésent adopte un point de vue différent : ne faire confiance à rien, tout auditer.

En permettant à ScalableBFT d'intégrer un déterminisme omniprésent, on obtient un système totalement paranoïaque, robuste à chaque couche grâce à une sécurité permanente (c'est-à-dire une forme de sécurité cryptographique enregistrable sur disque). Il intègre le modèle de sécurité Bitcoin pour les transactions, l'étend au niveau du consensus et ajoute des contrats intelligents sans avoir recours au minage ni aux compromis auxquels la plupart des acteurs du secteur sont habitués. Il s'agit d'une véritable blockchain, rapide et évolutive.

J'ai demandé à Will Martino (co-fondateur de Kadena) les détails du fonctionnement de ce système pour chaque couche :

Quel est votre modèle de sécurité de niveau consensuel ?

Pour la réplication, Kadena utilise un journal de transactions haché incrémentalement, répliqué à l'identique par chaque nœud. Ces derniers s'accordent sur le contenu du journal via les messages signés distribués contenant le hachage incrémental d'un index de journal donné. Ces messages sont ensuite collectés par les autres nœuds et utilisés pour déterminer individuellement quand une validation est justifiée. Aucun doublon n'est autorisé dans le journal et les messages de réplication du leader contenant des doublons sont immédiatement rejetés.

Nous utilisons les hachages Blake2 et le numéro de terme pour définir l'unicité, évitant ainsi aux clients du système de craindre l'envoi accidentel de doublons ou la soumission de commandes par un nœud malveillant ou un intermédiaire (MITM). Nous utilisons une sécurité permanente, une approche basée sur la signature PPK pour la vérification de l'auteur (ou toute autre approche enregistrable sur disque), très similaire à la vérification des transactions par Bitcoin , mais au niveau du consensus (en plus du niveau transactionnel).

Ceci s'oppose à la sécurité éphémère qui utilise des canaux sécurisés (TLS) pour la validation de la paternité - une approche bien inférieure où la question « qui a envoyé la transaction X ? » est répondue non pas via la cryptographie PPK mais via une requête de niveau consensus car aucun nœud individuel n'est incapable de fournir une réponse BFT.

Quel est votre modèle de sécurité au niveau des transactions ?

Les concepts de sécurité éphémère et permanente s'appliquent à la fois au niveau du consensus et des transactions, car c'est le consensus qui transmet les transactions individuelles à la couche d'exécution des contrats intelligents. Au niveau des contrats intelligents et des transactions, nous utilisons également la sécurité permanente, prenant en charge nativement l'autorisation par clé publique au niveau des lignes dans Pact.

Ceci est important, car le caractère éphémère implique qu'un attaquant est à un serveur près d'usurper l'identité d'une entité ; les canaux sécurisés fonctionnent par distribution point à point des nouvelles transactions par le client/émetteur aux nœuds du cluster via TLS, et le consensus garantit qu'une transaction donnée doit être validée et répliquée. Cependant, si un attaquant pirate le serveur client détenant l'autre extrémité de la connexion TLS, il peut effectuer des transactions comme s'il était le client sans que le cluster ne s'en aperçoive.

La sécurité permanente, en revanche, dispose de nombreuses clés pour les rôles individuels dans une entité donnée, ce qui oblige un attaquant à accéder aux clés individuelles ; de plus, avec la sécurité permanente, les transactions du PDG sont signées avec une clé différente de celle des transactions du commis au courrier, contrairement à la sécurité éphémère où le « qui envoie cette transaction » est déterminé par un champ « de : X ».

Si la même connexion TLS est utilisée pour soumettre les transactions du PDG et du commis, la logique d'autorisation et de paternité repose sur un modèle « parce que je l'ai dit/faites-moi confiance », contrairement à une approche PPK-sig où la vérification se fait par rapport à la clé appropriée avant l'exécution. La blockchain de Kadena est conçue pour accorder le moins de confiance possible ; si nous connaissions une approche plus paranoïaque ou plus fine que les signatures PPK au niveau des lignes, nous l'utiliserions plutôt.

Quel est votre modèle de transaction confidentielle ?

Nous utilisons le protocole Double-Ratchet (utilisé par Signal, WhatsApp, ETC pour les communications chiffrées) intégré à la blockchain (corps de transaction chiffrés) pour des cas d'utilisation multipartites préservant la Politique de confidentialité . Nous exploitons la notion de bases de données disjointes via la primitive « pact » de Pact ; elle décrit un flux de validation multiphase sur des bases de données disjointes via des messages chiffrés.

Contrats intelligents

Pact est un langage de contrats intelligents complet, dont l'interpréteur est basé sur Haskell. Dans Kadena, chaque transaction est un contrat intelligent, et le langage de contrats intelligents Pact est open source. Pact est centré sur les bases de données, transactionnel, incomplet selon Turing, à affectation unique (les variables ne peuvent pas être modifiées pendant leur durée de vie), et donc très propice à la vérification statique.

Pact est également interprété (le code que vous écrivez est celui qui s'exécute sur la chaîne), tandis que Solidity est compilé, ce qui rend difficile la vérification du code et la correction des problèmes de sécurité dans les anciennes versions de langage une fois compilées. Pact est livré avec son propre interpréteur, mais peut s'exécuter sur n'importe quelle blockchain à entrée déterministe et prendre en charge différents backends, y compris les SGBDR commerciaux. Dans la blockchain ScalableBFT, il s'exécute avec une couche de stockage SQLite rapide.

La blockchain Kadena contient toutes ces fonctionnalités :

En conclusion, Kadena a développé un algorithme de consensus déterministe, évolutif et entièrement réplicable pour les blockchains privées, offrant des performances élevées. Cette solution blockchain représente un véritable bond en avant pour les entreprises de services financiers souhaitant adopter une solution véritablement privée, fidèle à de nombreuses fonctionnalités clés de la blockchain Bitcoin, sans minage (preuve de travail), anonymat et résistance à la censure, tout en répondant aux exigences de conception clés des services financiers, notamment l'évolutivité et la confidentialité.

Cet article a déjà été publié sur leBlog Sammanticset a été reproduit ici avec permission. Certaines modifications ont été apportées pour des raisons de style et de concision.

Image des rouagesvia Shutterstock