Transférer le titre original：解读Starknet智能合约模型与原生AA：特立独行的技术巨匠

Auteurs originaux : Shew & Faust, Conseillers Web3 : CryptoNerdCn, Développeur principal de Starknet, Plateforme de développement Cairo WASM côté navigateur, Fondateur de Cairo

Résumé :

Les principales caractéristiques technologiques de Starknet comprennent le langage Cairo, qui est propice à la génération de preuves ZK, AA au niveau natif, et un modèle de smart contract où la logique métier est indépendante du stockage de l'état. Cairo est un langage ZK polyvalent qui peut être utilisé pour implémenter des smart contracts sur Starknet ainsi que pour développer des applications avec des orientations traditionnelles. Son processus de compilation introduit Sierra comme un langage intermédiaire, permettant des itérations fréquentes de Cairo sans modifier directement le bytecode sous-jacent. De plus, la bibliothèque standard de Cairo comprend de nombreuses structures de données de base requises pour l'abstraction de compte. Les smart contracts Starknet séparent la logique métier du stockage des données d'état, contrairement aux chaînes EVM. Le déploiement des contrats Cairo implique trois étapes : compilation, déclaration et déploiement, où la logique métier est déclarée dans une classe Contract. Des instances de contrats contenant des données d'état peuvent être associées à la classe et appeler le code qu'elle contient.

Le modèle de contrat intelligent susmentionné de Starknet favorise la réutilisation du code, la réutilisation de l'état du contrat, le stockage en couches et la détection des contrats indésirables. Il favorise également la réalisation de la location de stockage et de la parallélisation des transactions. Bien que ces deux derniers n'aient pas encore été mis en œuvre, la structure des contrats intelligents Cairo a créé des "conditions nécessaires" pour eux. · Il n'y a que des comptes de contrats intelligents sur la chaîne Starknet et pas de comptes EOA. Il prend en charge l'abstraction des comptes AA au niveau natif dès le début. Son plan AA intègre les idées de l'ERC-4337 dans une certaine mesure, permettant aux utilisateurs de choisir des solutions de traitement des transactions hautement personnalisées. Afin de prévenir les scénarios d'attaque potentiels, Starknet a pris de nombreuses contre-mesures et a mené d'importantes explorations dans l'écosystème AA.

texte : Suite à l’émission de tokens sur Starknet, STRK est progressivement devenu un élément indispensable aux yeux des observateurs d’Ethereum. Cette star de la couche 2 d’Ethereum, connue pour son attitude « indépendante » et « insouciante de l’expérience utilisateur », s’est discrètement taillé son propre territoire dans l’écosystème florissant de la couche 2 compatible avec EVM. En raison de sa négligence excessive des utilisateurs, et même de la mise en place ouverte d’un canal de « mendiant électronique » sur Discord, Starknet a déjà été critiqué par la communauté. Au milieu des accusations d’être « inhumain », sa profonde expertise technique a semblé instantanément dévaluée, comme si seules l’UX et la création de richesse étaient tout. La réplique du « Temple du Pavillon d’Or » - « le fait de ne pas être compris des autres avait été ma seule source de fierté » - est presque un autoportrait de Starknet. Cependant, si l’on met de côté ces questions triviales du monde, purement basées sur le goût technique des geeks du code, Starknet et StarkEx, en tant que pionniers de ZK Rollup, sont presque des trésors aux yeux des passionnés du Caire. Dans l’esprit de certains développeurs de jeux blockchain, Starknet et Cairo sont tout simplement tout dans le Web3, dépassant Solidity et Move. Le plus grand écart entre les « geeks techniques » et les « utilisateurs » aujourd’hui est en fait largement attribué au manque de compréhension de Starknet. Motivé par un intérêt pour la technologie blockchain et l’exploration de la valeur de Starknet, l’auteur de cet article part du modèle de contrat intelligent et de l’AA natif de Starknet pour décrire brièvement ses solutions techniques et ses conceptions de mécanismes, dans le but de présenter les caractéristiques techniques de Starknet à un plus grand nombre de personnes, tout en espérant aider les gens à comprendre ce « ranger solitaire incompris ». Après une brève introduction à la langue Cairo dans la section suivante, nous nous concentrerons sur la discussion du modèle de contrat intelligent de Starknet et de l’abstraction de compte native, en expliquant comment Starknet atteint l’AA natif. Après avoir lu cet article, les lecteurs comprendront également pourquoi les phrases mnémotechniques de différents portefeuilles ne peuvent pas être mélangées dans Starknet. Mais avant d’introduire l’abstraction de compte native, comprenons d’abord le langage innovant du Caire créé par Starknet. Dans le processus de développement du Caire, il y a eu les premières versions appelées Cairo0, suivies de la version moderne. La syntaxe générale de la version moderne de Cairo est similaire à celle de Rust et est en fait un langage ZK polyvalent. En plus d’être utilisé pour écrire des contrats intelligents sur Starknet, il peut également être utilisé pour le développement d’applications générales. Par exemple, nous pouvons développer un système de vérification d’identité ZK en utilisant la langue du Caire, et ce programme peut fonctionner sur notre propre serveur sans dépendre du réseau StarkNet. On peut dire que n’importe quel programme nécessitant des propriétés de calcul vérifiables peut être implémenté en utilisant le langage Cairo. Et Cairo est peut-être actuellement le langage de programmation le plus propice à la génération de preuves ZK.

Du point de vue du processus de compilation, Cairo utilise une méthode de compilation basée sur un langage intermédiaire, comme le montre la figure ci-dessous. Sierra dans l'image est une représentation intermédiaire (IR) dans le processus de compilation du langage Cairo, et Sierra sera compilée en une représentation du code binaire de niveau inférieur, nommée CASM, qui s'exécute directement sur le dispositif de noeud Starknet.

L'introduction de Sierra en tant que représentation intermédiaire facilite l'ajout de nouvelles fonctionnalités au langage Cairo. Dans de nombreux cas, il est seulement nécessaire de manipuler le langage intermédiaire Sierra sans modifier directement le code CASM sous-jacent. Cela évite beaucoup de problèmes, et le client de nœud de Starknet n'a pas besoin d'être mis à jour fréquemment. De cette manière, des itérations fréquentes du langage Cairo peuvent être réalisées sans modifier la logique sous-jacente de StarkNet. La bibliothèque standard de Cairo inclut également de nombreuses structures de données de base nécessaires pour l'abstraction de compte. D'autres innovations de Cairo incluent une solution théorique appelée Cairo Native, qui prévoit de compiler Cairo en code machine de bas niveau pouvant s'adapter à différents dispositifs matériels. Les nœuds de Starknet n'auront pas à dépendre de la machine virtuelle CairoVM lors de l'exécution des smart contracts. Cela peut grandement améliorer la vitesse d'exécution du code [il est encore à l'étape théorique et n'a pas encore été implémenté].

Modèle de contrat intelligent Starknet : logique du code de décapage et stockage de l'état

Contrairement aux chaînes compatibles avec Ethereum, Starknet a fait des innovations révolutionnaires dans la conception de son système de smart contract, principalement en préparation pour l'AA native et les prochaines fonctionnalités telles que le traitement des transactions parallèles. Il est important de comprendre qu'à la différence des chaînes publiques traditionnelles comme Ethereum, le déploiement de smart contract sur Starknet suit un processus différent. Prenons l'exemple du déploiement d'un smart contract Ethereum :

1. Les développeurs écrivent localement le code du contrat intelligent et compilent le programme Solidity en bytecode EVM à l'aide d'un éditeur. Ce bytecode peut ensuite être compris et traité directement par l'EVM.

1. Le développeur lance une transaction pour déployer le contrat intelligent, déployant le bytecode EVM compilé sur la chaîne Ethereum.

Source : not-satoshi.com

Bien que les smart contracts de Starknet suivent également l'idée de "compiler d'abord et déployer ensuite", les smart contracts sont déployés sur la chaîne sous forme de bytecode CASM pris en charge par CairoVM. Cependant, il existe d'énormes différences entre Starknet et les chaînes compatibles avec l'EVM en ce qui concerne la méthode d'appel et le mode de stockage d'état des smart contracts. En fait, le smart contract Ethereum = logique métier + informations d'état. Par exemple, le contrat USDT met en œuvre non seulement des fonctions communes telles que Transfert et Approbation, mais stocke également l'état des actifs de tous les détenteurs de USDT. Le code et l'état sont couplés ensemble, ce qui pose beaucoup de problèmes. Tout d'abord, cela n'est pas propice à la mise à niveau des contrats DAPP et à la migration d'état, ni propice au traitement parallèle des transactions. C'est un lourd fardeau technique.

En réponse à cela, Starknet a amélioré la façon dont l'état est stocké. Dans sa solution de mise en œuvre de contrat intelligent, la logique métier des DApps est complètement dissociée des états des actifs et stockée séparément. Les avantages de cette approche sont évidents : premièrement, elle permet au système de distinguer rapidement s'il existe des déploiements de code dupliqués ou redondants. Voici comment cela fonctionne : dans Ethereum, un contrat intelligent comprend à la fois la logique métier et les données d'état. Si plusieurs contrats ont une logique métier identique mais des données d'état différentes, leurs hachages seront également différents, ce qui rend difficile pour le système de déterminer si des "contrats indésirables" existent. Cependant, dans la solution de Starknet, le code et les données d'état sont séparés, ce qui facilite la détection par le système de la duplication du déploiement du même code en se basant sur le hachage de la partie code. Cela aide à prévenir le déploiement de code dupliqué et à économiser de l'espace de stockage sur les nœuds de Starknet.

Dans le système de contrat intelligent de Starknet, le déploiement et l'utilisation des contrats sont divisés en trois étapes : "compiler, déclarer et déployer". Si un émetteur d'actifs souhaite déployer un contrat Cairo, il compile d'abord le code Cairo écrit en formes de bytecode Sierra et CASM de niveau inférieur sur son appareil local. Ensuite, le déployeur de contrat publie une transaction de "déclaration", déployant le bytecode CASM du contrat et le code intermédiaire Sierra sur la chaîne, nommé comme la Classe de Contrat.

(Source: site officiel de Starknet)

Plus tard, si vous souhaitez utiliser les fonctionnalités définies dans le contrat d'actif, vous pouvez initier une transaction de "déploiement" via l'interface utilisateur DApp pour déployer une instance de contrat associée à la classe de contrat. Cette instance contiendra l'état de l'actif. Ensuite, les utilisateurs peuvent appeler les fonctions de la classe de contrat pour modifier l'état de l'instance de contrat. En fait, toute personne familière avec la programmation orientée objet devrait facilement comprendre ce que représentent la classe et l'instance dans Starknet. La classe de contrat déclarée par les développeurs ne contient que la logique métier du contrat intelligent, comprenant des fonctions que tout le monde peut appeler, mais elle n'a pas d'état d'actif réel, ne mettant donc pas directement en œuvre des "entités d'actif", n'ayant que l'"âme" sans le "corps". Cependant, lorsque les utilisateurs déploient des instances de contrat spécifiques, les actifs sont "matérialisés". Si vous avez besoin de modifier l'état de l'"entité" d'actif, comme transférer vos jetons à quelqu'un d'autre, vous pouvez appeler directement les fonctions écrites dans la classe de contrat. Le processus ci-dessus est quelque peu similaire à "l'instanciation" dans les langages de programmation orientée objet traditionnels (bien que pas entièrement identique).

Après que les contrats intelligents sont séparés en classes et en instances, la logique métier et les données d'état sont découplées, apportant les fonctionnalités suivantes à Starknet :

1. Propice à la réalisation du stockage en niveaux et du "système de location de stockage"

La soi-disant stratification du stockage signifie que les développeurs peuvent placer des données dans des emplacements personnalisés selon leurs besoins, tels que sous la chaîne Starknet. StarkNet est prêt à être compatible avec des couches DA telles que Celestia, et les développeurs d'application peuvent stocker des données dans ces couches DA tierces. Par exemple, un jeu peut stocker ses données d'actifs les plus importants sur le mainnet de Starknet, et stocker d'autres données dans des couches DA hors chaîne telles que Celestia. Cette solution de personnalisation de la couche DA selon les exigences de sécurité a été nommée « Volition » par Starknet.

Le système de location de stockage soi-disant signifie que tout le monde devrait continuer à payer pour l'espace de stockage qu'ils occupent. Autant d'espace sur la chaîne que vous occupez, vous devriez théoriquement continuer à payer un loyer.

Dans le modèle de contrat intelligent Ethereum, la propriété du contrat est incertaine, et il est difficile de distinguer si le déployeur ou le détenteur de l'actif devrait payer un «loyer» pour un contrat ERC-20. La fonction de location de stockage n'a pas été lancée depuis longtemps, et le déployeur n'est facturé qu'une fois le contrat déployé. Ce modèle de frais de stockage est déraisonnable.

Sous les modèles de contrats intelligents de Starknet, Sui, CKB et Solana, la propriété des contrats intelligents est plus clairement divisée, ce qui rend plus facile la collecte de fonds de stockage [Actuellement, Starknet ne lance pas directement un système de location de stockage, mais il sera mis en œuvre à l'avenir]

1. Réalisez une véritable réutilisation de code et réduisez le déploiement de contrats inutiles

Nous pouvons déclarer un contrat de jeton général à stocker sur la chaîne sous forme de classe, puis tout le monde peut appeler les fonctions de cette classe pour déployer leurs instances de jeton. De plus, le contrat peut également appeler directement le code de la classe, ce qui permet d'obtenir un effet similaire à la fonction de bibliothèque dans Solidity. En même temps, le modèle de contrat intelligent de Starknet aide à identifier les « contrats indésirables ». Cela a été expliqué précédemment. Après avoir pris en charge la réutilisation du code et la détection des contrats indésirables, Starknet peut réduire considérablement la quantité de données téléchargées sur la chaîne et réduire au minimum la pression de stockage sur les nœuds.

1. Réutilisation de l'état du contrat réel

Les mises à niveau de contrat sur la blockchain impliquent principalement des changements de logique métier. Dans le scénario Starknet, la logique métier des smart contracts est intrinsèquement séparée de l'état des actifs. Si l'instance de contrat modifie la classe de type de contrat associée, la mise à niveau de la logique métier peut être complétée. Il n'est pas nécessaire de migrer l'état des actifs vers un nouvel endroit. Cette forme de mise à niveau de contrat est plus approfondie et native que celle d'Ethereum.

Pour modifier la logique commerciale d'un contrat Ethereum, il est souvent nécessaire de "externaliser" la logique commerciale vers un contrat d'agence, et de modifier la logique commerciale du contrat principal en modifiant le contrat d'agence dépendant. Cependant, cette méthode n'est pas assez concise et n'est pas "native".

Source: Académie wtf

Dans certains scénarios, si l'ancien contrat Ethereum est complètement abandonné, le statut de l'actif à l'intérieur ne peut pas être directement migré vers le nouvel endroit, ce qui est très problématique; le contrat du Caire n'a pas besoin de migrer le statut et peut directement "réutiliser" l'ancien statut.

1. Propice au traitement parallèle des transactions

Pour maximiser la parallélisme des différentes instructions de trading, une étape nécessaire consiste à stocker l'état des actifs de différentes personnes dans des emplacements séparés, comme on peut le voir dans Bitcoin, CKB et Sui. Le préalable à l'atteinte de cet objectif est de séparer la logique commerciale des smart contracts des données d'état des actifs. Bien que Starknet n'ait pas encore réalisé de mise en œuvre technique approfondie des transactions parallèles, il considérera les transactions parallèles comme un objectif important à l'avenir.

Le déploiement du contrat AA natif de Starknet et du contrat de compte

En fait, le concept d'abstraction de compte (AA) et de comptes détenus par des tiers (EOA) a été inventé par la communauté Ethereum comme un concept unique. Dans de nombreuses nouvelles chaînes publiques, il n'y a pas de distinction entre les comptes EOA et les comptes de contrats intelligents, évitant les écueils du système de compte de style Ethereum dès le départ. Par exemple, dans le cadre d'Ethereum, le contrôleur du compte EOA doit avoir de l'ETH sur la chaîne avant de pouvoir initier une transaction. Il n'y a aucun moyen de choisir directement une variété de méthodes d'authentification, et il est extrêmement fastidieux d'ajouter une logique de paiement personnalisée. Certaines personnes pensent même que la conception des comptes d'Ethereum est simplement anti-humaine.

Si l'on regarde les produits phares tels que Starknet ou zkSyncEra "Native AA" chain, on peut clairement observer des différences : tout d'abord, Starknet et zkSyncEra ont des types de compte unifiés. Il n'y a que des comptes de contrat intelligent sur la chaîne. Il n'y a pas de compte EOA dès le départ. (zkSync Era déploiera un ensemble de codes de contrat par défaut sur le compte nouvellement créé de l'utilisateur pour simuler les caractéristiques du compte EOA Ethereum, afin qu'il soit compatible avec Metamask).

Cependant, Starknet ne prend pas directement en compte la compatibilité avec les périphériques Ethereum tels que Metamask. Lorsque les utilisateurs utilisent le portefeuille Starknet pour la première fois, un compte de contrat dédié est automatiquement déployé. En d'autres termes, l'instance de contrat précédemment mentionnée est déployée, et cette instance est associée à la classe de contrat déployée à l'avance par le projet de portefeuille. Les utilisateurs peuvent directement appeler certaines des fonctionnalités écrites dans la classe. Maintenant, plongeons dans un sujet intéressant : lors de la réclamation des largages STRK, de nombreuses personnes ont constaté que les portefeuilles Argent et Braavos n'étaient pas compatibles entre eux. L'importation du mnémonique d'Argent vers Braavos n'a pas permis d'exporter le compte correspondant, principalement en raison des différents algorithmes de génération de compte utilisés par Argent et Braavos, entraînant la génération d'adresses de compte différentes à partir du même mnémonique. Plus précisément, dans Starknet, l'adresse de contrat nouvellement déployée peut être dérivée à travers un algorithme déterministe, comme suit :

La fonction 'pedersen()' mentionnée ci-dessus est un algorithme de hachage facile à utiliser dans les systèmes ZK. Le processus de génération du compte implique de fournir plusieurs paramètres spéciaux à la fonction pedersen pour générer le hachage correspondant, qui est l'adresse du compte généré. L'image ci-dessus montre les paramètres utilisés par Starknet pour générer la « nouvelle adresse de contrat ». L'adresse du 'deployer' représente l'adresse du 'déployeur de contrat'. Ce paramètre peut être vide, ce qui signifie que même si vous n'avez pas de compte de contrat Starknet à l'avance, vous pouvez quand même déployer un nouveau contrat. Le 'sel' est la valeur de sel utilisée pour calculer l'adresse du contrat, qui est essentiellement un nombre aléatoire introduit pour éviter les adresses de contrat en double. Le 'class_hash' correspond à la valeur de hachage de la classe mentionnée précédemment, à laquelle l'instance de contrat est associée. Le 'constructor_calldata_hash' représente le hachage des paramètres d'initialisation du contrat.

Basé sur la formule ci-dessus, les utilisateurs peuvent calculer l'adresse du contrat généré avant de déployer le contrat sur la chaîne. Starknet permet aux utilisateurs de déployer des contrats directement sans avoir de compte Starknet à l'avance, comme suit :

1. Les utilisateurs déterminent d'abord l'instance de contrat qu'ils souhaitent déployer et la classe de contrat à associer, en utilisant le hachage de la classe comme l'un des paramètres d'initialisation, et calculent le sel pour déterminer l'adresse de contrat générée.
2. Après avoir su où ils déploieront le contrat, les utilisateurs transfèrent d'abord une certaine quantité d'ETH à cette adresse en tant que frais de déploiement du contrat. Généralement, cet ETH doit être transféré de L1 au réseau Starknet via un pont inter-chaîne.
3. Les utilisateurs initient la demande de transaction pour le déploiement du contrat.

En fait, tous les comptes Starknet sont déployés via le processus ci-dessus, mais la plupart des portefeuilles masquent les détails, et les utilisateurs ne perçoivent pas le processus comme le déploiement de leur compte de contrat dès qu'ils transfèrent de l'ETH.

La solution ci-dessus a entraîné quelques problèmes de compatibilité, car lorsque différents portefeuilles génèrent des adresses de compte, les résultats générés sont incohérents. Seuls les portefeuilles répondant aux conditions suivantes peuvent être mélangés :

1. La clé privée dérivée de la clé publique utilisée par le portefeuille est la même que l'algorithme de signature;
2. Le processus de calcul du sel du portefeuille est le même;
3. Les classes de contrat intelligent du portefeuille ne sont pas fondamentalement différentes dans les détails de mise en œuvre; \

Dans le cas mentionné précédemment, Argent et Braavos ont tous deux utilisé l'algorithme de signature ECDSA, mais les méthodes de calcul du sel étaient différentes entre les deux, ce qui a entraîné la génération d'adresses de compte incohérentes à partir du même mnémonique.

Maintenant, revenons sur le sujet de l'abstraction de compte. Starknet et zkSync Era ont déplacé une série de processus impliqués dans le traitement des transactions, tels que la vérification de l'identité (vérification des signatures numériques) et le paiement des frais de gaz, en dehors de la "couche de chaîne." Les utilisateurs peuvent personnaliser les détails de mise en œuvre de la logique ci-dessus dans leurs propres comptes. Par exemple, vous pouvez déployer une fonction de vérification de signature numérique dédiée dans votre compte de contrat intelligent Starknet. Lorsqu'un nœud Starknet reçoit une transaction initiée par vous, il appellera une série de logiques de traitement de transactions personnalisées par vous sur la chaîne.

Cette approche offre clairement plus de flexibilité. Dans la conception d'Ethereum, cependant, la logique telle que la vérification d'identité (signatures numériques) est codée en dur dans le code client du nœud et ne peut pas prendre en charge nativement des fonctionnalités de compte personnalisables.

Schéma de principe de la solution AA native spécifiée par l'architecte de Starknet. La vérification de la transaction et la vérification de la qualification des frais de gaz sont transférées au contrat on-chain pour traitement. La machine virtuelle sous-jacente de la chaîne peut appeler ces fonctions personnalisées ou spécifiées par l'utilisateur.

Selon les responsables de zkSyncEra et Starknet, cette approche modulaire de la fonctionnalité des comptes est inspirée de l'EIP-4337. Cependant, ce qui les distingue, c'est que zkSync et Starknet ont fusionné les types de comptes dès le départ, unifié les types de transactions et utilisé un seul point d'entrée pour recevoir et traiter toutes les transactions. En revanche, Ethereum, en raison du fardeau historique et du désir de la fondation d'éviter autant que possible les stratégies d'itération agressives telles que les hard forks, a soutenu l'EIP-4337 en utilisant une manière différente de résoudre le problème. Cependant, le résultat est que les comptes EOA et les solutions EIP-4337 ont chacun des flux de traitement des transactions indépendants, ce qui semble maladroit et encombrant, contrairement à l'agilité des AAs natifs.

Source: ArgentWallet

Cependant, l'abstraction de compte native dans Starknet n'a pas encore atteint sa pleine maturité. D'un point de vue pratique, bien que les comptes AA de Starknet aient implémenté des algorithmes de vérification de signature personnalisés, ils ne prennent actuellement en charge que le paiement des frais de gaz en ETH et STRK, et ne prennent pas encore en charge le paiement des frais de gaz par des tiers. Par conséquent, les progrès de Starknet dans les AA natifs peuvent être décrits comme "le cadre théorique est principalement mature, tandis que la mise en œuvre pratique est encore en cours". Étant donné que Starknet ne dispose que de comptes de contrats intelligents en interne, l'ensemble du processus de ses transactions tient compte de l'influence des contrats intelligents de compte. Tout d'abord, après qu'une transaction est reçue par le Mempool (pool de mémoire) du nœud Starknet, elle subit une vérification, qui comprend :

1. Vérification si la signature numérique de la transaction est correcte, à quel moment la fonction de vérification personnalisée du compte du signataire est appelée;
2. Vérification si le solde du compte de l'initiateur peut couvrir les frais de gaz. \

Il convient de noter ici que l'utilisation de la fonction de vérification de signature personnalisée dans le contrat intelligent de compte signifie qu'il existe un scénario d'attaque. En effet, le pool de mémoire ne facture pas de frais de gaz lors de la vérification de la signature des nouvelles transactions. (Si des frais de gaz étaient facturés directement, des scénarios d'attaque plus graves se produiraient). Les utilisateurs malveillants peuvent d'abord personnaliser une fonction de vérification de signature super complexe dans leur contrat de compte, puis initier un grand nombre de transactions. Lorsque ces transactions sont vérifiées, elles appelleront la fonction de vérification de signature complexe personnalisée, ce qui peut épuiser directement les ressources informatiques du nœud. Afin d'éviter cette situation, StarkNet impose les restrictions suivantes aux transactions:

1. Il y a une limite supérieure sur le nombre de transactions qu'un seul utilisateur peut initier dans une unité de temps;
2. La fonction de vérification de signature personnalisée dans le contrat de compte Starknet a des limitations de complexité, et les fonctions de vérification de signature excessivement complexes ne seront pas exécutées. Starknet limite la limite de consommation de gaz de la fonction de vérification de signature. Si la quantité de gaz consommée par la fonction de vérification de signature est trop élevée, la transaction sera directement rejetée. En même temps, la fonction de vérification de signature dans le contrat de compte n'est pas autorisée à appeler d'autres contrats.

Le diagramme de flux des transactions Starknet est le suivant :

Il convient de noter que, pour accélérer davantage le processus de vérification des transactions, le client de nœud Starknet a directement implémenté les algorithmes de vérification de signature des portefeuilles Braavos et Argent. Lorsqu’un nœud détecte des transactions générées à partir de ces deux principaux portefeuilles Starknet, il appelle les algorithmes de signature Braavos/Argent intégrés dans le client. Grâce à cette approche de type mise en cache, Starknet peut raccourcir le temps de vérification des transactions. Une fois que les données de transaction sont validées par le séquenceur (les étapes de vérification du séquenceur sont beaucoup plus approfondies que celles du pool de mémoire), le séquenceur empaquette et soumet les transactions du pool de mémoire au générateur de preuves ZK. Les transactions entrant dans cette étape se verront facturer des frais de gaz même en cas d’échec. Cependant, si les lecteurs sont familiers avec l’histoire de Starknet, ils remarqueront que les versions antérieures de Starknet ne facturaient pas de frais pour les transactions échouées. Le scénario le plus courant d’échec de transaction est lorsqu’un utilisateur ne dispose que de 1 ETH mais tente de transférer 10 ETH en externe, ce qui indique clairement une erreur logique et échouera inévitablement, mais personne ne connaît le résultat avant l’exécution. Cependant, dans le passé, StarkNet ne facturait pas de frais pour de telles transactions échouées. Ces transactions erronées gratuites gaspillent les ressources de calcul du nœud Starknet et peuvent conduire à des scénarios d’attaque DDoS. À première vue, facturer des frais pour les transactions erronées semble simple, mais en réalité, c’est assez complexe. Starknet a introduit une nouvelle version du langage Cairo1 en grande partie pour résoudre le problème des frais de gaz pour les transactions échouées. Comme nous le savons tous, une preuve ZK est une preuve de validité, et le résultat d’une transaction ayant échoué n’est pas valide et ne peut pas laisser de résultat de sortie sur la chaîne. Tenter d’utiliser une preuve de validité pour prouver qu’une certaine exécution d’instruction n’est pas valide et ne peut pas produire de résultats de sortie semble étrange et est en fait irréalisable. Par conséquent, dans le passé, Starknet excluait les transactions ayant échoué qui ne pouvaient pas produire de résultats de sortie lors de la génération de preuves. L’équipe de Starknet a ensuite adopté une solution plus intelligente et a créé un nouveau langage contractuel, Cairo1, qui garantit que « toutes les instructions de transaction peuvent produire des résultats de sortie et être sur la chaîne ». À première vue, le fait que toutes les transactions puissent produire des résultats de sortie signifie que les erreurs logiques ne se produisent jamais. Cependant, la plupart du temps, les transactions échouent parce qu’elles rencontrent des bogues qui interrompent l’exécution des instructions. Il est difficile de s’assurer que les transactions n’interrompent jamais et produisent avec succès des résultats de sortie, mais il existe en fait une solution alternative simple, qui consiste à permettre aux transactions de produire des résultats de sortie lorsqu’elles rencontrent des erreurs logiques qui entraînent des interruptions, bien qu’elles renvoient une valeur False indiquant que l’exécution de la transaction n’a pas été fluide. Il est important de noter que le renvoi d’une valeur False renvoie également un résultat de sortie, ce qui signifie que dans Cairo1, qu’une instruction rencontre une erreur logique ou soit temporairement interrompue, elle peut produire des résultats de sortie et être sur la chaîne. Ce résultat de sortie peut être correct ou un message d’erreur Faux. Par exemple, considérez l’extrait de code suivant :

À ce stade, _balances::read(from) - amount peut provoquer une erreur de débordement, ce qui entraîne l'interruption de l'instruction de transaction correspondante et son arrêt sans laisser de résultat de transaction sur la chaîne. Cependant, s'il est réécrit sous la forme suivante, il renvoie quand même un résultat de sortie en cas d'échec de la transaction, le laissant sur la chaîne. Purement d'un point de vue esthétique, il semble que toutes les transactions peuvent laisser en douceur des sorties de transaction sur la chaîne, rendant la collecte uniforme des frais particulièrement raisonnable.

Aperçu du contrat StarknetAA

Étant donné que certains lecteurs de cet article peuvent avoir des antécédents en programmation, voici une brève démonstration de l'interface du contrat abstrait de compte dans Starknet:

Le valider_déclarerl'interface mentionnée ci-dessus est utilisée pour valider les transactions de déclaration initiées par les utilisateurs, tandis que validerest utilisé pour la validation générale des transactions, vérifiant principalement la correction de la signature de l'utilisateur. D'autre part, exécuter est utilisé pour l'exécution des transactions. Il est à noter que les comptes de contrat Starknet prennent en charge intrinsèquement le multicall, permettant ainsi de réaliser plusieurs appels. La fonctionnalité multicall peut faciliter diverses fonctionnalités intéressantes, telles que regrouper les trois transactions suivantes lors de l'interaction avec certains protocoles DeFi :

1. Autorisation des jetons au contrat DeFi lors de la première transaction.
2. Déclenchement de la logique du contrat DeFi lors de la deuxième transaction.
3. Révocation de l'autorisation du contrat DeFi dans la troisième transaction.

Bien sûr, en raison de l'atomicité de multicall, il y a des cas d'utilisation plus complexes, tels que l'exécution de transactions d'arbitrage.

Résumé

Les principales caractéristiques technologiques de Starknet incluent le langage Cairo optimisé pour la génération de preuves ZK, l'abstraction de compte au niveau natif et le modèle de contrat intelligent qui sépare la logique métier du stockage d'état.

Cairo est un langage ZK polyvalent qui peut être utilisé pour les contrats intelligents sur Starknet ainsi que pour le développement d'applications plus traditionnelles. Son processus de compilation introduit Sierra comme langage intermédiaire, permettant à Cairo d'itérer fréquemment sans changer le bytecode sous-jacent, ne propageant que les changements au langage intermédiaire. La bibliothèque standard de Cairo inclut également de nombreuses structures de données de base nécessaires pour l'abstraction de compte.

Les contrats intelligents de Starknet séparent la logique métier du stockage des données d'état, contrairement aux chaînes EVM. Le déploiement du contrat Cairo implique trois étapes : compilation, déclaration et déploiement. La logique métier est déclarée dans les classes de contrat, et les instances de contrat contenant des données d'état peuvent être associées à une classe et appeler le code qu'elle contient.

Le modèle de smart contract de Starknet facilite la réutilisation du code, la réutilisation de l'état du contrat, le stockage en couches et la détection des contrats poubelles. Il facilite également la mise en œuvre de la location de stockage et la parallélisation des transactions, bien que ces fonctionnalités n'aient pas encore été entièrement mises en œuvre. L'architecture des smart contracts de Cairo crée les conditions nécessaires à ces fonctionnalités.

Starknet ne possède que des comptes de contrat intelligent, sans comptes EOA, et prend en charge l'abstraction de compte AA au niveau natif dès le début. Sa solution AA absorbe partiellement les idées de l'ERC-4337, permettant aux utilisateurs de choisir des solutions de traitement de transaction hautement personnalisées. Pour prévenir les scénarios d'attaque potentiels, Starknet a mis en œuvre diverses contre-mesures, effectuant des explorations importantes pour l'écosystème AA.

Avertissement：

1. Cet article est reproduit à partir de [Geek Web3]. *Transmettre le titre original 'Interprétation du modèle de contrat intelligent Starknet et de l'AA natif : le génie technique solitaire'. Tous les droits d'auteur appartiennent à l'auteur original [Shew & Faust]. En cas d'objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en matière d'investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.