🇫🇷 Entrez dans Hydra : l'évolutivité des registres distribués, résultat de la méthode basée sur les preuves

[Psychomb]

En savoir plus sur Hydra : le protocole à plusieurs têtes

Auteur : Prof Aggelos Kiayias
Traduction : The Stakhanovite Stake Pool (STKH)

L’évolutivité est le plus grand défi à relever pour l’adoption de la technologie blockchain. En suivant une approche fondée sur des principes et des preuves, nous sommes parvenus à une solution pour Cardano et les réseaux similaires : Hydra. Hydra est l’aboutissement de recherches approfondies et une étape décisive qui permet aux réseaux décentralisés de s’adapter en toute sécurité à une demande atteingnant l’échelle mondiale.

Qu’est-ce que l’évolutivité et comment la mesurer ?

Par évolutivité, on entend la capacité d’un système de registre distribué à fournir un débit de transaction élevé, une faible latence et un stockage minimal par nœud validateur. Ces propriétés ont été maintes fois présentées comme essentielles pour le déploiement réussi de protocoles blockchain dans un cadre de systèmes réels. En termes de débit, le réseau VISA traite en moyenne 1 736 transactions de paiement par seconde (TPS) avec la capacité d’en traiter jusqu’à 24 000 et VISA est fréquemment utilisé comme base de comparaison. Il est clairement souhaitable que la latence des transactions soit aussi faible que possible, avec pour objectif ultime l’instantanéité pour l’utilisateur final. D’autres applications basées sur les registres distribués ont un large éventail d’exigences différentes en ce qui concerne ces paramètres. Lors de la conception d’un registre distribué à usage général, il est naturel de s’efforcer d’exceller sur ces trois points.

Le déploiement d’un système qui offre une dimension satisfaisante pour un certain nombre de cas d’utilisation nécessite une combinaison appropriée de deux aspects indépendants : avoir une conception algorithmique appropriée et être déployé sur une infrastructure matérielle et réseau sous-jacente appropriée.

Lors de l’évaluation d’une conception algorithmique particulière, il peut être trompeur de considérer des nombres absolus en termes de mesures spécifiques. La raison en est que de telles quantités absolues doivent se référer à une configuration matérielle et de réseau particulière, ce qui peut brouiller les avantages et les inconvénients de certains algorithmes. En effet, un protocole mal conçu peut encore être suffisamment performant lorsqu’il est déployé sur un matériel et un réseau de qualité supérieure.

C’est pourquoi il est plus judicieux d’évaluer la capacité d’un protocole à atteindre les limites physiques du réseau et du matériel qui le sous-tendent. Cela peut être réalisé en comparant le protocole avec de simples protocoles de “paille”, dans lesquels tous les éléments de conception ont été supprimés. Par exemple, si nous voulons évaluer la surcharge d’un algorithme de cryptage, nous pouvons comparer les performances de communication de deux points en utilisant le cryptage par rapport à leurs performances lorsqu’ils échangent simplement des messages non cryptés. Dans une telle expérience, le taux absolu de messages par seconde est sans importance. La conclusion importante est la surcharge relative qui est ajoutée par l’algorithme de cryptage. En outre, si la surcharge est proche de 0 pour une configuration donnée du dispositif expérimental, nous pouvons conclure que l’algorithme se rapproche des limites physiques de la capacité de transmission de messages du réseau sous-jacent pour cette configuration particulière, et qu’il est donc optimal en ce sens.

Hydra - Une vue plongeante

Hydra est une architecture évolutive hors-chaîne pour les registres distribués qui répond aux trois défis d’évolutivité mentionnés ci-dessus : haut débit de transaction, faible latence et stockage minimal par nœud. Bien que Hydra soit conçu en conjonction avec le protocole Ouroboros et le registre Cardano, il peut également être utilisé sur d’autres systèmes, à condition que ces derniers partagent les caractéristiques essentielles de Cardano.

Bien qu’il s’agisse d’un système intégré visant à résoudre un seul problème - l’évolutivité - Hydra se compose de plusieurs sous-protocoles. Cela est nécessaire car l’écosystème de Cardano lui-même est hétérogène et se compose de multiples entités aux capacités techniques différentes : le système prend en charge les producteurs de blocs avec les groupes d’enjeu associés, les portefeuilles à haut débit comme ceux utilisés par les plateformes d’échange, mais aussi les utilisateurs finaux avec une grande variété de performances de calcul et de caractéristiques de disponibilité. Il n’est pas réaliste de penser qu’une approche unique et un seul protocole puisse suffire à assurer l’évolutivité globale d’un ensemble aussi diversifié de participants au réseau.

L’architecture évolutive de Hydra peut être divisée en quatre composantes : le protocole de tête, le protocole de queue, le protocole de communication entre tête et queue, ainsi qu’un ensemble de protocoles de soutien pour le routage, la reconfiguration et la virtualisation. La pièce maîtresse est le protocole “head” (de tête), qui permet à un ensemble de participants à haute performance et haute disponibilité (tels que des groupes d’enjeu) de traiter très rapidement un grand nombre de transactions avec des besoins de stockage minimaux par le biais d’un canal d’état multipartite - un concept qui généralise les canaux de paiement à deux parties, tel qu’il est mis en œuvre dans le contexte du réseau Lightning. Il est complété par le protocole “tail” (queue), qui permet à ces participants très performants d’offrir une évolutivité à un grand nombre d’utilisateurs finaux qui peuvent utiliser le système à partir d’appareils de faible puissance, tels que des téléphones portables, et qui peuvent être hors ligne pendant de longues périodes. Alors que les têtes et les queues peuvent déjà communiquer via la blockchain principale de Cardano, le protocole de communication entre têtes et queues offre une variante hors chaîne efficace de cette fonctionnalité. Tout cela est lié par le routage et la gestion de la configuration, tandis que la virtualisation facilite une communication plus rapide en généralisant la communication entre tête et queue.

Le protocole Hydra “head” (“tête”)

Le protocole Hydra “head” est le premier élément de l’architecture Hydra à être rendu public. Il permet à un ensemble de participants de créer un canal d’état hors chaîne (appelé tête) dans lequel ils peuvent exécuter des contrats intelligents (ou traiter des transactions plus simples) entre eux sans interaction avec la blockchain sous-jacente, dans le cas optimiste où tous les participants de la tête adhèrent au protocole. Le canal d’état offre un règlement très rapide et un débit de transaction élevé ; en outre, il nécessite très peu de stockage, car l’historique des transactions hors chaîne peut être supprimé dès que l’état qui en résulte a été sécurisé par une opération de " capture d’instantané " hors chaîne.

Même dans le cas pessimiste où un certain nombre de participants se comportent mal, la sécurité totale est rigoureusement garantie. À tout moment, tout participant peut déclencher la “fermeture” de la tête, ce qui a pour effet de transférer l’état de cette tête vers la blockchain (moins efficace). Nous soulignons que l’exécution de tout contrat intelligent peut être poursuivie de manière transparente sur la blockchain. Aucun fonds ne peut être généré en dehors de la chaîne, et aucun des participants actifs dans cette tête ne peut perdre de fonds.

Les canaux d’état mis en œuvre par Hydra sont isomorphes en ce sens qu’ils utilisent le même format de transaction et le même code de contrat que la blockchain sous-jacente : les contrats peuvent être déplacés directement d’un canal à l’autre ainsi que de et vers la blockchain. Ainsi, les canaux d’état donnent effectivement des frères et sœurs parallèles, hors chaîne. En d’autres termes, le registre lui-même devient multi-tête.

La confirmation des transactions dans la tête est réalisée de manière totalement parallèle par un processus de certification asynchrone hors chaîne utilisant des signatures multiples. Ce niveau élevé de parallélisme est rendu possible par l’utilisation du modèle UTxO étendu (EUTxO). Les dépendances des transactions dans le modèle EUTxO sont explicites, ce qui permet de mettre à jour les états sans séquentialisation inutile de transactions puisqu’elles sont indépendantes les unes des autres.

Validation expérimentale du protocole Hydra “head”

Comme première étape vers la validation expérimentale des performances du protocole Hydra “head”, nous avons mis en place une simulation. La simulation prend comme paramètre le temps requis par les actions individuelles (validation des transactions, vérification des signatures, etc.), et réalise une simulation réaliste d’un groupe de nœuds validateurs distribués formant une tête. Il en résulte des calculs réalistes du temps de confirmation des transactions et du débit.

Nous constatons qu’une seule tête de Hydra permet d’atteindre environ 1 000 TPS, donc en faisant tourner 1 000 têtes en parallèle (par exemple, une pour chaque groupe d’enjeu prévu pour Shelley), nous pourrions atteindre un million de TPS. C’est impressionnant et cela nous donne une longueur d’avance sur la concurrence, mais pourquoi s’arrêter là ? 2 000 têtes nous donneront 2 millions de TPS - et si quelqu’un demande un milliard de TPS, alors nous pouvons lui dire de lancer d’un million de têtes. En outre, diverses optimisations lors de l’implémentation peuvent améliorer ces chiffres, ce qui ajoute encore aux performances hypothétiques du protocole.

Alors, peut-on atteindre n’importe quel nombre de TPS ? En théorie, la réponse est un oui solide, ce qui met en évidence un problème lié à l’utilisation dominante des TPS comme mesure de comparaison des systèmes. S’il est tentant de réduire la complexité de l’évaluation des performances des protocoles à un seul chiffre, en pratique, cela conduit à une simplification excessive. Sans autre contexte, un nombre de TPS est presque dénué de sens. Afin de l’interpréter correctement et de faire des comparaisons, vous devez au moins vous demander quelle est la taille du groupe (qui influence le temps de communication) ; sa distribution géographique (qui détermine le temps nécessaire pour que les informations transitent par le système) ; l’impact d’un taux élevé de transactions sur la qualité du service (temps de confirmation des transactions, fourniture de données aux utilisateurs finaux) ; l’ampleur et la complexité des transactions (qui ont un impact sur les temps de validation des transactions, le temps de propagation des messages, les exigences relatives au système de stockage local et la composition des participants principaux) ; et le type de matériel et de connexions réseau utilisés dans les expériences. La seule modification de la complexité des transactions peut tripler le TPS, comme le montrent les chiffres présentés dans l’article (voir section 7 - Simulations).

Il est clair que nous avons besoin d’une meilleure norme. Le protocole Hydra “head” est-il de bonne conception ? Ce que nous devons nous demander, c’est : atteint-il les limites physiques du réseau, et non un simple nombre de TPS ? Ainsi, pour cette première itération de l’évaluation du protocole Hydra" head", nous avons utilisé l’approche suivante pour nous assurer que les données que nous fournissons ont vraiment du sens :

• Nous énumérons clairement tous les paramètres qui influencent la simulation : taille de la transaction, temps de validation d’une seule transaction, temps nécessaire aux opérations cryptographiques, largeur de bande passante allouée par nœud, taille des groupes de participants et répartition géographique, et limites du parallélisme avec lequel les transactions peuvent être émises. Sans cet environnement contrôlé, il serait impossible de reproduire nos résultats.

• Nous comparons les performances du protocole à des lignes de base qui fournissent des limites précises et absolues du réseau et de l’infrastructure matérielle sous-jacents. La manière dont nous approchons ces limites nous indique la marge de manœuvre dont nous disposons pour apporter des améliorations supplémentaires. Cela suit la méthodologie expliquée ci-dessus à l’aide de l’exemple d’un algorithme de cryptage.

Nous utilisons deux lignes de base pour Hydra. La première, “Full Trust”, est universelle : elle s’applique à tout protocole qui répartit les transactions entre les nœuds et insiste pour que chaque nœud valide les transactions l’une après l’autre - sans même assurer le consensus. Cela permet d’évaluer les limites maximales en terme de TPS en additionnant simplement les temps de latence et de validation des messages. La façon dont nous approchons cette limite nous indique sur le prix à payer pour obtenir un consensus, sans se fier à la comparaison avec d’autres protocoles. La deuxième base de référence, “Hydra Unlimited”, donne une limite TPS spécifique pour le protocole principal et fournit également la latence idélae et le stockage pour n’importe quel protocole. Nous y parvenons en supposant que nous pouvons envoyer suffisamment de transactions en parallèle pour amortir complètement les temps d’aller-retour sur le réseau et que toutes les actions peuvent être effectuées en cas de besoin, sans conflit de ressources. La base de référence nous aide à répondre à la question de savoir ce qui peut être réalisé dans des circonstances idéales avec la conception générale de Hydra (pour un ensemble de paramètres d’entrée donnés) ainsi qu’à évaluer la latence de confirmation et les frais généraux de stockage par rapport à n’importe quel protocole possible. Vous trouverez plus de détails et de graphiques pour les personnes intéressées dans notre article (à nouveau, section 7 - Simulations).

Quelle est la prochaine étape ?

La résolution de la question de l’évolutivité est le Saint Graal pour toute blockchain. Le temps est venu d’appliquer une approche fondée sur des principes et des preuves pour concevoir et mettre au point des solutions d’évolutivité des blockchains. La comparaison des propositions d’évolutivité par rapport à des bases de référence bien définies peut être d’une grande aide dans la conception de tels protocoles. Elle fournit des preuves solides quant à la pertinence des choix de conception et conduit en fin de compte à l’ingénierie de protocoles de registres distribués efficaces et performants qui fourniront les meilleures mesures absolues possibles pour les cas d’utilisation qui nous intéressent. Pendant que le protocole Hydra “head” est mis en œuvre et testé, nous publierons, à terme, le reste des composants de Hydra en suivant la même approche.

Pour terminer, Hydra est le fruit de l’effort conjoint de plusieurs chercheurs, que je tiens à remercier. Parmi eux, Manuel Chakravarty, Sandro Coretti, Matthias Fitzi, Peter Gaži, Philipp Kant et Alexander Russel. Ce travail a également été soutenu, en partie, par le projet européen n° 780477, PRIVILEDGE, que nous remercions.