Vitalik participe à l'investissement : comment Kakarot intègre-t-il la machine virtuelle Ethereum (EVM) dans Starknet ?
TechFlow SélectionTechFlow Sélection
Vitalik participe à l'investissement : comment Kakarot intègre-t-il la machine virtuelle Ethereum (EVM) dans Starknet ?
Dans cet article, l'analyste cookies explorera les différentes étapes de Kakarot, ses avantages et inconvénients, ainsi que les défis et opportunités auxquels le projet est confronté.
Dédié à des analyses Web3 approfondiesRédaction : cookies
Traduction : TechFlow
Kakarot zkEVM est une EVM implémentée en Cairo, conçue pour renforcer la compatibilité EVM et étendre l'écosystème de Starknet. Qu'est-ce qui lui a valu le soutien de Vitalik et de StarkWare ? Dans cet article, l'analyste cookies examine les différentes phases de Kakarot, ses avantages et inconvénients, ainsi que les défis et opportunités auxquels le projet est confronté.
Qu'est-ce que CairoVM ?
Kakarot repose sur la machine virtuelle (VM) CairoVM, qui constitue l'infrastructure fondamentale de Starknet.
Principales caractéristiques de CairoVM :
· Représente l'exécution sous forme de polynômes (équations) afin d'en garantir la vérifiabilité ;
· Permet d'utiliser des preuves STARK pour toutes les transactions de Starknet.
Qu'est-ce que Cairo ?
Une architecture CPU complète au sens de Turing et compatible STARK :
· Complète au sens de Turing : le système peut exécuter tout calcul ou programme imaginable ;
· Compatible STARK : système de preuve fourni par StarkWare. L'intégrité du calcul hors chaîne est prouvée par un prouveur et vérifiée par un vérificateur sur chaîne.
Fonctionnement de Cairo
Les développeurs peuvent utiliser Cairo pour écrire des programmes dans CairoVM, en décrivant en langage évolué l'énoncé à prouver. Cela améliore l'expérience des développeurs, car ils peuvent tirer parti de l'extensibilité offerte par les preuves à divulgation nulle de connaissance (ZKP), sans avoir à apprendre à concevoir des circuits complexes.
Architecture de Kakarot
Kakarot s'appuie sur CairoVM et est :
· Un interpréteur de bytecode EVM ;
· Un contrat intelligent (SC) déployé sur Starknet ;
· Écrit en Cairo.
Kakarot permet :
· Le déploiement de contrats intelligents EVM existants.
Kakarot n'est pas :
· Une blockchain ;
· Un compilateur : il ne convertit pas le code Solidity en Cairo.
À ce jour (mai 2023) :
· Architecture de bytecode à 100 % (zkEVM de type 3) ;
· Implémentation de 8 précompilations EVM sur 9.
Une fois les 9 précompilations EVM implémentées, Kakarot deviendra un zkEVM de type 2,5.
Le zkEVM de type 1 est entièrement équivalent à Ethereum, sans modification du système Ethereum, afin de faciliter la génération de preuves,
Avantages : solution ultime pour l'extension d'Ethereum.
Inconvénients : intensif en calcul, temps de preuve long (plusieurs heures).
Exemples : Scroll, Taiko.
Le zkEVM de type 2 est entièrement équivalent à l'EVM, avec de légères modifications du système Ethereum (utilisation d'une fonction de hachage différente) afin de :
· Faciliter le développement ;
· Accélérer la génération des preuves.
Avantages : la majorité des dApps Ethereum sont utilisables.
Inconvénients : problèmes d'efficacité liés à l'EVM et peu adaptée aux ZK.
Exemple : Scroll.
Le zkEVM de type 2,5 est équivalent à l'EVM, sauf pour les coûts en gaz. Il augmente le coût en gaz de certaines opérations spécifiques dans l'EVM qui sont difficiles à prouver via ZK.
Avantages : moins de risques comparé à une EVM plus large.
Inconvénients : réduction de la compatibilité avec les outils de développement, certaines dApps ne seront pas compatibles.
Le zkEVM de type 3 est presque équivalent à l'EVM, mais supprime uniquement les fonctionnalités particulièrement difficiles à implémenter (par exemple certaines précompilations).
Avantages : temps de preuve encore plus rapide, développement EVM facilité.
Inconvénients : certaines dApps devront être réécrites.
Exemples :
· Scroll ;
· Polygon.
Le zkEVM de type 4 est équivalent au niveau du langage évolué : il compile le code source des contrats intelligents (langage haut niveau) vers un langage compatible ZK-SNARK.
Avantages : évite de nombreux frais généraux.
Inconvénients : les contrats peuvent ne pas avoir la même adresse qu’ils auraient sur l’EVM, le bytecode EVM écrit manuellement pourrait ne pas être pris en charge, les infrastructures ne peuvent pas être transférées car elles reposent sur le bytecode EVM.
Exemples :
· zksync ;
· Nethermind.
Feuille de route de Kakarot | Phase 1 | Introduire l'EVM dans Starknet
Initialement, Kakarot existera comme une EVM intégrée (Enshrined EVM) au sein de Starknet. L'expérience des développeurs et des utilisateurs (UX) sera identique à celle de Polygon, Scroll ou Ethereum.
Phase 2 | zkEVMs L3
Déploiement de chaînes applicatives zkEVM via Kakarot, leur permettant d'utiliser des preuves de validité pour traiter les transactions sur Starknet. Réalisé en combinant Kakarot et MadaraStarknet en une pile unifiée.
D’un simple clic, les rollups obtiennent :
· Un zkEVM spécifique à l'application déployé sur Starknet ;
· Un accès à l’environnement EVM ;
· Une exécution rapide ;
· Des frais de gaz faibles : grâce à des solutions de disponibilité des données ;
· La sécurité.
En exécutant des contrats Solidity SC dans CairoVM via Kakarot : tout contrat Solidity déployé sur EVM pourra s’exécuter sur Starknet sans modification de code.
Capable de combiner les deux avantages :
· L'efficacité de l'EVM ;
· Les contrats intelligents deviennent vérifiables.
Phase 3 | zkEVM de type 1
Pour y parvenir, Kakarot doit :
· Utiliser Cairo pour implémenter les règles de consensus d’Ethereum dans un nœud complet Madara x Kakarot, afin de prouver le consensus L1 ;
· Passer de l’arbre de Merkle Patricia Trie (MPT) Pedersen à l’arbre MPT Keccak.
Ceci dépend de la feuille de route d’Ethereum : Verge. Actuellement, la mise en œuvre de MPT Keccak de manière vérifiable et économique constitue le principal obstacle à la compatibilité zkEVM. Après Verge, Keccak pourrait être remplacé par Poseidon comme fonction de hachage privilégiée d’Ethereum.
Mon analyse
C’est assurément une étape majeure vers l’intégration de la compatibilité EVM dans Starknet, mais certains points critiques entourent toujours le succès de Kakarot.
Face à la concurrence suivante
· Rollups ZK utilisant un système de preuve différent (SNARK) : Scroll, zksync, Polygon, Taiko, Linea ;
· Rollups optimistes : Optimism, Arbitrum, Base ;
· Autres zkVM : RISC Zero, Hyper Oracle.
Adéquation produit-marché (PMF)
Globalement, le modèle « Rollup-as-a-service » reste une proposition non encore validée, nécessitant de considérer deux aspects clés :
· Combien de rollups auront besoin de ce service ?
· Les rollups préféreront-ils construire en interne pour assurer souveraineté et personnalisation ?
Produit en itération constante
Kakarot construit un produit extrêmement complexe techniquement, qui pourrait nécessiter des itérations continues pour réussir. Il dépend également de plusieurs composants externes, notamment :
· Madara ;
· Solution DA (disponibilité des données) ;
· Feuille de route d’Ethereum : The Verge.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
cookies
