Le 21 Mars 2022 Matthias Fitzi, Chercheur associé chez IOG a publié un bulletin sur les stratégies qui seront mises en oeuvre sur court et moyen terme dans Cardano afin d’en augmenter le taux de transactions. Afin d’en faciliter l’accès aux non-anglophones, je vous propose ici une traduction en Français de celui-ci:
Augmenter le taux de transactions de Cardano
La diffusion par pipeline (« Diffusion pipelining », prévu pour cette été) augmentera la vitesse de propagation des blocs ainsi que le temps de validation. Ceci permettra alors d’avoir de plus gros blocs et une cadence de transaction plus grande. Voici une perspective sur les aspects techniques (ainsi qu’une introduction à AV, le jumeau encore plus performant de la diffusion par pipeline)
La disponibilité récente des contrats intelligents sur Cardano s’est accompagnée d’une augmentation significative de l’activité utilisateur sur le réseau. En même temps, la taille moyenne des transactions a augmentée due au fait que les transactions portent des scripts de programmes. Avec l’avènement des premières applications décentralisées (DeFi) sur l’écosystème de Cardano, et bientôt plus encore, nous nous attendons à ce que les tendances d’usages croissent encore à l’avenir. Afin de suivre ce niveau de demande, la capacité de traitement des transactions du système se doit d’être augmentée.
Une approche simple pour augmenter le taux de transaction consiste à augmenter la taille maximale des blocs afin de pouvoir mettre plus de transactions dans chaque bloc. La taille des blocs a en fait déjà été augmenté de 25% cette année ci (de 64kB à 80kB) et nous prévoyons d’autres augmentations. Cependant, considérant le taux de production de blocs actuel, il existe une limite quant à cette augmentation et ce, afin de garantir la sécurité du protocole de consensus du registre du blockchain. Afin d’assurer un fort taux de sortie sans compromettre la sécurité du système, des mesures additionnelles sont nécessaires. Pour comprendre pourquoi, nous devons nous pencher sur la manière dont fonctionne le consensus du registre:
Le protocole de consensus du registre est caractérisé par deux paramètres de temps:
- Δp, le temps de latence maximal pour qu’un bloc atteint (par ex.) 95% des noeuds du réseau.
- Δb, le temps prévu entre deux blocs consécutifs.
Dans un protocole typique, on considère qu’il y a consensus lorsqu’un bloc donné a été propagé sur le réseau avant que le suivant ne soit généré (tout du moins, la plupart du temps). Ainsi, Δb est choisi de tel sorte qu’il soit plus grand que Δp. Pour Cardano, on a Δp=5s (secondes) et Δb=20s.
Quel est la quantité de données qui peut être transporté par un bloc dans ces conditions? Pour savoir cela, nous devons examiner plus en détails ce que l’on doit en fait accomplir durant le temps Δp.
La Figure 1 décrit de manière simplifiée comment la propagation sur le réseau fonctionne. Le producteur du bloc (le « leader » sur la figure) envoie l’en-tête du nouveau bloc au pair 1 (boite blanche étiqueté « h »), congestionnant le canal de communication entre les deux noeuds du réseau et ce, durant le temps représenté par la largeur de la boite blanche « h ». Le pair 1 valide ensuite l’en-tête (impliquant un calcul local qui dure le temps indiqué par la largeur de la boite grise étiqueté « hv »). Si l’en-tête est valide (par exemple et entre autre, si l’en-tête contient la preuve que le noeud est éligible pour effectuer la production du bloc), alors le corps du bloc est téléchargé par le pair 1 (boite blanche « b »). Ceci encore une fois occupe le canal de communication entre les deux noeuds. Finalement, le pair 1 valide le corps du bloc (boite grise « bv »), et seulement si le corps est aussi valide, le pair 1 est prêt à propager le bloc à d’autres pairs selon le même schéma que ce qui vient d’être décrit.
Une conséquence indésirable de ce mode d’opération est que le CPU et la connexion réseau d’un noeud est seulement utilisée durant une toute petite fraction de Δp=5s, tandis que le noeud reste essentiellement au repos durant le temps restant jusqu’à Δb=20s.
Concrètement, la quantité de données que nous pouvons faire rentrer dans un bloc est déterminée par le délai de propagation du bloc dans le réseau pair-à-pair, ainsi que le temps requis pour effectuer la validation. Ces deux-ci croissent linéairement avec la taille du bloc multipliée par le nombre maximal de « sauts » requis afin d’atteindre 95% des noeuds. Des mesures montrent qu’afin de garantir une propagation au sein du réseau en Δp=5s, la taille des blocs ne doit pas excéder 2MB. Si nous tenons compte de l’intensité de la charge de calcul des scripts, il est très possible que les temps de validations imposent une limite bien plus basse.
La bonne nouvelle est que, dans la limite des contraintes discutées plus haut, le taux de transactions peut être supérieur si nous faisons des changements sur le réseau pair-à-pair et/ou sur la couche gérant le consensus. Nous allons expliquer cela ci dessous:
Diffusion par pipeline
En reprenant la Figure 1, on peut remarquer que toutes les actions des noeuds sont entrepris de façon séquentielles. Ainsi pour un noeud donné, le nombre de « sauts » dans le chemin pair-à-pair multiplié par le temps de calculs du noeud doit être inférieur à Δp. Bien que l’on observe que cela soit nécessaire lors de la transmission sur le réseau, cela ne l’est pas lors de l’étape de validation.
Considérons maintenant la Figure 2. En permettant aux blocs de se propager avant que leurs validations complètes soit assurées, nous pouvons exclure la validation (répétée) du corps du bloc au sein du chemin de propagation. Dès que le pair 1 a reçu le corps d’un bloc (boite « b »), celui ci peut d’hors et déjà commencer à propager le bloc de manière concurrente à la phase de validation du corps du bloc; et ainsi de suite.
Contrairement à ce que l’on voit dans la Figure 1 et en regardant le bilan comptable sur Δp, on se rend compte qu’il suffit de tenir compte du temps de validation du corps qu’une seule fois. Cela donne plus de temps pour la transmission pair-à-pair et/ou la validation du corps, permettant ainsi un plus grand taux de transactions. Pour faciliter la comparaison avec le Figure 1, ce gain est illustré par un plus large budget temps disponible pour la validation du corps (boite « bv » plus large sur la Figure 2 que sur la Figure 1).
Pour les raisons énoncées ci-dessous, il est crucial que les deux points suivants soient validés et restent entièrement redondants le long du chemin de propagation:
- Exactitude des en-têtes: par exemple, s’assurer que le bloc fait bien référence à son prédécesseur et que le leadership du bloc soit correct (Fonction Vérifiable-Aléatoire – VRF- et validation de la signature du bloc)
- L’intégrité du bloc: par exemple, le corps du bloc reçu (mais pas encore validé) est bien référencé par l’en-tête du hash du corps du bloc.
Comment la diffusion par pipeline (tel que décrit ci dessus) affecte la sécurité de la couche de consensus et celle du réseau?
Premièrement, notez que la couche de consensus n’est pas affectée par les changements:
- Les blocs honnêtes sont toujours valides, puisque le leader du bloc valide intégralement la chaine rallongée par le nouveau bloc ainsi que le bloc lui même (grâce au point 2, ci dessus).
- Les blocs incomplets ne sont pas propagés.
- Bien que les blocs invalides (mais complets) soient potentiellement propagés sur le réseau, ils seront toujours rejetés par un noeud honnête après vérification du corps du bloc.
Deuxièmement et concernant les attaques par déni de service (DoS) sur la couche réseau, notez que l’adversaire peut essayer de congestionner le système en diffusant des blocs invalides. Cependant, le leadership du bloc est toujours vérifié (grâce au point 1), ce qui implique que ce bloc ne sera propagé que si l’adversaire est de droit autorisé à propager le bloc. Par exemple, il n’y a pas de charge de calcul supplémentaire comparativement au cas d’un bloc honnête (à l’exception du fait que le bloc ne contribuera pas au débit du système). Qui plus est, les opérateurs de pools (SPOs) qui génèrent des blocs invalides peuvent être facilement identifiés et punis. En fait un système de gestion d’infractions est en cours de développement pour remplir exactement cette fonction.
Pour conclure, le diffusion par pipeline accroit dans la limite Δp, le temps disponible pour la propagation des blocs et pour la validation. Ceci permet d’avoir des blocs plus larges et donc d’avoir un taux de transactions plus grand, tout en préservant les règles du consensus. Cela permettra d’augmenter substantiellement le débit au prix de changements mineurs au système. Ceci constitue alors un candidat excellent pour une implémentation sur le court terme. Cependant, à lui seul l’impact de la méthode par pipeline reste limitée et nos ambitions ne s’arrête pas là.
Dans la suite, nous allons donner un résumé sur une technique plus puissante, qui permet d’atteindre un taux de transactions encore plus haut, mais qui nécessite des changement plus profond au niveau du protocole.
Validation asynchrone
L’idée essentielle derrière la diffusion par pipeline (validation du corps du bloc en différée) peut être poussée à l’extreme: Un nouveau bloc se doit toujours d’arriver dans l’intervalle Δp, mais nous n’exigeons plus que la validation du corps du bloc soit garanti dans ce même intervalle de temps. Nous appelons cela la validation asynchrone (AV).
Considérons la Figure 3. La validation du corps est typiquement autorisée à utiliser tout l’intervalle de temps Δb attendu (après avoir enlevé le temps de transmission des blocs et le temps de validation de l’en-tête), de tel sorte que cela pousse les CPUs du noeud à être pratiquement en charge maximal permanente. Cependant, notez que le lien réseau et le CPU ont aussi d’autres taches d’assignées (tel que la synchronisation du « mempool »). Cela signifie qu’il n’est pas possible d’utiliser tout le temps Δb restant pour la validation du corps. Il nous faut laisser quelques secondes pour d’autres taches.
Cela a une conséquence connexe notable. Contrairement à la diffusion par pipeline, la validation du registre est généralement en retard par rapport à la tête de la chaine de blocs. En particulier, même les blocs honnêtes peuvent potentiellement créer des blocs qui sont (partiellement) invalides. Ceci car il est possible que le noeud n’ai pas fini de valider l’historique des transactions qui mène au nouveau bloc.
Pour gérer cette effet secondaire, les règles du registre doivent être adaptées: Afin de s’assurer que les blocs honnêtes participent toujours à la sécurité du consensus, les blocs portant des transactions invalides doivent être considérés comme étant des extensions valides de la chaine. Les transactions invalides peuvent simplement être rejetées lors de l’étape de validation du registre.
Bien que le AV soit une amélioration substantielle par rapport à la diffusion par pipeline, le AV peut être amélioré plus encore. En effet, en règle général et sur l’intervalle de temps Δp, il n’est pas possible de diffuser suffisamment de données afin de produire suffisamment de travail de validation pour saturer les CPUs durant le temps libre au sein de la période Δb. Pour tirer parti au maximum des bénéfices de l’AV, nous pourrons le combiner avec un mécanisme d’approbation des entrées (« input endorsers »), que nous décrirons dans un autre bulletin.
Impact
Quel est l’impact attendu sur le débit de sortie avec la diffusion par pipeline et avec l’AV? Il n’est pas encore possible de fournir une réponse précise à cette question. Nos équipes réseaux et de recherches travaillent encore sur le sujet car cela nécessite une analyse rigoureuse dans le cas d’une attaque par un adversaire malveillant (tentant de perturber le plus possible le protocole). On peut toutefois fournir une première évaluation. Vous trouverez ici l’analyse du débit dans le scénario optimiste où tous les SPOs sont des acteurs honnêtes. Nous nous attendons à ce que les résultats dans le cas d’acteurs malveillant ne s’écarte pas de manière significative de celle-ci (et en supposant aussi un système de gestion des infractions). Notez tout de même que les valeurs réels du débit du système seront sûrement différentes des estimations fournis ici.
Dans la Table 1, nous avons représenté les estimations des débits (en transactions par secondes, TPS). Nous vous rappelons que le débit dépend à la fois de la taille des transactions et du temps pour leurs validations. Pour un échantillon varié de tailles et de temps de validations, nous fournissons la valeur du débit attendu, avec pour hypothèse que les transactions ont toutes les memes caractéristiques. Nous comparons cela pour différents protocoles:
- Praos: Le protocole de Cardano actuel (taille de bloc de 80kB)
- Praos Max: Praos en considérant la taille de bloc maximale possible (et avec les hypothèses discutés ci dessus)
- Diffusion par pipeline
- AV (avec 20% du temps Δb alloué pour d’autres taches)
On considère quatre types différents de transactions, variant en terme de taille et en terme de temps de validation. Une simple transaction pour un payement correspond approximativement à la catégorie 0.5 kB/0.5ms tandis qu’une transaction avec un script pourra se trouver dans l’une des autres catégories car les transactions sont alors à la fois plus grosses et nécessitent plus d’efforts pour être validées. Notez aussi la dernière colonne pour laquelle le temps de validation devient substantiel comparé au temps de propagation sur le réseau: Augmenter la taille des blocs (de Praos à Praos Max) n’aide pas à améliorer le débit car la validation sature le temps disponible. Par contre, puisque la diffusion par pipeline et l’AV augmentent le temps disponible pour la validation, ces solutions fournissent de forts gains relatifs spécifiquement dans cette situation.
Perspectives pour Cardano
Augmenter le débit d’un blockchain non-contraint (« permissionless blockchain ») est critique du point de vue de la sécurité. Ceci car en imposant une plus grande charge sur le système, on introduit des opportunités pour des attaques DoS. Il est donc préférable d’effectuer de tels changements en séquence de petites étapes tout en observant les effets sur le système.
Les premières étapes ont été accomplies en Décembre (2021) et en Février (2022). Elles ont consisté en un accroissement de la taille limite des blocs (et de la taille des unités mémoire des scripts Plutus) de 64 kB à 80kB (voir aussi le post récent de John Woods)
Durant les mois à venir, nous allons continuer à étroitement suivre et ajuster les paramètres, en fonction de la demande et des contraintes sur la capacité du réseau. Des améliorations additionnelles seront visibles grâce à l’implémentation de la diffusion par pipeline. D’autres optimisations au niveau du consensus, y compris le mécanisme d’approbation des entrées (« input endorsers ») sont en cours de développement et plus de détails sur la manière dont celles-ci vont être mises en place seront annoncées en temps voulu.
A noter que la quête à l’optimisation durant l’ère Basho de Cardano va au delà de la couche réseau et de consensus: Cela inclue des améliorations au niveau du script Plutus ainsi que des optimisations sur les processus hors-chaine (voir le post récent de Tim Harrison). Mais aussi et en particulier Hydra, un ensemble de protocoles de niveau 2 en cours de développement qui offre une autre voie pour augmenter de manière importante le total de transactions possibles en permettant de les exécuter hors-chaine.
.