Introduction

Après avoir bénéficié d’une traction énorme depuis sa sortie en 2015, Ethereum Mainnet - ou Ethereum Layer 1 (ETH L1) - souffre de son succès. Sa scalabilité est limitée et le réseau souffre de plus en plus des congestions récurrentes dues à une croissance exponentielle du nombre d'utilisateurs. En période d’intense utilisation, de fortes augmentations des coûts de transactions et un allongement de leur délai de validation.

Ces contraintes pénalisent l’expérience utilisateur d’Ethereum, et impactent son développement, son adoption et son champ des possibles.

Plusieurs pistes de solutions permettant d’outrepasser ces limitations ont été étudiées. Cet article à pour but de vous présenter l’une d’elle : StarkNet.

Pour ce faire, nous allons :

• Présenter succinctement les principales solutions qui existent pour résoudre le problème de scalabilité d’Ethereum,
• Se concentrer sur les Rollups et présenter leur fonctionnement technique général,
• Evoquer l’histoire de StarkWare et le développement de StarkNet,
• Présenter l’écosystème StarkNet.

Notes des auteurs : Nous ne sommes pas membres du projet et nous avons souhaité réaliser cet article afin d’approfondir notre connaissance de l’écosystème et de la faire partager au plus grand nombre. Nous ne sommes pas experts techniques. Par conséquent, certains éléments pourraient avoir été mal compris et mal retranscrits. Si vous remarquez de grosses âneries, on vous invite à nous contacter en DM sur Twitter @nono01022 & @cleminso.

Nos avons consulté de nombreuses sources disponibles sur internet pour constituer cet article. Nous avons cherché à nous approprier le maximum de connaissances et de vous les retranscrire sous la forme la plus compréhensible. Nous avons essayé de suivre un processus journalistique strict. Cependant, vous auteurs qui nous lisent, si vous considérez qu’une partie de votre travail a été utilisée dans cet article sans mention de la source & sans votre accord, faites nous savoir en DM et nous trouverons une solution.

1. Les solutions de scalabilité

a. Les autres Layer 1

Ethereum pouvant apparaître comme mal conçu, une des idées suivies a été de reconstruire entièrement une Blockchain plus scalable et plus rapide. Les exemples de ces Blockchains sont multiples : Binance Smart Chain (BSC), Avalanche, Fantom, Harmony, Solana, etc. Les blockchains dites EVM compatibles utilise la machine virtuel Ethereum pour fonctionner, en autre elle parlent le même langage et donc une app écrite en solidity peut également être déployer sur toutes les autres chain EVM compatible sans modification.

Cependant, selon le trilemme des blockchains, ces avantages sont bien souvent acquis grâce à un “compromis sur la” (lisez “moins de”) décentralisation. On sacrifie la résilience de la Blockchain pour plus de rapidité et de scalabilité. (Ce n’est pas toujours le cas on ne sacrifie pas toujours la décentralisation mais au moins une des 3 composantes)

b. Les Sidechains

Elles sont dénommées de manière générique SideChain, soit en français Chaine d’à côté, c'est-à-dire qui évolue en parallèle d’Ethereum. On compte notamment Polygon & Gnosis Chain. Elles se comportent comme des Layer 1 alternatifs à Ethereum, en validant les transactions directement sur leur chaine.

Cependant, elles envoient régulièrement des rapports d’activité de leur Chaine sur la blockchain Ethereum. Ainsi, elles bénéficient d’une résilience plus importante en cas de problème survenu sur leur réseau.

c. Modifier la structure d’Ethereum (ex : The Merge)

Il serait pertinent d’avoir la réflexion suivante : “Ethereum est un logiciel : il suffit de le mettre à jour !”.

En effet, Il est possible de mettre à jour et d’implémenter de nouvelles fonctionnalités dans la blockchain Ethereum. Ces modifications/mises à jour sont appelées EIP pour Ethereum Improvement Proposal. Très simplement, le processus est le suivant :

• On propose et on rédige la proposition et on lui donne un numéro : par exemple l’EIP1559.
• Des discussions sont menées par la communauté sur cette proposition : avantages, inconvénients, développement, fonctionnement, implémentation, etc.
• Si une majorité s’entend sur un consensus, il sera suivi par la communauté : implémenter la proposition, la retravailler pour l’améliorer ou abandonner l’EIP.

Cependant, pour pouvoir améliorer la scalabilité, il faudrait toucher au cœur même de la machine Ethereum. Et c’est compliqué. Trèèèèès compliqué.

Imaginez, avec les moyens actuels, repeindre l’intégralité des routes de France avec une peinture de couleur Jaune. Cela sans interférer avec le trafic habituel, donc :

• sans immobiliser aucun véhicule,
• ni barrer une seule route,
• ni laisser de trace jaunes sur les pneus des usagers de la route.

On approche du niveau de difficulté de The Merge.

Il faut arriver à mettre à jour la Blockhain Ethereum, sans mettre en suspens le trafic qu’il y a dessus et assurer la compatibilité avec l’intégralité de l’écosystème qui ne cesse de se développer jour après jour.

C’est une opération qui est d’une complexité extrême, et qui prend des années à être organisée. The Merge représente la plus grande mise à jour d’une blockchain jamais opérée jusqu’alors. Sans rentrer dans le détail de chaque changement qu’elle va apporter, et seulement sur le point de la scalabilité : elle va permettre d’améliorer très légèrement la rapidité d’Ethereum Mainnet (environs 10%) en réduisant la durée moyenne de validation des blocs de 13,5 secondes à 12 secondes. Ce qui n’est pas suffisant au vu du trafic actuel et à venir.

Pourquoi ne pas en faire plus alors ? Parce que les développeurs se confrontent à nouveau au Trilemme de la Blockchain évoqué plus haut. Ethereum ne cherche pas à faire de compromis sur la sécurité et la décentralisation. C’est une des Blockchains les plus résilientes derrière Bitcoin. De plus, d’autres pistes semblent bien plus efficaces, et moins contraignantes à mettre en place.

d. Les Rollups.

• Ethereum a un nombre de transactions maximal par seconde (TPS) trop faible par rapport à sa popularité.
• Le système de validation des transactions et des blocs dans lesquels ces dernières sont archivées est la chose la plus importante pour assurer la véracité de l’information et la durabilité de celle-ci.

Pourquoi ne pas déporter une partie des transactions hors d’Ethereum Mainnet et les renvoyer seulement quelques informations primordiales sous une forme compacte sur le Mainnet, sans quitter l’écosystème Ethereum ?

Ainsi :

• On retire la gestion/validation de ces transactions à Ethereum Mainnet qui s’en verra décongestionné.
• On ne fait pas de compromis sur la sécurité, car :
  • On ne quitte pas l’écosystème Ethereum,
  • On renvoie des données essentielles prouvant la validité de ces transactions sont renvoyées le Mainnet.

C’est ainsi qu’opèrent les rollups. Ils déplacent le calcul (et le stockage de l’état) off-chain, mais conservent certaines données par transaction on-chain.

“En pratique, des smart contracts sont déployés sur la chaîne principale et font office de ponts entre ETH et les solutions de seconde couche. Lorsqu’un grand nombre de transactions sont enregistrées sur le Rollup, celles-ci sont aggrégées et publiées sur Ethereum Mainnet sous la forme d’une seule transaction, toujours via des smart contracts.” (source : coinacademy)

Les transactions sont validées en dehors de la blockchain Ethereum (off-chain) avant d’être agrégées et envoyées sur ETH L1 sous une seule transaction.

Il en existe deux grandes catégories Rollup, avec un fonctionnement et des performances qui diffèrent :

• Les Optimistic Rollup (Arbtirum, Optimism, etc.)
• Les Zero Knowledge Rollup ou ZK-Rollup. (Loopring Zk-Sync, StarkNet, etc.).

2. Les rollups

a. Principes de fonctionnement commun

Le fonctionnement des Rollup fait appel à la notion d’Arbre de Merkle.

Un smart contrat déployé sur le Mainnet Ethereum va maintenir une racine d’État, qui correspond à l’état des données qui sont contenues à l’intérieur du rollup (solde des comptes, code contract, etc.). Cet état va être amené à évoluer à la suite d'interactions réalisées dans le roll-up (transactions, interactions avec des smarts contracts, etc.). Ces modifications sont agrégées ensemble, avec l’ancienne racine d'état et sont fortement compressées via tout un système d’astuces de compression. On appelle cela la Publication d’un Lot/Batch*.*

Le contrat va alors vérifier que la racine d’état précédente du Lot correspond à sa racine actuelle, et si c’est le cas, la nouvelle racine d’état prend la place de la précédente dans le contrat du Roll-up.

De nouvelles interactions peuvent avoir lieu, qui mène à la publication d’un nouveau Lot, etc.

b. Validité des transactions

Nous avons décrit précédemment le fonctionnement de validation d’un Lot par rapport à son état précédent.

Mais rien n'empêche un auteur frauduleux de faire passer une transaction dans laquelle il transférerait l’intégralité des contenus des portefeuilles du Rollup sur son propre portefeuille ? **

En d’autres termes : Comment les transactions d’un Lot sont-elles considérées comme valides et non frauduleuses ?

Ce mécanisme de vérification des transactions - et donc de sécurisation des fonds - a génèrer des divergences entre les différents rollup.

c. Optimistic Rollup

Les Optimistics Roll-up utilisent une Preuve de Fraude.

Les utilisateurs du roll-up vont, par leurs activités, réaliser des transferts et publier leurs interactions sur le réseau. Ils vont donc modifier l’état du Roll-up. Ils sont appelés émetteurs.

Ensuite, les agrégateurs agrègent les transactions sous forme de Lots et publient le changement d’état sur Ethereum Mainnet.

Les règles pour sélectionner qui peut prétendre à ce poste diffèrent selon les caractéristiques des roll-up, mais en général, pour soumettre un lot, ils doivent déposer un montant conséquent afin de garantir leur bonne foi. Si jamais ils s’avéraient avoir un comportement frauduleux : ce dépôt serait en partie brûlé ou donné en récompense à celui qui a prouvé la fraude.

Le contrat de Rollup conserve une trace de tout son historique, de ses racines d’état au cours du temps et l’emprunte cryptographique de chaque Lot. Et n’importe qui peut vérifier que chaque empreinte cryptographique d’un lot correspond bien à sa racine d’état associée. Chaque Lot peut etre vérifié pendant 7 jours après sa publication, avant d’être définitif.

Cas pratique :  C’est pour cette raison que lorsqu’un retrait de fonds est effectué depuis un Optimistic Roll-up vers le Mainnet Ethereum, il y a un délai d’attente de 7 jours.

Durant ces 7 jours, des vérifieurs - n’importe qui en mesure de calculer la racine d’état et vérifier si elle est correcte - vont venir réaliser des contrôles entre empreinte cryptographique d’un lot & racines d’état. Or, s’il s’avère qu’un lot avait une racine post-état incorrecte, le vérifieur peut publier une preuve (la racine d’état valide) de cette erreur on-chain, prouvant que le Lot a été mal calculé. Le contrat vérifie la preuve et renvoie ce lot ainsi que tous les lots suivants.

Le vérifieur va ainsi être récompensé et l’agrégateur frauduleux sanctionné, le premier récupère une partie du collatéral déposé par le second.

d. Zk-Rollup

Les zk-rollup utilisent des Preuves de Validités.

Comme pour les Optimistic Rollup, nous allons retrouver les émetteurs et les relayeurs(=agrégateurs). Ces derniers sont en charge de collecter & agréger les transactions. Les agrégateurs vont ensuite publier les transactions dans un Rollup et générer une preuve, qui représente la différence d’état des comptes avant et après Rollup.

i. Principe de fonctionnement technique - Allégorie de la caverne

Imaginons une grotte en forme d’anneau avec une seule entrée et une porte magique qui sépare deux chemins latéraux. Pour franchir la porte magique, il faut murmurer les mots secrets appropriés. Imaginez qu'Alice veut prouver à Bob qu'elle connaît les mots secrets - tout en les gardant secrets. A cette fin, Bob accepte d'attendre dehors, pendant qu'elle entre dans la grotte et marche jusqu'au bout de l'un des deux chemins possibles. Dans cet exemple, elle décide de passer par le chemin 1.

*Après un moment, Bob passe devant l'entrée et crie de quel côté il veut qu'Alice apparaisse (chemin 2 dans ce cas). Si Alice connaît vraiment le secret, elle se montrera sûrement depuis le chemin qu’a choisi Bob. Tout ce processus peut être répété plusieurs fois (*potentiellement un nombre infini) afin de confirmer qu'Alice ne choisit pas le bon chemin par hasard.

Les preuves à divulgation nulle de connaissance (zero knowledge proof) permettent à un individu de prouver à un autre qu’une déclaration est vraie, sans divulguer d’autres informations que la validité de la déclaration. Les parties impliquées sont communément appelées « prouveurs » et « vérificateurs », et l’attestation qu'elles détiennent en secret s'appelle un « témoin ». L'objectif principal de ces preuves est de révéler le moins de données possible entre les deux parties. En d'autres termes, on peut utiliser des preuves à divulgation nulle de connaissance pour prouver qu'on possède certaines connaissances sans révéler aucune information sur la nature des connaissances en elles-mêmes. (source)

ii. zk-SNARK

L’acronyme signifie Zéro-Knowledge Succinct Non interactive ARgument of Knowledge – littéralement : argument de connaissance succinct non-interactif à divulgation nulle de connaissance. (source)

Si on décompose l’acronyme sur la base anglaise, nous avons ceci :

• Zero Knowledge - Divulgation nulle de connaissance : Garantit la confidentialité des transactions.
• Succint - Succinct : signifie que les preuves sont de taille réduite et peuvent être rapidement vérifiées.
• Non interactive - Non itératif : Il y a peu ou pas d'interaction entre le “prouveur” et le “vérifieur” (c’était le cas avant sur d’anciens systèmes). Donc il y a peu de risques de collusion entre les deux.
• Argument - Argument : L’argument est considéré comme rationnel sur le plan informatique, ce qui signifie qu'un prouveur malhonnête a très peu de chances de tricher avec succès. Cette propriété est appelée solidité ou soundness. L’Argument pourrait être falsifié si un acteur disposait d’une puissance de calcul démesuré, c’est pour cela que certains considèrent les ordinateurs quantiques comme une menace pour les zk-SNARK.
• of Knowledge - de connaissance : il n'est pas possible pour le prouveur de construire une preuve sans avoir réellement l’information (ou le témoin) pour appuyer sa déclaration.

Ces preuves sont créées de manière cryptographique, afin de prouver que la racine post-état est le résultat correct de l’exécution du lot.

zk-SNARK permet, via la génération de cette preuve de validité, de diminuer le nombre d'informations contenues dans un roll-up et donc d'être encore plus scalable que les Optimistic.

Point de faiblesses :

• l’argument :   La solidité de l’argument suppose que le prouveur dispose d'une puissance de calcul limitée. Théoriquement, un prouveur disposant de suffisamment de puissance de calcul pourrait créer de fausses preuves (risque ordinateur quantique cité plus haut).
• Non itératif : Bien qu’il n’y ai peu ou pas d'interaction entre un prouveur et un vérifieur, les preuves zk-SNARK dépendent d'une configuration sécurisée initiale entre un prouveur et un vérifieur, ce qui signifie qu'un ensemble de paramètres publics est nécessaire pour construire des preuves à divulgation nulle de connaissance et, par conséquent, des transactions privées. Ces paramètres ressemblent à une règle de jeu, ils sont encodés dans le protocole et constituent l’un des facteurs nécessaires pour prouver la validité d’une transaction. Cependant, cela crée un point de centralisation potentiel, car les paramètres sont souvent élaborés par un très petit groupe.

Cas pratique :  Si une personne avait accès au caractère aléatoire qui a généré les paramètres de la configuration initiale, elle pourrait créer de fausses preuves qui auraient l’air valables pour le vérifieur.

Génération de la Preuve de validité : Elle demande un effort plus conséquent et un calcul plus important, pouvant limiter la scalabilité du système, en comparaison avec un Optimistic roll-up.

iii. zk-STARK

Les zk-STARKs ont été créés comme une version alternative des preuves zk-SNARKs avec les améliorations suivantes : Il ne nécessite pas de configuration initiale de confiance. Le T signifie donc Transparent. Il remplace le N (Non-iterratif).

Dans les faits, pour se passer de cette configuration initale de confiance, les zk-STARKs viennent s’appuyer sur des méthodes cryptographiques qui sont résistantes aux collusions entre prouveur et vérifieur. Et cela a pour conséquences :

• d’éliminer les risques de zk-SNARKs qui coûtent cher.
• d’éliminer le risque d’attaque par des ordinateurs très puissants (de type quantique)

En effet, avec les zk-SNARK, le nombre d’échanges entre pouveur et vérifieur est corrélé à la difficulté de calcul. Ce n’est plus le cas avec zk-STARK, où le nombre de tours de communication reste stable entre les parties. La taille des données est donc plus faible sur les zk-STARK, ce qui permet une implémentation moins chère et plus rapide de la technologie.

Point de faible :

Il autorise la Turing Completeness, ce qui le rend difficilement compatible avec l’Ethereum Virtual Machine (EVM).

Explication du terme :

Scalabilité (S) : signifie que deux propriétés d’efficacité tiennent simultanément (ref) ici est pris en compte celle du prouveur et du verifieur

Transparence (T) : signifie qu’il n’y a pas besoin de configuration de confiance, il n’y a pas d’utilisation de secrets dans la mise en place du système, à la différence des preuves SNARKs.

Avantages : Élimine la procédure de génération de configuration des paramètres qui constitue une potentielle faille.

e. Comparatif & performances

Afin de mieux visualiser les avantages chiffrés d’un roll-up, voici quelques comparaisons entre différentes actions exécutées sur un Roll-up et sur L1. Ces informations proviennent du site Ethereum-france et sont issus d’un article de Vitalik Butterin.

f. Plan de décentralisation

Dans les faits, les roll-up ne sont pas encore décentralisés. Dans le cadre de leur développement et afin de garantir la réactivité et l’efficience des corrections appliquées sur ces systèmes récents, de nombreux points de centralisation perdurent. Cependant, la vision à long terme de tous les roll-ups est la décentralisation.

StarkNet a fait le choix d’axer son développement selon cet ordre : Usage → Performance → décentralisation.

Après avoir développé la partie Usage (avec StarkEx notamment), la partie Performance va arriver courant 2022 avec la release de StarkNet sur le Mainnet. Le début de la Décentralisation est attendue commencera par la suite (probablement 2023). Le plan de décentralisation devrait quant à lui être précisé dans les prochains mois, actuellement en discussion sur le forum de gouvernance. Cela concernera :

• Le développement de full-node : N’importe qui sera en mesure de vérifier et conserver une copie du réseau localement. 3 teams développent actuellement des full nodes (Erigon, Nethermind & Equilibrium - rajouter les tweets)

• L’ouverture du séquensing et du proving des des transactions, avec la sortie d’un logiciel à destination du public : N’importe qui pourra participer au séquencage et à la génération de preuve sur StarkNet.

• Une structure va etre développée pour récompencer les personnes impliqués, incluant des récompenses pécunières. Les fees généres par Starknet seront redistribuée en partie, aux séquenseurs et aux prouveurs.

• À moyen terme le séquenseur développé par StarkWare sera dispoinible pour les tierces parties, et dans le long terme, ils esperent voir de nouvelles teams construires des séquenseur dédié au séquensage sur SartkNet.

  Tout un programme qui ne va pas se faire en un jour !

g. Disponibilités des données

La disponibilité des données est un des gros leviers pour les rollup.

Il consiste à renvoyer ou non les informations des transactions effectuées et validées sur les rollup. Cela permets dans un cas :

• De garantir la sécurité des transactions sur Ethereum Mainnet, mais augmente et la quantité de données à renvoyer sur le L1 au détriment des frais de gas .
• De pouvoir effectuer des transactions à un coût extrêmement faible, en conservant ses données sur le Rollup. Ainsi, en cas de défaillance du Rollup, il ne serait (théoriquement) pas possible de retrouver les transactions.

Sur Optimistic : La Data Availability ou DA est disponible sur L1.

Sur les zk-roll-up : les systèmes diffèrent et des alternatives sont étudiées :

• Sur StarkNet : Grâce à Volition, il sera possible de manière indépendante, pour chaque transaction, de renvoyer les données ou non sur le L1. Cela aura des conséquences sur le prix des fees de Tx, et les données non renvoyées seront conservées par un Data Availabilty Comitee, réputées sûr, mais centralisé.
• Sur zkSync : Il sera possible grâce à zkPorter de créer des sous-comptes ou les Données des Tx ne seront pas ramenées sur le L1, afin d’augmenter la scalabilité. Les données seront garanties par un réseau de “Guardians” qui seront récompensés par le Token natif de ZkSync.

3. StarkNet

StarkNet est un zk-STARK développé par la société StarkWare.

a. Histoire de StarkWare

La société StarkWare a été fondée en 2018 par une équipe chevronnée comptabilisant plus de 70 personnes aujourd’hui, voici la présentation des co-foundateurs :

• Eli Ben-Sasson, président et co-fondateur

Il obtient en 2001 son doctorat en informatique théorique de l’Hebrew University. Il effectue des recherches en cryptographie, plus précisément sur les zero knowledge proofs. Connu pour être le co-inventeur des preuves STARKS ainsi que du protocole Zerocash, il est l’un des scientifiques fondateur de la société Zcash. Eli occupera des postes de chercheur en mathématique à Institute for Advanced Study at Princeton, mais aussi à Havard et au MIT.

Linkedin | Twitter

• Uri Kolodny, co-fondateur et PDG

Il est titulaire d’un B.Sc. (Magna cum Laude) en informatique de Hebrew University et d’un MBA de MIT Sloan. Il a également co-fondé d’autres entreprises technologiques telles que OmniGuide et Mondra. Il a également travaillé en tant qu’EIR pour deux VC israéliens et en tant qu’analyste chez McKinzey.

Linkedin | Twitter

• Michael Riabzev, co-fondateur et architecte en chef

Titulaire d’un doctorat en informatique à Technion Israel Institute, Michael s’est concentré sur le développement de systèmes pratiques pour l’intégrité computationnelle dans les zero knowledge menant à la mise en œuvre du système zk-Stark. Il comptabilise 14 ans d’expérience dans le développement de logiciels, notamment à Intel et IBM Research Labs.

Linkedin | Twitter

• Alessandro Chiesa, co-fondateur et Chief Scientist

Il est professeur d’informatique à l’université de Berkeley, ses recherches portent sur les différents domaines tels que la théorie de la complexité, de la cryptographie et la sécurité ainsi que les applications pratiques des zero knowledge proof.

Tout comme Eli, il est Co-inventeur du protocole Zerocash et co-fondateur de la société Zcash, il est également l’auteur de Libsnark (librairie open-source pour les démonstrations succinctes de zero knowledge proof.)

Linkedin | Github

StarkWare a levé 161 millions de dollars auprès de différents “Ventures Capital” tels que : Paradigm; Pantera (la liste est disponible sur le site officiel et le détail est disponible sur Cypherhunter).

De plus, ils ont reçu une subvention de 12 millions de dollars de la Fondation Ethereum. On retrouve notamment dans les premiers investisseurs de grand nom tel que Vitalik Buterin - co-fondateur d’Ethereum - et Naval Ravikant - connu pour être l’un des fondateurs d'AngelList et de CoinList et investisseur dans de nombreux projets web2 ou web3.

Détail des levées de fonds :

• Janvier 2018 : 6 millions de $ levés. Dans ce premieur Tour, on y retrouve déjà Vitalik Buterin et Naval Ravikant accompagné de VC tel que Pantera, Polychain...
• Octobre 2018 : 30 millions de $ levés en série A dirigé par Paradigm
• Mars 2021 : 75 millions de $ levés en série B dirigé par Paradigm
• Novembre 2021 : 50 millions de $ levés en série C dirigé par Sequoia Capital
• Mai 2022 : 100 millions de $ levés en série D dirigé par Greenoaks Capital  et Coatue

b. StarkEx - Premier produit de StarkWare

StarkEx lancé en juin 2020 est le moteur dédié à la scalabilité de la couche secondaire d’Ethereum. Déjà déployé sur le mainnet, il permet d’effectuer des opérations complexes :

• Création de produits financiers & dérivés,
• Applications de Trading de Jetons & de NFTs,
• Jeux utilisant des NFT.

C’est notamment sur cette technologie qu'ont été construites les applications DeversiFi, dYdX, Immutable et Sorare.

StarkEx a permis à l’équipe de Starkware de tester ses outils et de mieux comprendre les besoins de l’écosystème. Il intègre des oracles de prix tels que Chainlink.

Une force de StarkEx est d’être disponible en plusieurs modes de data availability, on l’en retrouve 3 :

• Rollup, les données sont stockées on-chain. Ainsi, les transactions sont enregistrées en tant que données d'appel.
• Validium, les données sont stockées off-chain. C’est une solution plus scalable qui consomme une quantité relativement fixe de ressources de la blockchain, indépendamment du volume d'activité. Ce mode a l’avantage de ne pas nécessiter de paiement on-chain. Seul le coût en gas de vérification de la preuve est requis pour mettre à jour l’état de la blockchain.
• Volition, solution hybride on-chain/off-chain permettant aux utilisateurs de choisir eux-mêmes à tout moment de choisir ou souhaitent stocker leurs données.

c. StarkNet - La solution de scalabilité d’Ethereum

StarkNet est un Zero-Knowledge Rollup (ZK-Rollup) décentralisé, permissionless et résistant à la censure qui prend en charge le calcul général sur Ethereum. Il est basé sur le langage Turing-complet Cairo, différent de Solidity.

La solution de scalabilité fait appel à trois acteurs du réseau :

• les développeurs. Ils peuvent créer des applications, implémenter leur propre Business Logic et les déployer sur StarkNet.
• les utilisateurs. Ils peuvent envoyer des transactions à StarkNet pour qu’elles soient exécutées, tout comme ils interagissent avec Ethereum aujourd'hui.
• les nœuds StarkNet.  Ils seront incités sur le plan crypto-économique pour garantir que le réseau fonctionne de manière efficace et équitable.

Son objectif est d'atteindre la même sécurité et les mêmes propriétés permissionless que celles d'Ethereum.

d. L’Ecosystème

Cette seconde partie porte sur les projets developpés sur StarkEx ainsi que Starknet, respectivement lancés courant 2020 et fin 2021 pour l’Alpha Mainnet de Starknet.

(Liste non exhaustive, pour découvrir plus de projet vous pouvez consulter le site StarkNet Ecosystem

Bridges

StarkGate, le bridge Officiel de StarkNet (actuellement disponible sur mainnet et testnet)

Orbiter Finance, bridge spécialisé dans les transferts d’actif sur Ethereum Mainnet, ses Sidechains et ses Rollup (Optimistic & Zk).

DEX/AMM

Alpha Road Finance est une plateforme décentralisée non-custodial qui proposera à l’avenir différents services tel qu’un AMM ainsi que des stratégies de rendement sur ses actifs personnels. Ils ont également reçu un grant de StarkWare.

Basée en Suisse, l’équipe a des expériences antérieures sur des projets web2 & Web3.

SithSwap : AMM qui semble avoir une équipe dynamique avec une veTokenomics, et disposant d’un Grant obtenu par StarkWare.

Starkswap, un AMM classique proposant des pools de liquidité. Actuellement est en testnet, le projet à également reçu un grant par StarkWare.

ZKX est un protocole permissionless permettant de trader des actifs dérivés avec un carnet d’ordres, construit il y a maintenant plus d’un an. Voici leur présentation à l'Hackathon d’Amsterdam par Eduard son fondateur : https://www.youtube.com/watch?v=dEpmCQJG-ug?t=6810.

Ils ont également reçu un Grant de la part de StarkNet

Protocole de prêt & emprunt d’actif

zkLend est un protocole de prêt et d’emprunt d’actifs construit sur StarkNet.

L’équipe souhaite développer deux solutions :

• Armetis : service permissionless pour les utilisateurs DeFi
• Appollo : service avec permission ciblé pour les clients Institutionnels. Ainsi, il faudra se soumettre à un contrôle de conformité juridique (tel que KYC, KYB etc) afin d’être enregistré sur une Whitelist.

Magnety est un protocole de gestion d’actif qui propose la construction de Vaults utilisant différentes stratégies déployées par des utilisateurs pour optimiser les rendements (comme un Yearn avec la possibilité pour quiconque de déployer son propre Vault).

GameFi

Phi est un métavers créé à partir de domaines ENS et alimenté par l’activité on-chain des participants. Ils proposent de générer des terrains virtuels à quiconque détient une adresse ENS afin de les remplir d’objets représentant leurs activités on-chain. Un terrain est relié à son adresse, donc si celle-ci change de propriétaire, le terrain en change également, ceci offrant un nouveau cas d’utilisation aux adresses ENS.

Topology porte comme mission de combiner une recherche de pointe sur les systèmes zk-Proof afin de développer un métaverse on-chain avec une interopérabilité et un composabilité permissionless.

Le premier jeu est Isaac, un jeu de coopération combiné avec des lois physiques et métaphysiques tel que le problème des N corps et de la mécanique de jeu Factorio, tout ceci on-chain.

Les joueurs jouent “Factorio” à la surface d’une planète cuboïde pour diriger le sort de leur planète

La team est composé de Guiltygyoza | Kunho, en s’avoir plus ici.

Mention spéciale :

Avec différents produits, OnlyDust souhaite changer la façon dont nous travaillons en se rapprochant des promesses que porte le Web3 avec de meilleurs incentives.

Dans un premier temps, l’idée est d’intégrer et d’accompagner les développeurs souhaitant apprendre le langage de programmation Cairo (propose à StarkNet) le tout avec une approche ludique et de Gamification. Dans un second temps, identifier les besoins de l’écosystème et les mettre en relation avec de potentiels contributeurs.

Une équipe française composée de 10 membres et co-fondée par AbdelHamid, Paco et Grégoire

Petit clin d’œil à Briq construit par une équipe française (Sylve & Lancelot)

Briq est un jeu de construction mixant Minecraft et les LEGO permettant de construire des univers pouvant être mintés en NFT et être tradés sur des marketplace telle que PlayOasis mais également être utilisés dans d’autres jeux. Laissez place à votre imagination et créez ce qui vous passe par la tête.

BlueChip qui se déploie sur StarkNet :

Maker a annoncé, sans plus de détail, vouloir se déployer sur StarkNet. Pour rappel, ce dinosaure de la DeFi à l’origine du $DAI, un des plus anciens stablecoin dollars existant en DeFi. Le protocole n’est actuellement déployé que sur Ethereum mainnet.

Leur arrivée passera par plusieurs étapes explicitées dans ce Tweet.

Aave a également vu la publication d’une proposal suggérant le déploiement du protocole sur StarkNet le 1er Février 2022. Le déploiement du protocole se fera conjointement avec StarkNet, avec un partage des frais de déploiement.

Remerciement

En espérant que ce tour d’horizon vous aura permis de vous faire une meilleure idée du potentiel de StarkNet et vous donnera envie de prendre part à cet écosystème qui s’annonce prometteur pour l’avenir d’Ethereum. Merci de nous avoir lu !

Mention toute particulière à Nyfan et Reborn pour ses bons conseils, un grand merci !

Comptes de l’écosystème à suivre : Odin / Louis Guthmann / Henri Lieutaud / Swagtimus

StarkWare / StarkNet Intern

Crédit : @nono01022 & @cleminso