La Fondation Starknet est fière d'annoncer la formation de son Comité DeFi. Présidé par six membres, le rôle principal du Comité est d'amorcer et de développer l'écosystème DeFi sur Starknet.

Le Comité DeFi

Rôle et Fonction

Le rôle du Comité DeFi est de promouvoir la croissance de la DeFi sur Starknet. Son succès sera mesuré par des métriques telles que la valeur totale verrouillée (TVL) et le volume quotidien échangé ; ainsi que par l'écart, la profondeur et la disponibilité de la liquidité.

Vue d'ensemble

La finance décentralisée (DeFi) est un pilier fondamental de l'écosystème Starknet. La conception architecturale avancée de Starknet le positionne comme une plateforme idéale pour des applications DeFi uniques. Le Comité DeFi reconnaît l'importance de la DeFi et constitue la première étape concrète vers un focus sur sa croissance.

Composition Nommé par le Conseil de la Fondation Starknet, le Comité DeFi est constitué de :

• Damian, Fondation Starknet

• Itamar Lesuisse, Argent

• Jane Ma, zkLend

• Mentor Reka, AVNU

• Richard Thomas-Pryce, Nostra

• Vitaly Yakovlev, ZKX

Leur expertise combinée permettra d’atteindre les objectifs du comité.

Mission

Le Comité est chargé de la recherche, de la conception et de la mise en œuvre d'un programme d'incitation à la liquidité visant à positionner Starknet comme choix principal pour les développeurs et les utilisateurs d'applications DeFi.

Feuille de route du Comité

Phase 1 (Stratégie)

• Évaluer l'état de préparation du réseau, les fonctionnalités centrales de la DeFi, les besoins de soutien aux projets DeFi et les plans de liquidité.

• Livrable : Rapport de stratégie interne pour la Fondation.

Phase 2 (Surveillance et Incitations)

• En partenariat avec une entreprise externe ou une tierce partie, le Comité établira des métriques clés DeFi et des systèmes de surveillance.

• Livrable : Cadre de surveillance et cadre d'incitation.

Phase 3 (Mise en œuvre)

• Sur la base des résultats des deux phases précédentes, le Comité présentera une proposition approfondie à la Fondation et au Conseil, couvrant les besoins essentiels, les incitations, les programmes proposés. Ainsi que tout autre élément jugé nécessaire au cours de leurs recherches.

• Livrable : Proposition de programme d'incitation pour la Fondation.

Phase 4 (Surveillance de l'exécution et itération)

• Avec l'approbation de la Fondation et de son Conseil, le Comité supervisera l'exécution et la mise en œuvre des propositions de cette phase.

• Livrable : Surveillance de l'exécution du programme d'incitation approuvé.

Le Comité se réunira régulièrement, sollicitera des commentaires de la communauté DeFi et rendra compte au Comité exécutif de la Fondation Starknet. Les décisions majeures seront documentées et approuvées, assurant transparence et responsabilité.

Budget

Le Comité s'est vu allouer un total de 50 millions de STRK.

Mots de fin

En réfléchissant aux réalisations de nos comités passés tels que l'EAG et le Comité d'Onboarding de l'écosystème, nous anticipons que le Comité DeFi jouera un rôle clé dans le renforcement de la croissance DeFi de Starknet.

Si vous pensez que vous seriez un partenaire précieux pour le Comité DeFi, veuillez soumettre vos propositions directement à : defi@starknet.org.

Starknet révolutionne l'espace émergent des mondes autonomes

TL;DR

• Starknet est à la pointe de l'évolution du gaming on-chain et des mondes autonomes. Exploitant la puissance du moteur de jeu Dojo et de Madara permettant le gaming on-chain.

• Grâce au haut débit de Starknet et Cairo, un monde de possibilités s'ouvre pour les développeurs et les utilisateurs qui veulent utiliser la propriété des actifs et une interopérabilité sans limites.

• Plusieurs équipes exploitent les capacités de Starknet pour contourner les limitations de l'EVM et explorer de nouveaux horizons de jeu.

Intro

Les mondes autonomes (Autonomous World) représentent la convergence de la technologie, du jeu, de la décentralisation, de la créativité et de l'innovation. Ces mondes fonctionnent de manière indépendante et sans autorité centrale, permettant aux utilisateurs de s'engager, d'explorer, de créer du contenu et d'interagir, tout cela sans demander la permission à quiconque et sans aucune crainte de censure.

Starknet s'est imposé comme le choix naturel pour ceux qui sont à la pointe de la création de ces mondes. Ces mondes ont besoin d'une couche L1 pour s'assurer qu'ils peuvent exister éternellement, mais ils ont également besoin d'une solide couche L2 pour gérer leur complexité. La combinaison d'Ethereum, comme couche de base, et de Starknet, comme couche de scalabilité et d'activation de la créativité, permet à ces mondes d'émerger.

Examinons cette nouvelle frontière des mondes autonomes et du jeu on-chain et les caractéristiques de Starknet qui le rendent si adapté à cette vision.

Qu'entendons-nous exactement par Mondes Autonomes?

Comme mentionné précédemment, ces mondes fonctionnent indépendamment et sans l'autorité centrale. Voici quelques caractéristiques distinctives d'un monde autonome :

• Accessibilité constante : Ils sont toujours disponibles.

• Interactivité Multijoueur : Ils permettent à plusieurs joueurs d'explorer et de vivre des expériences interactives simultanément.

• Immunité à la Fermeture : Ces mondes sont à l'épreuve de la censure, signifiant qu'aucune autorité centrale ne peut les faire fermer.

• Engagement Utilisateur Non Restreint : Ils permettent aux utilisateurs d'explorer, de créer et d'interagir (individuellement ou en groupe) sans aucune autorité centrale.

Les joueurs, tant individuellement que collectivement, créent, contrôlent et participent à ce monde par eux-mêmes. C'est une nouvelle frontière dans le monde des jeux avec des capacités inexplorées et de nouveaux cas d'usage. Cela remet en question les conventions actuelles du jeu et redéfinit ce qui est possible. Le potentiel est immense.

Cependant, pour que ces mondes autonomes existent, ils doivent être sur la blockchain, sur un réseau capable de répondre aux exigences mentionnées ci-dessus. Ils doivent également être performants et efficace en termes de coûts. C'est là où Starknet intervient.

Les Origines du Jeu sur la Blockchain avec Starknet

En novembre 2021, StarkWare a lancé Starknet Alpha, et avant cela, Cairo. La combinaison d'un Validity Rollup offrant une sécurité de niveau Ethereum, et d'un nouveau langage de programmation non compatible avec l’EVM, était à la fois un défi et une énigme. Cela a ouvert un nouveau monde d'opportunités. Les premiers adoptants de Cairo, comme Perama et Guiltygyoza, ont commencé à explorer le langage, créant des guides et expérimentant avec la physique et les réseaux neuronaux. Ce niveau d'innovation dans l'écosystème Ethereum était impressionnant.

Finalement, le premier jeu sur Starknet a vu le jour : une proposition pour recréer le jeu classique "Drug Wars" a été soumise, une subvention a été accordée, et un moteur de jeu entièrement sur la blockchain a commencé à se développer.

Des équipes comme Realms, Influence et Briq ont été parmi les premières à se construire sur Starknet. Venant du monde de Solidity, où il était presque impossible de créer des jeux complexes, ces équipes ont trouvé une nouvelle opportunité. D'autres, tels que Topology, se sont tournés vers Starknet en raison des limitations qu'ils ont entendues concernant Solidity. Pour toutes ces équipes, leurs visions sont devenues possibles grâce à Starknet. Cairo, en tant que langage de programmation général, a levé les barrières posées par l'EVM, permettant aux équipes de découvrir sa flexibilité.

Échapper à la Limite EVM : Jeux en ligne autonomes sur Starknet

Après des années de recherche et d'itérations, Starknet est désormais l'une des premières solutions de seconde couche (L2) capable d'accueillir durablement des jeux nécessitant un haut débit de transactions par seconde (TPS) sur la blockchain. C'est la plateforme où les développeurs de jeux peuvent donner vie à leurs visions complexes de mondes autonomes et décentralisés. Parmi les solutions L2 en activité, Starknet a attiré le plus grand nombre de développeurs et d'équipes de jeux.

Nous allons examiner deux technologies clés qui font de Starknet la plateforme de choix pour construire à la fois des jeux autonomes on-chain - le moteur de jeu Dojo et le séquenceur Madara.

Moteur de Jeu Dojo

Dans un article récent, nous avons présenté le Moteur de Jeu Dojo - le premier moteur de jeu onchain vérifiable au monde. Dojo permet aux développeurs de jeux Starknet d'offrir transparence, vérifiabilité et évolutivité pour leurs jeux.

Le moteur de jeu Dojo est un cadre logiciel pour les développeurs Starknet, facilitant la création de jeux rapides et vérifiables sur la blockchain. Il fournit aux développeurs tous les outils nécessaires pour commencer à créer des jeux et des mondes autonomes, incluant la physique, les graphiques et les mécaniques de jeu.

Dojo est le fruit de la collaboration entre deux équipes innovantes dans le développement de jeux basés sur Starknet - Cartridge et Realms. Leur collaboration a été inspirée par les insights acquis lors d'un voyage d'un an, débutant en 2021, où ils ont exploré les méthodes les plus efficaces pour construire des jeux sur Starknet.

Dojo comprend le système Entity Component System (ECS), un système pour le développement de jeux basés sur la blockchain qui favorise la modularité, l'efficacité et la flexibilité. Il comprend également trois outils supplémentaires pour les développeurs de jeux : Sozo, Torii et Katana.

Sozo

Sozo est un planificateur de migration qui simplifie la tâche complexe de déployer des mondes autonomes on-chain. En utilisant une simple commande sozo migrate, il est possible de déployer une instance du monde de jeu on-chain.

Sozo donne également la possibilité à tout participant de l'écosystème de proposer de nouveaux composants à l'univers du jeu on-chain en utilisant un simple outil CLI. C'est une philosophie clé des jeux autonomes : les mondes peuvent survivre à leurs créateurs, et des contributeurs supplémentaires peuvent enrichir l'écosystème avec leurs propres actifs, niveaux, personnages et plus encore.

Katana

Katana est un séquenceur conçu pour le développement de jeux locaux. Exécuter ce séquenceur sur Starknet permet d'augmenter considérablement la productivité. Katana rend disponibles les méthodes RPC offertes par Starknet sur le mainnet, permettant ainsi au développeur de tester différents paramètres tels que le temps de bloc, les frais de base par transaction, etc.

Torii

Torii est une couche d'indexation construite sur le moteur Dojo. Elle relie l'infrastructure de la chaîne aux clients de développement de jeux tels que Unity ou Unreal Engine. En se basant sur le code source du jeu développé, Torii peut être utilisé pour indexer facilement des événements spécifiques au jeu et exposer une API GraphQL pour les requêtes. Pour créer une API GraphQL fonctionnelle sur http://localhost:8080, prête à être interrogée, il suffit d'exécuter torii.

Séquenceur Madara

Le séquenceur Madara est un séquenceur Starknet haute performance qui permet de créer des appchains hautement personnalisables et efficaces, spécialement adaptées aux jeux. Madara est construit en utilisant le framework Substrate éprouvé par l'écosystème Polkadot.

Les appchains sont une instance privée de Starknet qui donne aux développeurs la possibilité de contrôler presque tous les paramètres configurables dans un réseau : séquençage, disponibilité des données, couche de règlement, gouvernance et bien plus encore.

Pourquoi est-ce utile ? Par exemple, si un jeu souhaite prioriser la vitesse des transactions des joueurs, ils pourraient choisir d'implémenter un type de séquençage Premier Arrivé, Premier Servi. Mais s'ils veulent plutôt encourager les utilisateurs à enchérir plus haut pour une inclusion de bloc plus rapide, le séquençage Priority Gas Auction (PGA) pourrait être mis en place avec une perspective plus orientée vers le profit.

Avec de nombreux autres paramètres possibles, tels que les temps de bloc, la fréquence de règlement sur L2, ou l'utilisation de solutions de disponibilité de données non natives, la possibilité de lancer leurs jeux sur une appchain Starknet offre aux développeurs des choix et du pouvoir.

Fonctionnalités Futures : Jeux off-chain Prouvables

Chaque action prise par le joueur ne devrait pas nécessairement être on-chain. Pour certains jeux, où les actions de l'utilisateur ne devraient pas être rendues publiques avant que l'état du jeu ne change, une preuve off-chain de l'action de l'utilisateur pourrait être générée sur le client. Seule la preuve indiquant que l'action a eu lieu serait soumise on-chain. Cette infrastructure est prometteuse non seulement pour les jeux multijoueurs, mais aussi pour les enchères et les applications de système de vote où il pourrait être souhaitable d'obscurcir les données d'entrée de l'utilisateur.

La preuve côté client ouvre également la possibilité de modèles où les joueurs adoptent une approche hybride : les preuves sont publiées, mais seulement lorsque quelque chose d'important se produit dans le jeu (par exemple, un niveau est passé ou le personnage trouve un objet rare).

Mondes Autonomes en Action - Shoshin

Dans un article précédent, nous avons exploré certains des plus grands projets de jeux construits sur Starknet. Ils vont des jeux de stratégie de colonisation de l'espace aux "machines d'arcade immuables" activées par les circuits ZK. Nous avons évoqué des jeux qui peuvent être façonnés et évoluer selon les directives des joueurs, même si leurs créateurs cessent de les exploiter.

Un autre exemple est Shoshin. Ce jeu a introduit une nouvelle façon de jouer on-chain où l'utilisateur programme son personnage et ses actions. Une fois cette logique programmée, les joueurs peuvent faire combattre leurs personnages contre ceux des autres joueurs.

Tous les mécanismes de jeu sont exécutés au sein de la machine virtuelle Cairo. Shoshin a même organisé un tournoi en personne récemment à Palo Alto pour les joueurs pionniers. Pour essayer le jeu, connectez-vous sur shoshin.gg et démontrez vos compétences de combat en programmant un personnage invincible !

Conclusion

Avec les jeux on-chain et les mondes autonomes, Starknet ne fait pas que perfectionner l'état actuel du jeu ; il façonne l'avenir de la manière dont les jeux sont joués, les actifs sont possédés et les communautés sont construites.

Des individus tels que eth_worm, Guiltygyoza, et d'autres, révolutionnent le domaine des jeux on-chain et de l'innovation technique. Des équipes comme Realms, Topology, Influence, Briq, Cartridge et Madara se développent sur Starknet, échappant aux limites de l'EVM.

Avec ces collaborateurs et bien d'autres qui repoussent les limites, Starknet est prêt à ouvrir la voie dans ce nouveau paysage de mondes autonomes.

Vous avez envie de jouer à un jeu on-chain basé sur Starknet ? Découvrez Shoshin, un jeu de combat asynchrone en 2 dimensions développé par Topology.

TL;DR

• StarkWare avance vers la décentralisation en suivant deux axes : la planification et la mise en œuvre.

• Une feuille de route précise a été établie pour les étapes nécessaires à la transition du protocole Starknet vers un protocole proof-of-stake, décentralisé.

Introduction

Starknet tire parti de la sécurité et de la décentralisation offertes par Ethereum en transmettant des preuves STARKs et des transitions d'état pour sa vérification sur la blockchain Ethereum. Ce processus limite considérablement le pouvoir des entités centralisées qui construisent et maintiennent Starknet. Telles que StarkWare et la Fondation Starknet : aucune entité centralisée sur le réseau ne peut falsifier des messages de transaction qui déformeraient ou manipuleraient frauduleusement les données ou les actifs des utilisateurs.

C'est la première étape essentielle pour garantir que Starknet soit minimisé en termes de confiance, et que les utilisateurs de Starknet ne dépendent pas de l'honnêteté d'une partie centralisée lorsqu'ils utilisent le réseau. Cependant, d'autres efforts doivent être entrepris pour assurer une minimisation totale de la confiance et une décentralisation complète. De sorte que même si des entités comme la Fondation ou StarkWare venaient à disparaître, le réseau continuerait de fonctionner comme prévu et sans interruption. Ce post présente une feuille de route préliminaire pour ces prochaines étapes.

Comment nous en sommes arrivés là ?

Il y a presque un an, nous avons commencé à documenter notre processus de recherche sur la décentralisation à travers une série d'articles, aboutissant à une proposition claire et concise.

En résumé, notre but est de transférer le fonctionnement du Séquenceur + Prouveur vers un protocole proof-of-stake, décentralisé. Dans ce modèle, tout le monde peut participer au séquençage et aucun acteur n'est essentiel à la vivacité du réseau. Pour atteindre cet objectif, deux initiatives sont nécessaires :

1. Mise en œuvre des différents composants nécessaires pour le fonctionnement d’un protocole décentralisé.

2. Un processus de transition pour décentraliser progressivement les opérations vers les acteurs de Starknet.

Dans cet article, nous allons nous concentrer sur le deuxième point.

Le processus de transition

Pour résumer, le processus de transition comporte quatre fils conducteurs principaux :

1. Transition vers une architecture de réseau décentralisée tout en conservant le fonctionnement du séquenceur en mode centralisé.

2. Assurer la disponibilité d'une stack technologique entièrement open source.

3. Développer des réseaux de test et d'intégration de plus en plus larges.

4. Encourager l'intégration des participants à l'épreuve d'enjeu avant la transition finale de l'opération du séquenceur vers les participants au proof-of-stake.

Le numérotage indique certaines dépendances séquentielles évidentes, mais beaucoup de travail simultané sont possibles. Ci-dessous, nous détaillons légèrement avec un paragraphe pour chaque fil conducteur.

Architecture d’un réseau décentralisée Le réseau Starknet passera à un modèle plus décentralisé :

1. Actuellement, les nœuds complets ne communiquent pas entre eux, chaque nœud s'appuyant sur des requêtes périodiques au séquenceur via une passerelle centralisée.

2. Dans un modèle moins centralisé, les nœuds complets feront partie d'un réseau peer-to-peer qui ne nécessite pas de connexion individuelle avec le séquenceur.

Ce changement va au-delà de la connectivité du réseau. Pour illustrer cela, voici deux exemples.

Premièrement, le séquenceur signera ses blocs pour atténuer certaines hypothèses de confiance et préparer un protocole BFT basé sur le vote avec de nombreux votants.

Deuxièmement, la propagation des données sera plus distribuée, les nœuds aidant mutuellement à synchroniser l'état et à compléter leur vue locale.

Travailler vers une stack technologique entièrement open source

Stack technologique open source : Pour permettre à tous de participer aux différents aspects du protocole et du réseau, une stack technologique open source est essentielle. À mesure que StarkWare et d'autres contributeurs mettent en œuvre davantage de composants, ils seront disponibles pour que tous puissent les tester, les critiquer et se familiariser avec eux. Parmi les exemples notables de parties déjà open source de la stack, nous comptons les nœuds complets (Pathfinder, Juno, Deoxys), les prouveurs (Stone, Sandstorm), les séquenceurs (Blockifier, Madara) et les explorateurs de blocs (Starkscan, Voyager, ViewBlock, Stark Compass).

Réseaux de test et d'intégration : Pour faciliter la transition, des réseaux de test et d'intégration de plus en plus étendus sont nécessaires. Chaque nouveau composant suivra probablement une progression allant d'un testnet interne à un testnet autorisé légèrement plus large avec des participants externes, jusqu'à un testnet public, une intégration et un mainnet. Des choix devront être faits plus tard, par exemple entre des approches séquentielles et concurrentes pour introduire des tests de nouveaux composants.

Intégration des participants : Il est important de laisser le temps au staking contract sur le L1 d'accumuler suffisamment de staked tokens pour sécuriser le protocole décentralisé avec un poids économique réel. Ceci afin d'éviter un scénario où un petit nombre de participants, ayant peu d'intérêt réel, tenteraient malicieusement de prendre le contrôle de Starknet.

Conclusion

En résumé, nous avons présenté ici un aperçu général du plan provisoire pour la décentralisation de Starknet. Comme pour tout projet d'ingénierie, surtout d'une telle complexité, il est probable qu'il évoluera et changera au fil du temps à mesure que notre communauté de contributeurs développe de meilleures perspectives et compréhensions.

Comme toujours, nous accueillons vos commentaires, suggestions et critiques. N'hésitez pas à vous exprimer sur le forum de la communauté Starknet !

Un guide en douceur pour vous accompagner dans vos premiers pas avec Starknet.

Contexte

Lorsque j'ai essayé de commencer à utiliser Starknet, j'ai trouvé qu'il était difficile de savoir exactement quoi faire. Bien que j'aie souvent entendu parler des merveilles de Starknet et de la façon dont il peut me faire économiser des frais tout en offrant sécurité et absence de confiance, je suis un débutant en matière de blockchain. Dans ma quête pour embarquer sur Starknet et essayer certaines des applications de l'écosystème, j'ai trouvé beaucoup d'informations utiles, mais je n'en ai pas trouvé tant que ça.

Cet article fournit donc les informations que je n'ai pas pu trouver et propose des liens vers des informations que quelqu'un d'autre a pris la peine de fournir ailleurs.

Que pouvez-vous faire sur Starknet ? Vous pouvez swap des jetons, investir à l'aide des dApps, jouer à des jeux et constituer votre collection de NFT. Pour plus d'informations, consultez la page des dApps sur Starknet.io.

À propos de l'utilisation de MetaMask en tant que wallet Starknet

Note du traducteur : Metamask Snap est officiellement disponible pour interagir sur le mainnet de Starknet.

MetaMask prend en charge Starknet sous la forme d'un MetaMask Snap. Un Snap est le terme de MetaMask pour un plugin. Il est en version bêta, et je voulais l'essayer. Il y a une section spéciale ci-dessous sur l'installation et l’alimentation d'un wallet MetaMask.

Actuellement, vous ne pouvez envoyer et recevoir que des fonds L2 (c'est encore en version bêta !), mais d'autres fonctionnalités sont en préparation. J’ai donc hâte de pouvoir utiliser MetaMask en tant que wallet Starknet à part entière pour plus d'activités sur le réseau, comme la création de NFT par exemple.

Prérequis

Bien que ce guide soit destiné aux débutants, vous en retirerez davantage en utilisant Starknet et ce tutoriel si vous comprenez les bases d'Ethereum. Il est important de comprendre les termes L1 et L2, on-chain et off-chain, et ce qu'ils signifient dans le contexte d'Ethereum. Vous pouvez trouver des explications à ce sujet sur le site web d'Ethereum.

De plus, il est essentiel de comprendre ce que sont les wallets, la différence entre les hot wallets et les cold wallets (wallets en ligne et hors ligne), les EOAs (Externally Owned Accounts) et les comptes de contrat. Vous pouvez trouver ces informations sur le site web d'Ethereum.

Les étapes majeures

Chacune de ces étapes est détaillée soit dans d'autres sections de cet article de blog, soit dans la documentation externe sur un autre site.

1. Configurez un portefeuille Ethereum.

   Il en existe de nombreux. Pour une liste, consultez les wallets Ethereum, et pour un guide utile, consultez Comment "créer" un compte Ethereum. Les deux ressources se trouvent sur le site Ethereum. Vous pouvez utiliser un moteur de recherche comme Google pour vous aider à choisir celui qui vous convient. J'ai trouvé que les Meilleurs Portefeuilles Ethereum de 2023 m'ont aidé, et pour commencer, j'ai décidé d'utiliser MetaMask. Pour des informations sur la configuration d'un portefeuille, consultez la documentation du portefeuille que vous choisissez.

2. Déposez un peu d'ETH sur votre portefeuille Ethereum. Vous pouvez utiliser votre carte de crédit ou votre compte bancaire avec une plateforme d'échange comme Binance ou Coinbase.

3. Configurez un portefeuille Starknet, ce qui comprend le financement du portefeuille et le déploiement de votre compte sur Starknet. Pour plus d'informations, consultez la configuration d'un portefeuille Starknet ci-dessous.

   REMARQUE : Vous pouvez également ajouter des fonds directement à votre portefeuille Starknet à partir d'une carte de crédit ou d'une banque en utilisant un service on-ramp, tel que Banxa ou Ramp. Pour l'instant, Ramp est le seul service de ce type qui fonctionne avec MetaMask Starknet Snap. Si vous choisissez d'utiliser un service on-ramp, passez directement à l'étape 3.

Après avoir effectué ces procédures, vous serez prêt à commencer réellement à faire vos premiers pas sur Starknet.

Par exemple, ce tutoriel vous guide dans le processus d'échange d'ETH contre une autre crypto-monnaie en utilisant Jediswap. Il y a beaucoup d'autres choses que vous pouvez faire, comme fournir de la liquidité à un pool, acheter des NFT, créer vos propres NFT et jouer à des jeux.

Commençons - Configuration d'un wallet Starknet

Pour des informations sur l'utilisation de MetaMask, passez à la section Utilisation de MetaMask comme wallet Starknet ci-dessous.

Une fois que vous avez un wallet Ethereum avec un peu d'ETH, vous pouvez installer et configurer un wallet Starknet.

Consultez la liste à jour des wallets Starknet disponibles sur le site Starknet. Pour plus d'informations sur un wallet spécifique, y compris les instructions d'installation, consultez le site de ce wallet. Quel que soit votre choix, assurez-vous de l'installer comme une extension de navigateur.

Dans cet article de blog, j'ai utilisé les portefeuilles de Braavos et d'Argent.

Après avoir terminé l'installation, vous devez configurer le wallet en y ajoutant des fonds. Vous pouvez utiliser StarkGate, un pont qui transfère des fonds entre votre wallet Ethereum sur L1 et votre wallet Starknet sur L2. StarkGate prend en charge pleinement Braavos et Argent, et le support de MetaMask est en développement actif et devrait bientôt être en place. Vous pouvez accéder à StarkGate via un lien dans le wallet ou aller sur https://starkgate.starknet.io/.

Procédure

• Cliquez sur Connect wallet, puis sur Start. StarkGate vous invite à sélectionner un portefeuille Ethereum.

• Cliquez sur le wallet que vous souhaitez utiliser. Dans cet exemple, cliquez sur MetaMask, car il est déjà installé.

• Lorsque votre wallet vous demande de vous connecter, approuvez la connexion. StarkGate termine la connexion. Votre wallet Ethereum est maintenant connecté.

• StarkGate vous invite à connecter un wallet Starknet, en affichant les wallet que vous avez connectés à votre navigateur. Cliquez sur le wallet que vous souhaitez utiliser.

• Lorsque le wallet vous demande d'approuver la connexion. Par exemple, voici ce qui est apparu lorsque j'ai cliqué sur ArgentX :

et voici ce qui est apparu lorsque j'ai cliqué sur Braavos :

StarkGate a terminé la connexion.

Votre wallet Starknet est maintenant connecté, et il vous invite à ajouter des fonds. Pour déployer votre compte sur Starknet, vous devez ajouter des fonds. REMARQUE : Le déploiement d'un compte entraîne des frais de gaz minimes sur Ethereum. Mais ne vous inquiétez pas, vous n'avez à déployer le compte qu'une seule fois.

• Confirmez que vous êtes sur l'onglet Dépôt.

• StarkGate vous permet de choisir parmi plusieurs types de jetons. Cet exemple utilise le jeton par défaut, l'ETH. Vérifiez que le solde disponible dans votre wallet Ethereum est suffisant pour transférer des fonds et payer les frais de gaz nécessaires pour le transfert.

• Entrez le montant d'ETH que vous souhaitez transférer. Votre wallet Ethereum vous demande de confirmer le transfert. Votre wallet peut également vous montrer le coût estimé de la transaction. Par exemple, MetaMask montre approximativement la quantité de gaz nécessaire pour effectuer le transfert, ainsi que le coût du gaz nécessaire en ETH et en USD.

• Confirmez le transfert dans votre wallet Ethereum.

• StarkGate confirme la transaction et affiche son statut, y compris des liens vers Etherscan et StarkScan, afin de pouvoir consulter la transaction à la fois sur Ethereum et sur Starknet.

Après un court laps de temps, généralement quelques minutes, StarkGate devrait afficher les soldes mis à jour dans votre wallet Ethereum et Starknet :

Utilisation de MetaMask en tant que wallet Starknet

J'ai rédigé cette section pendant que je suivais le processus d'installation. En réalité, c'est assez simple, vous n'avez donc peut-être même pas besoin de suivre ces étapes, mais je sais que je trouve des étapes comme celles-ci utiles, vous pouvez ainsi les suivre si vous le souhaitez.

REMARQUE : Comme le Snap est en développement actif, le processus que vous suivez peut différer de ce qui est décrit ici. Mais même s'il en est ainsi, cette section devrait vous donner une idée générale de ce que vous devez faire.

Lorsque j'ai ouvert MetaMask dans mon navigateur, voici ce que j'ai vu :

J'ai cliqué sur Learn More, et une page s'est ouverte à l'adresse https://metamask.io/snaps/ qui explique ce que sont les Snaps et comment ils fonctionnent. Voici les étapes que j'ai suivies pour installer Starknet Snap :

• Cliquez sur Discover Snaps dans l'en-tête du site.

• Cliquez sur Starknet Snap dans la liste.

  Une page s'ouvre avec des informations sur Starknet Snap, y compris son repo Github. Je suis un grand partisan du logiciel open source, donc... Hourra ! Les informations comprennent également le développeur, Consensys, et les auditeurs, Cobalt et Consensys Diligence. Ce sont tous des développeurs Starknet respectés, mais vous devriez vérifier cela par vous-même. (Après tout, je travaille pour StarkWare.)

• Cliquez sur Add to Metamask et lisez Third-party software notice.

• Cliquez sur Accept. Un message vous invite à connecter le Snap à votre portefeuille.

• Cliquez sur Connect

• Après avoir tout lu sur cette page, cliquez sur Install.

• Cliquez sur Confirm pour procéder avec prudence.

Une fois l'installation terminée, ce message apparaît : Installation completed successfully.

• Cliquez sur l'URL pour ouvrir le Snap.

Un message vous invite à connecter votre wallet .

• Cliquez sur Connect. Un écran apparaît affichant votre nouvelle adresse de compte Starknet et le solde de votre portefeuille.

À présent, vous devez financer votre wallet. StarkGate devrait bientôt prendre en charge cela, mais pour l'instant, vous devez recevoir des fonds L2 d'un autre wallet Starknet ou utiliser le service on-ramp tel que Ramp avec une carte de crédit pour le financer.

Une fois que vous avez des fonds dans votre wallet, vous pouvez envoyer des fonds à une autre adresse Starknet. Comme je l'ai dit, plus de fonctionnalités seront bientôt disponibles.

Échanger de l'ETH contre un autre jeton en utilisant JediSwap

JediSwap est un Automated Market Maker (AMM) communautaire sur Starknet qui vous permet d'échanger un type de jeton contre un autre. La documentation de JediSwap fournit des informations sur l'échange et l'ajout de liquidité. Cette procédure vous montre comment échanger de l'ETH contre du WBTC.

Procédure

• Allez sur JediSwap à l'adresse https://app.jediswap.xyz.

• -Connectez votre wallet en cliquant sur Connect Wallet puis en sélectionnant votre wallet Starknet.

• Lorsque votre wallet vous demande d'approuver la connexion, cliquez sur Approuve. Une fois que JediSwap se connecte à votre wallet, il affiche votre solde dans chaque jeton qu'il prend en charge. Par exemple, mon wallet contient environ 0,05 ETH.

1. Sélectionnez les jetons que vous souhaitez échanger dans les sections Swap From et Swap To (est.), puis cliquez sur "Swap". J'ai échangé 0,025 ETH contre du WBTC.

2. Votre portefeuille vous invite à signer la transaction en cliquant sur "Sign". Cliquez sur "Sign" pour soumettre la transaction.

3. JediSwap affiche "Transaction soumise". Cliquez sur Open Browser pour afficher la transaction sur StarkScan.

4. Ouvrez votre wallet pour voir votre solde et les actifs que vous possédez. Par exemple, voici mon wallet Braavos après l'échange :

Que faire maintenant ?

Maintenant que vous avez franchi ces premières étapes sur Starknet, il est temps de plonger plus profondément dans l'écosystème en constante expansion de Starknet. En tant que réseau sans autorisation, Starknet voit constamment de nouveaux développeurs créer des dApps et des fonctionnalités novatrices.

Pour naviguer en toute sécurité dans les eaux inexplorées de Starknet, veillez à :

• Suivre les nouvelles sorties. Scannez régulièrement les sites d'actualités de Starknet et suivez la communauté de base pour rester au courant des nouvelles dApps. Cet univers évolue rapidement.

• Faites des recherches avant d'interagir avec une dApp sur Starknet. Comme pour toutes les plates-formes sans autorisation, effectuez des vérifications sur la légitimité et la sécurité de toutes dApps avant de connecter votre wallet.

• Cherchez des compagnons de voyage. Le forum Starknet à l'adresse https://forum.starknet.io/ est idéal pour apprendre des pionniers. Posez des questions, faites preuve de réflexion critique.

• Soyez prudent face aux escroqueries. Vérifiez les URL, les transactions et les adresses, ne vous laissez pas piéger.

Surtout, activez des protections de portefeuille comme l'authentification à deux facteurs (2FA), les signataires matériels ou les Wallet Shields. Ce niveau de protection novateur est possible sur Starknet grâce à l'abstraction de compte native.

En restant vigilant et en effectuant des recherches approfondies, vous pouvez pleinement profiter de la gamme croissante dApps et d'intégrations de Starknet. Comme pour toute nouvelle technologie, la prudence éclairée est très importante. Si quelque chose semble trop beau pour être vrai, c'est probablement le cas. Avec un peu de bon sens, vous pouvez explorer Starknet en toute sécurité.

Ce guide a été rédigé par Steve Goodman, Technical Writer Principal chez StarkWare Industries. Vous pouvez lui envoyer vos questions sur Twitter à l'adresse @CityOfNewOrleans.

Découvrez l'analyse complète de la sécurité des STARKs.

TLDR

• Les STARKs non interactifs commencent comme des Preuves Oracle Interactives (IOPs) qui sont ensuite compilées en versions non interactives dans le modèle d'oracle aléatoire.

• Cet article explique la récente mise à jour de la documentation ethSTARK, qui fournit une analyse complète et concrète de la sécurité du protocole ethSTARK dans le modèle d'oracle aléatoire.

Explication de la sécurité des STARK

Un système de preuve STARK (Scalable Transparent Argument of Knowledge) est un outil puissant pour garantir l'intégrité des calculs effectués sur des données publiques sans nécessiter de confiance. Dans cet article, nous explorons la sécurité offerte par les preuves STARK en définissant le concept et en explorant les techniques pour prouver la sécurité du schéma.

(Pour tous les détails, veuillez consulter la section 6 de la documentation ethSTARK (version 1.2) ainsi que le travail indépendant et complet de Block et al. sur le sujet.)

Quel est notre objectif avec cette analyse de sécurité ? Nous cherchons à prévenir une "attaque réussie" sur le système STARK, qui se produit lorsque nous avons une fausse déclaration et une preuve STARK acceptée par le vérificateur STARK pour cette (fausse) déclaration. Étant donné que les fausses déclarations peuvent prendre différentes formes et tailles, nous voulons être protégés contre toutes les fausses déclarations. Toute fausse déclaration, aussi simple que 1+1=3, combinée à une preuve STARK acceptée par un vérificateur STARK pour cette déclaration, est considérée comme une attaque réussie sur le système. (Les personnes ayant des connaissances cryptographiques seront intéressées de savoir que les STARKs satisfont également des notions de sécurité plus fortes, telles que la propriété de knowledge soundness, mais pour simplifier, cet article se concentre sur le cas plus simple de la justesse.)

Comment définissons-nous formellement la sécurité d'un système STARK ? Nous le faisons en analysant “soundness error”, qui mesure approximativement le "coût" attendu qu'un attaquant devrait dépenser pour construire une attaque réussie (c'est-à-dire trouver une preuve STARK pour une fausse déclaration qui est néanmoins acceptée par le vérificateur STARK). Mathématiquement, soundness error est une fonction (t) qui prend en entrée un paramètre de temps "t", représentant la quantité de temps de calcul qu'un attaquant est prêt à dépenser pour monter l'attaque, et retourne la probabilité de succès de l'attaquant pour réussir l'attaque (trouver une preuve convaincante d'une fausse déclaration). À mesure que le "coût" (t) que l'attaquant est prêt à dépenser augmente, sa probabilité de succès augmente également.

Jusqu'à présent, nous avons défini la sécurité des STARKs comme une fonction (t), ce qui n'est pas la manière dont vous discutez naturellement de la sécurité, disons, sur le Twitter crypto. Là-bas, vous avez probablement entendu des déclarations du type "Le schéma a 96 bits de sécurité". Comment cette déclaration se traduit-elle dans notre définition de sécurité ? Il n'y a pas de réponse unique car les gens ont des interprétations légèrement différentes de "x bits de sécurité" :

• Une traduction très stricte signifierait que pour tout (t) entre 1 et 2⁹⁶, l'erreur de justesse est (t)2⁹⁶. Cela signifie que tout temps d'exécution d'attaque inférieur ou égal à 2⁹⁶ a une probabilité de succès extrêmement faible, inférieure à 2⁹⁶, ce qui est inférieur à une chance sur un milliard de milliards de milliards.

• Une traduction plus souple, et peut-être plus courante, est que 96 bits de sécurité signifient que pour tout (t), il est valable que t/(t) 2⁹⁶. Cela signifie que la probabilité de succès décroît de manière inversement linéaire par rapport au temps d'exécution. Par exemple, si un attaquant a un temps d'exécution de 2⁸⁶, sa probabilité de succès est au plus 2¹⁰.

Dans cet article, nous nous référerons à la deuxième option.

Des IOP aux STARK avec une Sécurité de 96 Bits

Comment prouvons-nous qu'un schéma a une sécurité de 96 bits ? Pour répondre à cela, nous devons comprendre la structure globale de la construction des STARKs.

STARK est composé de trois éléments principaux : un IOP (une preuve oracle interactive), un arbre de Merkle et un hachage Fiat-Shamir. Le composant principal sur lequel nous nous concentrerons est l'IOP. Une fois ces éléments spécifiés, ils peuvent être compilés pour obtenir STARK. Nous allons expliquer ces éléments plus en détail, ce qu'ils sont et comment les assembler.

Le premier élément que nous examinerons est l'IOP : Il ressemble à une preuve interactive classique, où un prover et un verifier interagissent pendant plusieurs tours (nous nous limitons aux protocoles à public coin, où le verifier envoie uniquement des défis aléatoires au prover). Dans un IOP, le verifier ne lit pas entièrement les messages du prover, mais échantillonne plutôt un petit nombre de bits de chaque message du prover. C'est ce qui permet la concision du STARK compilé par la suite.

Maintenant que nous avons un IOP, comment construire STARK à partir de celui-ci ? Les messages du prover pourraient être longs (en réalité, ils sont plus longs que le calcul lui-même). Pour compresser les messages, nous utilisons des arbres de Merkle. Un arbre de Merkle est un arbre de hachage binaire où chaque nœud feuille représente une requête ou une réponse dans l'IOP. La racine de l'arbre est un engagement envers l'ensemble du message. Lorsque le vérificateur souhaite lire un emplacement spécifique dans un message, le prover fournit la valeur à cet emplacement ainsi qu'un chemin d'authentification. Le vérificateur peut ensuite utiliser le chemin pour vérifier que la valeur est correcte. Le vérificateur IOP ne lit qu'un petit nombre d'emplacements des messages du prover. Ainsi, l'utilisation d'un arbre de Merkle permet d'obtenir un protocole succinct (avec une petite communication).

Compression des tours

On peut choisir d'utiliser des STARKs interactifs, ce qui signifie qu'il est souvent pratique de les rendre non interactifs afin de simplifier le processus de génération, de sorte que le prover n'ait pas besoin d'attendre des messages externes lors de leur construction. En effet, c'est ainsi que tous les systèmes STARK sont actuellement déployés, y compris le protocole ethSTARK. Les STARKs non interactifs sont également un cas particulier des SNARKs transparents (la transparence signifie qu'aucune configuration de confiance n'est nécessaire pour les instancier ; cela est également connu sous le nom de "protocole Arthur Merlin" ou de "IOP à public coin"). Dans cette optique, une étape finale consiste à appliquer Fiat-Shamir pour compresser les tours en un seul message, que nous appellerons la Preuve STARK. La transformation Fiat-Shamir convertit un protocole interactif en un protocole non interactif. Le prover simule le protocole interactif tout en "parlant à une fonction de hachage". Pour dériver le défi aléatoire pour le tour i, le prover hache le transcript partiel jusqu'au tour i, et interprète la sortie comme le prochain défi.

Cela garantit que le prover ne peut pas modifier ses réponses après que le défi ait été généré. Cependant, le prover tricheur dispose de nouvelles stratégies qu'il n'avait pas avec l'IOP interactif. Le prover peut régénérer le défi du vérificateur en modifiant le dernier message du prouveur, ce qui donnerait un nouveau transcript, et donc un nouveau défi également. Il s'avère que la notion de justesse standard des IOPs ne suffit pas à prouver la sécurité de la transformation Fiat-Shamir.

Par exemple, considérons un IOP avec 96 tours avec le "hack" suivant pour le verifier : si le premier bit de l'aléa du verifier est 0 lors de chacun des 96 tours, alors le vérificateur accepte (sans regarder la preuve du tout). On peut voir qu'ajouter ce hack au vérificateur n'ajoute qu'un terme de 2⁹⁶ à l'erreur de justesse de l'IOP. Cependant, après la transformation Fiat-Shamir, un attaquant peut facilement modifier les messages du prover pour s'assurer que chaque hachage commence par un zéro, brisant essentiellement le système en très peu de temps. Soyez rassuré, ce scénario effrayant est simplement un exemple théorique, et ne s'applique pas aux STARKs déployés. Alors, voyons pourquoi nos STARKs sont finalement sécurisés ? En un mot, nous montrerons qu'un attaquant exécutant au plus t étapes réussira à attaquer avec une probabilité au plus ((t) t 2⁹⁶. Les détails suivent.

Par exemple, considérez un IOP avec 96 rounds et la "faille" suivante pour le verifier : si le premier bit de la séquence aléatoire du verifier est 0 dans chacun des 96 rounds, alors le verifier accepte (sans même examiner la preuve). On peut constater que l'ajout de cette faille au verifier n'ajoute qu'un terme de 2⁹⁶ à soundness error de l'IOP. Cependant, après la transformation Fiat-Shamir, un attaquant peut facilement modifier les messages du prover pour s'assurer que chaque hachage commence par un zéro, ce qui revient essentiellement à compromettre le système en très peu de temps. Soyez rassuré, ce scénario effrayant n'est qu'un exemple théorique, il ne s'applique pas aux STARKs déployés. Alors, voyons pourquoi nos STARKs sont sécurisés malgré tout ? En résumé, nous montrerons qu'un attaquant qui effectue au plus t étapes réussira à attaquer avec une probabilité d'au plus (t) t 2⁹⁶. Les détails suivent.

IOPs et justesse Tour par Tour

La sécurité d'un STARK dépend de la sécurité de son IOP sous-jacent. Mais que signifie-t-il pour un IOP d'avoir une sécurité de 96 bits ? Selon la définition standard, cela signifie que l'IOP a une soundness error de 2⁹⁶ : cela signifie que la probabilité pour n'importe quel attaquant (indépendamment du temps d'exécution) de tromper le verifier est au plus de 2–96. Cependant, comme nous l'avons discuté précédemment, la justesse de l'IOP n'est qu'un des trois composants nécessaires pour obtenir une sécurité de 96 bits pour le STARK compilé à partir de ces trois étapes. Au lieu de cela, la sécurité du STARK compilé est prouvée en supposant que le STARK a une soundness error tour par tour de 96 bits (parfois appelée state-restoration soundness).

Intuitivement, la justesse tour par tour signifie que chaque tour a une sécurité de 96 bits, et pas seulement le protocole global. Plus précisément, la justesse tour par tour indique qu'il existe un prédicat qui prend en entrée un transcrit partiel du protocole et nous indique si ce transcrit est "trompeur" : le transcrit vide n'est pas "trompeur", un transcrit complet est "trompeur" si et seulement si le vérificateur l'accepte. Enfin, pour tout transcrit partiel qui n'est pas un transcrit trompeur pour le vérificateur, la probabilité qu'au tour suivant le transcrit devienne "trompeur" est au plus de 2⁹⁶. Si un tel prédicat existe avec ces propriétés, nous disons que le protocole a une justesse tour par tour de 96 bits (le prédicat n'est pas nécessairement calculable efficacement).

Dans de nombreux cas, seule soundness d'un IOP est analysée et non la soundness tour par tour. Il est difficile de penser à des exemples où un IOP a une soundness standard et non une soundness tour par tour (sauf dans des exemples artificiels). Cependant, les différences entre les deux pourraient apparaître lors de la dérivation de limites de sécurité concrètes où chaque bit compte. Ainsi, pour obtenir des limites précises et concrètes, il est nécessaire de donner une analyse précise d’une soundness tour par tour de l'IOP. C'est précisément ce que nous faisons pour le protocole FRI, puis pour l'IOP ethSTARK qui sous-tend l'IOP de nos STARKs. L'analyse elle-même est complexe et dépasse le cadre de cet article. Grâce à cette nouvelle analyse, nous pouvons définir des paramètres précis pour nos preuves.

Soundness tour par tour nous donne la garantie souhaitée. Le prover peut régénérer le défi plusieurs fois, mais nous savons que pour n'importe quel tour, la probabilité de générer un transcrit "trompeur" est de 2⁹⁶. Ainsi, si le prover prend un temps t, mesuré en nombre d'invocations de hachage, alors il peut essayer au plus t fois d'obtenir un transcrit trompeur, ce qui limite sa probabilité de succès à (t) t 2⁹.

Ajout de tous les Termes d'erreur

Enfin, pour que tout cela soit valable, nous devons nous assurer que le prover ne peut pas altérer l'arbre de Merkle. On peut montrer que tant que le prover ne trouve pas de collision dans la fonction de hachage, il ne peut pas tricher dans l'arbre de Merkle. La probabilité qu'un attaquant trouve une collision en utilisant t invocations (à une fonction de hachage aléatoire) est au plus de t2/2, où est la longueur de sortie de la fonction de hachage (ceci est dû au "paradoxe des anniversaires"). C'est pourquoi nous devons définir la fonction de hachage pour avoir une longueur qui est le double de la sécurité désirée. Ainsi, si nous avons une fonction de hachage avec une longueur de sortie de 192 et un IOP avec une justesse tour par tour de 96 bits, nous obtenons un STARK compilé avec une soundness error (t)=t2-⁹⁶ + t2 2¹⁹. En particulier, un tel schéma a 95 bits de sécurité puisque t/(t) = t/(t 2⁹⁶+t2 2¹⁹⁶) 1/(2⁹⁶+1/2⁹⁶) = 2²⁹⁵.

Résumé

En conclusion, les STARKs offrent une méthode puissante pour vérifier la justesse des calculs effectués sur des données publiques de manière sans confiance. La sécurité des STARKs est généralement mesurée en termes “soundness error”, qui représente la probabilité qu'un attaquant fournisse avec succès une fausse déclaration et convainque le vérificateur avec une preuve. Pour atteindre un niveau de sécurité souhaité, tel que 96 bits, l'IOP sous-jacent doit satisfaire à la soundness tour par tour, garantissant que chaque tour maintient un niveau de sécurité élevé. Nous avons analysé soundness tour par tour de l'IOP sous-jacent à nos STARKs, ce qui nous a permis de dériver des limites de sécurité concrètes.

Décryptage de Cairo VM, CASM, Cairo Zero, Cairo et Sierra.

Introduction

Pour permettre une mise à l'échelle sécurisée et décentralisée d’Ethereum, les Validity Rollups rendent la vérification des lots de transactions bien plus efficace que leur ré-exécution naïve. Des nœuds spécialisés (appelés séquenceurs) sur la couche 2 (L2) regroupent les transactions en nouveaux blocs L2, tandis que les nœuds principaux d'Ethereum confirment ces transactions avec un effort minimal.

Starknet est un Validity Rollup qui exploite Cairo VM, spécifiquement conçu pour optimiser l'efficacité des preuves de validité. Starknet utilise les STARKs (Scalable, Transparent ARgument of Knowledge) comme système de preuve, permettant la génération de preuves succinctes pour des calculs complexes, réduisant ainsi considérablement la complexité des processus de vérification sur la chaîne.

Dans cet article de blog, nous plongerons dans les différents composants qui font de Starknet le L2 le plus performant en termes de Transactions par seconde - Cairo VM, CASM, Cairo Zero, Cairo et Sierra.

Cairo VM

Créer des preuves de validité pour des programmes informatiques généraux nécessite une compréhension approfondie des principes mathématiques complexes qui sous-tendent les STARKs. Pour chaque calcul, il est crucial de construire une Représentation Algébrique Intermédiaire (AIR), qui comprend un ensemble de contraintes polynomiales représentant fidèlement le calcul donné. Initialement surnommé "CPU AIR", Cairo est un CPU virtuel et un AIR singulier, capable de décrire n'importe quel calcul avec le même AIR "générique". Cairo VM est intentionnellement conçu pour les systèmes de preuve de validité et n'est pas limité par les restrictions imposées par l'EVM (Ethereum virtual machine).

CASM

CASM (Cairo Assembly) est le code machine exécuté par la machine virtuelle Cairo. CASM est traduit en contraintes polynomiales qui garantissent l'exécution correcte d'un programme.

CASM est un élément clé de l'écosystème, car quelle que soit la demande que l'utilisateur envoie au séquenceur Starknet, ce qui est prouvé est l'exécution correcte de CASM.

Cairo Zero, une percée

Lancé en 2020, Cairo Zero a introduit le premier langage Turing-complet au monde pour créer des programmes prouvables par les preuves STARKs, révolutionnant le calcul vérifiable.

Les programmes Cairo Zero étaient compilés localement en CASM, puis envoyés au séquenceur Starknet. Bien que révolutionnaire, Cairo Zero présentait une courbe d'apprentissage abrupte en raison de sa nature de bas niveau et ne masquait pas complètement les primitives cryptographiques nécessaires pour prouver l'exécution du programme.

Cairo : Cairo Zero, en mieux

Cairo (maintenant en v2.1.1) surmonte les limitations de Cairo Zero, promettant une rédaction de contrat plus sûre et plus efficace. Cairo améliore considérablement l'expérience du développeur avec une syntaxe similaire à Rust et en masquant les limitations présentes dans Cairo Zero (par exemple, la mémoire à écriture unique). Cairo adopte des concepts de programmation modernes du monde de Rust, tels que les traits/implémentations, les génériques et la correspondance des énumérations, sans compromettre l'efficacité de génération de preuves apportée par CairoVM sous-jacent.

Sierra

Avec Cairo est arrivé Sierra. Sierra sert de représentation intermédiaire entre Cairo et CASM. Cette couche supplémentaire garantit que le code utilisateur reste prouvable dans tous les cas. Sierra se compile en "safe CASM", un sous-ensemble de CASM qui est garanti comme prouvable pour toutes les entrées. Cette couche intermédiaire entre le code utilisateur et le code prouvé est cruciale pour protéger le séquenceur Starknet des attaques de type déni de service (DOS) sous la forme de transactions non prouvables.

Un avantage peut être surprenant de Sierra est que, grâce à cette représentation intermédiaire simple, les séquenceurs Starknet pourraient fonctionner directement sur du matériel natif au lieu de passer par CairoVM. Pour illustrer la puissance des séquenceurs exécutants Sierra, considérez l'exemple suivant : on peut utiliser les informations de type de Sierra pour travailler avec des types natifs (par exemple, u32) au lieu de travailler dans le champ principal de CairoVM.

Conclusion

Cairo s'appuie sur les fondations posées par la CairoVM pour révolutionner le calcul vérifiable. Avec une syntaxe similaire à Rust et des fonctionnalités de langages de programmation modernes, Cairo améliore considérablement l'expérience des développeurs, simplifie la rédaction de contrats et réduit les risques de bugs. Cairo émerge comme un outil puissant qui stimule l'innovation décentralisée.

Quels sont les nouveaux cas d'utilisation que permet Starknet et comment les développeurs peuvent-ils en profiter ?

Les coûts élevés de calcul ont freiné l'adoption et les cas d'utilisation de la blockchain

• Starknet, un rollup L2 d'Ethereum, permet un calcul à faible coûts.

• Starknet est déjà en direct sur le mainnet, avec des millions de transactions traitées.

• Possibilités d'intégration IA/ML avec déduction vérifiable, des modèles on-chain, et trainning vérifiable.

• Les développeurs peuvent utiliser le livre Starknet pour en savoir plus sur Cairo et construire sur Starknet.

Lors des marchés haussiers de 2021 (ou lors de la saison Pepe de mai 2023), tout le monde parlait de crypto et envoyait des millions de transactions sur Ethereum. Les prix du gas pouvaient alors atteindre 200 Gwei ou plus. Cela signifiait que si vous vouliez envoyer 10 USDC à quelqu'un sur Ethereum, cela vous coûterait 50 $ ou plus. Pas une très bonne affaire.

Avec l'arrivée de nombreux nouveaux utilisateurs des blockchains, la demande d'espace de bloc a explosé. Cette flambée des prix du gas sur Ethereum (et d'autres chaînes) a exposé les limites des blockchains monolithiques. Le public était prêt, mais la technologie ne l'était pas.

Pour résoudre ce problème, une évolution vers une conception modulaire est apparue avec les solutions de "couche 2", un ensemble de technologies construites sur une blockchain de base qui augmentent la scalabilité et la rentabilité. Selon l'article de Polynya, "toutes les blockchains qui en valent la peine s'éloigneront de la conception purement monolithique, d'une manière ou d'une autre, au cours des prochaines années (à moins qu’une mise à l’échelle ne soit pas requise, comme Bitcoin)".

Starknet — un rollup de validité (ou ZK), est un leader parmi ces solutions de couche 2 et a considérablement réduit le coût de computation. Dans cet article, nous explorerons comment les coûts élevés de computation ont freiné la blockchain, puis nous examinerons en détail plusieurs nouveaux cas d'utilisation désormais possibles grâce aux faibles coûts de calcul de Starknet.

Les L2 d'Ethereum

Sur Ethereum, une grande variété de solutions L2 ont été développées, principalement dans trois catégories : les rollups optimistes, les rollups à connaissance zéro (ZK) et les canaux d'état.

La particularité des rollups réside dans le fait qu'ils tirent leur sécurité d'Ethereum L1 en utilisant un réseau décentralisé de plus de 600 000 validateurs. Ils offrent également une exécution beaucoup plus rapide et moins coûteuse qu'une transaction sur le mainnet en effectuant les calculs en dehors d’Ethereum mainnet, où le calcul est moins coûteux. Cependant, pour conserver la sécurité du mainnet, ils postent périodiquement l'état du L2 sur le mainnet sous forme de lot, d'où le terme "enrouler" (Rollup) les transactions.

Qu'est-ce que Starknet ?

Starknet est un rollup de validité (communément appelé ZK rollup) développé par StarkWare qui utilise des systèmes cryptographiques appelés preuves STARKs pour réduire le coût de calcul.

Actuellement, la version mainnet de Starknet a des frais de transaction bien inférieurs à ceux d'Ethereum. Dans la version 0.13.0 (prévue pour être lancée au 3ème trimestre 2023), les coûts de transaction de Starknet devraient encore diminuer avec l'introduction de Volition (ou disponibilité de données off-chain). Actuellement, 95% des frais de transaction sur Starknet sont dus aux coûts de transaction sur le mainnet d'Ethereum (les 5% restants étant le calcul). De plus, une fois que l'EIP 4844 sera implémenté sur Ethereum mainnet, l'équipe envisage de pousser des mises à jour pour s'adapter à celui-ci dès que possible. À la suite de ces deux mises à jour, les coûts de transaction devraient considérablement diminuer.

Limitations des coûts de calcul élevés

Outre les frais exorbitants à payer pour simplement envoyer des tokens, il existe d'autres problèmes liés aux coûts de calcul élevés . Même aujourd'hui, de nombreuses applications sont limitées dans leurs cas d'utilisation en raison de ce coût élevé. Et à mesure que la technologie de la blockchain continue d'évoluer, la demande en matière de computation complexes augmentera. Les coûts élevés de calcul créent des limitations sur la croissance et l'adoption des applications décentralisées. Par exemple :

1. Transactions quotidiennes. La promesse de la "crypto-monnaie comme de l'argent liquide" n'est pas encore devenue réalité (sauf pour certaines exceptions où vous pouvez "survivre avec de la crypto"). Outre l'incertitude réglementaire, l'une des principales raisons de l'absence d'adoption quotidienne du grand public a été le coût élevé des transactions. Personne ne veut payer 1$ de frais de transaction pour un café à 2$.

2. Oracles. En raison de leur conception et de leurs principes inhérents, les blockchains ne peuvent pas récupérer de données réelles off-chain. Pour obtenir des données telles que les cours des actions, les données météorologiques, les résultats des matchs sportifs, etc, des applications spéciales appelées oracles sont utilisées. Ces oracles publient périodiquement des données on-chain, que les contrats intelligents peuvent ensuite récupérer. Cependant, en raison du coût élevé des transactions, les oracles ne peuvent pas publier régulièrement des données on-chain, ne les publiant souvent qu'à de longs intervalles. En conséquence, les données on-chain deviennent obsolètes et pourraient potentiellement entraîner de mauvaises décisions par les contrats intelligents. C'est particulièrement important pour pouvoir offrir des expériences de trading comparables au Web 2. De plus, en raison d'une exécution coûteuse, toute forme d'agrégation de données ou de calcul supplémentaire devient irréalisable.

3. Gouvernance. La gouvernance on-chain, ou le vote on-chain, est un moyen efficace de rendre les processus de prise de décision transparents et décentralisés. Jusqu'à présent, pour qu'un vote on-chain ait lieu, les électeurs devaient exprimer leur vote (en fonction de la quantité de token X qu'ils détiennent ou de tout autre mécanisme pour obtenir un pouvoir de vote) en envoyant une transaction. Cependant, pour que la gouvernance soit décentralisée, des décisions efficaces doivent être prises fréquemment et rapidement. En raison des coûts de calcul élevés , le vote on-chain est devenu un système de vote inefficace. Voter est trop cher, alors les gens ne votent tout simplement pas. Par conséquent, de nombreux projets ont opté pour une gouvernance off-chain , ce qui va à l'encontre de l'objectif des blockchains.

4. Jeux. Lorsqu'on parle de jeux on-chain, le jeu autrefois viral Axie Infinity vient à l'esprit. Dans le jeu développé par Sky Mavis, les personnages du jeu, les Axies, étaient représentés par des NFT. Cependant, la logique du jeu fonctionnait de manière similaire à tous les autres jeux traditionnels, sur un serveur centralisé. Les jeux nécessitent que les joueurs prennent de nombreuses décisions en peu de temps, chacune représentant une sorte de transaction. Et en fonction de la décision du joueur, l'intrigue du jeu peut changer, ce qui nécessite de grandes quantités de calcul. Cette limitation du calcul coûteux a fait que des jeux comme CryptoKitties et Axie Infinity ne comportaient que des composants limités on-chain. Cependant, en se présentant comme des jeux "web3", ils ont atteint une capitalisation boursière de plusieurs milliards de dollars à leur apogée, malgré le fait qu'ils ne représentaient pas véritablement le jeu sur blockchain.

Ouvrir de nouveaux cas d'utilisation grâce à une computation à faible coûts

Cependant, si nous pouvons effectuer une computation à faible coûts, nous pouvons ouvrir un nouvel ensemble de cas d'utilisation pour la blockchain. Starknet est déjà actif sur le mainnet et traite des dizaines de milliers de transactions chaque jour (avec plus de 7 millions de transactions effectuées à ce jour). Comme mentionné, une fois que l'EIP-4844 sera intégré, le coût des transactions diminuera considérablement.

Examinons certains des cas d'utilisation que ce calcul économique sur Starknet permet.

Transactions abordables et abstraction de compte

Le plus simple de tous est qu'avec des transactions bon marché vient une utilisation quotidienne. Payer votre café ne vous coûte désormais que quelques centimes (ou même une fraction de centime). De plus, grâce à l'abstraction de compte, votre portefeuille de crypto-monnaie fonctionne de manière similaire à un portefeuille traditionnel. Tout comme vous conservez l'essentiel de vos finances dans un compte d'épargne sécurisé, vous stockez la majorité de vos actifs dans un portefeuille avec plusieurs couches de sécurité (par exemple, nécessitant qu'une personne de confiance co-signe de gros transferts ou utilisant une clé privée unique).

Transformer les flux de données avec une computation on-chain abordable

Avec l'introduction d’une computation à faible coûts on-chain, les oracles auront un aspect très différent de celui d'aujourd'hui.

Tout d'abord, des mises à jour fréquentes des flux d'oracle deviennent possibles puisque les transactions individuelles coûtent beaucoup moins cher. Cela se traduira par des flux de données plus précis et permettra de développer davantage de cas d'utilisation pour les utilisateurs afin de construire des marchés basés sur ces données (protocoles d'options complexes, marchés de prévision, etc.).

Puisque Starknet est un rollup, il doit envoyer périodiquement un engagement sur le mainnet d'Ethereum pour mettre à jour l'état du rollup (généralement l'écart entre les engagements peut aller de quelques minutes à quelques heures). Cet engagement est l'un des coûts majeurs qu'un utilisateur paie lorsqu'il paie les frais de transaction sur un L2. Cependant, les rollups ne doivent s'engager que sur le dernier état sur le L1. Écraser plusieurs fois le même emplacement de stockage dans un seul bloc n'entraîne pas de coûts de stockage élevés. Dans le cas des oracles, si une variable (par exemple, le prix d'un actif) est mise à jour fréquemment dans le même engagement, le coût sur le L1 serait toujours équivalent à une seule écriture, car seul l'état final est publié sur le mainnet en tant que calldata.

Les flux de calcul — ou flux de données agrégées et calculées — deviennent possibles grâce au coût d'exécution moins cher. Dans la finance traditionnelle, les applications financières utilisent des flux de données sophistiqués, incluant le risque, le rendement et la volatilité. Des équipes comme Pragma travaillent à apporter ces flux au web3. Pragma a déjà deux flux de calcul en direct sur le testnet Starknet : un indice de volatilité et une courbe de rendement.

L'utilisation des preuves de stockage changera également le paysage des oracles. Les preuves de stockage sont un moyen cryptographique de suivre le stockage. L'utilisation de ces engagements cryptographiques permet de prouver sans confiance qu'un état particulier existait à un moment donné (ou à un bloc spécifique, dans le cas des blockchains). Pour vérifier ces preuves, des calculs sont nécessaires (bien qu'ils soient très légers), et le calcul économique améliorera l'expérience utilisateur. Avec les preuves de stockage, il devient possible de transférer des informations entre différentes chaînes de manière décentralisée, d'offrir des données historiques de la blockchain, et bien plus encore. Si vous souhaitez approfondir les preuves de stockage, consultez notre article sur Medium.

La transition vers une logique de jeu sur chaîne

L'univers des jeux vidéo est immense. Aux États-Unis, le plus grand marché de jeux, le chiffre d'affaires annuel généré par les jeux vidéo s'élève à un impressionnant 54 milliards de dollars. Bien que les jeux basés sur la blockchain aient récemment été sous les projecteurs, ils appartiennent principalement à la catégorie "web2.5" plutôt qu'à de véritables jeux "web3".

Pour qu'un jeu soit véritablement considéré comme un jeu de blockchain, il doit :

Pour que la logique d'un jeu soit entièrement sur chaîne, une exécution bon marché est essentielle.

Pour qu'un jeu soit considéré comme un jeu Web3, un test élémentaire "de témoin" pourrait être de savoir si le jeu pourrait survivre si les développeurs derrière le jeu disparaissaient soudainement. Cela ressemble beaucoup à la façon dont un contrat intelligent vit sur la chaîne ; peu importe si le développeur du contrat intelligent est toujours actif ou non, le jeu devrait continuer. Différentes interfaces pourraient être construites sur la logique du jeu si les mécaniques de jeu de base et les règles sont sur la chaîne. D'un autre côté, les développeurs seraient incités à construire avec des jetons spécifiques au jeu. Même si aucun grand jeu n'est actuellement entièrement construit sur la chaîne, plusieurs projets sur Starknet vont dans la bonne direction, y compris Realms et Influence.

Des développeurs de l'écosystème, comme Dojo, travaillent à fournir un cadre ECS (Entity-Component-System) open source pour l'écosystème Starknet. Un cadre ECS est un modèle de conception de base utilisé pour construire des jeux de manière modulaire. Par exemple, pour le cas de Mario Kart, Mario et sa voiture seraient des entités, la position et la vitesse des voitures seraient des composants et la logique des collisions de voitures serait mise en œuvre comme un système. Le développeur du jeu utiliserait ensuite ces composants pour construire le jeu. Des projets comme celui-ci sont nécessaires à mesure que l'écosystème grandit, et de plus en plus de développeurs de jeux rejoignent pour construire des jeux sur Starknet.

Applications IA transparentes

Avec le buzz récent autour de l'intelligence artificielle, il semble que l'IA pourrait bientôt être intégrée à notre univers numérique. Bien qu'il ne soit pas certain que les modèles d'IA soient mis sur chaîne, plusieurs raisons pourraient rendre cela bénéfique. Et un calcul économique est indispensable pour ces cas d'utilisation.

1. L'inférence vérifiable signifie que les modèles sont pré-entraînés sur des serveurs centralisés. Cependant, une fois l'entraînement terminé, les poids du modèle pourraient être publiés sur la chaîne. Une fois cela fait, les entrées pourraient être transmises au modèle sur chaîne, et les sorties maintiendraient la transparence avec l'utilisateur ayant la preuve du modèle générant une certaine sortie.

2. Des ensembles de modèles sur chaîne pourraient être rendus possibles si le calcul est suffisamment économique pour que les modèles soient exécutés pour générer des sorties sur chaîne. Les sorties de plusieurs modèles pourraient ensuite être agrégées pour former un modèle "ensemble" couramment utilisé dans les applications ML.

3. L'entraînement vérifiable signifierait que les modèles pourraient être entraînés sur la chaîne, en maintenant une preuve vérifiable d'un entraînement bienveillant sans introduire de biais externes. Il s'agit peut-être de l'application la plus intensive en calcul parmi celles mentionnées ci-dessus et aussi la moins susceptible d'être mise en service prochainement. De nos jours, les grands modèles d'IA/ML prennent des jours (ou des années) pour être formés sur des GPU avec d'énormes ressources. De plus, la génération de preuves S[N/T]ARK pour le calcul effectué lors de l'entraînement serait un surcoût actuellement. De plus, Cairo fonctionne spécifiquement sur des CPU (qui sont beaucoup plus lents que les GPU).

Source: https://www.moduluslabs.xyz

Giza et Modulus Labs (également abrégé en ML) font partie des principales équipes de recherche travaillant à l'introduction de l'IA sur chaîne en utilisant des preuves ZK.

Quel est l'avenir de Starknet ?

Dans un avenir proche, la feuille de route de Starknet se concentre sur la performance et une meilleure expérience utilisateur. On prévoit une augmentation du débit, une réduction de la latence et des frais de transaction plus bas d'ici le troisième trimestre 2023. Pour plus de détails sur les plans de développement, vous pouvez vous référer à la feuille de route donnée ici.

Cairo est spécialement conçu pour la preuve STARK, ce qui le rend optimal pour exploiter les avantages des systèmes de preuve algébrique et garantir des processus de calcul et de vérification efficaces.

Starknet est conçu pour la scalabilité, garantissant qu'il peut accueillir une croissance exponentielle sans sacrifier la sécurité ou la décentralisation.

Conclusion

Avec les recherches intensives autour de l'espace "blockchain modulaire", l'objectif de "rassembler un milliard d'utilisateurs" se rapproche de plus en plus. Et avec Starknet, le calcul à faible coût est disponible et ne cesse de devenir de moins en moins cher.

Le livre Starknet offre un excellent point de départ pour les développeurs qui entament leur voyage avec Cairo pour Starknet. Les chapitres 0 à 2 fournissent notamment une introduction à divers sujets.

TL;DR:

• Les NFTs dynamiques sont des jetons interactifs qui modifient les données on-chain en fonction des événements.

• Les NFTs actuels rencontrent des défis liés aux données statiques ou aux risques de centralisation.

• Starknet permet des NFTs dynamiques et décentralisés avec des coûts de calcul et de stockage réduits.

• Les NFTs dynamiques permettent des applications innovantes dans les domaines du jeu, de la musique et de l'art.

• L'émergence des NFTs dynamiques signifie une évolution dans la sphère NFT, offrant une plus grande flexibilité et adaptabilité.

Si vous avez suivi le web3 ces dernières années, vous avez probablement entendu parler du Bored Ape Yacht Club - des NFTs qui se sont vendus pour des centaines d'ETH. (La plus grosse vente du Bored Ape Yacht Club s'est faite pour la somme astronomique de 3,4 millions de dollars.)

Ces images JPEG de personnages pixelisés sont probablement ce qui vous vient à l'esprit lorsque vous entendez le mot "NFT". Cependant, le concept de token non fongible est bien plus diversifié que de simples JPEGs, et potentiellement bien plus puissant.

Dans cet article, nous examinerons le concept des NFTs dynamiques - des NFTs qui peuvent changer leurs données on-chain en réponse à un événement on-chain (ou même réel). Nous verrons quelques exemples actuels, certaines utilisations futures potentielles, puis comment Starknet permet ce nouveau type de NFT avec ses coûts de calcul et de stockage réduits.

Qu'est-ce que les NFTs dynamiques ?

NFT signifie "token non fongible", un actif numérique qui représente la propriété d'un élément/information unique. Les créateurs peuvent tokeniser leurs œuvres en les représentant avec des NFTs. Par exemple, les billets pour des événements peuvent être représentés sous forme de NFTs, des actifs réels tels que des biens immobiliers peuvent être liés à de tels tokens et devenir échangeables, et même la musique et les films peuvent être capturés sous forme de NFTs.

Cependant, ces NFTs peuvent encore être considérés comme de "première génération" - les cas d'utilisation les plus intéressants restent à explorer, et des évolutions de la norme sont en cours de création.

Un exemple de l'avenir des NFTs est les NFTs Dynamiques - des NFTs qui peuvent changer la valeur qu'ils représentent. Par exemple, des NFTs qui représentent une image peuvent voir cette image changer de couleurs et de forme, ou même prendre un aspect complètement nouveau. Les NFTs audio peuvent faire évoluer leur son en réaction à des événements on-chain.

Puisque toutes les données relatives à ces NFTs sont stockées on-chain, ces changements sont transparents et peuvent être liés à certaines permissions ou événements. Nous entrerons dans les détails de la manière dont un tel projet pourrait fonctionner plus tard dans cet article, mais commençons d'abord par examiner les NFTs d'un point de vue technique et voyons pourquoi la plupart des NFTs actuels ne peuvent pas être dynamiques.

L'état actuel des NFTs

En général, lorsqu'on parle de NFT, on fait référence à la norme ERC-721, qui a été officiellement créée en 2018. Cette norme est une interface de base pour les tokens non fongibles, qui déclare certaines des fonctions que chaque contrat intelligent implémentant l'ERC-721 doit prendre en charge. Pour ceux qui n'ont pas de connaissances en Solidity, il s'agit d'une sorte de plan qui définit comment interagir avec un contrat/classe, en spécifiant les fonctions sans leurs implémentations.

À chaque fois qu'un NFT change de propriétaire, la fonction transferFrom est appelée, ce qui modifie le propriétaire du NFT dans le registre. De même, lorsque nous vérifions qui possède un token particulier, nous appelons la fonction ownerOf.

Les places de marché telles qu'OpenSea dépendent des NFT pour respecter cette norme afin d'afficher les tokens sur leurs sites web et de transférer les NFT entre acheteurs et vendeurs.

Cependant, examinons de plus près l'un des NFT BAYC : le Singe n°8817. Si vous visitez la page sur OpenSea, vous verrez l'image associée au Singe 8817. Mais où cette image est-elle stockée ? Ce n'est pas on-chain ! Stocker l'image entière sur le réseau principal d'Ethereum coûterait une petite fortune en espace de stockage, et étant donné qu'il y a des millions de NFT sur Ethereum, il est impossible de stocker toutes ces images on-chain.

Au lieu de cela, ces contrats intelligents stockent toutes leurs données liées aux NFT (c'est-à-dire les "métadonnées") sur une URL accessible depuis internet. Les deux principales options pour les NFT consistent à conserver les métadonnées off-chain sur une solution de stockage décentralisée comme IPFS (voici un exemple des métadonnées liées au Singe n°8817), ou à stocker les données sur une source centralisée comme le stockage cloud traditionnel.

Le premier choix, IPFS, crée une contrainte fondamentale : les données deviennent statiques. Une fois stockées sur IPFS, il est impossible d'apporter des modifications.

La deuxième solution permet de modifier les métadonnées liées aux NFT, mais introduit le sérieux problème de la centralisation, allant à l'encontre de l'éthique de la blockchain.

Ainsi, dans ce conflit constant entre une accessibilité accrue et une centralisation accrue, nous nous retrouvons avec des NFT qui restent "identiques", même pour des cas d'utilisation qui nécessitent des changements dynamiques, tels que les jeux, les SBT, les tokens de créateurs, etc.

Il est nécessaire d'avoir des NFT qui bénéficient des avantages de ces deux options : dynamiques et décentralisés. C'est là qu'interviennent les NFT dynamiques.

Les NFTs dynamiques rendus possibles par la faible consommation et le stockage sur Starknet

Starknet est un rollup de validité (également appelé zero-knowledge rollup) développé par StarkWare, utilisant des systèmes cryptographiques nommés STARKs pour réduire les coûts de calcul et de stockage de manière significative. Grâce à ces économies, Starknet rend enfin possible le concept de NFTs dynamiques - à la fois dynamiques et décentralisés.

Voyons comment cela fonctionne avec un exemple.

Le protocole Carbonable est un projet qui vise à être un hub pour la neutralité carbone. Il finance des projets de régénération, gère les programmes de bilan net zéro des entreprises et leur reporting. Leur engagement en faveur de la décentralisation et de la transparence les a conduits à développer l'une des premières preuves de concept pour des NFTs "dynamiques", de telle sorte que les métadonnées du NFT sont stockées entièrement on-chain. Ci-dessous se trouve un exemple de token du contrat NFT que Carbonable a déployé.

En guise d'expérience, j'ai transféré une grande partie de cette "valeur" vers une autre adresse. Les métadonnées associées au token ont été mises à jour automatiquement. L'image décrivant mon token a également changé. Comme vous pouvez le voir ci-dessous, la couleur du texte est passée de doré à bronze. Notez que ce changement s'est produit entièrement on-chain. C'est la puissance des NFTs dynamiques !

Contrairement aux ERC-721, où le solde et l'ID d'un token spécifique sont utilisés pour comprendre la propriété d'un NFT, pour les NFTs dynamiques, l'information principale est la valeur stockée dans un token.

Cela signifie que chaque fois qu'un utilisateur demande la valeur stockée dans le token, cette valeur peut changer. Ceci est mis en œuvre en déclarant un contrat simple (appelons-le le contrat "métadonnées") qui gère à la fois la partie dynamique et la partie statique des métadonnées du NFT. Pour une compréhension plus superficielle, nous pouvons considérer la partie "statique" comme une courte chaîne de caractères qui stocke une propriété du NFT.

D'un autre côté, la partie "dynamique" est différente car pour retourner certaines informations (pour simplifier, supposons qu'elle retourne également une chaîne de caractères), elle peut exécuter du code sur le contrat de métadonnées. Le code peut être dynamique dans le sens où les valeurs qu'il retourne peuvent changer en fonction de différents paramètres spécifiques à la chaîne ou de l'état du contrat lui-même. Il serait possible de changer l'état du contrat suite à une interaction externe.

Notez que le contrat de métadonnées ne doit être déclaré que sur Starknet; il n'est même pas nécessaire de le déployer en tant que tel. Contrairement à Ethereum, Starknet distingue entre une classe de contrat et une instance de contrat. Une classe de contrat représente le code d'un contrat (mais sans état), tandis qu'une instance de contrat représente une instance spécifique de classe avec son propre état. Lorsque vous déclarez une classe de contrat, le code est stocké on-chain, mais il n'y a pas d'état à entretenir. Étant donné que le contrat de métadonnées n'a pas nécessairement à avoir un état, le simple fait de le déclarer suffit pour exécuter le code à l'intérieur des fonctions qui sont appelées par le contrat NFT.

La preuve de concept déployée par l'équipe de Carbonable est entièrement décentralisée car le code SVG stocké dans l'image est entièrement déployé sur le contrat (voir le code ici). Cela permet à quiconque de suivre les modifications apportées au SVG. Dès que le jeton est transféré d'un utilisateur à un autre, la valeur du jeton peut changer, démontrant ainsi sa capacité d'adaptation.

Cas d'utilisation des NFT dynamiques

Cet exemple déployé uniquement à des fins de test ouvre la porte à une vaste gamme de possibilités, telles que :

• Images et animations : comme le montre l'exemple ci-dessus, des images modifiables peuvent être stockées on-chain. De plus, des animations peuvent également être stockées on-chain et peuvent être modifiées avec l'interaction de l'utilisateur. Plusieurs équipes travaillent actuellement sur ce sujet avec d'énormes possibilités dans l'espace de jeu crypto. Par exemple, dans le projet de preuve de concept de Carbonable (que nous avons mentionné plus tôt), la couleur du texte change avec la valeur stockée dans le token. Ainsi, si un utilisateur possède un token avec une valeur > 1000, la couleur du texte peut être dorée, tandis qu'elle serait argentée si la valeur est comprise entre 100 et 1000.

• Musique et audio : lorsque nous écoutons de la musique ou des fichiers audio, ces fichiers sont souvent au format .mp3 ou .wav. Ce format de fichier audio est "fini" en ce sens qu'il n'y a pas de moyen rapide de changer un rythme ou une petite partie du clip. Les formats audio (comme WAV ou MP3) stockent des données sonores réelles, tandis que les fichiers MIDI (Musical Instrument Digital Interface) contiennent des instructions pour les synthétiseurs ou d'autres dispositifs pour générer des sons.

Raphael Doukhan, le co-fondateur de Rosis Lab, a travaillé sur une preuve de concept pour la musique générative en stockant un fichier MIDI sous forme d'objet JSON sur Starknet et a permis au fichier d'être modifié par une interaction externe. Certaines parties du fichier musical étaient constantes (par exemple, la structure musicale, le thème de la mélodie, etc.) et d'autres étaient modifiables (par exemple, BPM, profil de tension, clés, etc.). Cette preuve de concept était un exemple de musique générative où l'œuvre d'un artiste "n'est plus un objet fini, mais vit au-delà du créateur et de la création". Par exemple, la fréquence de battement du fichier audio peut être modifiée à mesure que les utilisateurs interagissent avec le fichier, et donc, la musique acquerrait une caractéristique unique lors de nouvelles interactions.

• Jeux, sports fantastiques et objets de collection : on-chain pourraient exploiter la puissance des NFT dynamiques pour apporter des modifications in-game à l'environnement, aux objets et aux personnages en fonction des différents modes de jeu.

  Par exemple, Realms, un jeu multijoueur on-chain Starknet, explore le cas d'utilisation des NFT dynamiques pour avoir des skins de personnages on-chain (et même de la musique) qui changent avec le jeu.

Dans les sports fantastiques, les caractéristiques d'un personnage pourraient être améliorées/diminuées en fonction de la performance réelle du joueur (qui pourrait être récupérée à partir d'oracles). Un exemple de cela est le NFT alimenté par ChainLink de LaMelo Ball. Après chaque match, les statistiques du joueur de NBA sont apportées on-chain à l'aide d'un oracle, et les fans peuvent collecter le "talent" du joueur sous forme de tokens. Il existe 4 catégories différentes de NFTs de LaMelo : Red Mars, Blue Neptune, Silver Moon et Gold Sun. Elles sont toutes liées à différentes statistiques du joueur de NBA. Par exemple, Red Mars est lié aux points marqués, et Silver Moon est lié aux passes réalisées. Ainsi, chaque fois que LaMelo marque des points ou fait une passe, la valeur à l'intérieur du NFT respectif augmente.

Cette idée peut être intégrée dans les jeux pour que les skins des personnages deviennent "plus cool" à mesure que le niveau du joueur augmente, ou que les réussites du joueur soient affichées sur le NFT sous forme de médailles et de trophées.

• Art génératif : L'art prend de nombreuses formes, dont certaines ont été évoquées ci-dessus. Cependant, la notion d'art est vaste. OG:CR (Organic Growth: Crystal Reef) est un projet NFT dynamique qui fait le lien entre l'art numérique et physique. Les utilisateurs peuvent collecter des NFT de cristaux on-chain, et les NFT évoluent à chaque transfert entre les utilisateurs. L'historique du portefeuille de l'utilisateur (avec une pointe d'aléatoire) décide des changements apportés aux cristaux. L'idée finale est de convertir les cristaux numériques en une œuvre d'art physique qui peut être exposée dans des musées du monde entier.

Les NFT dynamiques sont une évolution

Bien que toujours en développement, les NFT offrent une multitude d'applications. L'émergence des NFT dynamiques représente une évolution supplémentaire dans l'adoption de cette technologie. Stocker une grande quantité d'informations de manière efficace et la modifier de manière cohérente est rendu possible par des chaînes à faible coût de calcul comme Starknet. Starknet est en train de connaître un développement significatif, et c'est le moment opportun de rejoindre les développeurs de l'avenir et d'envisager de construire des projets avec de nouveaux cas d'utilisation passionnants sur Starknet.

Conclusion

Les Tokens Non Fongibles Dynamiques (NFTs) sont à l'avant-garde d'une métamorphose des actifs numériques, répondant et évoluant de concert avec des événements on-chain ou dans le monde réel. Ces versions améliorées des NFT traditionnels brisent le moule des données statiques, introduisant des changements transformateurs en valeur et en forme. La puissance du calcul et du stockage rentables de Starknet fait passer le rêve des NFT dynamiques à la réalité, dévoilant une multitude de possibilités telles que des images adaptables, de la musique évolutive, des jeux interactifs et de l'art génératif. Alors que notre exploration de l'univers de la blockchain et des actifs numériques se poursuit, les NFT dynamiques incarnent une évolution passionnante, marquant une nouvelle ère dans les sphères de la technologie et de la créativité.

Guider les développeurs dans leur chemin vers la programmation en Cairo

TL;DR

• Les développeurs élargissent leurs compétences pour inclure Cairo, motivé par la croissance de Starknet.

• Solidity a permis la création de contrats intelligents interopérables à l'échelle mondiale, mais nécessitait une répétition importante des calculs.

• L'efficacité de Cairo découle de sa capacité à créer des preuves d'exécution de transactions vérifiables à l'aide d'une seule machine.

• Cairo et Solidity sont tous deux des langages de contrats intelligents, mais leurs fonctionnalités et leurs principes sont distincts.

Introduction

Avec la croissance de Starknet (et l'enthousiasme continu autour des Rollups), Cairo est devenu l'une des compétences les plus recherchées dans le domaine de la web3.

Cairo, est utilisé pour écrire des contrats intelligents sur Starknet et StarkEx, ainsi que pour mettre à l'échelle des applications telles que dYdX et ImmutableX. Le nombre de développeurs à temps plein a augmenté de manière spectaculaire de 875 % au cours des deux dernières années et de 83 % d'une année sur l'autre. Et comme Cairo peut être utilisé en dehors des blockchains chaque fois qu'une preuve de calcul est nécessaire, l'adoption de Cairo par les développeurs devrait continuer à augmenter.

Beaucoup de ces nouveaux développeurs Cairo proviennent de Solidity, le langage de contrats intelligents du L1. Si vous faites partie des développeurs qui effectuent cette transition, nous sommes là pour vous aider !

Dans cet article, nous vous donnerons un guide du développeur pour passer de Solidity à Cairo. Nous parlerons de ce qui distingue Cairo, de son fonctionnement d'un point de vue technique, puis nous examinerons quelques exemples de code pour montrer les principales différences entre les langages.

Commençons !

Qu’est-ce que Cairo?

Cairo est le langage de contrats intelligents natif pour Starknet et inspiré de Rust.

Selon la documentation de Cairo, "Cairo est le premier langage Turing-complet permettant de créer des programmes prouvables par STARK pour le calcul général." Analysons cette définition.

Turing-complet signifie que ce langage de programmation peut simuler une machine Turing-complet. Une machine Turing-complet (nommée d'après Alan Turing) est un ordinateur capable d'effectuer n'importe quelle computation et d'exécuter n'importe quel algorithme si suffisamment de temps et de ressources lui sont fournis.

Prouvable par STARK signifie que les programmes écrits en Cairo peuvent être exécutés de manière à ce qu'une preuve STARK (Scalable Transparent ARguments of Knowledge) de l'exécution puisse être créée efficacement. Lorsqu'un programme écrit en Cairo est exécuté sur n'importe quelle machine, une preuve STARK nouvellement générée est créée. Ceci permettant à tout Verifier indépendant de vérifier de manière succincte l'exécution honnête du programme, sans avoir à faire confiance à la machine sur laquelle les calculs du programme ont été effectués.

Cairo 1.0 vient d'être publié ce printemps (remplaçant Cairo 0) et est déjà disponible sur le Mainnet de Starknet.

Lequel est meilleur - Cairo ou Solidity ?

Aucun des deux ! D'une certaine manière, c'est une comparaison "entre pommes et oranges".

Solidity est le langage d'abord utilisé pour l'adoption généralisée de la computation composable. Un paradigme de programmation dans lequel différents composants d’un système peuvent être utilisés en synchronisation et composés en logiciels compliqués en utilisant différents composants comme des blocs Lego.

Solidity a permis aux contrats intelligents d'être étroitement liés pour les raisons suivantes :

• Le bytecode est rendu public et transparent pour le monde

• Les structures ABI standard (qui permettaient à d'autres d'interagir avec des contrats intelligents externes)

• Mettez à profit le réseau Ethereum pour une disponibilité proche de 100%

• L'utilisation du réseau Ethereum comme moyen d'exécuter des transactions financières

• L'interopérabilité globale des contrats intelligents grâce à un EVM commun et unique (dont une copie est détenue par tous les validateurs du réseau)

Même si Solidity a atteint une myriade d’innovations en étant le langage de contrat intelligent le plus adopté, Cairo a une propriété unique et puissante : sa capacité à créer des programmes prouvables pour la computation générale.

Cette propriété fait une différence unique, nous permet de passer d'un système dans lequel chaque computation doit être répétée des centaines de milliers de fois (c'est le nombre de validateurs dans le réseau Ethereum), à un système plus récent où une seule machine (appelée Prover) crée une preuve de l'exécution correcte d'une transaction que d'autres sur le réseau peuvent vérifier.

Différences entre la machine virtuelle Cairo et la machine virtuelle Ethereum

Pour que l'exécution des programmes Cairo soit efficacement convertie en une preuve STARK, il existe quelques différences clés entre la machine virtuelle Cairo et la machine virtuelle Ethereum (EVM) :

1. Modèle de mémoire : La machine virtuelle Cairo utilise un modèle de mémoire à écriture unique. Un emplacement mémoire ne peut pas être écrasé (contrairement à l'EVM). Bien que cela puisse sembler être une complexité importante, le compilateur Cairo résout ce problème, et la version abstraite permet l'utilisation de variables mutables dans le code (nous y reviendrons plus tard). Le modèle de mémoire à écriture unique rend Cairo plus prévisible et vérifiable. Chaque adresse mémoire est écrite une seule fois et conserve sa valeur jusqu'à ce que l'exécution du programme soit terminée. Cela signifie qu'il existe un enregistrement clair et immuable du calcul, ce qui est essentiel lors de la génération de preuves STARK, car elles reposent sur la vérification de la conformité des calculs.

2. Champs (Fields) : Lorsque nous parlons de preuves cryptographiques, nous évoquons presque toujours la création de ces preuves pour des opérations sur des éléments d'un certain champ (field). Comme discuté dans notre article sur l'arithmétisation, en mathématiques, un champ est un ensemble d'éléments avec deux opérations binaires, l'addition et la multiplication. Il satisfait certains axiomes, tels que la clôture, l'associativité, la commutativité, et l'existence d'inverses et d'éléments d'identité. Les éléments d'un tel champ sont les sujets d'opérations qui font partie de n'importe quelle computation générale pouvant être prouvée. Lorsque l'on parle de champs, il est important de noter que certains champs sont finis (celui utilisé dans Cairo est également fini). Dans un champ fini, le nombre d'éléments est fini, et tous les éléments sont inférieurs à “l'ordre” le plus élevé du champ. “L'ordre” d'un champ équivaut au nombre le plus élevé que les éléments d'un champ peuvent atteindre plus un. De plus, toutes les opérations d'addition et de multiplication donnent un nombre, le module de l'ordre le plus élevé. Par exemple, dans un champ d'ordre 6, l'addition 3+4 donnerait comme résultat (3+4) mod 6 = 7 mod 6 = 1. Cairo utilise un champ fini d'ordre 2²⁵¹ + 17 * 2¹⁹² + 1. Puisque, lors de la génération de preuves, tous les éléments doivent être des éléments de champ, la machine virtuelle Cairo utilise des éléments de champ comme base pour toutes les opérations. Elle ne suit pas le système conventionnel uint256 ou uint32 utilisé par l'EVM. Cependant, des techniques d'abstraction peuvent être créées pour utiliser le type uint256 (ou similaire) plus pratique. Néanmoins, ces structures nécessitent plus de ressources (augmentation du nombre d'opérations pour prouver la même chose de l'ordre de dizaines) lors de l'exécution.

3. Héritage et polymorphisme : Cairo n'a pas les concepts d'héritage et de polymorphisme. Bien que les contrats puissent être étendus en important des fonctions et des variables de stockage spécifiques, les concepts très utilisés de la programmation orientée objet nécessitent une réflexion un peu différente.

Cairo se compile en Sierra

Une étape à noter est que lorsque vous rédigez un smart contrat Cairo, il est d'abord converti en code Sierra, qui doit être publié sur le réseau. Le code Sierra est une abstraction du code assembleur Cairo brut (CASM) interprété par la machine virtuelle Cairo. La compilation du code Cairo en code Sierra entoure le code Cairo de certaines mesures de sécurité, la plus importante étant un mécanisme pour éviter les attaques DoS.

Selon la documentation de Starknet, "Une propriété cruciale de chaque L2 décentralisée est que les séquenceurs sont garantis d'être rémunérés pour le travail qu'ils accomplissent. La notion de transactions révoquées en est un bon exemple : même si la transaction de l'utilisateur a échoué en cours d'exécution, le séquenceur devrait pouvoir l'inclure dans un bloc et facturer des frais d'exécution jusqu'au point d'échec."

Cependant, parfois, un utilisateur peut écrire une ligne de code ou inclure une transaction, prouvant que l'exécution est impossible. Par exemple, l'instruction assert 1 == 0 est une instruction Cairo valide ; cependant, inclure cette exécution dans une preuve cryptographique n'est pas possible car cette instruction est fausse, et elle se traduit par des contraintes polynomiales qui ne sont pas satisfaisables. Par conséquent, Sierra ajoute une couche de sécurité qui garantit que même les transactions révoquées impossibles à prouver sont facturées. Cela atténue à la fois le potentiel d'une attaque DoS contre le séquenceur et répond aux incitations économiques du séquenceur.

Comparaison entre Cairo et Solidity

Maintenant, nous avons une idée des types, fonctions et structures de base de Cairo. Comparons-les à leurs homologues en Solidity pour établir quelques parallèles entre les deux langages de smart contrat. (Gardez à l'esprit que Cairo peut également être utilisé pour écrire du code non lié aux smart contrats pouvant être utilisé pour créer des programmes vérifiables. Cependant, cela sort du cadre de notre discussion actuelle.)

Note : À partir de ce point, toute discussion concernant Cairo concerne Cairo 1. Cairo 0 n'est plus recommandé comme langage de choix pour écrire des smart contrats sur Starknet.

Types de Cairo

Voici la liste de quelques types fondamentaux en Cairo :

Comme vous pouvez le voir dans la liste ci-dessus (nous venons d'ajouter les nombres entiers signés et nous avons également Dict.) À partir de Cairo 1, les nombres entiers non signés ont été ajoutés à Cairo, similaires à leurs homologues en Solidity. Bien que l'utilisation d'entiers puisse être moins rentable pour le séquenceur que l'utilisation directe de felts, l'intégration des entiers dans Cairo promet de simplifier la vie des développeurs.

Mis à part cela, l'utilisation des tableaux est très similaire à la syntaxe en Rust, et leur logique est similaire à celle de Solidity.

Fonctions en Cairo

Les fonctions en Cairo peuvent être de types suivants :

• interne

• externe

• vue

• constructeur

Par défaut, toutes les fonctions de contrat sont considérées comme interne (de telles fonctions ne peuvent être appelées que depuis l'intérieur du contrat, quelque peu similaires aux fonctions privées dans d'autres langages).

Les fonctions externes sont ouvertes au monde et peuvent être appelées par d'autres smart contracts, y compris les comptes. (Hourra, abstraction de compte !)

Les fonctions de vue sont un type de fonction externe qui ne peut lire que l'état on-chain. Les fonctions de vue ne peuvent pas modifier l'état de la chaîne.

Le constructeur est un autre attribut des fonctions en Cairo donné aux... constructeurs d'un smart contrat !

Maintenant, comparons la syntaxe de déclaration de fonction entre Cairo et Solidity :

Penchons-nous plus en détail sur quelques différences clés :

1. Le mot-clé pour déclarer une fonction est fn dans Cairo, tandis qu’avec Solidity, c'est function.

2. Les types de fonctions sont déclarés avant le mot-clé de la fonction avec Cairo (#[view]), mais pour Solidity, le format est différent (voir ci-dessus).

3. Dans le langage de programmation Cairo, la syntaxe pour déclarer les valeurs de retour implique l'utilisation du symbole →. En revanche, avec Solidity, le mot-clé returns est utilisé pour indiquer les valeurs de retour.

Modules dans Cairo

Les modules dans Cairo servent à regrouper des fonctionnalités connexes dans un namespace. Le mot-clé mod est utilisé pour définir un module, suivi du nom du module et d'un bloc de code qui comprend des fonctions et d'autres déclarations. Les modules peuvent importer d'autres modules et utiliser leur fonctionnalité.

Ces modules sont similaires aux bibliothèques dans d'autres langages, et avec Solidity, les modules peuvent être comparés à l'héritage des contrats.

Par exemple, dans le code ci-dessus, les modules starknet et array sont importés. La syntaxe diffère des déclarations import avec Solidity ou de l'héritage qui utilise le mot-clé is (voir ceci). Notez que le mot-clé use rend toutes les fonctions du module importé accessibles à l'intérieur du module d'importation avec Cairo.

Tableaux en Cairo

L'utilisation des tableaux avec Cairo 1.0 est devenue plus simple, car les manipulations du tableau dynamique sont rendues possibles avec les fonctions exportées du module de tableau, telles que append, array_at, et array_len.

Exemple de contrat intelligent avec Cairo

Maintenant que nous comprenons l'ensemble des types et des fonctions en Cairo, examinons un exemple de code de contrat intelligent ERC20 avec Cairo. Un contrat ERC20 est un modèle de contrat intelligent standard pour les tokens que les utilisateurs détiennent on-chain. Il permet aux utilisateurs de transférer des tokens entre eux, de vérifier les soldes des utilisateurs et d'approuver les transferts vers une autre entité. Voici notre contrat :

Remarque : La syntaxe de Cairo 1 change légèrement et sera mise à jour plus tard cette année (2023). Veuillez consulter ce billet pour plus de détails.

Le code ci-dessus est basé sur https://github.com/argentlabs/starknet-build/blob/main/cairo1.0/examples/erc20/ERC20.cairo

Examinons en détail certaines des parties les plus importantes.

Les lignes 1 et 2 initialisent et donnent le nom au smart contract

#[contract]

mod ERC20 {

La ligne 4 importe la fonction get_caller_address depuis le module starknet. La fonction get_caller_address() renvoie l'adresse du contrat qui a appelé la fonction.

use starknet::get_caller_address;

Les lignes 7 à 14 définissent une structure (similaire à struct en Solidity) qui est utilisée plus tard dans le code.

Les lignes 20 et 21 définissent un événement Transfer qui est émis chaque fois que le jeton ERC20 est transféré. Les événements constituent un moyen efficace de suivre les activités de contract/les changements d'état, permettant ainsi aux auditeurs externes de réagir en conséquence.

#[event]

fn Transfer(from_: felt, to: felt, value: u256) {}

Les lignes 36 à 54 contiennent une fonction constructeur (la fonction appelée lorsque le contrat est déployé) et une fonction d'affichage qui lit la variable de stockage name et renvoie sa valeur à l'utilisateur.

Les lignes 97 à 101 définissent une fonction externe (comme discuté précédemment) qui est utilisée pour transférer des jetons ERC20 d'un compte à un autre. Cette fonction appelle la fonction transfer_helper() en dessous, qui émet également l'événement Transfer() défini ci-dessus.

Conclusion

Si vous êtes à l'aise avec Solidity, vous devriez maintenant avoir une excellente base pour comprendre comment fonctionne Starknet, les différences entre Cairo et Solidity, et comment lire des contrats intelligents Cairo de base.

Pour la prochaine étape de votre parcours de développement Cairo, consultez la documentation de Cairo, inscrivez-vous à Cairo Basecamp ou suivez les tutoriels.

Comment nous en sommes arrivés là, notre ADN et où nous allons.

Cet article est basé sur une conférence du professeur Eli Ben-Sasson, co-fondateur et président de StarkWare, lors de StarkWare Sessions 2023 qui s’est récemment tenue en Israël.

Comment en sommes-nous arrivés là ?

La technologie STARK est basée sur des preuves, et plus précisément : des preuves d'intégrité. Le grand C.S. Lewis a magnifiquement défini l'intégrité comme "faire ce qu'il faut, même quand personne ne regarde". L'objectif est l'intégrité, et les preuves sont un moyen d'y parvenir. Les STARKs utilisent les mathématiques pour garantir l'intégrité, en veillant à ce que le calcul soit effectué correctement, même si personne ne regarde.

Le concept d'utiliser un seul ordinateur fiable pour surveiller un groupe de supercalculateurs peu fiables a été introduit dans un article de 1991 par László Babai, Lance Fortnow, Leonid Levin et Mario Szegedy. Cette technologie "PCP" emploie les mathématiques pour surveiller et garantir l'intégrité d'un calcul complexe. Voici comment cela se passe :

Les affirmations computationnelles peuvent être transformées en un puzzle de type Sudoku avec des contraintes qui s'entrecroisent de diverses manières. Chaque affirmation conduit à un puzzle unique. L'entité qui fait l'affirmation est appelée "Prover", et la preuve qu'il soumet équivaut à un puzzle Sudoku rempli (voir l'image ci-dessous). La caractéristique d'une affirmation correcte est que les solutions soumises satisfont chacune des innombrables contraintes associées au puzzle. Et la propriété la plus magique de ces PCP (et la plus difficile à établir mathématiquement) est que, pour les fausses affirmations, n'importe quelle solution soumise violera au moins 99 % des contraintes du Sudoku.

Le Verifier, un ordinateur de confiance, mais à faible capacité, connaît le puzzle unique devant être résolu pour prouver l'affirmation. Au lieu de lire l'intégralité de la solution du Prover, il effectue un "sondage" aléatoire et vérifie une contrainte aléatoire de la solution soumise (la preuve). Et décide ainsi d'accepter ou de rejeter l'affirmation en fonction de la satisfaction de cette seule contrainte aléatoire. Compte tenu de la nette différence entre les solutions des vraies affirmations (qui satisfont toutes les contraintes) et les solutions des fausses affirmations (qui ne peuvent satisfaire plus de 1 % des contraintes). Les propriétés élémentaires des statistiques et du sondage peuvent être utilisées : en échantillonnant, par exemple, 6 contraintes aléatoires et en vérifiant si elles sont valides. Le Verifier saura avec une quasi-certitude, jusqu'à une probabilité d'erreur d'au plus une chance sur un billion (1 000 000 000 000), si le calcul a été effectué avec intégrité.

La dernière propriété magique nécessaire à la scalabilité est que même si le puzzle Sudoku est aussi grand que le nombre d'étapes dans le calcul, le Verifier peut échantillonner, lire et vérifier une contrainte aléatoire en lui rapidement. En fait, la quantité de calcul nécessaire à cette fin est exponentiellement plus petite que la taille du puzzle Sudoku !

Le début des STARKs

La technologie PCP a été développée dans les années 1990, et les STARKs en sont une version modifiée. Une différence clé est qu'au lieu de générer et de remplir un seul puzzle Sudoku, ce processus, de génération de puzzles Sudoku et de remplissage par le Prover, est répété plusieurs fois. Le Verifier échantillonne ensuite une seule contrainte de ce Sudoku multidimensionnel et, en fonction de celle-ci, décide d'accepter ou de rejeter l'affirmation.

En utilisant les STARKs, le petit gars peut vérifier et s'assurer qu'une énorme entreprise, un monopole ou un gouvernement fonctionne correctement.

Une partie importante de cette histoire concerne l'endroit où cette technologie pourrait être utilisée dans le monde réel. Dans le monde conventionnel, il est difficile de trouver un cadre dans lequel un seul ordinateur de confiance, mais à faible capacité, est nécessaire pour surveiller un groupe de supercalculateurs non fiables et potentiellement peu fiables. Où trouvons-nous le scénario d'un seul PC à faible capacité, mais fiable en qui tout le monde a confiance ?

L’arrivée de la Blockchain

Une catégorie cruciale d'innovation au-delà de la cryptographie et du calcul a émergé en 2008 : le travail de Satoshi en 2008 a tout changé.

Tout au long de l'histoire, les transactions étaient effectuées de manière peer-to-peer avec de l'argent liquide et des biens, mais aujourd'hui, elles se font par le biais de plateformes centralisées telles qu'Apple Pay, Visa et Swift. Les utilisateurs doivent faire confiance à ces plateformes pour gérer équitablement leurs transactions.

Bitcoin a revitalisé la nature peer-to-peer de l'échange monétaire en éliminant le besoin d'un intermédiaire de confiance. Ethereum a poussé plus loin ce concept en permettant la création de programmes génériques formant le tissu économique de la société.

Il y a une convergence de deux lignes d'innovation. D'un côté, nous avons PCP (et les STARKs) qui permettent à un seul ordinateur de confiance, mais à faible capacité d'appliquer l'intégrité à plus grande échelle. D'un autre côté, nous avons une blockchain, qui est un ordinateur très fiable qui utilise les mathématiques pour vérifier les calculs à grande échelle. Cela a conduit à la réalisation significative que les blockchains s'alignent parfaitement avec les mathématiques qui garantissent l'intégrité.

L’arrivée de StarkWare

En 2018, StarkWare a été le pionnier de l'utilisation des preuves de validité STARK pour résoudre les problèmes de scalabilité d'Ethereum. La répartition inégale des calculs entre le Prover off-chain et le Verifier on-chain ouvre la voie à une scalabilité massive. Le Prover off-chain traite de grands lots de transactions et génère une preuve STARK, tandis que le Verifier vérifie la preuve on-chain avec un minimum de calcul. Cela permet le traitement off-chain de calculs volumineux tout en garantissant leur intégrité on-chain avec un minimum de frais généraux.

Depuis lors, StarkWare a atteint plusieurs étapes importantes :

• StarkEx, basé sur un modèle économique SaaS, revendique la plus mise à l’échelle de couche 2 sur Ethereum et est en production depuis juin 2020.

• Cairo - Le besoin d'écrire des programmes via un langage de programmation général (Turing complet) qui serait sûr et efficace pour les développeurs à écrire. Le tout en conduisant à des preuves STARKs efficaces pour l'exécution de ces programmes, a conduit à la création de Cairo. Il s'agit du langage de programmation le plus efficace pour tirer parti des preuves de validité, qui sont essentielles pour la scalabilité.

• Starknet est le premier réseau décentralisé en production qui permet d'écrire une logique personnalisée, similaire à Ethereum.

Qu'est-ce qui est dans l'ADN des STARKs ?

• La tête dans les étoiles, les pieds dans la boue : Nous suivons une approche à deux volets. Nous aimons la technologie, les mathématiques et l'innovation, et nous nous concentrons sur la livraison de nos produits.

• L'excellence engendre l'excellence : La plus grande réalisation de StarkWare est le niveau d'excellence auquel aspirent ses giga-brains.

• L'excellence engendre la magnanimité : Nous embrassons et soutenons d'autres équipes qui repoussent les limites d'Ethereum et/ou des STARKs.

• "Pour aller vite, vas-y seul. Pour aller loin, allons-y ensemble." StarkEx, Cairo, et même Starknet ont été initialement réalisés en interne, et ils ont été expédiés rapidement. Ensuite, nous nous efforçons de rendre nos produits open source et décentralisés, et nous nous concentrons sur la transformation des STARKs en un bien public.

https://twitter.com/EliBenSasson/status/1628129930591539228?s=20

Où allons-nous ?

Starknet possède déjà un écosystème en pleine expansion avec environ 1000 développeurs et plus de 400 référentiels GitHub.

En adoptant la mentalité "Pour aller vite, vas-y seul. Pour aller loin, allons-y ensemble", StarkWare va :

• Faire de Starknet un rollup de validité décentralisé et sans permission, gouverné par la Fondation Starknet.

• Se concentrer sur la décentralisation des différentes parties en mouvement de Starknet, telles que le Prover, le Sequencer et la gouvernance.

Pour profiter de la puissance et de la scalabilité des STARKs, apprenez le langage de programmation Cairo en open source et écrivez vos programmes de cette manière.

Accès à l'information inter-chaînes sans confiance sur Starknet.

Introduction

Les preuves de stockage sont une méthode cryptographique permettant de suivre les informations de la blockchain afin qu'elles puissent être partagées entre les chaînes. Similaires aux oracles, les preuves de stockage fournissent une preuve de la véracité de l'information. Cependant, contrairement aux oracles, elles ne nécessitent pas de faire confiance à une tierce partie pour cette preuve; avec les preuves de stockage, la confiance est intégrée dans le stockage lui-même.

Dans certains cas, les preuves de stockage peuvent remplacer les oracles. Dans d'autres cas, elles peuvent les améliorer et ouvrir de nouveaux cas d'utilisation de la blockchain qui n'étaient pas possibles auparavant.

Examinons donc en détail les preuves de stockage : ce qu'elles sont, comment elles fonctionnent, leurs cas d'utilisation, et comment elles peuvent améliorer (et parfois remplacer) les oracles.

Qu'est-ce que les preuves de stockage?

Les preuves de stockage permettent d'ouvrir des engagements cryptographiques d'état. Elles peuvent être optimisées en les associant avec des S[N/T]ARKS. Ces preuves de validité démontrent qu'un état particulier existait et était valide à un bloc particulier dans le passé.

Fondamentalement, les blockchains sont des bases de données contenant des données engagées de manière cryptographique à l'aide d'arbres Merkle, d'arbres Patricia Merkle, d'arbres Verkle, etc. Puisque toutes les données sont engagées, nous pouvons prouver que certaines informations sont encapsulées dans un état donné. Cependant, avec des schémas d'engagement simples, la taille de cette preuve devient plus importante à mesure que la taille des données qu'elle contient augmente. La vérification de telles preuves on-chain devient alors trop coûteuse pour être pratique.

D'un autre côté, les preuves de stockage, lorsqu'elles sont utilisées conjointement avec des STARKs ou des SNARKs, peuvent être relativement petites et permettent de vérifier un morceau spécifique d'état, à un moment précis, et sur n'importe quel domaine, sans avoir à faire confiance à une tierce partie. Au lieu d'utiliser des tierces parties, elles reposent sur la sécurité de la chaîne sous-jacente elle-même.

Pourquoi est-ce important? Aujourd'hui, Ethereum n'est plus la chaîne monolithique simple (L1) qu'elle était il y a plusieurs années. Avec l'avènement des solutions L2, les données sont désormais réparties sur plusieurs chaînes.

Il n'est plus possible de faire des hypothèses synchrones sur l'état de la chaîne. De nombreuses solutions de partage de données sont désormais opérationnelles, telles que les systèmes de messagerie L1->L2, les ponts entre chaînes et les oracles. Toutefois, le problème avec ces solutions actuelles est qu'elles incluent la confiance en une tierce partie telle que les relais, les signataires multisig et les comités. Les preuves de stockage nous permettent de valider l'état d'une blockchain à n'importe quel moment en utilisant des engagements cryptographiques, sans avoir à faire confiance à une tierce partie.

Les cas d'utilisation des preuves de stockage

Étant donné que les preuves de stockage nous permettent de "compresser" efficacement une blockchain et de transmettre les données ailleurs, elles ont de nombreuses applications. Le coût abordable de vérification, une propriété intégrale des preuves de stockage, permet à la preuve d'être validée sur la chaîne de destination, réduisant ainsi le besoin de développer des systèmes de messagerie entre chaînes.

Les cas d'utilisation potentiels comprennent :

• L'accès général à l'information d'une chaîne à partir d'une autre sur l'état et les transactions sur la blockchain.

• Les systèmes de vote inter-chaînes simplifiés.

• Une alternative aux ponts entre chaînes.

• Une UX améliorée pour les cas d'utilisation de l'abstraction de compte (AA)

Un exemple de preuve de stockage

Générer des preuves de stockage sur des chaînes compatibles EVM est simple. Par exemple, la bibliothèque Web3.js possède la fonction getProof qui peut générer une preuve de l'état d'un contrat sur Ethereum (et d'autres chaînes compatibles EVM comme Polygon ou BSC). Pour utiliser cette fonction, il est nécessaire de transmettre à la fonction l'adresse du contrat et l'emplacement de stockage pour le contrat.

Sur Ethereum, les contrats intelligents utilisent une key-value store pour stocker les données dans leur stockage. Chaque morceau de donnée est stocké dans un emplacement spécifique connu sous le nom de "slot de stockage". Ces slots de stockage sont des emplacements mémoire à l'intérieur du stockage du contrat et sont identifiés par un index unique. Pour mieux comprendre, examinons un exemple de contrat intelligent avec le code suivant, déployé sur le réseau principal Ethereum à l'adresse 0xcc…da8b.

La variable owner serait stockée dans l'emplacement 0. Pour prouver que le owner de ce contrat était l'adresse A, nous pouvons utiliser la fonction getProof de la manière suivante :

Le rendu du code ci-dessus ressemble à ceci :

La "storageProof" renvoyée contient la preuve de stockage pour la variable "owner". Étant donné qu'Ethereum utilise des arbres Merkle Patricia pour s'engager envers son état, l'état des comptes et leur stockage, la preuve de stockage générée peut être utilisée pour prouver un emplacement de stockage (ou un état de compte). Cependant, comme mentionné précédemment, ces preuves ne sont pas suffisamment évolutives pour discuter des transferts de messages entre chaînes. Utiliser des mathématiques ZK complexes peut réduire les calculs nécessaires pour vérifier la preuve.

Alors, comment les preuves de stockage se comparent-elles et se distinguent-elles des oracles?

Par conception, les blockchains ne peuvent pas récupérer des données off-chain. Cela rend une blockchain sans confiance mais introduit également des limites sur la capacité d'un contrat intelligent à prendre des décisions basées sur des événements réels.

Des entités spéciales appelées oracles ont été créées pour récupérer ces données off-chain (ou récupérer les résultats de certains calculs off-chain lourds). Les oracles sont également couramment employés pour obtenir des informations historiques sur la blockchain, car l'acquisition de ces données directement est très difficile et donc susceptible d'erreurs.

Actuellement, ces oracles nécessitent une tierce partie, telle qu'une institution ou un réseau décentralisé d'opérateurs de nœuds, pour soumettre des données sur la chaîne qui deviennent publiques pour les utilisateurs et les contrats intelligents. Cette hypothèse de confiance est actuellement inévitable, mais pas idéale (bien que plusieurs équipes travaillent à minimiser cette exigence de confiance, comme Pragma).

Chainlink est un exemple d'oracle de blockchain qui fournit une grande variété de données du monde réel (cours des actions, données météorologiques, etc.), des services de calcul off-chain pour minimiser le coût des calculs lourds on-chain, et des services inter-chaînes qui lisent et écrivent des informations entre différentes blockchains.

Étant donné que les contrats intelligents n'ont pas d'autre moyen de savoir ce qui se passe dans le monde réel à part utiliser des oracles, ces derniers sont devenus une partie indispensable de l'écosystème de la blockchain.

L'état des oracles sur Starknet

Sur le testnet Starknet, Chainlink fournit actuellement des flux de données de prix pour sept paires de cryptomonnaies et s'est associé à l'équipe Starkware pour "accélérer davantage le développement d'applications et la croissance générale de l'écosystème Starknet". Chainlink minimise l'hypothèse de confiance avec un réseau décentralisé de nœuds qui fournissent des données provenant de sources off-chain, mais l'agrégation des données se fait off-chain.

Pragma et Stork Network sont deux des plus grands fournisseurs d'oracle sur Starknet, opérant à la fois sur le mainnet et le testnet. En plus des tickers de prix pour plusieurs paires de cryptomonnaies, Pragma travaille à la mise en œuvre d'un flux de hasard vérifiable sur le mainnet qui permettrait aux protocoles de demander un hasard sécurisé on-chain. Les flux de prix sur Pragma sont basés sur des soumissions de prix par de grandes institutions et des teneurs de marché, et l'agrégation des prix se fait on-chain en tirant parti de la technologie ZK.

Les oracles peuvent-ils être remplacés ou améliorés par des preuves de stockage?

Dans certains cas, une preuve de stockage peut en effet remplacer un oracle.

Toutes les données fournies par les oracles ne nécessitent pas forcément l'intervention d'une tierce partie. Dans certains cas, ces données étaient déjà disponibles on-chain (sous forme de stockage on-chain ou d'une transaction) et peuvent être récupérées en examinant un état précédent de la blockchain. Dans de tels cas, une preuve de stockage suffit à remplacer l'oracle et la nécessité de faire confiance à une tierce partie, permettant ainsi aux contrats intelligents de s'appuyer entièrement sur la sécurité des engagements cryptographiques.

Dans d'autres cas, où les preuves de stockage ne peuvent pas complètement remplacer un oracle, elles peuvent souvent les améliorer avec des fonctionnalités supplémentaires, telles que :

• Les oracles transmettent des informations des fournisseurs de données aux consommateurs de données. Cependant, tous les consommateurs de données ne sont pas sur la même chaîne. Avec l'aide des preuves de stockage, il est possible de réaliser certains calculs sur les données provenant de différentes sources et d'exporter le résultat vers d'autres chaînes.

• La chaîne source préférée pour ces données est celle avec un calcul bon marché, et la validation de la preuve peut être effectuée de manière rentable sur d'autres chaînes de destination.

• Herodotus est l'un des leaders de la recherche dans ce domaine, et ils offrent un accès aux données entre différents domaines sur différentes chaînes Ethereum à l'aide de preuves de stockage et de mathématiques ZK. Pragma s'associe également à Herodotus pour activer le support de l'oracle inter-chaînes dans un avenir proche.

• Les preuves de stockage peuvent unifier l'état de plusieurs rollups et permettre des lectures synchrones entre les couches Ethereum.

• Une autre amélioration est la récupération sans confiance des données historiques publiées on-chain. Les blockchains avec état, telles qu'Ethereum et Starknet, enregistrent et préservent cryptographiquement leur état grâce à des structures de données spécialisées, telles que les arbres Merkle/Verkle et les MPT. Cela rend possible la preuve de l'inclusion de n'importe quelle donnée stockée dans ces structures. Par conséquent, toute donnée passée publiée on-chain peut également être fiable, récupérée et utilisée dans d'autres applications (pas nécessairement sur la même chaîne). Ces preuves de stockage permettent aux contrats intelligents d'accéder à des informations remontant même au bloc de genèse.

• Pragma étudie la viabilité de développer un oracle en tant que L3 sur Starknet à partir duquel les données peuvent être "tirées" sur d'autres chaînes et vérifiées à l'aide de preuves de stockage. Les avantages d'avoir l'oracle dans un domaine différent sur un réseau aussi économique que Starknet comprennent :

  • Étant donné que le L3 pourrait être une chaîne hautement personnalisable, divers paramètres peuvent être ajustés pour parvenir plus rapidement à un consensus sur les blocs, réduisant considérablement la latence des données pour l'oracle.

  • En combinaison avec les preuves de stockage, les données à faible latence peuvent être transférées de manière asynchrone vers d'autres chaînes, une fois le consensus atteint sur la chaîne source.

  • La possibilité d'accroître la confiance dans les données en développant un système intégré dans le L3 pour punir les fournisseurs de données malhonnêtes. Si les incitations appropriées sont données, les fournisseurs de données sur le L3 pourraient mettre en jeu leurs actifs comme garantie de la publication de données correctes. Étant donné que le consensus de l'ensemble du réseau sur le L3 est nécessaire avant que d'autres chaînes puissent utiliser les données, les données fournies par l'oracle peuvent être considérées comme sécurisées par la participation validateur sur le L3.

Conclusion

Au cours des derniers mois, l'utilisation croissante des L2 sur Ethereum nous a donné une vision plus claire de l'avenir de l'industrie. La narration autour des L2 gagne en traction avec des réseaux tels que Starknet, Optimism et Arbitrum. Cependant, l'un des principaux freins à sa croissance a été la mise en œuvre d'un système de messagerie inter-chaînes décentralisé. Bien qu'ils en soient encore à un stade naissant, les preuves de stockage promettent d'incroyables améliorations à ce problème.

Un grand merci à Marcello Bardus et Kacper Koziol pour avoir relu cet article.

TLDR:

• 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.

La machine virtuelle off-chain

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.

L'Approche zkEVM

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.

Prouvabilité de l'EVM

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.)

L'Approche Cairo-VM

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.

Cairo et le Pluralisme du Codage

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.

Résumé

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.

Types de zkEVM

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é.

TLDR

• Starknet présente : Volition !

• Volition permettra aux développeurs de réguler la disponibilité des données sur Ethereum (L1) ou sur Starknet (L2). La réduction des données on-chain sur le L1 peut radicalement réduire les coûts.

• La flexibilité dans les modes de disponibilité des données offrira aux développeurs et utilisateurs de Starknet une plus grande liberté, leur permettant de choisir le niveau de sécurité le plus adapté à leurs besoins spécifiques de manière rentable.

• Volition sera implémenté sur le testnet au cours du quatrième trimestre de 2023.

Rollups de Validité : Augmenter le Débit, Réduire les Coûts

À mesure qu'Ethereum continue de croître, le besoin de scalabilité et de réduction des coûts devient de plus en plus urgent. Pour répondre à cela, les Rollups de Validité sont apparus comme une solution de scalabilité efficace qui fonctionne au-dessus d'Ethereum.

Starknet, un Rollup de Validité créé par les inventeurs des preuves STARK, fonctionne comme une couche 2 qui permet des calculs massifs et réduit les frais de calcul en ne soumettant à Ethereum (L1) que les données indispensables de chaque transaction. Le tout en utilisant un Prover partagé (SHARP) pour répartir les frais de validation on-chain de la preuve sur toutes les transactions dans un lot donné.

Au quatrième trimestre de 2023, Starknet débloquera une autre réduction significative des coûts, abordant un défi majeur auquel les développeurs sont confrontés en ce qui concerne les frais de transaction : le coût élevé des données on-chain du L1.

Parmi les différents facteurs qui déterminent le coût d'une transaction, la disponibilité des données on-chain à elle seule peut représenter jusqu'à 95 % du coût moyen de la transaction. Trouver un moyen de réduire les données on-chain du L1 peut avoir un impact majeur sur la réduction globale des coûts que les utilisateurs et les développeurs peuvent obtenir. La solution de Starknet à ce défi : Volition.

Présentation : Volition

Actuellement, Starknet fonctionne en mode Rollup de Validité, ce qui signifie que les données de Starknet et l'engagement envers l'état sont envoyés pour être soumis sur Ethereum. Avec Volition, les données pourraient être stockées sur le L2 de Starknet, permettant aux développeurs d'optimiser leurs contrats en choisissant leur mode de disponibilité des données au niveau de la variable de stockage individuelle.

Volition - comme son nom l'indique - fournira la possibilité de choisir la disponibilité des données d'une application ou d'une transaction. Les développeurs de Starknet pourront être flexibles dans tout le spectre de la disponibilité des données, en choisissant dynamiquement leur solution de disponibilité des données, et en déterminant si les données de leur application seront disponibles sur Ethereum L1 ou sur Starknet L2. Ils seront libres de transmettre ce choix aux utilisateurs de leur application.

Volition est rendu possible en mettant en œuvre l'état de Starknet comme deux arbres d'engagement de stockage distincts : un pour le mode de disponibilité des données L1 et un pour le mode de disponibilité des données L2. Alors que les données de l'arbre du mode de disponibilité des données L1 seront publiées sur Ethereum Mainnet, la disponibilité des données L2 signifie que les données des transactions seront mises à jour sur le L2 et communiquées au réseau Starknet. Seul l'engagement pour les données (c'est-à-dire la « racine » de l'arbre d'engagement) sera envoyé à L1.

Faites-en Votre Choix

La sécurité de la couche où les données sont publiées détermine le niveau de certitude de la disponibilité des données. Les données publiées sur le L1 bénéficieront du niveau de sécurité fourni par Ethereum et seront aussi disponibles que toute autre donnée sur Ethereum. D'autre part, les données publiées sur le L2 bénéficieront de coûts réduits et seront communiquées à tous les nœuds Starknet L2. Cela assure une minimisation des risques de défaillances ou d'actions malveillantes qui pourraient empêcher les retraits ou refuser l'accès aux données stockées sur le L2.

Bien que ces mesures soient nécessaires pour assurer un niveau élevé de sécurité pour la disponibilité des données L2, nous reconnaissons que pour une sécurité maximale, la disponibilité des données L1 (DA) devrait être privilégiée, accordant une sécurité de niveau Ethereum. La disponibilité des données L2 devrait être utilisée dans les cas où les développeurs et les utilisateurs considèrent les compromis entre les coûts L2 et la sécurité L1. Nous recommandons également aux développeurs de rédiger des contrats qui utilisent L2DA, de manière à permettre au contrat de fonctionner (tout en perdant les actifs L2DA, par exemple) en cas de crise de disponibilité des données L2. En introduisant Volition, nous reconnaissons que le raffinement des innovations prend du temps. Par conséquent, Volition sera disponible sur le testnet pendant une période prolongée. Durant cette phase, nous utiliserons activement les retours de notre communauté pour l'adapter aux besoins de nos créateurs.

L'introduction de Volition sur Starknet améliorera l'efficacité et l'expérience des développeurs (DevEx). La capacité de choisir de manière indépendante comment optimiser l'équilibre entre la sécurité et les coûts permettra aux applications de la couche 2 d'ajuster leur conception aux besoins des utilisateurs, et d'atteindre un public plus large.

Cas d'Utilisation et Applications de Volition

Pour illustrer au mieux l'efficacité de Volition, examinons quelques exemples concrets.

Imaginez que vous participez à un jeu Web 3 de grande envergure sur une application construite sur Starknet. Vous faites une offre réussie et achetez un NFT principal d'une arbalète. Étant donné l'importance de cette transaction, vous pouvez choisir le mode de disponibilité des données on-chain. Cela garantira que la propriété de l'arbalète est enregistrée de manière sécurisée sur la blockchain Ethereum, bénéficiant de sa large décentralisation. Par la suite, vous décidez d'acheter 150 NFT de flèches. Comme cet achat est de moindre valeur, vous pouvez opter pour la disponibilité des données L2 pour compléter la transaction, vous permettant ainsi d'économiser sur les coûts.

Le même concept s'applique au trading décentralisé à haute valeur, où les principales priorités des DEX sont la sécurisation des fonds et la minimisation des frais de transaction. Les utilisateurs peuvent garder certains fonds dans leur compte de disponibilité de données L2 pour optimiser les opérations de trading. L'utilisation des fonds stockés dans le stockage de données L2 permet aux traders d'exécuter un grand volume de transactions avec des frais réduits. Lorsque les fonds dans le compte de disponibilité de données L2 atteignent un montant élevé, le DEX privilégiera la sécurité sur les coûts en transférant les fonds vers un compte de disponibilité de données L1. Ce transfert garantit que la majeure partie des fonds est disponible en toute sécurité sur le L1.

Comme on peut le voir dans les deux exemples, Volition permet aux développeurs et aux utilisateurs de choisir le mode de disponibilité des données pour chaque contrat, ce qui permet un contrôle accru et améliore l'expérience de trading de l'utilisateur.

Quand sera lancé Volition ?

Volition sera introduit sur le Testnet de Starknet au quatrième trimestre 2023. Il restera en testnet pendant une période prolongée, nous permettant de comprendre et d'améliorer divers aspects de la sécurité en fonction des commentaires et de l'expérience de la communauté. On s'attend à ce que Volition permette de réduire les coûts pour de nombreux utilisateurs et constructeurs de dApp. À l'avenir, Starknet définira des modes de disponibilité de données supplémentaires, tels qu'Adamantium (un mode de disponibilité de données qui utilise un comité pour les utilisateurs qui préfèrent une partie de confiance pour la disponibilité de leurs données).

Résumé

Volition de Starknet s'attaque à la fois aux préoccupations en matière de sécurité et aux coûts élevés des données on-chain. En permettant le stockage des données sur le L2 de Starknet, les développeurs ont la possibilité de réduire les coûts et d'augmenter la scalabilité, tout en maintenant la sécurité d'Ethereum. L'avantage d'utiliser Volition sur Starknet est vaste, ouvrant potentiellement les portes à un développement d'applications innovantes. Si vous êtes curieux à propos de Volition, plongez-vous dans une discussion approfondie sur notre forum communautaire.

Fini les clés complexes, place à Face ID. Une étude de cas sur l'abstraction de compte

Au moment où les gens pourront utiliser des méthodes familières comme la reconnaissance faciale (Face ID) pour signer des transactions crypto, nous assisterons à un essor de la garde autonome. Tout le monde sait que gérer son propre portefeuille est l'idéal original en crypto, mais cela peut être intimidant et pousse les gens à préférer les plateformes d’exchange centralisées.

Ceci est une étude de cas sur la façon dont une fonctionnalité de Starknet appelée Abstraction de Compte est utilisée par Braavos pour obtenir une manière beaucoup plus intuitive d'utiliser votre portefeuille.

Introduction à l'Abstraction de Compte

Après le scandale de FTX, la question est plus pertinente que jamais. Pourquoi les gens choisissent-ils encore de confier leurs crypto à des institutions centralisées plutôt que de les garder eux-mêmes ? La réponse : pour la plupart des gens, la garde autonome est compliquée. Les phrases de récupération sont le mécanisme de récupération "meilleur-pire", décourageant de nombreuses personnes (même parmi les plus endurcis).

La réponse à ce défi : l'Abstraction de Compte. L'Abstraction de Compte permet aux portefeuilles de répondre (et de dépasser) les attentes en matière d'expérience utilisateur (UX) des utilisateurs Web2 avec des fonctionnalités telles que la signature d'une transaction avec la reconnaissance faciale ou l'utilisation de l'authentification à deux facteurs. Elle facilite également la segmentation des comptes et les limites de dépense ; et permet éventuellement une récupération de compte simple et l'élimination complète de la phrase de récupération. C'est une révolution pour l'UI et l'UX.

Starknet

Starknet, le principal Validity Rollup, présente plusieurs caractéristiques clés qui en font la solution la plus prometteuse pour mettre à l'échelle Ethereum. Basé sur les preuves STARKs, offrant des frais de gaz réduits sans compromettre la sécurité d'Ethereum. Le bilan des preuves STARKs alimentant StarkEx comprend 800 milliards de dollars de volume d'échanges cumulés, 300 millions de transactions et 90 millions NFT.

Les capacités des preuves STARK à fournir des frais réduits, associées à la puissance de l'Abstraction de Compte, ont permis à Braavos de développer les fonctionnalités innovantes de portefeuille que nous visons.

Contexte

La plupart des principales blockchains, dont Bitcoin et Ethereum, utilisent les schémas de signature cryptographique de courbe elliptique secp256k1 (voir ici pour une liste complète). Cette implémentation de courbe elliptique est considérée comme robuste, de nombreuses blockchains l'utilisent et elle a fait ses preuves. Mais elle n'est pas compatible avec le schéma de signature cryptographique disponible dans les modules de sécurité matérielle (HSM) des appareils mobiles, tels que les iPhones et les téléphones Android (Pixel et autres).

Ces appareils utilisent une autre courbe - secp256r1 (également appelée NIST-P256). Cela signifie que les utilisateurs de ces blockchains ne peuvent pas profiter des puces de sécurité de leurs appareils et doivent recourir aux portefeuilles matériels s'ils veulent obtenir un haut niveau de sécurité. Cela limite considérablement toute innovation en matière d'expérience utilisateur sur la manière dont les utilisateurs peuvent se connecter à un portefeuille et approuver les transactions (d'où l'omniprésence des phrases de récupération).

Starknet ne prend pas en charge secp256r1, et a sa propre courbe propriétaire qui est adaptée aux STARKs. Mais contrairement à d'autres blockchains, Starknet dispose nativement de l’abstraction de compte sur sa plateforme, ouvrant un nouveau monde d'opportunités en termes d’UX pour les applications de portefeuille. Braavos a exploité ce potentiel pour introduire le Signataire Matériel (Hardware Signer).

Le Signataire Matériel

Le Signataire Matériel se compose de deux parties principales :

• Le sous-système sécurisé dans le dispositif mobile des utilisateurs

• Le contrat intelligent de compte capable d'exécuter une logique arbitraire (également appelée Abstraction de Compte)

Sous-système sécurisé

Le signataire matériel utilise le sous-système sécurisé intégré à l’appareil de l’utilisateur, nommé Secure Enclave de l’iPhone ou Titan HSM du téléphone Android pour protéger le compte.

La puce Secure Enclave / Titan sont un sous-système dédié et isolé, totalement séparé du processeur d'application, pouvant générer des clés privées et signer des messages. Elle génère les clés en utilisant un Générateur de Nombres Aléatoires Véritables (TRNG) interne et signe les messages sur la courbe elliptique NIST-P256 (secp256r1) via son Accélérateur de Clé Publique (PKA) interne. Les clés privées ne quittent jamais le système sécurisé et sont inconnues/inaccessibles pour quiconque, même pas pour l'utilisateur ni pour l'application elle-même.

Cela signifie que même si le noyau du processeur d'application de l'appareil est compromis, les clés de l'utilisateur restent en sécurité !

Plongée plus profonde dans la Secure Enclave

Pendant le processus de fabrication de la puce, un Identifiant Unique (UID) est généré par le TRNG et est stocké dans le PKA. Il ne peut pas être lu et ne quitte jamais le PKA, il est donc même inconnu pour le processeur de la Secure Enclave et pour le Système d'Exploitation du Processeur de la Secure Enclave (SepOS).

Cet UID est un nombre aléatoire unique pour chaque appareil et est utilisé pour chiffrer toutes les autres clés qui seront générées à l'avenir sur cet appareil. La manière dont cela fonctionne est la suivante : l'application demandera au SepOS de générer une nouvelle paire de clés, le SepOS instruira le TRNG de la Secure Enclave pour générer une clé et la chiffrer (en utilisant l'UID). L'application peut ensuite demander au SepOS de déchiffrer la clé et de signer un message à l'aide de la clé générée. Pendant tout ce processus, la clé générée ne quitte pas l'enclave et reste inconnue de tous.

(Pour plus d'informations sur la Secure Enclave, veuillez voir ici).

La manière dont la Secure Enclave est construite et fonctionne, ainsi que le fait qu'elle soit la cible d'attaques de puissantes sociétés et gouvernements du monde entier, explique pourquoi sa sécurité dépasse celle des portefeuilles matériels standard.

Abstraction de Compte

La puissance de Braavos en tant que portefeuille basé sur des contrats intelligents sur Starknet réside dans le fait qu'il est composé de deux piliers :

• Le côté client (par exemple, l'application) permettant à l'utilisateur de passer en revue/signer des transactions et de les envoyer à la chaîne.

• Le côté on-chain disposant d'un contrat intelligent de compte pouvant exécuter une logique arbitraire ; et en particulier dans notre cas, exécuter une logique arbitraire de vérification d’une signature.

L'application signe la transaction en utilisant le module de sécurité de l'appareil mobile, puis l'envoie au contrat de compte on-chain qui peut la vérifier.

Comme mentionné ci-dessus, le module de sécurité sur les iPhones et les téléphones Android utilise une cryptographie appelée NIST-P256 (secp256r1), qui n'est pas compatible avec un quelconque schéma cryptographique majeur de blockchain, y compris Starknet. C'est pourquoi avoir un contrat de compte intelligent on-chain par lequel passent toutes les transactions et qui peut exécuter une logique arbitraire est crucial pour utiliser ces HSM sur les iPhones et les téléphones Android.

Biométrie

Comment l'utilisateur approuve-t-il une transaction via le portefeuille Braavos ? Une application malveillante peut-elle simplement signer automatiquement une transaction sans le consentement de l'utilisateur ?

Non !!

La chose intéressante dans le module de sécurité intégré aux appareils mobiles, comme la Secure Enclave, est qu'il prend en charge intrinsèquement l'authentification biométrique de l'identité de l'utilisateur. Cela signifie que même l'approbation réelle pour signer une transaction est effectuée directement via la Secure Enclave. L'approbation ne passe pas par l'application, et l'utilisateur devra approuver la transaction avec son empreinte digitale ou son identification faciale.

Récupération

Si personne ne connaît la clé privée, que se passe-t-il si l'appareil est perdu ou devient inutilisable ? Comment l'utilisateur peut-il reprendre le contrôle du compte ?

Dans Braavos, un compte aura en réalité 2 clés publiques : la clé Hardware Signer, qui sera utilisée pour signer toutes les transactions, et la clé dérivée de la phrase de récupération qui ne peut signer qu'une transaction, une "Demande de suppression du Hardware Signer". Cette demande ne sera pas exécutée immédiatement, mais elle aura un délai de 4 jours (configurable) pour permettre à l'utilisateur d'utiliser le Hardware Signer pour annuler une telle demande. Cela signifie que si l'appareil est volé, perdu ou inutilisable, les utilisateurs pourront toujours récupérer leur compte dans les 4 jours. Cependant, si leur Phrase de Récupération est volée et qu'un attaquant émet une demande de suppression du Hardware Signer, l'utilisateur recevra automatiquement (et à plusieurs reprises) une notification sur son appareil mobile et pourra annuler la demande et conserver tous les actifs en sécurité.

Résumé

La fonctionnalité Hardware Signer offre à la fois un niveau de sécurité de pointe pour les utilisateurs de crypto, et l'expérience à laquelle les utilisateurs sont habitués avec le web2. En ce sens, signer une transaction est aussi fluide et sans souci que de payer avec Apple/Google Pay.

Ceci n'est qu'un exemple, bien que marquant, du pouvoir de Starknet, du portefeuille basé sur des contrats intelligents (alias Account Abstraction) et du nouvel espace de conception qu'il permet.

Nous prévoyons le développement de capacités de plus en plus naissant conduisant l'industrie de la crypto vers un avenir meilleur et plus inclusif, offrant aux nouveaux et aux anciens utilisateurs une sécurité inégalée couplée à une expérience utilisateur inégalée.

UX fluide, technologie innovante, adoption accrue

TLDR

• Le voyage de la blockchain vers le grand public a rencontré un obstacle : les limites de sécurité et d'UX ont créé une barrière pour présenter la blockchain à un public plus large d'utilisateurs Web 2.

• La solution ? L'Abstraction de Compte (Account Abstraction - AA). Il s'agit de la couche logicielle qui révolutionne le paysage de la blockchain en permettant aux comptes d'avoir un design flexible et un comportement déterministe ajustable.

• L'AA est disponible sur Ethereum et Starknet, mais implémenté différemment. Starknet dispose d’une implementation AA native, ce qui signifie que tous les comptes sont des comptes intelligents. Ethereum dispose de l'ERC-4337, qui ajoute l'AA sans omettre l'héritage des EOAs. Les avantages de l'AA seront considérablement réduits dans tout environnement où les EOAs continuent de prospérer, ne serait-ce que parce que les applications devront continuer à s'adapter aux propriétés des EOAs.

Le Mur des EOAs

Externally Owned Account (EOA) est la solution simple d'Ethereum pour créer une représentation utilisateur on-chain permettant aux utilisateurs d'interagir avec la blockchain et de posséder des actifs en les liant aux actifs du compte.

Bien que plus simples, le comportement des EOAs est prédéterminé par le protocole sur lequel ils sont déployés et manque donc de flexibilité pour les adapter aux différents besoins des utilisateurs. Cela conduit souvent à une mauvaise UX et crée une barrière à une adoption massive. Le plus gros problème est déterminé dans le protocole : les EOAs sont contrôlés par une paire de clés privées et publiques. Les trois principaux problèmes liés à l'utilisation d'une paire de clés pour initier des transactions sont :

1. Mauvaise UX - l'exigence de garder la clé privée dans un endroit sûr et discret n'est pas intuitive pour le détenteur de la clé qui est habitué à utiliser des méthodes plus intelligentes et modernes comme un mot de passe à 6 chiffres ou l'identification faciale, rendant les transactions plus difficiles à initier.

2. Rien qu'une clé - La connaissance des détails de la clé privée n'est pas seulement le seul moyen d'initier des transactions, mais aussi le seul moyen par lequel le protocole identifie le propriétaire du compte. Cela crée un risque de sécurité, si votre clé est compromise, vous êtes indiscernable de l'entité qui l'a volée.

3. Le protocole est le maître - Il ressort clairement des exemples ci-dessus que dans le domaine des EOAs, c'est le protocole Ethereum, et non le développeur, qui détermine quelle transaction est considérée comme valide.

Les complications causées par la détermination du comportement du compte dans le cadre du protocole de la chaîne se retrouvent dans la plupart des chaînes.

Briser le Mur : Introduire l'Abstraction de Compte

Le problème causé par le protocole, qui détermine le comportement des comptes plutôt que l'utilisateur, se retrouve dans la plupart des chaînes. Dès 2015, le cofondateur d'Ethereum, Vitalik Buterin, a évoqué ces défis. Il décrit l'Abstraction de Compte (AA) comme la solution qui représente un moyen plus simple de gérer les comptes, réduisant, voire mettant fin à la dépendance aux clés privées. De plus, l'AA crée un ensemble d'autres avantages qui rendront l'expérience utilisateur Web3 indiscernable du Web2 et faciliteront la voie vers une adoption massive.

Au fil des années, deux approches importantes de l'AA ont émergé, et elles ont toutes deux le même objectif de permettre aux développeurs d'applications de concevoir leurs applications et de créer un moyen plus simple de gérer les comptes.

ERC-4337

Comme mentionné précédemment, les EOAs font partie intégrante d'Ethereum, et leur comportement est défini par le protocole Ethereum. En plus des EOAs, Ethereum possède également des contrats, qui peuvent contenir du code défini par l'utilisateur. En 2023, Ethereum a introduit une mise au niveau du protocole - l’ERC-4337 - afin de combler l'écart structurel entre les EOAs et les contrats, sans introduire de changements majeurs dans le protocole. L'idée principale de l'ERC-4337 est d'introduire un nouveau rôle : le Bundler. Le rôle du Bundler est de collecter les opérations des utilisateurs (pensez à elles comme des métatransactions qui sont collectées dans une mempool spécialisé) et de les envoyer à Ethereum à partir de leurs propres EOAs (contrôlés par le Bundler). De cette manière, le Bundler permet aux développeurs et aux utilisateurs de déployer et d'interagir avec des contrats de compte et de bénéficier des avantages de l'AA.

Introduire l'AA dans Ethereum avec l'ERC-4337 permet aux développeurs de créer un comportement plus flexible pour les contrats. Cependant, Ethereum continue de maintenir les EOAs. Pour les développeurs, la conséquence est de devoir servir à la fois les EOAs et l'ERC-4337. Dans un écosystème où les EOAs sont moins chers, il est probable de supposer que les EOAs resteront dominants, et les applications ne pourront pas récolter la vraie valeur de l'AA dans l'ensemble de leur base d'utilisateurs.

Les chaînes EVM qui suivent ou émulent Ethereum, y compris les zkEVM, connaîtront une évolution similaire : les EOAs resteront la forme dominante de comptes, annulant les avantages de l'AA et perdant l'avantage de ne pas avoir à contourner l'héritage des EOAs.

L'Abstraction de Compte Native de Starknet

Cependant, Starknet a l'AA au cœur de son système : tous les comptes sont des comptes intelligents et il n'y a pas d'EOAs. Cette décision constitue un pas en avant vers un monde où chaque compte est intelligent. Toute l'infrastructure, y compris les portefeuilles et les explorateurs de blocs, est conçue et construite pour l'AA. Ceci est unique parmi les chaînes L1 et L2, faisant de Starknet le premier écosystème intelligent : les constructeurs peuvent construire leurs applications et outils en sachant que l'AA s'applique à tous les comptes, et économiser le besoin de travailler et de servir des comptes non-AA. Les constructeurs peuvent concevoir leur application pour bénéficier de toute l'étendue des opportunités offertes par l'AA, sachant que les comptes intelligents sont le seul moyen pour les utilisateurs d'interagir avec l'application.

L'AA native sur Starknet élimine les complexités supplémentaires associées à l'introduction d'un Bundler, comme cela a été fait avec l'ERC-4337. Il n'y a pas besoin d'adapter l'infrastructure et les outils pour interagir avec elle. Cette simplification est obtenue en désignant le Séquenceur pour remplir le rôle du Bundler.

Les Trois Piliers de l'Abstraction de Compte

Il y a trois composantes principales de l'AA. Chaque composant sert un but unique pour améliorer l'expérience utilisateur globale :

• Abstraction de Signature : conçoit le flux des transactions. Le pouvoir de définir une transaction valide est entre les mains de l'architecte - le concepteur du compte, que ce soit le développeur ou l'utilisateur. Le principal avantage ici est la liberté de personnaliser les permissions du compte, ainsi que l'utilisation potentielle des smartphones pour contrôler les comptes.

• Abstraction des Frais : permet d'utiliser différents jetons comme paiement pour les frais de transaction, sans être restreint au jeton natif du réseau. Par exemple, un utilisateur pourrait utiliser l'USDC pour payer les frais de transaction, évitant ainsi de devoir d'abord convertir l'USDC en jeton natif, économisant ainsi sur les frais d'échange et de temps.

• Abstraction de Nonce : assure le confort pour l'utilisateur. Les solutions de nonce séquentielles traditionnelles présentent plusieurs inconvénients en termes d'UX. Empêchant par exemples les utilisateurs d'envoyer simultanément plusieurs transactions indépendantes en raison de son application d'un ordre complet. L'Abstraction de Nonce offre la flexibilité requise en permettant la personnalisation du mécanisme de protection contre la relecture du compte.

Les Rollups, tels que Starknet, peuvent être considérés comme des systèmes d'exploitation blockchain. Lors de la conception d'un nouveau système d'exploitation, les choses fonctionnent mieux sans hériter des défis des systèmes d'exploitation précédents. C'est l'équivalent de construire une nouvelle maison plutôt que de rénover une ancienne. Lors de la conception d'une nouvelle maison, les infrastructures critiques telles que le câblage électrique, la plomberie et le système de chauffage, doivent être incorporées dès l'étape du plan. Il est peu logique de construire une nouvelle maison avec de simples ajustements et des solutions contournées pour ce qui est déjà connu comme étant la norme requise dans le futur.

Le même principe s'applique à l'AA. La conception de Starknet a été faite en regardant vers l'avenir, vers ce que nous croyons devenir le moyen standard de construire des applications. Avec l'AA comme option par défaut, et en fait, la seule option, Starknet offre l'expérience fluide, efficace et conviviale que nous aimerions avoir à l'avenir.

En regardant les fonctionnalités activées par la mise en œuvre de l'AA, il est clair que l'avantage est double - le premier pour les utilisateurs, car ils bénéficient d'une meilleure UX, et l'autre pour les développeurs, car ils n'ont pas besoin d'être encombrés par l'héritage des EOAs.

En Construction - Mises en Œuvre de l'Abstraction de Compte sur Starknet

L'écosystème intelligent de Starknet offre déjà un terrain fertile pour la croissance, un peu comme l'introduction du logiciel a révolutionné l'économie monétaire. Au départ, le logiciel a numérisé les dossiers et rationalisé les processus, et il a depuis évolué en un ensemble plus large de systèmes qui gèrent les transactions, suivent les finances et automatisent les processus financiers. De même, l'écosystème intelligent de Starknet donne aux développeurs la possibilité d'interagir de manière transparente avec diverses applications et fournisseurs. Cela améliore non seulement les expériences des utilisateurs, les rendant plus riches et plus dynamiques, mais promeut également un environnement collaboratif et innovant, favorisant un terrain toujours fertile pour le développement.

Cela ressort clairement des avancées passionnantes suivantes dans les applications réalisées à l’aide de l’abstraction de signature sur les comptes intelligents natifs de Starknet :

Braavos

En utilisant le compte intelligent natif de Starknet, l'équipe de Braavos a créé un portefeuille intelligent qui permet une expérience de type Web-2. Vous permettant d'utiliser la fonction d'identité biométrique de votre téléphone mobile pour accéder à votre portefeuille. Cela est excitant car les différences entre la cryptographie utilisée dans la plupart des blockchains et celle des téléphones mobiles entraînent généralement une vérification de signature extrêmement coûteuse, et pourraient à l'avenir permettre de valider des transactions en utilisant des téléphones mobiles, tout en maintenant un haut niveau de sécurité.

Argent

Une autre innovation apportée par l'utilisation de l'abstraction de signature est le service de gardien d'Argent X, Argent-Shield. Ce service permet aux utilisateurs d'ajouter une couche de protection supplémentaire à leur compte en ayant Argent comme gardien, qui n'approuvera vos transactions que si elles ont été confirmées par mail. Il s'agit d'un autre mécanisme d'authentification à deux facteurs dont la plupart d'entre nous sont familiers grâce à de nombreuses applications non liées à la blockchain.

Visa

Les preuves STARK ont été inventées pour relever le défi de la scalabilité d'Ethereum, dans le but d'atteindre la même capacité en transactions par seconde (TPS) que Visa. Pour cette raison, la décision de Visa de mener son exploration très discutée des “ paiements automatiques pour portefeuilles self custody” sur Starknet représente une étape importante. Elle démontre leur reconnaissance de notre technologie de pointe et de notre écosystème intelligent innovant.

Conclusion

L'écosystème Starknet grandit chaque jour, avec de plus en plus de créateurs qui utilisent l'AA natif de Starknet pour concevoir leurs applications de la manière la plus flexible possible. Les opportunités d'intégration avec d'autres fournisseurs et la capacité d'offrir aux utilisateurs des expériences plus sophistiquées et personnalisées reflètent le potentiel illimité d'une économie numérique.

Les développeurs ne sont pas tenus de trouver des solutions pour les pratiques passées. Au lieu de cela, ils peuvent construire leur application dans un environnement conçu pour leurs besoins futurs, construit à partir de zéro.

StarkWare rend Open Source le prouveur STARK, désormais nommé Stone, sous licence Apache 2.0.

Une session de revue de code aura lieu le 31 août lors de Starknet Summit. À cette date, le code du prouveur Stone sera disponible pour la communauté.

TL;DR

• Comme annoncé en février 2023, nous sommes sur le point de rendre open source le prouveur STARK de StarkWare, à présent appelé Stone (STARK one), sous licence Apache 2.0.

• La mise en open source du prouveur est une étape majeure vers la décentralisation de Starknet. Cela favorisera la collaboration et l'innovation, permettant aux développeurs d'observer, d'optimiser et d'utiliser le code du prouveur, de préférence pour le bien de Starknet.

• Cette étape s'inscrit dans la continuité des précédentes initiatives de mise en open source de la licence de la stack Starknet. Avec une communauté de développeurs en forte croissance, Starknet dispose de la stack Rollup la plus décentralisée. Comprenant plusieurs composants d'infrastructure clés, tels que Cairo, plusieurs implémentations de nœuds complets, le nouveau Séquenceur de Starknet et d'autres fonctionnalités open source développées par des équipes indépendantes.

• Le prouveur Stone est un moteur puissant, et les équipes sont encouragées à ajouter des personnalisations autour de celui-ci afin de construire le système de preuve dont elles ont besoin et qu'elles exigent.

Grande nouvelle :

Nous sommes enthousiastes ! Comme annoncé plus tôt cette année et prévu dès les premières étapes de Starknet, nous rendons open source le code du prouveur STARK, désormais appelé Stone. La base de code du prouveur sera disponible sous la licence Apache 2.0. Une session d'introduction au code aura lieu lors de Starknet Summit le 31 août, date à laquelle le code sera disponible.

Il s'agit d'une étape majeure vers la décentralisation de la technologie de StarkWare, permettant à la communauté de construire et de contribuer au développement du prouveur de manière indépendante.

Pour les développeurs, cela signifie que le moteur, testé au combat, est au centre des réalisations de StarkWare, et disponible pour que tous puissent l'utiliser pour prouver des programmes Cairo. Nous vous fournissons un puissant prouveur STARK, et vous pouvez l'utiliser pour contribuer au développement de l'écosystème Starknet.

Mise en Open Source du Prouveur STARK - Stone

Le Prouveur STARK est un composant vital au sein de la stack de Starknet. Il est responsable de la compression des transactions et de la génération de preuves cryptographiques, jouant un rôle clé dans l'évolutivité d'Ethereum.

Ce Prouveur est en production depuis juin 2020, jouant un rôle crucial dans la validation des transactions provenant d'applications décentralisées alimentées par StarkEx (comme Immutable X, Sorare, dYdX, et d'autres) et Starknet. Le code a été continuellement optimisé, et nous partageons sa version mise à jour la plus récente (qui a été publiée en mars 2023).

Depuis son lancement, les solutions de scalabilité basées sur la technologie STARK construites avec ce Prouveur à leur base (y compris StarkEx et Starknet) ont compressé et validé 1 000 milliards de dollars de volume de transactions cumulées, 500 millions de transactions et plus de 100 millions de créations de NFT. Bien sûr, des innovations et des optimisations supplémentaires sont possibles, que ce soit par StarkWare ou par les développeurs qui choisiront de prendre le code et de l'utiliser pour leurs propres initiatives.

Un Prouveur open source permet à davantage de regards d'examiner le code et d'offrir des optimisations, d'améliorer sa qualité, de détecter les bugs et de fournir de la transparence.

Actuellement, StarkWare a déjà open source Cairo, le noeud complet Papyrus et toutes les versions de Starknet. Le nouveau Séquenceur Starknet en cours de développement sera également open source. Ces projets sont rejoints par plusieurs projets open source dans l'écosystème Starknet.

Qu'est-ce qui est Open Source et comment les développeurs peuvent-ils l'utiliser ?

Le code open source comprend le Prouveur STARK - Stone en C++ (sous licence Apache 2.0). De plus, un Verifier STARK en C++ sera aussi disponible.

Le Prouveur Stone open source permettra des initiatives innovantes qui pourront l'utiliser comme moteur de validation sous-jacent de leurs systèmes de validation. Les développeurs pourront l'utiliser comme suit :

1. Écrire un programme Cairo0.

2. Utiliser les outils Cairo pour prendre le programme Cairo0 et le compiler en CASM.

3. Exécuter le code CASM avec cairo_run et recevoir une trace Cairo pour cette exécution.

4. Utiliser le Prouveur STARK - Stone pour prouver la trace Cairo.

5. Recevoir une Preuve STARK.

6. Utiliser le Vérifier C++ pour s'assurer que la preuve est valide.

Le Prouveur Stone est adapté pour la validation des programmes Cairo. Des personnalisations supplémentaires peuvent être construites au-dessus de lui afin de l'utiliser pour différents systèmes et besoins de validation. Les développeurs peuvent prendre ce moteur testé au combat et construire leur propre service de validation sur mesure. Par exemple, StarkWare a construit le système SHARP avec ce Prouveur comme base.

Résumé

Avec la publication du code source du Prouveur Stone sous la licence Apache 2.0, StarkWare marque un moment crucial dans le développement et la mise à disposition d'outils ouverts pour la mise à l'échelle sécurisée d'Ethereum. StarkWare estime que la mise en open source de la stack Starknet signifie davantage de collaboration, une meilleure qualité, une sécurité améliorée, de l'innovation et de l'indépendance. Toutes ces valeurs peuvent aider Starknet et Ethereum à atteindre leur plein potentiel.

À l'avenir, tout ce dont les développeurs ont besoin pour exploiter et exécuter la stack Starknet est prévu d'être en open source, comme il convient à un réseau de couche 2 décentralisé et sans permission.

Note : Des développements ont eu lieu dans l’espace depuis la publication de cet article. Pour toutes les mises à jour, rendez-vous sur 'Abstraction de Compte Natif : Ouvrir la Blockchain à de Nouvelles Possibilités'.

L'innovation technologique dans la blockchain a prospéré au cours des dernières années : les STARKs, les SNARKs, l'EIP-1559, The Merge d'Ethereum, sont toutes des prouesses technologiques majeures. Cependant, la conception de l'expérience utilisateur (UX) et de l'interface utilisateur (UI) a du mal à suivre le rythme. Les personnes restent encore bloquées avec des phrases de récupération de 16 mots, et entrer dans la finance décentralisée (DeFi) sans intermédiaire centralisé est encore trop intimidant pour beaucoup. Pour accueillir le prochain milliard d'utilisateurs dans le Web3, il est essentiel d'améliorer l'expérience d'intégration des utilisateurs.

Comme l'a démontré FTX (et Gemini, Celsius et Mt. Gox), conserver la garde autonome de ses actifs est d'une importance cruciale. Cependant, jusqu'à récemment, les portefeuilles self-custody étaient maladroits et déroutants pour l'utilisateur moyen. La plupart des gens oublient leurs mots de passe Web2 mensuellement, comment s'attendre à ce que les utilisateurs gardent leur phrase de récupération et leurs clés privées en sécurité pour l'éternité ?

En un mot, c'est un cauchemar en matière de sécurité. Comme nous l'avons vu maintes fois, une erreur, qu'elle soit initiée par des acteurs malveillants ou par négligence, peut entraîner la perte de millions de dollars.

En tant que premier point de contact pour les nouveaux utilisateurs de crypto, les portefeuilles Ethereum doivent être faciles à utiliser, sécurisés et personnalisables pour répondre aux besoins de chaque utilisateur. Cela nécessite que les développeurs intègrent la simplicité des produits financiers Web2 avec les fonctionnalités de Web3.

C'est précisément ce que réalise l'abstraction de compte.

L'abstraction de compte améliore la sécurité des produits des portefeuilles self-custody en supprimant la dépendance des utilisateurs à l'égard de la clé privée et en rendant les portefeuilles plus programmables. Avec cette UX améliorée, les portefeuilles non-custody peuvent enfin évoluer pour atteindre des millions d'utilisateurs mainstream.

Mais pour comprendre pleinement l'impact de l'abstraction de compte, nous devons nous rappeler comment fonctionnent les comptes Ethereum.

Les Bases des Comptes Ethereum

Il existe deux types de comptes Ethereum :

1. Externally Owned Accounts - EOA

2. Contract Accounts - CA

Examinons chacun d'entre eux de plus près.

Externally Owned Accounts

Les EOA, comme MetaMask et Coinbase Wallet, sont le type de compte typique pour les utilisateurs d'Ethereum. Chaque EOA se compose d'une clé privée et d'une clé publique, appelées paire de clés.

Toutes les transactions sont autorisées et signées par des clés privées. Une fois qu'une transaction est signée, l'EVM vérifie que la signature est valide en utilisant l'adresse du compte EOA. La logique codée dans l'EVM signifie que le compte (l'objet contenant vos jetons) et la clé privée (le signataire) sont liés en tant qu'entité unique.

Perdre votre clé privée signifie perdre vos fonds, voire le contrôle de votre compte, de façon permanente.

Contract Accounts

Pendant ce temps, les contract accounts, synonymes d'abstraction de compte, sont des contrats intelligents déployés sur la blockchain Ethereum. Ces contrats sont contrôlés par une logique de code et ne nécessitent pas de clés privées. Contrairement aux EOA, les contract accounts ne peuvent pas initier de transactions. Au lieu de cela, leurs transactions sont déclenchées par des instructions provenant des EOA.

L'Importance de l'Abstraction de Compte

L'abstraction de compte consiste à dissocier la logique d'autorisation codée des EOA, transformant chaque compte en un contrat intelligent programmable pouvant être adapté aux besoins de chaque individu.

Comme l'explique Julien Niset, cofondateur et directeur scientifique d'Argent, lors d'un récent événement Stark @ Home, cette logique d'autorisation flexible donne aux développeurs la liberté d'expérimenter des fonctionnalités de compte telles que...

• Matériel de Signature : Utiliser l'enclave sécurisée d'un iPhone ou d'un Android pour transformer n'importe quel smartphone en portefeuille matériel. À partir de là, les utilisateurs peuvent vérifier les transactions en utilisant des données biométriques telles qu'une empreinte digitale ou Apple Face ID. Nous avons déjà commencé à voir des portefeuilles self-custody comme Braavos déployer cette fonctionnalité.

• Paymasters : Permettre aux utilisateurs de payer les frais de gaz avec n'importe quel token, voire de faire en sorte qu'un mécanisme conçu par un tiers paye les transactions.

• Social Recovery : En cas de perte ou d'une clé privée compromis, les utilisateurs peuvent autoriser une nouvelle clé en tant que propriétaire légitime du portefeuille. Cela peut inclure une variété de méthodes de récupération via des contacts de confiance, des portefeuilles matériels ou des services tiers. L'idée est de rendre la récupération de l'accès à votre compte aussi facile que la récupération du mot de passe de votre compte bancaire via un e-mail.

• Authentification Multifacteur : Similaire aux pratiques courantes de Web2 en matière d'authentification à deux facteurs (2FA), les utilisateurs peuvent configurer deux (ou plus) méthodes d'authentification pour leurs portefeuilles crypto. Où une transaction est signée uniquement une fois qu'un utilisateur confirme l'approbation via une deuxième option telle que l'e-mail ou le SMS. Les utilisateurs peuvent également configurer des limites de transfert quotidiennes ou des listes d'adresses de compte avec lesquelles le portefeuille est automatiquement bloqué pour interagir.

• Quantum Resistant et Économes en Gaz : Le schéma de signature actuel d'Ethereum, ECDSA, est exigeant en capacité de calcul (lire : frais de gas élevés) et peut être brisé par des ordinateurs quantiques. Grâce à l'abstraction de signature, différents contrats de compte utilisent des schémas de signature plus efficaces et sécurisés quantiquement. Starknet utilise sa propre courbe propriétaire compatible avec STARK.

Non seulement ces fonctionnalités offrent aux utilisateurs une plus grande sécurité et une plus grande flexibilité, mais surtout, elles résultent en une expérience utilisateur bien meilleure.

Énumérées par Vitalik Buterin comme un "rêve de longue date" pour la communauté de développeurs d'Ethereum, les innovations autour de l'abstraction de compte, principalement l’EIP-2938 et l’EIP-3074, tournent depuis 2020. Cependant, les deux ont nécessité des compromis en matière de sécurité et de mise en œuvre. L’EIP-4337, le développement le plus prometteur à ce jour, propose une version de l'abstraction de compte sans nécessiter de modifications du protocole Ethereum.

Abstraction de Compte et StarkNet

Contrairement à Bitcoin et Ethereum, qui adaptent leurs protocoles actuels pour prendre en charge l'abstraction de compte, StarkNet a mis en œuvre l'abstraction de compte dès le premier jour. Associé à la scalabilité et aux capacités de nos preuves STARK, le potentiel d'innovation en matière de portefeuilles est illimité. C'est pourquoi la prochaine génération de portefeuilles self-custody, tels qu'Argent et Braavos, est en train d'être construite sur notre réseau.

L'approche de StarkNet est similaire à celle de l'EIP-4337, reconnaissant que l'abstraction de compte complète entraînerait toujours une UX confuse pouvant ouvrir la porte à des attaques sur les séquenceurs. Au lieu de cela, l'objectif est de réaliser à la fois une abstraction de signature et une abstraction de paiement en mutualisant une partie de l'infrastructure requise on et off-chain.

Et même s'il reste encore beaucoup de travail à faire, l'abstraction de compte gagne en popularité au-delà d'un petit cercle de passionnés de la cryptographie. En décembre, Visa a proposé l'idée d'utiliser l'abstraction de compte pour configurer des paiements récurrents automatiques sur Starknet. En utilisant un compte pouvant être délégué, les utilisateurs peuvent accorder l'autorisation d'initier un paiement à un contrat intelligent pré-approuvé. À partir de là, le contrat intelligent sera programmé pour déduire un montant de paiement défini à une date spécifique, sur une durée de temps déterminée. Bien que Visa n'ait pas encore révélé ses plans pour ses propres services, l'intérêt seul en dit long et pourrait annoncer un monde où les plateformes d'abonnement des géants de la technologie comme Netflix et Spotify pourraient adopter la crypto-monnaie.

Quant à ce que l'avenir réserve, seul le temps le dira. Mais une chose est certaine. En rendant les portefeuilles plus faciles et plus sûrs à utiliser, l'abstraction de compte servira de puissant catalyseur permettant aux portefeuilles blockchain self-custody de se développer à des millions d'utilisateurs de cryptomonnaies grand public. En attendant, nous continuerons de construire.

Des réductions de coûts massives au contrôle personnalisé, Découvrez l'Avenir de l'Infrastructure Blockchain.

TL;DR

• Madara est un séquenceur à haute performance pour Starknet, offrant la capacité de créer des appchains personnalisables et productive.

• En utilisant le framework Substrate, Madara amplifie les capacités de la machine virtuelle Cairo, conduisant à des programmes vérifiables, sécurisés et flexibles.

• Son implémentation offre de nombreux avantages tels qu'une infrastructure scalable, un débit élevé et un contrôle inédit sur les applications.

• Les fonctionnalités uniques de Madara incluent le support de la confidentialité on-chain potentielle, l'interopérabilité simplifiée entre différentes chaînes et une exécution robuste.

• Madara ouvre la voie au développement d'applications décentralisées en offrant des solutions rentables, scalable et personnalisables dans le domaine de la blockchain.

Introduction

Imaginez avoir le pouvoir de créer une blockchain spécifiquement adaptée aux besoins uniques de votre application. C'est exactement ce que les appchains offrent. Les appchains sont des blockchains spécifiques à une application qui offrent aux développeurs la flexibilité de personnaliser certains aspects d’une chaîne afin de répondre aux besoins de leurs applications, telles que le choix d'une fonction de hachage différente ou la personnalisation de l'algorithme de consensus.

Le meilleur ? Les appchains héritent de la sécurité robuste de L1 ou L2 sur lesquelles elles sont construites, offrant aux développeurs le meilleur des deux mondes.

Laissez-moi vous présenter Madara, un séquenceur révolutionnaire qui allie flexibilité et performances fulgurantes. Les séquenceurs sont des entités chargées d'exécuter les transactions et de les regrouper en lots. Agissant comme une passerelle pour lancer votre propre appchain Starknet, Madara ouvre un monde de possibilités d'expérimentation dans l'écosystème Starknet comme jamais auparavant.

Avant d'explorer les capacités fascinantes de Madara permettant les appchains Starknet, il est important de répondre à la question de savoir pourquoi les développeurs choisiraient de construire des appchains sur Starknet plutôt que d'utiliser directement son Validity Rollup de Starknet.

On pourrait se demander si Starknet est déjà suffisant pour la plupart des scénarios.

Commençons par comprendre pourquoi les appchains sont une extension convaincante de l'écosystème Starknet.

Pourquoi les Appchains

Madara, développé par l’équipe exploration de StarkWare, également connue sous le nom de Keep Starknet Strange, est spécifiquement conçu pour concrétiser la vision du scaling fractale de StarkWare. Il existe de nombreuses raisons convaincantes pour lesquelles les développeurs pourraient choisir d'établir une appchain Starknet ou L3 au lieu de s'appuyer directement sur Starknet.

Débit

Les développeurs d'applications sont confrontés à d'importants défis en termes de scalabilité au sein de l'infrastructure blockchain existante. La scalabilité englobe deux aspects cruciaux : forte vitesse et des frais réduits. En mettant en œuvre une réduction des coûts de 1 000 fois à chaque layer, les développeurs peuvent obtenir une réduction globale remarquable des coûts de L1 à L3, atteignant potentiellement jusqu'à 1 000 000 fois. Le débit n'est pas affecté par l'activité des applications tierces, car l'application dispose d'une blockchain dédiée et ne rivalise pas pour les ressources. Cela garantit une expérience constamment fluide.

Personnalisation

Les chaînes à usage général comme Starknet et Ethereum ont plusieurs mesures en place pour garantir que le réseau soit utilisable par tous, ce qui crée un environnement contraint. Avec les appchains, les développeurs peuvent affiner différents aspects de leurs applications et de leur infrastructure, créant des solutions sur mesure. Vous n'aimez pas une fonctionnalité de la machine virtuelle Cairo ? Supprimez-la dans votre appchain.

Innovation

La personnalisation des appchains permet également aux développeurs de travailler avec des fonctionnalités actuellement indisponibles ou risquées dans des environnements comme Starknet. Les appchains offriront à chaque équipe l'autonomie nécessaire pour écrire et autoriser tout code souhaité. Cela permet aux appchains de débloquer de nombreux cas d'utilisation, comme la possibilité d'appliquer la conformité KYC on-chain sans divulguer d'informations privées.

L'effet de Madara sur la Stack des Appchains

Jetons un coup d'œil à l'interaction des différentes couches qui alimentent les appchains, et où Madara entre en jeu.

• Exécution : La couche d'exécution définit l'exécution des blocs et la génération de la différence d'état. Madara offre la flexibilité de passer entre deux conteneurs d'exécution, blockifier de StarkWare et starknet_in_rust de LambdaClass. Quelle que soit le conteneur choisi, le framework sous-jacent utilise la machine virtuelle Cairo. Le langage Cairo facilite la création de programmes prouvable, permettant la démonstration d'une exécution correcte des calculs.

• Règlement : En tant que Validity Rollup, l'état d'une appchain Madara peut être reconstruit uniquement en examinant sa couche de règlement. En réglant plus fréquemment sur le L2 Starknet, une appchain L3 peut atteindre une finalité plus rapide, tandis que la décentralisation de la couche de séquençage permet une finalité douce et plus robuste. Ainsi, le règlement est amélioré sur les deux fronts (finalité en dur et souple).

• Séquençage : Madara prend en charge le processus de séquençage, qui peut être modifié pour répondre aux besoins de l'application. Que ce soit FCFS simple, PGA ou des schémas plus complexes comme Narwhall & Bullshark. Certaines appchains peuvent choisir de déployer des mempools encrypté afin de garantir un ordre équitable et atténuer l'impact de la MEV.

• Disponibilité des données : La disponibilité des données garantit que l'arbre d'état complet reste accessible, donnant aux utilisateurs la confiance qu'ils peuvent prouver la propriété de leurs fonds même si Madara subit une interruption. Madara offrira aux développeurs une gamme de schémas de disponibilité des données (DA) parmi lesquels choisir.

• Gouvernance : Chaque appchain Madara peut choisir son modèle de gouvernance. Snapshot X propose un système de gouvernance entièrement on-chain reposant sur des preuves de stockage. D'autres mécanismes de gouvernance sont également en exploration, tels que l’ensemble de la gouvernance native de Substrate. La gouvernance on-chain est une valeur fondamentale pour Madara.

L'Arrivée de Madara

Avec Madara, la machine virtuelle Cairo se voit améliorée en utilisant le framework Substrate et en intégrant la VM Cairo pour exécuter les programmes Cairo et les contrats intelligents Starknet. Substrate est un framework Rust open-source pour construire des blockchains personnalisables, reconnu pour sa flexibilité. Pendant ce temps, la machine virtuelle Cairo est spécifiquement conçue pour générer efficacement des Preuves de Validité pour l'exécution de programmes. En utilisant un suivi d'état et un contrat intelligent pour vérifier ces preuves sur L2, l'appchain assure une intégration sécurisée avec Starknet. Ainsi, Madara exploite la puissance de Cairo pour permettre la vérifiabilité de l'exécution de programmes.

La nature modulaire inhérente au framework Substrate permet aux développeurs de personnaliser facilement l'appchain. Aucune hypothèse n'est imposée, vous permettant d'incorporer votre propre protocole de consensus, fonction de hachage, schéma de signature, disposition de stockage. Tout ce dont votre application a besoin, tout en utilisant Cairo pour générer des preuves. Aucune limite à ce que les développeurs peuvent faire tout en restant vérifiables, en héritant de la sécurité de la chaîne sous-jacente, que ce soit Starknet ou Ethereum.

Initialement, Madara ressemblera fortement à Starknet, permettant la composition de contrats intelligents au sein de l'écosystème Starknet. De plus grands projets sont prévus en réserve pour l'avenir alors que Starknet s'intègre à Herodotus pour exploiter les preuves de stockage afin d'atteindre l'interopérabilité. L'intégration des preuves de stockage permettra également aux appchains Madara de considérer l'état et la liquidité des autres chaînes.

Préparez-vous à assister à une nouvelle ère de possibilités dans l’écosystème de Starknet, rendue possible par Madara.

Un bond quantique dans le débit de Starknet apporte un nouveau cas d'utilisation financier de pointe à l'écosystème Starknet.

"Pouvons-nous passer à la bonne partie ?”

Paradex, un nouvel exchange de dérivés pour les crypto-actifs, est lancée sur la première Appchain de Starknet. Paradex proposera des transactions de contrats à terme perpétuels avec une profonde liquidité , une efficacité en capital et des performances tout en restant transparente et self-custody. Paradex a été incubée par l'équipe de Paradigm, le plus grand réseau de liquidité institutionnelle en crypto.

Cette collaboration entre StarkWare, les inventeurs de la technologie STARK, et Paradex, démontre la puissance de Starknet pour répondre aux besoins des applications nécessitant une scalabilité, des coûts réduits et des spécifications personnalisées, tout en atteignant la décentralisation et la propriété self-custody.

Comment nous en sommes arrivés là ?

La technologie de la blockchain a été inventée avec la décentralisation et la sécurité comme éléments essentiels, afin de résoudre les inconvénients de la finance traditionnelle et de sa dépendance à un tiers lors de la gestion des actifs. Des événements notables, tels que le crash de FTX en novembre 2022, ont souligné le besoin essentiel de fournir aux utilisateurs la propriété self-custody, une sécurité et une transparence.

Solutions basées sur les STARK

La technologie STARK vise à fournir une mise à l'échelle massive d'une part, tout en conservant la sécurité et la décentralisation d'Ethereum d'autre part. Elle a été utilisée pour traiter plus de 1 000 milliards de dollars, y compris des applications alimentées par StarkEx telles que Sorare et dYdX.

Starknet, un Rollup de Validité de couche 2 basé sur les STARK, a établi l'un des écosystèmes les plus créatifs et robustes dans le domaine du Web3. Avec la variété croissante de cas d'utilisation sur Starknet, il est naturel que certains développeurs d'applications souhaitent utiliser Starknet pour la mise à l'échelle, mais ils aimeraient le personnaliser en fonction de leurs besoins.

Saut de chaîne : Présentation de Paradex, la première Appchain de Starknet

« Paradex a joué un rôle clé en étant la première Appchain à adopter le nouveau séquenceur, une démonstration claire de notre profonde croyance en l'équipe de StarkNet et de son écosystème émergent »

« Alors que nous commencions à évaluer les technologies de mise à l'échelle de la blockchain qui permettraient de concrétiser la vision ambitieuse de Paradex, il est devenu clair que nous avions besoin d'une solution qui non seulement offrirait des performances et une évolutivité, mais aussi un contrôle et une personnalisation. Une instance privée de Starknet, ou Appchain, fournit cela en abondance. »

Nafaa Hendaoui, Chef de produit chez Paradex

En tant qu’exchange de dérivés, Paradex nécessite des capacités de calcul importantes pour exécuter une logique métier complexe. L'objectif est de le faire tout en établissant une décentralisation adéquate afin de garantir aux utilisateurs une expérience de trading équitable, transparente et sécurisée.

Les preuves de validité basées sur les STARK fournissent l'intégrité grâce aux mathématiques, avec leur puissance renforcée par les avancées technologiques récentes sur Starknet, notamment l'amélioration majeure du débit introduit dans Starknet Quantum Leap (V0.12.0), qui a rendu possible la création de la première Appchain de Starknet.

Les Appchains de Starknet permettent aux applications nécessitant une mise à l'échelle significative de créer leur propre voie, où elles sont les seules utilisatrices, libres d'ajuster les spécifications sans dépendre des protocoles des autres, tout en bénéficiant de la sécurité et de la décentralisation de qualité Ethereum.

Construction avec Cairo. Rapidité.

La logique métier de l'application a été rédigée en Cairo par l'équipe de Paradex. La rapidité avec laquelle l'équipe a maîtrisé Cairo, ainsi que la nature ergonomique du langage, ont assuré sa progression rapide. En seulement six mois, l'équipe de Paradex a pu construire une Appchain Starknet répondant à ses besoins, et participer aux impressionnantes améliorations d'échelle de Starknet V.0.12.0 avant de le déployer sur le Mainnet.

La logique métier, le développement des fonctionnalités et l'ajout de l'Appchain ont été déterminés uniquement par l'équipe qui l'exploitera et se permettant une optimisation maximale en utilisant de nouvelles fonctionnalités personnalisées ainsi que des fonctionnalités de propos à Starknet, telles que les multiples appels, qui permettront l'optimisation du trading perpétuel sur Paradex.

Rejoignez le mouvement

Accueillir l'Appchain de Paradex dans l'écosystème de Starknet est un signe de son innovation et de sa force qui lui ont valu la reconnaissance des principaux acteurs du monde de la cryptographie. À mesure que de nouvelles fonctionnalités, initiatives et possibilités déverrouillent l'utilisation de l'écosystème sur le Starknet public, telles que la Stack de Starknet récemment introduite, il devient de plus en plus clair jour après jour que Starknet est en plein essor.

Bien que Paradex ait été le premier à utiliser l'Appchain de Starknet, cela ouvre un monde de nouvelles opportunités pour des entreprises de tailles variées cherchant la mise à l'échelle, la sécurité et la décentralisation réunies dans un produit sur mesure adapté aux besoins spécifiques de chaque entreprise. Exploiter la technologie des STARK pour atteindre de nouveaux sommets et offrir aux clients des performances améliorées est à votre portée. Rejoignez-nous dès maintenant.

TL;DR :

• Starknet redéfinit l'industrie des jeux crypto en offrant des transactions rapides, bon marché et sécurisées sur Ethereum.

• Les jeux on-chain tels que Realms et Influence, construits sur Starknet, mettent en avant le potentiel des jeux crypto.

• Starknet exploite Cairo - un langage ergonomique et conviviale pour les développeurs familiarisé à Rust - pour le développement de jeux.

Introduction

Depuis des années, les jeux crypto ont vanté le potentiel de transformer l'industrie du jeu, grâce à la capacité donnée aux utilisateurs de posséder et transférer des actifs in-game. La propriété n'est que le début pour les jeux basés sur la blockchain, le plus grand potentiel étant une révolution tel que la DeFi, basée sur la décentralisation et l'interopérabilité dans les jeux on-chain. Malheureusement, les réalités des transactions blockchain lentes et coûteuses ont empêché la réalisation complète de ce potentiel.

Starknet change cela en permettant des transactions rapides et bon marché tout en offrant la sécurité d'Ethereum. Avec les dernières améliorations de débit de Starknet, plusieurs jeux on-chain sont déjà en cours de construction et sont sur le point de réaliser le plein potentiel des jeux on-chain. Deux de ces jeux sont Realms et Influence. Nous explorerons de quoi parlent ces jeux, quelles fonctionnalités de Starknet leur permettent de construire des systèmes de nouvelle génération et comment vous pouvez vous impliquer !

Tout d'abord, examinons rapidement Starknet et comment il alimente les jeux on-chain.

Starknet et Cairo

Starknet est un puissant Rollup de validité (L2) construit sur Ethereum. Cela signifie que non seulement les transactions sont rapides et bon marché (car elles sont "regroupées" et traitées sur le L2), mais elles sont également sécurisées. Voici une explication à la récente augmentation des TPS sur Starknet. Cela est extrêmement important pour les industries à forte demande de transactions, comme les jeux on-chain.

Cairo est un langage de contrat intelligent similaire à Rust permettant aux développeurs de construire facilement des applications pouvant être prouvées, tirant le meilleur parti du potentiel de la scalabilité des STARKs. Plusieurs projets de jeux (Influence, Realms, Topology, Briq, le moteur de jeu Dojo, etc.) construisent sur Starknet en utilisant Cairo. La version 1.0 de Cairo l'a rendu plus facile à utiliser que jamais, ainsi si vous avez déjà écrit du code avec Cairo Zero, il est temps de le vérifier. (Voici un guide pour les développeurs passant de Solidity à Cairo)

Explorons maintenant le parcours de deux des plus grands jeux sur le point de publier leurs premières versions publiques sur Starknet - Realms et Influence - et discutons à la fois des défis et des nouvelles possibilités qui se dressent devant eux.

Realms

Realms.World - l'un des pionniers du secteur des jeux on-chain - a plusieurs jeux et un 'studio de création' en développement.

Realms a été inspiré par les idées de 'Loot', un projet lancé sur Ethereum en 2021 dans le but de démarrer le développement d'un monde fantastique détenu et construit par la communauté sur la blockchain.

L'idée d'utiliser des contrats intelligents comme blocs de construction pour construire collectivement un monde fantastique sur Ethereum a séduit de nombreux développeurs et joueurs, qui ont réalisé le potentiel que la décentralisation, l'open-source et l'auto-garde peuvent avoir sur le jeu.

Dans les jeux Web2 centrés sur le créateur, comme Minecraft et Roblox, les utilisateurs du monde sont toujours des visiteurs dans le monde de l'éditeur. Avec des mondes de jeu construits on-chain, ces mondes deviennent autonomes, une fois déployés, par rapport à leur créateur initial et n'importe qui peut construire dessus. Pour les joueurs, la promesse des jeux on-chain va au-delà du 'modding' et de la propriété des actifs, pour devenir une manière complètement nouvelle de construire et de jouer ensemble.

La communauté de Realms a été inspirée par ces possibilités et a ainsi formé Bibliotheca DAO pour faire avancer le développement d'un monde de jeu on-chain qui englobait à la fois, lore de Loot et sa propre lore. La DAO et le projet ont été parmi les premiers à adopter Cairo, Starknet et les nouvelles possibilités qu'ils offrent aux jeux on-chain.

Realms Eternum and Loot Survivor

Eternum est un jeu de stratégie qui combine le gameplay de jeux de navigateur populaires comme Travian et Tribal War, avec des schémas de jeu rappelant les jeux de société comme Catan et Risk, et des considérations économiques. Les 8 000 royaumes d'Eternum sont des territoires individuels, gérés et développés par le seigneur de chaque territoire. Eternum est un jeu éternel : il fonctionnera aussi longtemps qu'Ethereum produira des blocs, et les événements de ce monde détermineront sa direction.

Loot Survivor est un jeu basé sur des sessions, l'un des premiers jeux complexes entièrement on-chain fonctionnant sur n'importe quelle couche 2. Dans ce jeu, les joueurs rencontrent des bêtes, des pièges et des opportunités d'améliorer leur armement et leur armure à chaque mouvement. La complexité du jeu est rendue possible par la vitesse, le coût et la puissance de calcul vérifiable de Starknet. Loot Survivor est le premier exemple d'une "machine d'arcade immuable" rendue possible par les circuits ZK.

Influence

"Influence est un jeu de colonisation spatiale hautement stratégique et social, dans lequel les joueurs se disputent la domination et le contrôle de la colonie humaine nouvellement formée dans la ceinture d'astéroïdes d'Adalian.”

Chris Lexmond, PDG de Unstoppable Games, Inc. et créateur d'Influence

Après avoir fui une Terre moribonde, l'humanité a trouvé sa nouvelle frontière dans la ceinture d'astéroïdes du système Adalia. Les 250 000 astéroïdes, dont chacun a une composition minérale unique, orbitent tous en temps réel autour de l'étoile Adalia. Les joueurs s'affrontent sur plusieurs fronts : exploitation minière, construction, commerce, voyage, recherche et combat.

Dans la première version du jeu, Exploitation, les joueurs se concentrent sur la création de colonies autour d’Adalia et sur la fondation d'une économie de jeu gérée par les joueurs.

Dans les phases suivantes du jeu - Découverte et Conflit - les joueurs se concentreront sur les avancées technologiques et les conflits inter-astéroïdes. À ce stade, le jeu se transformera en une véritable expérience de guerre entre joueurs.

Influence offre aux joueurs la liberté de choisir entre revendiquer leur propre astéroïde ou commencer leur voyage sur Adalia Prime, le plus grand astéroïde du système qui sert de terre ouverte à partir de laquelle tous les joueurs peuvent extraire de précieuses ressources pour commencer à étendre leur influence. Il est intéressant de noter que la structure de la ceinture d'astéroïdes respecte les principes de la physique orbitale du monde réel.

Unstoppable Games publiera bientôt sur Testnet la première version entièrement jouable du jeu, baptisée "Pre-Release".

Actuellement, plus de 15 applications indépendantes sont déjà en cours de construction avec les contrats Influence au centre - quelque chose qui n'est possible que lorsque vous avez un système ouvert et sans permission comme la blockchain.

La révolution des jeux on-chain

1. Éternel : Realms et Influence sont conçus pour être des jeux éternels. Tant que la logique du jeu reste on-chain et que la blockchain qui supporte les jeux est active, les jeux continueront d'exister et devraient pouvoir fonctionner indépendamment des développeurs qui les ont créés. De plus, comme toute la logique du jeu existe on-chain, d'autres peuvent s’appuyer sur le code du jeu.

2. Responsabiliser les joueurs et les contributeurs tiers : les joueurs sont autorisés à jouer un rôle dans l'élaboration des jeux, à contribuer à leur développement et à s'y engager d'une manière qui transcende les frontières traditionnelles du jeu. Il peut s'agir de créer des outils d'analyse, des gestionnaires de ressources ou des compteurs DPS. Cette évolution pilotée par les joueurs contribue à faire évoluer le jeu en permanence et à créer un écosystème dynamique.

3. Contrôle accru des ressources du jeu : les joueurs peuvent acheter, vendre et échanger des ressources librement, sans restrictions de la part d'une autorité centrale.

4. Puissance de Dojo : Les créateurs de Realms ont construit le jeu avec Dojo, le premier moteur de jeu prouvable au monde, ce qui a facilité le travail des développeurs du jeu. (En savoir plus sur Dojo ici)

5. Cairo comme passerelle : Comme le montre la base du code de Realms, le jeu a été écrit en Cairo. Alors que l'industrie du jeu passe du Web2 au Web3, le fait que Cairo soit un langage similaire à Rust peut jouer un rôle crucial dans le paysage du jeu sur Starknet : Les développeurs de jeux familiers avec les langages similaire à Rust peuvent se lancer dans le développement de jeux sur la blockchain. Dans ce contexte, Cairo peut servir de passerelle.

"Starknet joue sur le long terme, et dans le domaine des logiciels, le long terme est le jeu que vous voulez jouer. Parce qu'il y a tellement d'optimisation qui peut se produire sur la CairoVM dans un avenir proche."

Développeurs de Realms

Conclusion

Les jeux on-chain responsabilisent les joueurs et ouvrent une nouvelle ère dans le domaine des jeux. Cette approche, fondée sur la décentralisation, cultive une économie axée sur les joueurs et favorise l'émergence de communautés dynamiques au sein des jeux. En outre, elle encourage l'innovation dans le jeu, ce qui conduit à un écosystème dynamique et évolutif.

L'utilisation de Cairo, le langage natif de Starknet, ne fait qu'améliorer la capacité des jeux on-chain à réussir, car ils peuvent massivement traiter des calcules informatiques, avoir une vérification ultra-efficace et créer une interface utilisateur transparente grâce à l'abstraction des comptes. En outre, comme des améliorations telles que Volition et l’abstraction des comptes sont nativement intégrées dans Starknet, le coût des transactions devrait encore diminuer. Grâce aux améliorations constantes apportées au séquenceur de Starknet, la vitesse des transactions ne fera qu'augmenter. Au milieu de ce scénario progressif, les perspectives pour l'industrie du jeu et Starknet n'ont jamais été aussi prometteuses.