Redéfinir la scalabilité

Initialement publié en anglais par StarkWare le 1 décembre, 2021

Redéfinir la scalabilité

La scalabilité des blockchains a toujours été un sujet brûlant. Presque tous les réseaux blockchain vantent le nombre élevé de transactions par seconde (TPS) comme un argument de vente. Cependant, le TPS n'est pas une mesure valable pour comparer les réseaux blockchain, ce qui rend difficile l'évaluation de leurs performances relatives. De plus, les grands nombres de TPS ont généralement un coût, ce qui pose la question suivante : ces réseaux sont-ils réellement évolutifs ou se contentent-ils d'augmenter leur débit ?

Examinons donc comment définir la scalabilité, quels compromis sont faits pour y parvenir et pourquoi les Validity Rollups constituent la solution la scalabilité par excellence.

Toutes les transactions ne sont pas égales

Tout d'abord, nous devons établir notre affirmation selon laquelle la mesure simple et pratique des TPS ne sont pas une mesure précise de la scalabilité.

Pour compenser les nœuds pour l'exécution des transactions (et pour dissuader les utilisateurs de spammer le réseau avec des calculs inutiles), les blockchains facturent des frais proportionnels à la charge de calcul imposée à la blockchain. Dans Ethereum, la complexité de la charge de calcul est mesurée en gas. Le gas étant une mesure très pratique de la complexité des transactions, le terme sera utilisé tout au long de cet article pour les blockchains autres qu'Ethereum, même s'il est généralement spécifique à Ethereum.

Les transactions diffèrent considérablement en termes de complexité et, par conséquent, de quantité de gas qu'elles consomment. Bitcoin, le pionnier des transactions de pair à pair (P2P) trustless, ne prend en charge que le rudimentaire script Bitcoin. Ces simples transferts d'adresse à adresse consomment peu de gas. En revanche, les chaînes de smart contract comme Ethereum ou Solana prennent en charge une machine virtuelle et des langages de programmation complets de Turing qui permettent des transactions beaucoup plus complexes. Par conséquent, les dApps comme Uniswap nécessitent beaucoup plus de gas.

C'est pourquoi il est absurde de comparer les TPS de différentes blockchains. Ce que nous devrions plutôt comparer, c'est la capacité de calcul ou débit.

Toutes les blockchains ont une taille de bloc (variable) et un temps de bloc qui déterminent combien d'unités de calcul peuvent être traitées par bloc et à quelle vitesse un nouveau bloc peut être ajouté. Ensemble, ces deux variables déterminent le débit d'une blockchain.

Qu'est-ce qui limite la scalabilité ?

Les blockchains s'efforcent d'être des réseaux inclusifs et décentralisés au maximum. Pour y parvenir, deux propriétés fondamentales doivent être contrôlées.

1. Exigences matérielles

La décentralisation d'un réseau blockchain est déterminé par la capacité du nœud le plus faible du réseau à vérifier la blockchain et à en conserver l'état. Par conséquent, les coûts de fonctionnement d'un nœud (matériel, bande passante et stockage) doivent être maintenus aussi bas que possible afin de permettre à un maximum d'individus de devenir des participants permissionless au réseau trustless.

2. Croissance de l'État

La croissance de l'état (state growth) fait référence à la vitesse de croissance de la blockchain. Plus le débit d'une blockchain est élevé par unité de temps, plus la blockchain se développe rapidement. Les nœuds complets stockent l'historique du réseau, et ils doivent être en mesure de valider l'état du réseau. L'état d'Ethereum est stocké et référencé à l'aide de structures efficaces telles que des arbres (arbre de Merkle). Au fur et à mesure que l'état se développe, de nouvelles feuilles et branches sont ajoutées, ce qui rend l'exécution de certaines actions toujours plus complexe et plus longue. Au fur et à mesure que la blockchain s'agrandit, elle empire l’exécution par les nœuds dans le pire des cas, ce qui entraîne un temps toujours plus long pour valider les nouveaux blocs. Au fil du temps, cela augmente également le temps total nécessaire à la synchronisation d'un nœud complet.

Impacts néfastes de l'augmentation du débit

1. Nombre de nœuds

Les exigences minimales pour faire fonctionner un nœud et le nombre de nœuds sont les suivants :

  • Bitcoin¹ : 350 Go d'espace disque, connexion 5 Mbit/s, 1 Go de RAM, CPU >1 Ghz. Nombre de nœuds : ~10 000
  • Ethereum² : 500GB+ espace disque SSD, connexion 25 Mbit/s, 4-8GB RAM, CPU 2-4 cores. Nombre de nœuds : ~6 000
  • Solana³ : 1,5 To+ d'espace disque SSD, connexion 300 Mbit/s, 128 Go de RAM, CPU 12+ cœurs. Nombre de nœuds : ~1 200

Notez que plus les exigences en matière de CPU, de bande passante et de stockage pour les nœuds nécessaires au débit d'une blockchain sont élevées, moins il y a de nœuds sur le réseau, ce qui entraîne une décentralisation plus faible et un réseau moins inclusif.

2. Temps de synchronisation d'un nœud complet

Lorsqu'un nœud fonctionne pour la première fois, il doit se synchroniser avec tous les nœuds existants, télécharger et valider l'état du réseau depuis le bloc de genèse jusqu'à l'extrémité de la chaîne. Ce processus doit être aussi rapide et efficace que possible pour permettre à quiconque d'agir en tant que participant permissionless du protocole.

En prenant comme indicateur les tests de synchronisation des nœuds Bitcoin 2020 et 2021 de Jameson Lopp, le tableau 1 compare le temps nécessaire à la synchronisation d'un nœud complet de Bitcoin, d'Ethereum et de Solana sur un PC grand public moyen.

Tableau 1. Comparaison du débit de la blockchain et de la synchronisation des nœuds
Tableau 1. Comparaison du débit de la blockchain et de la synchronisation des nœuds

Le tableau 1 montre que l'augmentation du débit entraîne des temps de synchronisation plus longs, car de plus en plus de données doivent être traitées et stockées.

Bien que des améliorations soient constamment apportées au logiciel des nœuds pour atténuer le défi posé par la croissance de la blockchain (réduction de l'empreinte du disque, vitesses de synchronisation plus rapides, meilleure résistance aux pannes, modularisation de certains composants, etc.

Comment définir la scalabilité ?

La scalabilité est le terme le plus mal représenté dans l'espace blockchain. Si l'augmentation du débit est souhaitable, elle n'est qu'une partie du puzzle.

La scalabilité signifie plus de transactions pour le même matériel.

Pour cette raison, la scalabilité peut être séparée en deux catégories.

La scalabilité du séquenceur

Le séquençage décrit l'acte d'ordonner et de traiter les transactions dans un réseau. Comme il a été établi précédemment, toute blockchain pourrait trivialement augmenter son débit en augmentant la taille des blocs et en raccourcissant leur durée jusqu'à un point où l'impact négatif sur sa décentralisation est jugé trop important. Mais le fait d'ajuster ces simples paramètres ne permet pas d'obtenir les améliorations nécessaires. L'EVM d'Ethereum peut, en théorie, gérer jusqu'à environ 2 000 TPS, ce qui est insuffisant pour répondre à la demande d'espace de bloc à long terme. Pour mettre à l'échelle le séquençage, Solana a fait quelques innovations impressionnantes : tirer parti d'un environnement d'exécution parallélisable et d'un mécanisme de consensus astucieux, qui permet un débit bien plus efficace. Mais, malgré ses améliorations, il n'est ni suffisant ni évolutif. À mesure que Solana augmente son débit, les coûts matériels pour faire fonctionner un nœud et traiter les transactions augmentent également.

Scalabilité de la vérification

La scalabilité de la vérification décrit des approches qui augmentent le débit sans imposer aux nœuds des coûts matériels toujours plus élevés. Plus précisément, elle fait référence aux innovations cryptographiques telles que les preuves de validité. Elles sont la raison pour laquelle les Validity Rollups peuvent faire évoluer une blockchain de manière durable.

Qu'est-ce qu'un Validity Rollup ?

Les Validity Rollups (également connus sous le nom de "ZK-Rollups") déplacent le calcul et le stockage d'état off-chain mais conservent une petite quantité de certaines données on-chain. Un smart contract sur la blockchain sous-jacente maintient la racine de l'état du Rollup. Sur le Rollup, un lot de transactions hautement compressées, ainsi que la racine de l'état actuel, sont envoyés à un Prouveur off-chain. Le Prouveur calcule les transactions, génère une preuve de validité des résultats et de la nouvelle racine d'état, et l'envoie à un Verifieur on-chain. Le vérifieur vérifie la preuve de validité et le smart contract qui maintient l'état du rollup, le met à jour avec le nouvel état fourni par le vérifieur.

Comment les Validity Rollup évoluent-ils avec les mêmes exigences matérielles ?

Même si les Prouveurs nécessitent du matériel haut de gamme, ils n'ont pas d'impact sur la décentralisation d'une blockchain, car la validité des transactions est garantie par des preuves mathématiquement vérifiables.

Ce qui importe, ce sont les exigences pour vérifier les preuves. Comme les données impliquées sont hautement compressées et largement abstraites par le calcul, leur impact sur les nœuds de la blockchain sous-jacente est minime.

Les vérifieurs (nœuds Ethereum) n'ont pas besoin de matériel haut de gamme, et la taille des lots n'augmente pas les exigences matérielles. Seules les transitions d'état et une petite quantité de données d'appel doivent être traitées et stockées par les nœuds. Cela permet à tous les nœuds Ethereum de vérifier les lots Validity Rollup en utilisant leur matériel existant.

Plus il y a de transactions, moins c'est cher

Dans les blockchains traditionnelles, plus il y a de transactions, plus le coût est élevé pour tout le monde, car l'espace du bloc se remplit et les utilisateurs doivent surenchérir sur le marché des frais pour que leurs transactions soient incluses.

Pour un Validity Rollup, cette dynamique est inversée. La vérification d'un lot de transactions sur Ethereum a un certain coût. Au fur et à mesure que le nombre de transactions dans un lot augmente, le coût de vérification du lot augmente à un rythme exponentiellement plus lent. L'ajout d'un plus grand nombre de transactions à un lot entraîne des frais de transaction moins élevés, même si le coût de vérification du lot augmente, car il est amorti sur toutes les transactions du lot. Les modules d'extension de validité veulent qu'un lot contienne le plus grand nombre possible de transactions, afin que les frais de vérification puissent être répartis entre tous les utilisateurs. Au fur et à mesure que la taille du lot augmente jusqu'à l'infini, les frais amortis par transaction convergent vers zéro, c'est-à-dire que plus il y a de transactions dans un Validity Rollup, moins c'est cher pour tout le monde.

dYdX, une dApp alimentée par un Validity Rollup, voit fréquemment des lots de plus de 12 000 transactions. La comparaison de la consommation de gas des mêmes transactions sur le Mainnet et sur un Validity Rollup illustre les gains de scalabilité :

Règlement d'une transaction dYdX sur Ethereum Mainnet : 200 000 gas

Règlement d'une transaction dYdX sur StarkEx : <500 gas

Une autre façon de voir les choses : Le coût principal des Validity Rollups évolue linéairement avec le nombre d'utilisateurs d'un même lot.

Pourquoi les Optimistic Rollups ne sont pas aussi scalable qu'on pourrait le penser ?

En théorie, les Optimistic Rollups offrent presque les mêmes avantages de scalabilité que les validity rollups. Mais il existe une distinction importante : Les Optimistic Rollups sont optimisés pour le cas moyen, alors que les Validity Rollups sont optimisés pour le cas le plus défavorable. Les systèmes de blockchain fonctionnant dans des conditions extrêmement défavorables, l'optimisation pour le pire des cas est le seul moyen d'assurer la sécurité.

Dans le pire cas du Optimistic Rollups, les transactions d'un utilisateur ne seront pas vérifiées par les contrôleurs de fraude. Ainsi, pour contester une fraude, l'utilisateur doit synchroniser un nœud complet Ethereum, un nœud complet L2, et calculer lui-même la transaction suspecte.

Dans le pire des cas, un utilisateur n'aurait qu'à synchroniser un nœud complet Ethereum pour vérifier la preuve de validité, s'épargnant ainsi la charge de calcul.

Contrairement aux Validity Rollups, le coût des Optimistic Rollups s'échelonne linéairement avec le nombre de transactions au lieu du nombre d'utilisateurs, ce qui les rend plus chers.

Dernière pièce du puzzle - Accès permissionless à l'état du rollup

Pour garantir la validité des transactions, les utilisateurs doivent exécuter un nœud Ethereum uniquement. Cependant, les utilisateurs et les développeurs peuvent vouloir voir, et exécuter, l'état et l'exécution du Rollup à diverses fins. Un nœud L2 d'indexation répond parfaitement à ce besoin. Non seulement il permet aux utilisateurs de voir les transactions dans le réseau, mais il s'agit également d'une pièce essentielle nécessaire au fonctionnement de l'infrastructure de l'écosystème. Les indexeurs comme The Graph, Alchemy, Infura, les réseaux Oracle comme Chainlink, et les explorateurs de blocs, tous sont entièrement pris en charge par un nœud L2 d'indexation permissionless.

Conclusion

De nombreuses approches pour aborder la scalabilité des blockchains se concentrent à tort sur l'augmentation du débit. Mais cela néglige l'impact des débits sur les nœuds : les exigences matérielles toujours croissantes pour traiter les blocs et stocker l'historique du réseau, et la façon dont cela inhibe la décentralisation d'un réseau.

Avec l'avènement de la cryptographie à l'épreuve de la validité, une blockchain peut atteindre une véritable scalabilité qui n'impose pas aux nœuds des coûts toujours plus élevés et permet une large décentralisation. Il est désormais possible d'effectuer davantage de transactions avec des calculs plus puissants et plus complexes pour le même matériel, ce qui inverse le dilemme du marché des frais dans le processus plus il y a d'activité sur un Validity Rollup, moins il est cher !

SwagtimusPrime.eth et Louis Guthmann

¹ de https://bitcoin.org/en/bitcoin-core/features/requirements

² de https://ethereum.org/en/developers/docs/nodes-and-clients/

³ de https://docs.solana.com/running-validator/validator-reqs

⁴ Fortement simplifié et ajusté pour les tailles moyennes de blocs dynamiques

Traduction faite par @Valentin Negro

Subscribe to Starknet France
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.