Interprétation du modèle de contrat intelligent et de l'AA natif de Starknet : un maître technicien singulier
TechFlow SélectionTechFlow Sélection
Interprétation du modèle de contrat intelligent et de l'AA natif de Starknet : un maître technicien singulier
Cet article présente brièvement le modèle de contrat intelligent de Starknet et son authentification abstraite (AA) native, en exposant leurs solutions techniques et leur conception mécanique.
Dédié à des analyses Web3 approfondiesAuteurs : Shew & Faust, Geeks de web3
Conseiller : CryptoNerdCn, développeur principal de l'écosystème Starknet, fondateur de WASM Cairo, plateforme de développement Cairo côté navigateur
Résumé
Les principales caractéristiques techniques de Starknet incluent le langage Cairo favorable à la génération de preuves ZK, l'abstraction des comptes au niveau natif, et un modèle de contrat intelligent séparant logique métier et stockage d'état.
Cairo est un langage ZK généraliste pouvant servir à implémenter des contrats intelligents sur Starknet ainsi qu'à développer des applications plus traditionnelles. Son processus de compilation introduit Sierra comme langage intermédiaire, permettant à Cairo d'évoluer fréquemment sans modifier le bytecode de base, en reportant les changements uniquement sur le langage intermédiaire. En outre, la bibliothèque standard de Cairo intègre déjà de nombreuses structures de données fondamentales nécessaires à l'abstraction des comptes.
Sur Starknet, la logique métier et les données d'état des contrats intelligents sont stockées séparément. Contrairement aux chaînes EVM, le déploiement d'un contrat Cairo suit un processus en trois étapes : "compilation, déclaration, déploiement". La logique métier est déclarée dans une classe Contract (Contract class), tandis que l'instance Contract contenant les données d'état peut être associée à cette classe et invoquer son code.
Ce modèle de contrat intelligent favorise la réutilisation du code et de l'état, la hiérarchisation du stockage, la détection des contrats inutiles, ainsi que la mise en œuvre future du système de location de stockage et de la parallélisation des transactions. Bien que ces deux dernières fonctionnalités ne soient pas encore activées, l’architecture des contrats Cairo crée les « conditions nécessaires » pour leur adoption ultérieure.
Sur la chaîne Starknet, seuls existent des comptes contrats intelligents ; il n’y a pas de comptes EOA. Dès le départ, elle prend donc en charge nativement l’abstraction des comptes (AA). Sa solution AA s’inspire partiellement de ERC-4337, en permettant aux utilisateurs de choisir des schémas hautement personnalisés de traitement des transactions. Pour prévenir d’éventuels scénarios d’attaque, Starknet a mis en place plusieurs contre-mesures, contribuant significativement à l’exploration de l’écosystème AA.
Contenu principal
Depuis le lancement du jeton STRK, ce dernier est progressivement devenu un élément incontournable aux yeux des observateurs d'Ethereum. Ce projet phare de la couche 2 d'Ethereum, connu pour son indépendance d'esprit et son mépris affiché pour l'expérience utilisateur, ressemble à un ermite paisible cultivant tranquillement son propre petit champ dans l’écosystème L2 dominé par la compatibilité EVM.
Trop négligent vis-à-vis des utilisateurs, allant jusqu’à ouvrir publiquement un canal Discord baptisé « mendicité électronique », Starknet a été critiqué par les chasseurs de primes. Accusé d'être « insensible », sa profonde expertise technique semblait soudain « sans valeur ». Seules l'UX et la création de richesse semblaient désormais compter. La phrase du *Pavillon d’Or* – « Ne pas être compris est devenu mon unique fierté » – résume parfaitement l’esprit de Starknet.
Mais en mettant de côté ces querelles superficielles, et en adoptant simplement le « goût technologique » des puristes du code, Starknet et StarkEx, pionniers des ZK Rollup, apparaissent comme de véritables joyaux aux yeux des passionnés de Cairo. Pour certains développeurs de jeux full-chain, Starknet et Cairo incarnent littéralement l’essence du web3, surpassant largement Solidity ou Move. Aujourd’hui, le fossé entre les « geeks technologiques » et les « utilisateurs » provient surtout d’une méconnaissance de Starknet.
Portés par un intérêt sincère pour la technologie blockchain et la découverte de la valeur de Starknet, les auteurs de cet article présentent simplement, à partir du modèle de contrat intelligent et de l’AA native de Starknet, ses solutions techniques et mécanismes de conception, afin non seulement de mieux faire connaître les caractéristiques techniques de Starknet, mais aussi de permettre à davantage de personnes de comprendre ce « solitaire incompris ».
Introduction simple au langage Cairo
Dans ce qui suit, nous nous concentrerons sur le modèle de contrat intelligent de Starknet et son abstraction des comptes native, en expliquant comment Starknet réalise l’AA native. Après lecture, vous comprendrez pourquoi les phrases de récupération (mnémoniques) de différents portefeuilles Starknet ne sont pas interchangeables.
Avant d’aborder l’abstraction des comptes native, commençons par découvrir le langage Cairo, exclusif à Starknet. Au cours de son évolution, Cairo a connu une version initiale appelée Cairo0, puis une version moderne. Cette dernière adopte une syntaxe similaire à Rust et constitue en réalité un langage ZK généraliste, pouvant servir non seulement à écrire des contrats intelligents sur Starknet, mais aussi à développer des applications générales.
Par exemple, on peut utiliser Cairo pour développer un système de vérification d’identité ZK, exécutable sur un serveur privé sans dépendre du réseau StarkNet. Tout programme nécessitant des calculs vérifiables peut être implémenté en Cairo. Cairo est probablement aujourd’hui le langage le plus adapté à la génération de preuves ZK.
Du point de vue du processus de compilation, Cairo utilise une méthode basée sur un langage intermédiaire (IR), illustrée ci-dessous. Sierra, représenté sur l’image, est une forme intermédiaire dans le processus de compilation de Cairo. Sierra est ensuite compilé en CASM, une forme binaire plus bas niveau directement exécutée par les nœuds Starknet.
L’introduction de Sierra comme étape intermédiaire facilite l’ajout de nouvelles fonctionnalités à Cairo : souvent, il suffit de modifier Sierra sans toucher au code CASM sous-jacent, évitant ainsi de nombreux tracas et rendant inutile une mise à jour fréquente des clients nœuds de Starknet. Ainsi, Cairo peut évoluer rapidement sans altérer la logique fondamentale de StarkNet. De plus, la bibliothèque standard de Cairo inclut déjà de nombreuses structures de données fondamentales requises pour l’abstraction des comptes.
Parmi les autres innovations de Cairo figure une proposition théorique appelée « Cairo Native », qui vise à compiler Cairo en code machine adapté à différents matériels, permettant aux nœuds Starknet d’exécuter les contrats intelligents sans passer par la machine virtuelle CairoVM, ce qui accélérerait considérablement l’exécution du code [actuellement au stade théorique, non implémenté].
Modèle de contrat intelligent de Starknet : dissociation de la logique et du stockage d’état
Contrairement aux chaînes compatibles EVM, Starknet innove radicalement dans la conception de son système de contrats intelligents. Ces innovations préparent notamment l’AA native et la future fonctionnalité de traitement parallèle des transactions. Il faut savoir que sur Ethereum et autres blockchains traditionnelles, le déploiement de contrats intelligents suit généralement le modèle « compiler puis déployer ». Prenons l’exemple d’un contrat ETH :
1. Le développeur écrit localement le contrat, puis le compile via un éditeur en bytecode EVM, compréhensible directement par la machine virtuelle EVM.
2. Le développeur lance une transaction de déploiement, transférant le bytecode compilé sur la chaîne Ethereum.
(Source : not-satoshi.com)
Bien que Starknet suive également le principe « compiler puis déployer », avec des contrats déployés sous forme de bytecode CASM pris en charge par CairoVM, il existe des différences majeures avec les chaînes EVM en matière d’appel des contrats et de modèle de stockage d’état.
Plus précisément, un contrat intelligent Ethereum = logique métier + informations d’état. Par exemple, le contrat USDT implémente des fonctions telles que Transfer et Approval, tout en conservant l’état des actifs de tous les détenteurs d’USDT. Code et état sont ainsi couplés, ce qui pose de nombreux problèmes : difficile à mettre à jour ou migrer, incompatible avec le traitement parallèle des transactions — un fardeau technique pesant.
Face à cela, Starknet améliore la manière de stocker l’état. Dans son schéma de contrat intelligent, la logique métier et l’état des actifs sont complètement découplés et stockés séparément. Les avantages sont immédiats : le système peut identifier plus rapidement les doublons ou redondances de code. Le principe est le suivant :
Un contrat Ethereum = logique métier + données d’état. Si plusieurs contrats ont une logique identique mais des états différents, leurs hachages seront différents, empêchant le système d’identifier efficacement les contrats redondants ou inutiles.
En revanche, dans Starknet, code et données d’état sont séparés. Le système peut comparer les hachages du code seul, facilitant la détection de déploiements multiples du même code car leurs hachages sont identiques. Cela permet de limiter les déploiements redondants et économiser l’espace de stockage des nœuds Starknet.
Dans le système de contrat intelligent de Starknet, le déploiement et l’utilisation suivent trois étapes : "compilation, déclaration, déploiement". Pour déployer un contrat Cairo, l’émetteur commence par compiler localement son code Cairo en formes Sierra et bytecode CASM.
Ensuite, le déployeur envoie une transaction « declare » pour publier sur la chaîne le bytecode CASM et le code intermédiaire Sierra, créant ainsi une Contract Class.
(Source : site officiel de Starknet)
Enfin, pour utiliser les fonctions définies dans ce contrat, un utilisateur peut lancer via l’interface DAPP une transaction « deploy », créant une instance Contract liée à la Contract Class, instance qui contiendra l’état des actifs. L’utilisateur pourra alors invoquer les fonctions de la Contract Class pour modifier l’état de l’instance.
Quiconque connaît la programmation orientée objet devrait facilement comprendre ce que représentent Class et Instance ici. La Contract Class déclarée par le développeur contient uniquement la logique métier — un ensemble de fonctions appelables par tous — mais aucun état réel, ni « corps », seulement une « âme ».
Seul le déploiement d'une instance Contract concrétise l’actif. Pour modifier l’état de cet « entité », par exemple transférer des jetons, l’utilisateur invoque simplement les fonctions prédéfinies dans la Contract Class. Ce processus rappelle vaguement l’instanciation en programmation orientée objet (bien que pas totalement identique).
Une fois séparés en Class et instances, la dissociation de logique et d’état confère à Starknet les propriétés suivantes :
1. Favorise la hiérarchisation du stockage et la mise en œuvre du « système de location de stockage »
La hiérarchisation du stockage signifie que les développeurs peuvent choisir où placer leurs données, y compris hors chaîne. StarkNet prévoit de prendre en charge des couches DA comme Celestia, permettant aux DAPP de stocker leurs données sur ces tiers. Par exemple, un jeu pourrait conserver les données critiques sur le réseau principal Starknet, et les autres sur Celestia ou d'autres couches DA hors chaîne. Cette approche de choix personnalisé de la couche DA selon les besoins de sécurité est nommée « Volition » par Starknet.
Quant au système de location de stockage, il repose sur l’idée que chacun doit payer régulièrement pour l’espace qu’il occupe. Plus on consomme d’espace sur chaîne, plus on doit payer un loyer continu.
Dans le modèle de contrat Ethereum, la propriété n’est pas clairement définie, rendant difficile de décider si c’est le déployeur ou les détenteurs du jeton ERC-20 qui doivent payer le « loyer ». Aussi, aucune fonction de location n’a été mise en œuvre, seule une taxe ponctuelle étant demandée au moment du déploiement. Ce modèle tarifaire est peu équitable.
En revanche, dans les modèles de contrats intelligents de Starknet, Sui, CKB ou Solana, la propriété est mieux définie, facilitant la collecte des frais de stockage [Starknet n’a pas encore activé directement ce système, mais le fera à l’avenir].
2. Permet une véritable réutilisation du code et réduit le déploiement de contrats inutiles
On peut déclarer un contrat de jeton générique comme class sur la chaîne, permettant à tous d’utiliser ses fonctions pour déployer leurs propres instances de jetons. Les contrats peuvent aussi appeler directement le code de la class, réalisant un effet similaire aux bibliothèques (Library) en Solidity.
De plus, ce modèle facilite la détection des « contrats inutiles ». Comme expliqué précédemment, en permettant la réutilisation du code et la détection des doublons, Starknet peut réduire massivement la quantité de données sur chaîne, allégeant ainsi la pression sur le stockage des nœuds.
3. Réutilisation véritable de l’« état » du contrat
La mise à jour d’un contrat blockchain concerne principalement la modification de la logique métier. Dans Starknet, logique et état sont naturellement séparés : une instance de contrat peut changer de type de classe pour mettre à jour sa logique, sans migrer son état. Cette méthode de mise à jour est plus complète et native que celle d’Ethereum.
Pour modifier la logique sur Ethereum, on délègue souvent la logique à un contrat proxy, en changeant le proxy dépendant pour modifier la logique du contrat principal. Mais cette méthode manque d’élégance et n’est pas « native ».
(Source : wtf Academy)
Dans certains cas, si un ancien contrat Ethereum est abandonné, son état ne peut pas être directement transféré, ce qui est très problématique. Un contrat Cairo, lui, n’a pas besoin de migrer l’état, il peut le « réutiliser » directement.
4. Facilite le traitement parallèle des transactions
Pour maximiser le parallélisme des instructions de transaction, il est essentiel de disperser les états d’actifs de différentes personnes. On observe cela sur Bitcoin, CKB et Sui. Une condition préalable à cet objectif est de séparer logique métier et données d’état. Bien que Starknet n’ait pas encore profondément implémenté la parallélisation des transactions, cela restera un objectif prioritaire à l’avenir.
Abstraction native des comptes et déploiement de comptes contrats sur Starknet
En réalité, le concept d’« abstraction des comptes » (AA) est une invention spécifique de la communauté Ethereum. Sur de nombreuses nouvelles blockchains, il n’existe pas de distinction entre comptes EOA et comptes contrats, évitant dès le départ les pièges du modèle de comptes d’Ethereum. Par exemple, sur Ethereum, un contrôleur de compte EOA doit posséder des ETH sur chaîne pour lancer une transaction, ne peut pas choisir librement sa méthode d’authentification, et ajouter une logique de paiement personnalisée est extrêmement complexe. Certains vont jusqu’à dire que ce design est carrément « anti-humain ».
Si l’on examine des chaînes comme Starknet ou zkSync Era, qui promeuvent fortement l’« AA native », on observe une différence nette : d’abord, Starknet et zkSync Era unifient les types de comptes ; il n’existe que des comptes contrats intelligents, pas de comptes EOA (zkSync Era déploie par défaut un code contrat sur les nouveaux comptes pour imiter les caractéristiques d’un compte EOA Ethereum, assurant ainsi la compatibilité avec Metamask).
Starknet, quant à lui, ne cherche pas à être directement compatible avec Metamask ou d’autres outils Ethereum. Lorsqu’un utilisateur crée un portefeuille Starknet pour la première fois, un compte contrat spécialisé est automatiquement déployé — autrement dit, une instance de contrat comme mentionné plus tôt — cette instance est associée à une class de contrat préalablement déployée par le fournisseur du portefeuille, pouvant directement appeler certaines fonctions prédéfinies dans cette class.
Abordons maintenant un sujet intéressant : lors de la distribution de l’airdrop STRK, beaucoup ont constaté que les portefeuilles Argent et Braavos ne sont pas compatibles entre eux : importer la mnémonique d’Argent dans Braavos ne permet pas de retrouver le compte correspondant. Cela vient du fait qu’Argent et Braavos utilisent des méthodes différentes de calcul de génération de comptes, produisant des adresses différentes à partir de la même mnémonique.
Plus précisément, sur Starknet, l’adresse d’un nouveau contrat peut être déterminée par un algorithme déterministe, utilisant la formule suivante :
Dans cette formule, pedersen() est un algorithme de hachage facile à utiliser dans les systèmes ZK. Générer un compte revient à entrer certains paramètres spécifiques dans la fonction pedersen pour produire un hachage, qui devient l’adresse du compte.
L’image ci-dessus montre les paramètres utilisés par Starknet pour générer une « nouvelle adresse de contrat ». deployer_address représente l’adresse du « déployeur de contrat », pouvant être vide — même sans compte Starknet préexistant, on peut déployer un nouveau contrat.
salt est la valeur ajoutée (sel) pour le calcul de l’adresse du contrat, en pratique un nombre aléatoire, utilisé pour éviter les doublons d’adresses. class_hash est le hachage de la class du contrat, présenté précédemment. constructor_calldata_hash représente le hachage des paramètres d’initialisation du contrat.
Grâce à cette formule, l’utilisateur peut prédéterminer l’adresse du contrat avant même son déploiement sur chaîne. Starknet autorise le déploiement de contrat même sans compte préalable, selon le processus suivant :
1. L’utilisateur choisit la class de contrat à laquelle sera liée son instance, utilise le hachage de cette class comme paramètre d’initialisation, calcule salt, et obtient ainsi l’adresse du futur contrat.
2. Une fois l’adresse connue, l’utilisateur y transfère une certaine quantité d’ETH pour couvrir les frais de déploiement. Généralement, ces ETH sont transférés via un pont depuis la couche 1 vers Starknet.
3. L’utilisateur lance la transaction de déploiement du contrat.
En réalité, tous les comptes Starknet sont déployés selon ce processus, mais la plupart des portefeuilles masquent ces détails techniques, rendant invisible la procédure à l’utilisateur, donnant l’impression que le compte est créé automatiquement après avoir transféré des ETH.
Ce schéma entraîne certains problèmes de compatibilité, car différents portefeuilles génèrent des adresses de compte différentes. Seuls les portefeuilles satisfaisant les conditions suivantes peuvent être utilisés de manière interchangeable :
-
Utilisent le même algorithme de dérivation de clé privée/publique et de signature ;
-
Ont le même processus de calcul de salt ;
-
Ne diffèrent pas fondamentalement dans les détails d’implémentation de leur contrat intelligent class.
Dans l’exemple cité, Argent et Braavos utilisent tous deux l’algorithme de signature ECDSA, mais leurs méthodes de calcul de salt diffèrent, générant ainsi des adresses de compte différentes à partir de la même mnémonique.
Revenons à l’abstraction des comptes. Starknet et zkSync Era déplacent hors du « niveau basique de la chaîne » toute une série de processus liés au traitement des transactions, tels que l’authentification (vérification de signature numérique) et le paiement des frais de gaz. L’utilisateur peut personnaliser ces logiques dans son propre compte.
Par exemple, vous pouvez déployer dans votre compte Starknet une fonction de vérification de signature spécialisée. Lorsque le nœud Starknet reçoit votre transaction, il invoque les logiques de traitement personnalisées définies dans votre compte sur chaîne. Cela offre clairement plus de flexibilité.
Dans la conception d’Ethereum, la logique d’authentification (signature numérique) est figée dans le code du client nœud, incapable de supporter nativement la personnalisation des fonctions de compte.
(Schéma proposé par l’architecte de Starknet : la validation des transactions et celle des frais de gaz sont transférées aux contrats sur chaîne ; la machine virtuelle de base peut invoquer ces fonctions personnalisées ou spécifiées par l’utilisateur.)
Selon les équipes officielles de zkSync Era et Starknet, cette modularisation des fonctions de compte s’inspire de l’EIP-4337. Mais contrairement à Ethereum, zkSync et Starknet ont fusionné dès le début les types de comptes, uniformisé les types de transactions, et centralisé la réception et le traitement de toutes les transactions. Ethereum, en raison de son héritage historique et du souhait de la fondation d’éviter les hard forks brusques, a opté pour EIP-4337, une solution détournée, dont l’effet est que les comptes EOA et ceux de la norme 4337 suivent des flux de traitement distincts, paraissant maladroits et lourds, bien moins souples que l’AA native.
(Source : ArgentWallet)
Mais actuellement, l’abstraction native des comptes de Starknet n’est pas encore pleinement mature. En pratique, Starknet permet la personnalisation de l’algorithme de vérification de signature, mais pour le paiement des frais, il ne supporte en réalité que le paiement en ETH et STRK, sans prise en charge du paiement par un tiers. Ainsi, concernant l’AA native, Starknet en est à un stade où « la théorie est presque mature, mais la mise en œuvre est encore en cours ».
Comme Starknet ne comporte que des comptes contrats intelligents, l’ensemble du processus de transaction prend en compte l’impact du contrat intelligent du compte. D’abord, une transaction acceptée par le mempool d’un nœud Starknet subit une vérification comprenant deux étapes :
-
Vérification de la signature numérique de la transaction, en appelant la fonction de vérification personnalisée dans le compte de l’expéditeur ;
-
Vérification que le solde du compte émetteur peut couvrir les frais de gaz.
Il faut noter qu’utiliser une fonction de vérification personnalisée dans un contrat intelligent expose à des scénarios d’attaque. Le mempool ne facture pas de frais lors de la vérification de signature (car cela créerait des attaques encore plus graves). Un utilisateur malveillant pourrait définir une fonction de vérification extrêmement complexe dans son contrat, puis envoyer massivement des transactions exigeant cette vérification, épuisant ainsi les ressources de calcul des nœuds.
Pour éviter cela, StarkNet impose les restrictions suivantes :
-
Limite supérieure au nombre de transactions qu’un utilisateur peut envoyer par unité de temps ;
-
Les fonctions de vérification de signature personnalisées dans les comptes Starknet sont limitées en complexité. Les fonctions trop complexes ne seront pas exécutées. Starknet fixe une limite supérieure de gaz consommé par la vérification ; si cette limite est dépassée, la transaction est rejetée. De plus, la fonction de vérification ne peut pas appeler d’autres contrats.
Voici le diagramme du processus de transaction de Starknet :
À noter que, afin d’accélérer davantage la vérification des transactions, les clients nœuds Starknet implémentent directement les algorithmes de vérification de signature des portefeuilles Braavos et Argent. Lorsqu’un nœud détecte une transaction provenant de l’un de ces deux portefeuilles dominants, il utilise l’algorithme intégré dans le client, raccourcissant ainsi le temps de vérification grâce à un mécanisme proche du cache.
Après vérification par le séquenceur (beaucoup plus approfondie que celle du mempool), les transactions du mempool sont regroupées et transmises au générateur de preuve ZK. À ce stade, même les transactions ayant échoué seront facturées en gaz.
Mais si le lecteur connaît l’histoire de Starknet, il saura que dans ses débuts, Starknet ne facturait pas les frais de gaz pour les transactions ayant échoué. Le cas le plus courant : un utilisateur disposant de 1 ETH tente d’en transférer 10 ETH. Cette transaction contient clairement une erreur logique et échouera nécessairement, bien que personne
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
