Initialement publié en anglais par StarkWare le 6 juin, 2022

• Les frais sont désormais obligatoires sur Testnet, bientôt sur Mainnet

• Configuration de Contract est maintenant possible !

• StarkNet introduit des classes de contrat

• Delegate call est remplacé par l’appel de la bibliothèque (library call)

Nous sommes heureux de vous présenter StarkNet Alpha 0.9.0 ! Il s’agit d’une version importante dans laquelle StarkNet fait des progrès significatifs vers la maturité, avec des ajouts substantiels à la fois aux fonctionnalités et à la conception du protocole.

Les frais sont obligatoires (actuellement seulement sur Testnet, jusqu’à ce que la version 0.9.0 soit disponible sur Mainnet) – tout L2 prospère doit avoir son propre système de frais indépendant. Après l’introduction des frais comme une fonctionnalité optionnelle dans la version 0.8.0, nous sommes maintenant confiants de les inclure comme un élément central du protocole, et de les rendre obligatoires. Plus de détails ci-dessous.

Un autre changement important au niveau du protocole est l’introduction des classes de contrat et de la séparation des classes et des instances. Cela permet une utilisation plus simple de la fonctionnalité ’delegate_call' et des déploiements à partir de contrats existants, permettant ainsi la configuration factory sur StarkNet.

En nous inspirant de la programmation orientée objet, nous distinguons le code de contrat son implémentation. Nous le faisons en séparant les contrats en classes et en instances.

Une classe de contrat est la définition du contrat : son bytecode Cairo, des informations d’indices, des noms de points d’entrée, et tout ce qui est nécessaire pour définir sans ambiguïté sa sémantique. Chaque classe est identifiée par son hash de classe (analogue à un nom de classe des langages OOP).

Une instance de contrat, ou simplement un contrat, est un contrat déployé correspondant à une classe donnée. Notez que seules les instances de contrat se comportent comme des contrats, c’est-à-dire qu’elles ont leurs propre stockage et peuvent faire l’objet d’un appel dans le cadre de transactions ou avec d’autres contrats. Une classe de contrat n’a pas nécessairement d’instance déployée dans StarkNet. L’introduction des classes s’accompagne de plusieurs changements de protocole.

Nous introduisons un nouveau type de transaction à StarkNet : la transaction ‘déclare’, qui permet de déclarer une classe de contrat. Contrairement à la transaction ’deploy', elle ne déploie pas une instance de cette classe. L’état de StarkNet inclura une liste des classes déclarées. De nouvelles classes peuvent être ajoutées via la nouvelle transaction ’declare'.

Une fois qu’une classe est déclarée, c’est-à-dire que la transaction ’declare' correspondante a été acceptée, nous pouvons déployer de nouvelles instances de cette classe. Pour cela, nous utilisons le nouveau call système ’deploy', qui prend les arguments suivants :

• Le hachage de la classe

• Salt

• Arguments du constructeur

Le call system ‘deploy’ déploiera alors une nouvelle instance de cette classe de contrat, dont l’adresse sera déterminée par les trois paramètres ci-dessus et l’adresse de déploiement (le contrat qui a invoqué l’appel système).

Inclure les déploiements dans une transaction invoke nous permet de fixer des prix et de facturer des frais pour les déploiements, sans avoir à traiter les déploiements et les invocations différemment. Pour plus d’informations sur les frais de déploiement, consultez les docs.

Cette fonctionnalité introduit les factory de contrat dans StarkNet, car tout contrat peut invoquer call system ’deploy', créant ainsi de nouveaux contrats.

L’introduction de classes nous permet de résoudre un problème bien connu dans le mécanisme delegate call d’Ethereum : lorsqu’un contrat effectue un delegate call vers un autre contrat, il n’a besoin que de sa classe (son code) et non d’une instance réelle (son stockage). Avoir à spécifier une instance de contrat spécifique lors d’un delegate call est donc une mauvaise pratique (en effet, cela a conduit à quelques bugs dans les contrats Ethereum) – seule la classe doit être spécifiée.

L’ancien system call ’delegate_call' devient obsolète (les anciens contrats déjà déployés continueront à fonctionner, mais les contrats utilisant ’delegate_call' ne seront plus compilés), et est remplacé par un nouveeau system call library_call qui obtient le hachage de classe (d’une classe précédemment déclarée) au lieu d’une adresse d’instance de contrat. Notez qu’un seul contrat est impliqué dans un call de library, donc nous évitons l’ambiguïté entre le contrat appelant et le contrat d’implémentation.

Nous avons ajouté deux nouveaux endpoints à l’API, permettant la récupération des données liées aux classes:

• ’get_class_by_hash' : renvoie la définition de classe donnée par le hash de classe

• ’get_class_hash_at' : retourne le hachage de classe d’un contrat déployé et donne l’adresse du contrat

Notez que pour obtenir directement la classe d’un contrat déployé, au lieu de passer par les deux méthodes ci-dessus, vous pouvez utiliser l’ancien endpoint ’get_full_contract', qui sera renommé dans les versions futures. Tous les endpoints mentionnés ci-dessus sont également utilisables à partir du CLI de StarkNet.

Nous procédons à l’incorporation des fees dans StarkNet, les rendant obligatoires (d’abord sur Testnet, puis aussi sur Mainnet) pour les transactions ’invoke'. La transaction ‘déclare’ ne nécessitera pas de fees à ce stade. De même, les transactions de déploiement ne nécessiteront pas non plus de fees, mais notez que ce type de transaction sera probablement obsolète dans les versions futures.

Plusieurs questions restent en suspens dans ce domaine, les plus importantes étant la facturation des fees pour les déclarations de contrat et le déploiement des comptes StarkNet. Nous aborderons ces questions dans les prochaines versions.

Quelle est la suite ?

Conformément à la roadmap que nous avons annoncée en février, nous nous engageons à améliorer les performances de StarkNet en général, et celles du séquenceur en particulier, afin d’obtenir des feedback plus rapides des utilisateurs sur leurs transactions. Dans la prochaine version, nous prévoyons d’introduire la parallélisation dans le séquenceur, ce qui permettra une production plus rapide des blocs.

La prochaine version majeure de StarkNet se concentrera sur la structure des comptes de StarkNet, d’une manière similaire à ERC-4337. Avec cela, nous aurons finalisé la façon dont les comptes StarkNet se comportent, franchissant une nouvelle étape importante vers l’adoption massive !

Traduction faite par @cleminso

Initialement publié en anglais par StarkWare le 6 juin, 2022

• Les frais sont désormais obligatoires sur Testnet, bientôt sur Mainnet

• Configuration de Contract est maintenant possible !

• StarkNet introduit des classes de contrat

• Delegate call est remplacé par l’appel de la bibliothèque (library call)

Nous sommes heureux de vous présenter StarkNet Alpha 0.9.0 ! Il s’agit d’une version importante dans laquelle StarkNet fait des progrès significatifs vers la maturité, avec des ajouts substantiels à la fois aux fonctionnalités et à la conception du protocole.

Les frais sont obligatoires (actuellement seulement sur Testnet, jusqu’à ce que la version 0.9.0 soit disponible sur Mainnet) – tout L2 prospère doit avoir son propre système de frais indépendant. Après l’introduction des frais comme une fonctionnalité optionnelle dans la version 0.8.0, nous sommes maintenant confiants de les inclure comme un élément central du protocole, et de les rendre obligatoires. Plus de détails ci-dessous.

Un autre changement important au niveau du protocole est l’introduction des classes de contrat et de la séparation des classes et des instances. Cela permet une utilisation plus simple de la fonctionnalité ’delegate_call' et des déploiements à partir de contrats existants, permettant ainsi la configuration factory sur StarkNet.

En nous inspirant de la programmation orientée objet, nous distinguons le code de contrat son implémentation. Nous le faisons en séparant les contrats en classes et en instances.

Une classe de contrat est la définition du contrat : son bytecode Cairo, des informations d’indices, des noms de points d’entrée, et tout ce qui est nécessaire pour définir sans ambiguïté sa sémantique. Chaque classe est identifiée par son hash de classe (analogue à un nom de classe des langages OOP).

Une instance de contrat, ou simplement un contrat, est un contrat déployé correspondant à une classe donnée. Notez que seules les instances de contrat se comportent comme des contrats, c’est-à-dire qu’elles ont leurs propre stockage et peuvent faire l’objet d’un appel dans le cadre de transactions ou avec d’autres contrats. Une classe de contrat n’a pas nécessairement d’instance déployée dans StarkNet. L’introduction des classes s’accompagne de plusieurs changements de protocole.

Nous introduisons un nouveau type de transaction à StarkNet : la transaction ‘déclare’, qui permet de déclarer une classe de contrat. Contrairement à la transaction ’deploy', elle ne déploie pas une instance de cette classe. L’état de StarkNet inclura une liste des classes déclarées. De nouvelles classes peuvent être ajoutées via la nouvelle transaction ’declare'.

Une fois qu’une classe est déclarée, c’est-à-dire que la transaction ’declare' correspondante a été acceptée, nous pouvons déployer de nouvelles instances de cette classe. Pour cela, nous utilisons le nouveau call système ’deploy', qui prend les arguments suivants :

• Le hachage de la classe

• Salt

• Arguments du constructeur

Le call system ‘deploy’ déploiera alors une nouvelle instance de cette classe de contrat, dont l’adresse sera déterminée par les trois paramètres ci-dessus et l’adresse de déploiement (le contrat qui a invoqué l’appel système).

Inclure les déploiements dans une transaction invoke nous permet de fixer des prix et de facturer des frais pour les déploiements, sans avoir à traiter les déploiements et les invocations différemment. Pour plus d’informations sur les frais de déploiement, consultez les docs.

Cette fonctionnalité introduit les factory de contrat dans StarkNet, car tout contrat peut invoquer call system ’deploy', créant ainsi de nouveaux contrats.

L’introduction de classes nous permet de résoudre un problème bien connu dans le mécanisme delegate call d’Ethereum : lorsqu’un contrat effectue un delegate call vers un autre contrat, il n’a besoin que de sa classe (son code) et non d’une instance réelle (son stockage). Avoir à spécifier une instance de contrat spécifique lors d’un delegate call est donc une mauvaise pratique (en effet, cela a conduit à quelques bugs dans les contrats Ethereum) – seule la classe doit être spécifiée.

L’ancien system call ’delegate_call' devient obsolète (les anciens contrats déjà déployés continueront à fonctionner, mais les contrats utilisant ’delegate_call' ne seront plus compilés), et est remplacé par un nouveeau system call library_call qui obtient le hachage de classe (d’une classe précédemment déclarée) au lieu d’une adresse d’instance de contrat. Notez qu’un seul contrat est impliqué dans un call de library, donc nous évitons l’ambiguïté entre le contrat appelant et le contrat d’implémentation.

Nous avons ajouté deux nouveaux endpoints à l’API, permettant la récupération des données liées aux classes:

• ’get_class_by_hash' : renvoie la définition de classe donnée par le hash de classe

• ’get_class_hash_at' : retourne le hachage de classe d’un contrat déployé et donne l’adresse du contrat

Notez que pour obtenir directement la classe d’un contrat déployé, au lieu de passer par les deux méthodes ci-dessus, vous pouvez utiliser l’ancien endpoint ’get_full_contract', qui sera renommé dans les versions futures. Tous les endpoints mentionnés ci-dessus sont également utilisables à partir du CLI de StarkNet.

Nous procédons à l’incorporation des fees dans StarkNet, les rendant obligatoires (d’abord sur Testnet, puis aussi sur Mainnet) pour les transactions ’invoke'. La transaction ‘déclare’ ne nécessitera pas de fees à ce stade. De même, les transactions de déploiement ne nécessiteront pas non plus de fees, mais notez que ce type de transaction sera probablement obsolète dans les versions futures.

Plusieurs questions restent en suspens dans ce domaine, les plus importantes étant la facturation des fees pour les déclarations de contrat et le déploiement des comptes StarkNet. Nous aborderons ces questions dans les prochaines versions.

Quelle est la suite ?

Conformément à la roadmap que nous avons annoncée en février, nous nous engageons à améliorer les performances de StarkNet en général, et celles du séquenceur en particulier, afin d’obtenir des feedback plus rapides des utilisateurs sur leurs transactions. Dans la prochaine version, nous prévoyons d’introduire la parallélisation dans le séquenceur, ce qui permettra une production plus rapide des blocs.

La prochaine version majeure de StarkNet se concentrera sur la structure des comptes de StarkNet, d’une manière similaire à ERC-4337. Avec cela, nous aurons finalisé la façon dont les comptes StarkNet se comportent, franchissant une nouvelle étape importante vers l’adoption massive !

Traduction faite par @cleminso