Rollup de validité et le rôle de la machine virtuelle Cairo

• Les Rollups de validité sont le moyen le plus prometteur pour augmenter le débit d'Ethereum de manière sécurisée et décentralisée ; les zkEVM et la machine virtuelle Cairo (CVM) sont deux types de machines virtuelles utilisées par les Rollups de validité

• zkEVM se concentre sur la compatibilité avec Ethereum, mais sacrifie les performances et la scalabilité.

• Cairo VM, utilisée dans Starknet, privilégie les performances et la scalabilité par rapport à la compatibilité.

Les rollups sont le sujet phare de l'année lorsqu'il s'agit de mettre à l’échelle Ethereum. Parmi les différents types de Rollups, nous croyons que les Rollups de validité (VRs), également connus sous le nom de zk-rollups, sont le moyen le plus prometteur pour augmenter le débit d'Ethereum de manière sécurisée et décentralisée. Au cœur de cette solution de mise à l'échelle se trouve l'utilisation de preuves de validité pour la computation vérifiable.

Voici comment elles fonctionnent :

• Au lieu de traiter chaque transaction sur la chaîne principale Ethereum, les opérateurs déchargent l'exécution des transactions dans un environnement off-chain. Cet environnement off-chain sert de couche 2, c'est-à-dire une couche fonctionnant au-dessus d'Ethereum.

• Après avoir traité de vastes lots de transactions, l'opérateur de la couche 2 renvoie les résultats à appliquer à l'état d'Ethereum, ainsi qu'une preuve de validité pour vérifier l'intégrité de l'exécution off-chain. La preuve garantit que toutes les transactions d'un lot sont valides et est vérifiée de manière autonome par le contrat vérificateur on-chain. Cela permet à Ethereum d'appliquer le résultat à son état.

Note : Les Rollups de validité sont souvent incorrectement désignés comme des ZK Rollups, mais cela n'est pas exact. La plupart des Rollups de validité n'utilisent pas de preuves ZK et ne sont pas utilisés dans le but d'assurer la confidentialité. Par conséquent, le terme "Rollups de Validité" est plus précis.

Avant de poursuivre, la première question à laquelle nous devons répondre est : Qu'est-ce qu'une machine virtuelle (VM) ? En termes simples, c'est un environnement dans lequel des programmes peuvent s'exécuter, comme un Mac exécutant un système d'exploitation Windows. Elle passe d'un état à un autre après avoir effectué des calculs sur certaines entrées. La Machine Virtuelle Ethereum (EVM) est la VM qui exécute les contrats intelligents d'Ethereum.

Une Machine Virtuelle à Preuve de Zéro Connaissance (zkVM) est un environnement d'exécution de programme qui, conjointement avec les sorties du programme, permet la génération d'une Preuve de Validité pouvant être facilement vérifiée. Cette Preuve de Validité prouve que le programme a été exécuté correctement. Lorsque le terme "zkEVM" est utilisé, il se réfère généralement à un Rollup qui utilise la Machine Virtuelle Ethereum (EVM) et est capable de prouver les exécutions de l'EVM. Cette terminologie peut être trompeuse car l'EVM lui-même ne génère pas ces preuves ; à la place, les preuves sont générées par un mécanisme de preuve distinct qui prend les résultats de l'exécution de l'EVM comme point de départ. De plus, ces preuves concernent la validité, pas la confidentialité, elles ne sont donc pas exactement des preuves ZK. Néanmoins, pour des raisons de cohérence, nous utiliserons le terme conventionnel "zkEVM" dans cet exposé.

Bien que tous les Rollups de validité cherchent à exploiter les Preuves de Validité pour mettre Ethereum à l'échelle, ils diffèrent dans leur choix de VM pour exécuter les transactions off-chain. De nombreux Rollups de validité ont choisi de reproduire la conception de l'EVM (et sont donc appelés "Rollups zkEVM"), tentant de reproduire Ethereum sur les couche 2. Starknet utilise une nouvelle VM - la Machine Virtuelle Cairo (CVM) - qui a été spécifiquement conçue pour optimiser l'efficacité des preuves de validité.

Ces deux approches ont leurs propres avantages et compromis, mais les zkEVMs sacrifient les performances pour la compatibilité avec Ethereum, tandis que la Machine Virtuelle Cairo privilégie les performances par rapport à la compatibilité, mettant en avant les capacités de mise à l'échelle.

Un zkEVM est un Rollup de validité ayant pour objectif de porter complètement l'expérience Ethereum sur les chaînes de blocs de couche 2. Son but est de reproduire l'environnement de développement Ethereum en tant que Rollup. Avec les zkEVM, les développeurs n'auraient pas besoin de modifier leur code ou d'abandonner leurs outils EVM (et contrats intelligents) lorsqu'ils écrivent ou portent des contrats intelligents vers des solutions plus évolutives.

Un inconvénient majeur de cette approche est qu'elle réduit le potentiel de mise à l'échelle des Preuves de Validité. Les zkEVM sont plus lents et plus gourmands en ressources en raison de leur engagement envers la compatibilité avec Ethereum. Contrairement à la CVM, l'EVM n'a pas été conçu en gardant à l'esprit l'efficacité de la preuve. Cela limite l'utilisation d'optimisations qui pourraient améliorer l'efficacité et la scalabilité, affectant finalement les performances globales du système.

Le principal défi de l'approche zkEVM trouve ses origines dans la conception originale de l'EVM. Il n'a pas été conçu pour fonctionner dans un contexte de Preuve de Validité. Par conséquent, les efforts pour reproduire sa fonctionnalité ne parviennent pas à libérer le plein potentiel des preuves de validité, entraînant une efficacité inférieure à l'optimal. Une telle inefficacité finit par peser sur les performances globales du système. La compatibilité de l'EVM avec les Preuves de Validité est entravée par les facteurs suivants :

• L'EVM utilise un modèle basé sur une stack, tandis que les Preuves de Validité sont plus efficacement utilisées avec un modèle basé sur les registres. La nature basée sur la stack de l'EVM rend intrinsèquement plus difficile de démontrer la justesse de son exécution et de fournir un support direct pour sa chaîne d'outils native.

• La structure de stockage Ethereum repose fortement sur Keccak et un grand arbre de Merkle Patricia, qui ne sont pas favorables aux Preuves de Validité et imposent un fardeau de preuve substantiel. Par exemple, Keccak est très rapide pour les architectures x86 (sur lesquelles nous exécutons généralement l'EVM), mais nécessite 90 000 étapes pour être prouvé (avec une construction spéciale intégrée). Tandis que Pedersen (une fonction de hachage compatible avec les preuves ZK) nécessite 32 étapes. Même avec une compression récursive, l'utilisation de Keccak dans un zkEVM entraîne une utilisation élevée des ressources du prouveur, ce qui finit par être payé par l'utilisateur.

En conséquence, différents zkEVM visent différents niveaux de prise en charge des outils Ethereum, plus un zkEVM est compatible avec Ethereum, moins il est performant. (Pour plus d'informations sur les types de zkEVM, rendez-vous à la fin de l'article.)

Les solutions zkEVM investissent un temps de développement considérable dans "rendre l'EVM fonctionnel pour les Rollups de validité", en privilégiant la compatibilité plutôt que les performances et la scalabilité à long terme. Il existe une autre option : utiliser une toute nouvelle machine virtuelle (VM) dédiée et ajouter la prise en charge des outils Ethereum en tant que couche supplémentaire par-dessus. C'est l'approche adoptée par Starknet, un Rollups de validité sans permission lancé en novembre 2021. Starknet est le premier Rollups de validité à offrir une plateforme de contrats intelligents à usage général sur un réseau entièrement composable.

Starknet utilise la machine virtuelle Cairo (CVM), avec un langage de haut niveau du même nom. La machine virtuelle Cairo-VM est conçue pour une génération efficace de Preuves de Validité pour l'exécution des programmes.

Avec Cairo (la machine virtuelle et le langage), nous avons :

1. Des preuves de validité optimisées, chaque instruction possède une représentation algébrique efficace.

2. Un langage moderne similaire à Rust pour écrire des programmes prouvables.

3. Une représentation intermédiaire (Sierra) entre le langage de haut niveau Cairo et l'assembleur Cairo (instructions de la VM), ce qui permet une exécution efficace du code Cairo.

Le développement d'un nouveau langage permet de l'adapter aux besoins spécifiques qu'il est destiné à satisfaire, ainsi que de lui fournir des fonctionnalités répondant à des besoins précédemment non satisfaits.

Afin de créer une Preuve de Validité pour une certaine computation, il faut d'abord exprimer cette computation sous forme d'une séquence de contraintes mathématiques la décrivant la computation. Ce processus peut être très complexe en raison du défi d'optimiser les calculs pour l'efficacité, ainsi que du besoin d'outils spécialisés.

Le langage Cairo a été initialement conçu pour simplifier cette tâche et faciliter l'ajout de fonctionnalités et de business logique complexe à StarkEx. Les programmes Cairo sont compilés en un code machine algébrique - une séquence de nombres - qu'une VM fixe exécute. Avec Cairo, toute la complexité de la génération de contraintes mathématiques décrivant la computation - un problème épineux pour les Preuves de Validité - est abstraite et capturée par l'ensemble fixe de contraintes (moins de 50 contraintes au total). En conséquence, les développeurs peuvent exploiter les Preuves de Validité pour mettre à l'échelle leurs applications sans avoir besoin de comprendre les mathématiques sous-jacentes et l'infrastructure, en écrivant du code dans une syntaxe avec laquelle ils sont familiers.

https://twitter.com/EliBenSasson/status/1638270015009968134

Starknet est axé sur l'innovation, et cela se reflète dans son approche pluraliste du code. La puissance de Cairo pour obtenir la meilleure mise à l'échelle à l'aide des preuves STARK ne se limite pas à ceux qui écrivent nativement leurs contrats en Cairo. Les développeurs peuvent opter pour une approche qui leur convient le mieux :

1. Codage natif en Cairo : Avec la sortie de Cairo 1.0, les développeurs ont désormais accès à un langage ergonomique et sûr inspiré de Rust, ce qui facilite grandement l'écriture de la logique du programme et réduit les risques d'erreurs.

2. Compatibilité avec Solidity : Les développeurs Solidity peuvent écrire du code pouvant être utilisé par la machine virtuelle Cairo. Cette méthode offre une expérience de développement similaire à Ethereum et permet de rendre les contrats intelligents Solidity portables vers Starknet. Il existe deux façon d'atteindre cela :

   • zkEVM sur Starknet : La machine virtuelle Cairo peut être utilisée pour prouver l'exécution d'une autre machine virtuelle. Kakarot est un zkEVM écrit en Cairo, qui peut être utilisé pour exécuter les contrats intelligents Ethereum sur Starknet. La machine virtuelle Cairo et le zkEVM ne sont pas des approches concurrentes, et au lieu de choisir entre la machine virtuelle Cairo et le zkEVM, nous pouvons avoir les deux !

   • Transpilation : précédemment possible avec Wrap, projet mené par Nethermind dont le développement ils ont annoncé l’arrêt cet été.

Bien que Cairo soit récent, c'est le 4e langage de contrat intelligent le plus populaire en termes de TVL (Total Value Locked) et il sécurise déjà plus de 350 millions de dollars.

Un zkEVM vise à reproduire l'environnement Ethereum en tant que Rollup de validité et permet aux développeurs d'utiliser des outils Ethereum familiers. Cependant, cette approche limite le plein potentiel des Preuves de Validité et peut être gourmande en ressources.

La machine virtuelle Cairo est spécialement conçue pour les systèmes de Preuve de Validité, sans être limitée par les contraintes de l'EVM. Elle est soutenue par un nouveau langage de programmation sûr et ergonomique inspiré de Rust, appelé Cairo 1.0, formant un outil puissant conçu pour tirer le meilleur parti des preuves STARK pour mettre Ethereum à l'échelle.

Il est passionnant de voir les performances que Cairo réalise semaine après semaine, ainsi que la croissance des différentes options pour les développeurs, telle que le zkEVM Kakarot. À mesure que les applications Starknet entrent en production, démontrant la puissance de Cairo, nous sommes convaincus qu'il sera utilisé pour des projets de plus en plus ambitieux à l'avenir.

Grâce aux trois voies de mise à l'échelle STARK décrites ci-dessus, et sans aucun doute d'autres qui seront proposées dans les mois à venir, les développeurs ont désormais un contrôle auparavant inimaginable sur la mise à l'échelle des chaînes de blocs.

Vitalik classe principalement les zkEVM en quatre types :

Type 1 ou entièrement équivalent à Ethereum : Ne changez aucune partie de l'écosystème Ethereum.

Type 2 ou entièrement équivalent à l'EVM : Compatible avec les dApps existantes, mais apporte quelques modifications à la conception d'Ethereum pour une génération plus rapide des preuves.

Type 3 ou presque équivalent à l'EVM : Prend en charge la plupart des opcodes EVM, mais supprime certaines fonctionnalités difficiles à implémenter dans une implémentation zkEVM (par exemple, les précompilations, les fonctions de hachage).

Type 4 ou équivalent à un langage de haut niveau : Prend le code de contrat intelligent écrit en Solidity / Vyper et le compile dans un langage compatible avec les Preuves de Validité.

Rollup de validité et le rôle de la machine virtuelle Cairo

• Les Rollups de validité sont le moyen le plus prometteur pour augmenter le débit d'Ethereum de manière sécurisée et décentralisée ; les zkEVM et la machine virtuelle Cairo (CVM) sont deux types de machines virtuelles utilisées par les Rollups de validité

• zkEVM se concentre sur la compatibilité avec Ethereum, mais sacrifie les performances et la scalabilité.

• Cairo VM, utilisée dans Starknet, privilégie les performances et la scalabilité par rapport à la compatibilité.

Les rollups sont le sujet phare de l'année lorsqu'il s'agit de mettre à l’échelle Ethereum. Parmi les différents types de Rollups, nous croyons que les Rollups de validité (VRs), également connus sous le nom de zk-rollups, sont le moyen le plus prometteur pour augmenter le débit d'Ethereum de manière sécurisée et décentralisée. Au cœur de cette solution de mise à l'échelle se trouve l'utilisation de preuves de validité pour la computation vérifiable.

Voici comment elles fonctionnent :

• Au lieu de traiter chaque transaction sur la chaîne principale Ethereum, les opérateurs déchargent l'exécution des transactions dans un environnement off-chain. Cet environnement off-chain sert de couche 2, c'est-à-dire une couche fonctionnant au-dessus d'Ethereum.

• Après avoir traité de vastes lots de transactions, l'opérateur de la couche 2 renvoie les résultats à appliquer à l'état d'Ethereum, ainsi qu'une preuve de validité pour vérifier l'intégrité de l'exécution off-chain. La preuve garantit que toutes les transactions d'un lot sont valides et est vérifiée de manière autonome par le contrat vérificateur on-chain. Cela permet à Ethereum d'appliquer le résultat à son état.

Note : Les Rollups de validité sont souvent incorrectement désignés comme des ZK Rollups, mais cela n'est pas exact. La plupart des Rollups de validité n'utilisent pas de preuves ZK et ne sont pas utilisés dans le but d'assurer la confidentialité. Par conséquent, le terme "Rollups de Validité" est plus précis.

Avant de poursuivre, la première question à laquelle nous devons répondre est : Qu'est-ce qu'une machine virtuelle (VM) ? En termes simples, c'est un environnement dans lequel des programmes peuvent s'exécuter, comme un Mac exécutant un système d'exploitation Windows. Elle passe d'un état à un autre après avoir effectué des calculs sur certaines entrées. La Machine Virtuelle Ethereum (EVM) est la VM qui exécute les contrats intelligents d'Ethereum.

Une Machine Virtuelle à Preuve de Zéro Connaissance (zkVM) est un environnement d'exécution de programme qui, conjointement avec les sorties du programme, permet la génération d'une Preuve de Validité pouvant être facilement vérifiée. Cette Preuve de Validité prouve que le programme a été exécuté correctement. Lorsque le terme "zkEVM" est utilisé, il se réfère généralement à un Rollup qui utilise la Machine Virtuelle Ethereum (EVM) et est capable de prouver les exécutions de l'EVM. Cette terminologie peut être trompeuse car l'EVM lui-même ne génère pas ces preuves ; à la place, les preuves sont générées par un mécanisme de preuve distinct qui prend les résultats de l'exécution de l'EVM comme point de départ. De plus, ces preuves concernent la validité, pas la confidentialité, elles ne sont donc pas exactement des preuves ZK. Néanmoins, pour des raisons de cohérence, nous utiliserons le terme conventionnel "zkEVM" dans cet exposé.

Bien que tous les Rollups de validité cherchent à exploiter les Preuves de Validité pour mettre Ethereum à l'échelle, ils diffèrent dans leur choix de VM pour exécuter les transactions off-chain. De nombreux Rollups de validité ont choisi de reproduire la conception de l'EVM (et sont donc appelés "Rollups zkEVM"), tentant de reproduire Ethereum sur les couche 2. Starknet utilise une nouvelle VM - la Machine Virtuelle Cairo (CVM) - qui a été spécifiquement conçue pour optimiser l'efficacité des preuves de validité.

Ces deux approches ont leurs propres avantages et compromis, mais les zkEVMs sacrifient les performances pour la compatibilité avec Ethereum, tandis que la Machine Virtuelle Cairo privilégie les performances par rapport à la compatibilité, mettant en avant les capacités de mise à l'échelle.

Un zkEVM est un Rollup de validité ayant pour objectif de porter complètement l'expérience Ethereum sur les chaînes de blocs de couche 2. Son but est de reproduire l'environnement de développement Ethereum en tant que Rollup. Avec les zkEVM, les développeurs n'auraient pas besoin de modifier leur code ou d'abandonner leurs outils EVM (et contrats intelligents) lorsqu'ils écrivent ou portent des contrats intelligents vers des solutions plus évolutives.

Un inconvénient majeur de cette approche est qu'elle réduit le potentiel de mise à l'échelle des Preuves de Validité. Les zkEVM sont plus lents et plus gourmands en ressources en raison de leur engagement envers la compatibilité avec Ethereum. Contrairement à la CVM, l'EVM n'a pas été conçu en gardant à l'esprit l'efficacité de la preuve. Cela limite l'utilisation d'optimisations qui pourraient améliorer l'efficacité et la scalabilité, affectant finalement les performances globales du système.

Le principal défi de l'approche zkEVM trouve ses origines dans la conception originale de l'EVM. Il n'a pas été conçu pour fonctionner dans un contexte de Preuve de Validité. Par conséquent, les efforts pour reproduire sa fonctionnalité ne parviennent pas à libérer le plein potentiel des preuves de validité, entraînant une efficacité inférieure à l'optimal. Une telle inefficacité finit par peser sur les performances globales du système. La compatibilité de l'EVM avec les Preuves de Validité est entravée par les facteurs suivants :

• L'EVM utilise un modèle basé sur une stack, tandis que les Preuves de Validité sont plus efficacement utilisées avec un modèle basé sur les registres. La nature basée sur la stack de l'EVM rend intrinsèquement plus difficile de démontrer la justesse de son exécution et de fournir un support direct pour sa chaîne d'outils native.

• La structure de stockage Ethereum repose fortement sur Keccak et un grand arbre de Merkle Patricia, qui ne sont pas favorables aux Preuves de Validité et imposent un fardeau de preuve substantiel. Par exemple, Keccak est très rapide pour les architectures x86 (sur lesquelles nous exécutons généralement l'EVM), mais nécessite 90 000 étapes pour être prouvé (avec une construction spéciale intégrée). Tandis que Pedersen (une fonction de hachage compatible avec les preuves ZK) nécessite 32 étapes. Même avec une compression récursive, l'utilisation de Keccak dans un zkEVM entraîne une utilisation élevée des ressources du prouveur, ce qui finit par être payé par l'utilisateur.

En conséquence, différents zkEVM visent différents niveaux de prise en charge des outils Ethereum, plus un zkEVM est compatible avec Ethereum, moins il est performant. (Pour plus d'informations sur les types de zkEVM, rendez-vous à la fin de l'article.)

Les solutions zkEVM investissent un temps de développement considérable dans "rendre l'EVM fonctionnel pour les Rollups de validité", en privilégiant la compatibilité plutôt que les performances et la scalabilité à long terme. Il existe une autre option : utiliser une toute nouvelle machine virtuelle (VM) dédiée et ajouter la prise en charge des outils Ethereum en tant que couche supplémentaire par-dessus. C'est l'approche adoptée par Starknet, un Rollups de validité sans permission lancé en novembre 2021. Starknet est le premier Rollups de validité à offrir une plateforme de contrats intelligents à usage général sur un réseau entièrement composable.

Starknet utilise la machine virtuelle Cairo (CVM), avec un langage de haut niveau du même nom. La machine virtuelle Cairo-VM est conçue pour une génération efficace de Preuves de Validité pour l'exécution des programmes.

Avec Cairo (la machine virtuelle et le langage), nous avons :

1. Des preuves de validité optimisées, chaque instruction possède une représentation algébrique efficace.

2. Un langage moderne similaire à Rust pour écrire des programmes prouvables.

3. Une représentation intermédiaire (Sierra) entre le langage de haut niveau Cairo et l'assembleur Cairo (instructions de la VM), ce qui permet une exécution efficace du code Cairo.

Le développement d'un nouveau langage permet de l'adapter aux besoins spécifiques qu'il est destiné à satisfaire, ainsi que de lui fournir des fonctionnalités répondant à des besoins précédemment non satisfaits.

Afin de créer une Preuve de Validité pour une certaine computation, il faut d'abord exprimer cette computation sous forme d'une séquence de contraintes mathématiques la décrivant la computation. Ce processus peut être très complexe en raison du défi d'optimiser les calculs pour l'efficacité, ainsi que du besoin d'outils spécialisés.

Le langage Cairo a été initialement conçu pour simplifier cette tâche et faciliter l'ajout de fonctionnalités et de business logique complexe à StarkEx. Les programmes Cairo sont compilés en un code machine algébrique - une séquence de nombres - qu'une VM fixe exécute. Avec Cairo, toute la complexité de la génération de contraintes mathématiques décrivant la computation - un problème épineux pour les Preuves de Validité - est abstraite et capturée par l'ensemble fixe de contraintes (moins de 50 contraintes au total). En conséquence, les développeurs peuvent exploiter les Preuves de Validité pour mettre à l'échelle leurs applications sans avoir besoin de comprendre les mathématiques sous-jacentes et l'infrastructure, en écrivant du code dans une syntaxe avec laquelle ils sont familiers.

https://twitter.com/EliBenSasson/status/1638270015009968134

Starknet est axé sur l'innovation, et cela se reflète dans son approche pluraliste du code. La puissance de Cairo pour obtenir la meilleure mise à l'échelle à l'aide des preuves STARK ne se limite pas à ceux qui écrivent nativement leurs contrats en Cairo. Les développeurs peuvent opter pour une approche qui leur convient le mieux :

1. Codage natif en Cairo : Avec la sortie de Cairo 1.0, les développeurs ont désormais accès à un langage ergonomique et sûr inspiré de Rust, ce qui facilite grandement l'écriture de la logique du programme et réduit les risques d'erreurs.

2. Compatibilité avec Solidity : Les développeurs Solidity peuvent écrire du code pouvant être utilisé par la machine virtuelle Cairo. Cette méthode offre une expérience de développement similaire à Ethereum et permet de rendre les contrats intelligents Solidity portables vers Starknet. Il existe deux façon d'atteindre cela :

   • zkEVM sur Starknet : La machine virtuelle Cairo peut être utilisée pour prouver l'exécution d'une autre machine virtuelle. Kakarot est un zkEVM écrit en Cairo, qui peut être utilisé pour exécuter les contrats intelligents Ethereum sur Starknet. La machine virtuelle Cairo et le zkEVM ne sont pas des approches concurrentes, et au lieu de choisir entre la machine virtuelle Cairo et le zkEVM, nous pouvons avoir les deux !

   • Transpilation : précédemment possible avec Wrap, projet mené par Nethermind dont le développement ils ont annoncé l’arrêt cet été.

Bien que Cairo soit récent, c'est le 4e langage de contrat intelligent le plus populaire en termes de TVL (Total Value Locked) et il sécurise déjà plus de 350 millions de dollars.

Un zkEVM vise à reproduire l'environnement Ethereum en tant que Rollup de validité et permet aux développeurs d'utiliser des outils Ethereum familiers. Cependant, cette approche limite le plein potentiel des Preuves de Validité et peut être gourmande en ressources.

La machine virtuelle Cairo est spécialement conçue pour les systèmes de Preuve de Validité, sans être limitée par les contraintes de l'EVM. Elle est soutenue par un nouveau langage de programmation sûr et ergonomique inspiré de Rust, appelé Cairo 1.0, formant un outil puissant conçu pour tirer le meilleur parti des preuves STARK pour mettre Ethereum à l'échelle.

Il est passionnant de voir les performances que Cairo réalise semaine après semaine, ainsi que la croissance des différentes options pour les développeurs, telle que le zkEVM Kakarot. À mesure que les applications Starknet entrent en production, démontrant la puissance de Cairo, nous sommes convaincus qu'il sera utilisé pour des projets de plus en plus ambitieux à l'avenir.

Grâce aux trois voies de mise à l'échelle STARK décrites ci-dessus, et sans aucun doute d'autres qui seront proposées dans les mois à venir, les développeurs ont désormais un contrôle auparavant inimaginable sur la mise à l'échelle des chaînes de blocs.

Vitalik classe principalement les zkEVM en quatre types :

Type 1 ou entièrement équivalent à Ethereum : Ne changez aucune partie de l'écosystème Ethereum.

Type 2 ou entièrement équivalent à l'EVM : Compatible avec les dApps existantes, mais apporte quelques modifications à la conception d'Ethereum pour une génération plus rapide des preuves.

Type 3 ou presque équivalent à l'EVM : Prend en charge la plupart des opcodes EVM, mais supprime certaines fonctionnalités difficiles à implémenter dans une implémentation zkEVM (par exemple, les précompilations, les fonctions de hachage).

Type 4 ou équivalent à un langage de haut niveau : Prend le code de contrat intelligent écrit en Solidity / Vyper et le compile dans un langage compatible avec les Preuves de Validité.