Initialement publié en anglais par StarkWare le 21 mars, 2023

• Starknet alpha v0.11.0 est maintenant disponible sur le Testnet

• Vous pouvez désormais déployer et interagir avec des contrats Cairo 1.0 sur le Testnet de Starknet !

• Le coût de calcul sur Starknet est réduit de 5 fois !

• Pour la première fois, la mise à jour de Starknet alpha v0.11.0 vers le Mainnet sera soumise à un vote de gouvernance

• Cela marque le début de la période de transition avant Regenesis

• Le déploiement de contrats Cairo 1.0 sur le Mainnet sera activé seulement après quelques semaines d’exécution sur le Testnet, une fois que nous aurons assuré le bon fonctionnement du nouveau système.

Nous sommes heureux d'annoncer que le très attendue Starknet alpha v0.11.0 est disponible sur le Testnet ! Pourquoi est-ce une étape importante pour Starknet ? Dans Starknet v0.11.0, vous pouvez déclarer, déployer et exécuter des contrats intelligents Cairo 1.0. Nous introduisons également un nouvel call système permettant une transition en douceur des contrats existants vers une implémentation Cairo 1.0.

Cairo 1.0 améliore Starknet sur deux aspects différents. Tout d'abord, il améliore l'expérience de développement en offrant un langage de programmation plus riche, introduisant (entre autres) des types/generics/traits/error handling à Cairo.

Deuxièmement, Cairo 1.0 joue un rôle clé dans le parcours de décentralisation de Starknet : les contrats Cairo 1.0 envoyés dans Starknet alpha v0.11.0 sont compilés vers Sierra. Sierra garantit que chaque exécution de contrat est vérifiable, ce qui est une propriété cruciale pour un Starknet décentralisé.

Une autre amélioration importante dans cette version est une réduction de 5 fois du coût de calcul. Cela rendra Starknet encore plus adapté aux applications gourmande en calcul. Plus de détails ci-dessous.

Starknet alpha v0.11.0 marque le début de la période de transition, qui permettra de se préparer à l’évènement Regenesis de Starknet. Le plan de Regenesis de Starknet a été publié il y a quelques mois et vise à passer d'un système basé sur Cairo 0 à un système basé sur Cairo 1.0.

Pendant la période de transition, les contrats existants de Cairo 0 (s'ils sont mis à jour) ont la possibilité de conserver leur adresse et leur stockage, et de passer sans problème à une implémentation en Cairo 1.0 (voir la section suivante).

En tant qu'utilisateur de Starknet, cela signifie que vous n'avez besoin de mettre à jour votre portefeuille qu'une fois que la nouvelle implémentation Cairo 1.0 de votre compte sera disponible (vous pourrez le faire à tout moment jusqu'à l’évènement Regenesis lui-même). Aucune interruption de service n'est prévue, toutes les applications décentralisées du système continueront de fonctionner normalement.

Après l’évènement Regenesis, Starknet cessera de prendre en charge les contrats restants de Cairo 0 dans l'ensemble du système. Cela sera communiqué en avance et les développeurs auront suffisamment de temps pour migrer leurs contrats. La période de transition devrait durer quelques mois, et les développeurs d'applications décentralisées peuvent déjà commencer à migrer leur implémentation vers Cairo 1.0. À la fin de la période de Transition, l’évènement Regenesis aura lieu.

Avec la transition vers Cairo 1.0, les contrats existants de Cairo 0 sont obsolètes et ne seront plus pris en charge après Regenesis. Pour permettre aux contrats de Cairo 0 mis à niveau de continuer à fonctionner, même après Regenesis, et de conserver l'état construit jusqu'à ce moment, nous avons ajouté un nouveau call système : [replace_class](https://docs.starknet.io/documentation/starknet_versions/upcoming_versions/#replace_class_syscall). Les contrats mis à niveau n'ont aucun problème à passer à une implémentation en Cairo 1.0, mais le proxy sous-jacent (le contrat qui détient l'état réel) sera toujours bloqué avec l'implémentation Cairo 0. Le call système replace_class résout ce problème en permettant au contrat proxy de remplacer sa classe sous-jacente, c'est-à-dire de conserver la même adresse et le même stockage, mais de remplacer l'implémentation.

Aujourd'hui, les frais de transaction sur Starknet comportent deux composantes majeurs : le calcul et les données on-chain. L'élément de calcul des frais de transaction Starknet est déterminé par le coût marginal de vérification de sa preuve sur L1 (voir la documentation pour plus de détails).

Initialement, nos 200 millions d’étapes Cairo dans une preuve qui nécessite 5 millions de gas pour la vérification ont conduit à une estimation naïve de 0,05 gaz par étapes Cairo. Depuis lors, nous sommes passés à des preuves récursives qui permettent une réduction significative du coût de vérification L1 (seule la racine d'un arbre de récursion atteint L1). Il est maintenant temps de mettre à jour nos estimations initiales en conséquence : le prix de chaque étape Cairo sur L2 sera réduit de 5 fois, et coûtera désormais 0,01 gaz.

Cette réduction de coût est significative pour les applications gourmande en calcul, par exemple les contrats de compte avec des signatures non natives. Les transactions simples verront une légère réduction des coûts (~ 5 %). Dans les futures versions, nous traiterons le deuxième composant : les coûts des données on-chain. Une fois que des alternatives aux données on-chain seront introduites dans Starknet (alias Volition), la réduction des coûts sera ressentie à tous les niveaux.

La première phase de la gouvernance de Starknet a été lancée (plus de détails ici). Les membres de la communauté peuvent désormais participer à façonner Starknet grâce à un canal supplémentaire, à savoir le vote sur les changements du protocole.

Les premières phases de la gouvernance de Starknet se concentreront sur les mises à jour du protocole Starknet. Chaque mise à jour de version de Starknet sera d'abord déployée sur le Testnet ; les électeurs auront une période de 6 jours pour examiner et tester la version mise à jour car celle-ci fonctionnera sur Goerli. Pendant ce temps, une proposition Snapshot sera ouverte, et la communauté pourra voter pour approuver la nouvelle version en vue de son déploiement sur Mainnet.

Si la proposition obtient une majorité de votes 'YES' pendant la période de vote de 6 jours, la proposition est acceptée et Starknet Mainnet sera mis à jour en conséquence.

Starknet alpha v0.11.0 est la première version de Starknet soumise à un vote. Le vote pour Starknet alpha v0.11.0 sera ouvert pendant six jours à partir du déploiement sur le Testnet.

Liens pertinents :

• Espace Snapshot

• Page de découverte de la délégation

• Thread sur Starknet alpha v0.11.0 sur le forum communautaire

Sierra (Safe Intermediate Representation) est une représentation intermédiaire qui se compile en Cairo assembly (CASM). Avant Starknet alpha v0.11.0, un développeur compilerait Cairo 0 en CASM et enverrait le résultat au séquenceur Starknet. Avec Cairo 1.0, les développeurs compilent leur code vers Sierra et envoient cette représentation intermédiaire au séquenceur. Le séquenceur le compile ensuite en CASM. Sierra est garanti pour compiler en "safe CASM", c'est-à-dire un sous-ensemble de CASM qui ne peut pas échouer, rendant chaque exécution vérifiable. Cela garantit au séquenceur de pouvoir facturer des frais même pour les transactions annulée/échouée, protégeant ainsi contre les attaques DOS. Pour plus d'informations, consultez la documentation.

Starknet alpha 0.11.0 utilisera la version Cairo 1.0-alpha.6. Cette version est proche de la parité des fonctionnalités avec Cairo 0, avec toutes les calls système Starknet déjà présents.

Notez que le séquenceur Starknet utilise une version de compilateur fixe, ce qui signifie que les améliorations du langage ne seront peut-être pas immédiatement disponibles dans Starknet et le seront uniquement après une mise à jour de la version Starknet. Plus précisément, si les améliorations affectant la compilation Cairo 1.0 → Sierra peuvent prendre effet immédiatement, les changements dans le compilateur Sierra → CASM (voir la documentation pour plus de détails) devront attendre une mise à niveau de Starknet.

Nouveau type de transaction - Declare v2

Nous ajoutons un nouveau type de transaction pour déclarer des classes Cairo 1.0. Cette nouvelle version de transaction declare est similaire à la version existante, mais avec deux distinctions importantes :

• L'objet de classe envoyé représente maintenant Sierra plutôt que CASM, c'est-à-dire que la sémantique de la classe est définie par la représentation Sierra.

• L'utilisateur signe également le hachage de la classe compilée. Il s'agit d'une étape cruciale jusqu'à ce que la compilation Sierra → CASM soit prouvée dans le cadre de Starknet OS.

Pour plus de détails, consultez la documentation.

Du point de vue du développeur, l'expérience reste la même. Après avoir écrit votre code Cairo 1.0, vous pouvez utiliser CLI (Command-Line Interface) pour déclarer la classe.

Notez qu'initialement, les transactions declare v2 ne seront pas acceptées sur Starknet Mainnet. Après une période d'expérimentation sur le Testnet, le nouveau type de transaction sera activé sur Mainnet et les classes Cairo 1.0 deviendront disponibles.

Poseidon est là

Poseidon est une famille de fonctions de hachage conçues pour avoir des circuits algébriques très efficaces. En tant que telles, elles peuvent être très utiles dans les systèmes de preuve ZK tels que les STARKs et les SNARKs. À partir de Starknet alpha v0.11.0, les développeurs pourront utiliser Poseidon. De plus, certaines des calculs de hachage qui font partie du protocole Starknet passeront à Poseidon (notamment le hachage de classe, le hachage de classe compilé et certaines parties de l'engagement de l'état utiliseront Poseidon, voir la documentation pour plus de détails). À l'avenir, plus de composants internes passeront à l'utilisation de la fonction de hachage Poseidon.

Vous pouvez trouver la version exacte et les paramètres utilisés dans Starknet ici.

Changements divers

Comme pour les versions précédentes de Starknet, une mise à jour a également des implications pour nos API et autres composants de bas niveau. Nous répertorions ci-dessous ceux-ci et abordons les changements spécifiques qui ont été apportés :

• Les transactions invoke et declare de la version v0 ne sont plus prises en charge.

• Les messages de L1 à L2 nécessitent désormais des frais. Autrement dit, les messages envoyés avec un frais nul ne seront pas traités par le séquenceur Starknet.

• Le format des données on-chain a été modifié.

• Changements d'API (tous les changements ne sont pas répertoriés ici, veuillez vous référer à la documentation pour une liste exhaustive) :

• ajout d'un nouvel endpoint get_compiled_class_by_class_hash

• get_class_by_hash renvoie à la fois les classes Cairo 0 / Cairo 1.0 (en fonction du hachage demandé).

• get_state_update a une nouvelle section pour les classes remplacées, et les déclarations sont divisées entre les classes Cairo 0 et Cairo 1.

• estimate_fee et simulate_tx peuvent maintenant ignorer la validation.

• Une

Maintenant que toute l'infrastructure liée à Cairo 1.0 est en place, vous pouvez vous attendre à :

• De nouvelles améliorations de langage pour Cairo 1.0

• Des améliorations de performance : comme promis, nous continuons à avancer vers une augmentation significative des TPS (transactions par seconde). La prochaine étape de notre feuille de route consiste à passer au séquenceur Rust, qui est développé en open source sous la licence Apache 2.0. Le nouveau séquenceur utilisera le CairoVM en Rust et le nœud complet Papyrus, formant ainsi le Trio de Performance.

• Offchain Data Availability ! Dans cette version, nous avons géré la composante computationnelle des coûts de transactions. Dans les prochaines versions, nous nous occuperons des coûts des données on-chain, qui en moyenne sont aujourd'hui le coût dominant pour les transactions.

Initialement publié en anglais par StarkWare le 21 mars, 2023

• Starknet alpha v0.11.0 est maintenant disponible sur le Testnet

• Vous pouvez désormais déployer et interagir avec des contrats Cairo 1.0 sur le Testnet de Starknet !

• Le coût de calcul sur Starknet est réduit de 5 fois !

• Pour la première fois, la mise à jour de Starknet alpha v0.11.0 vers le Mainnet sera soumise à un vote de gouvernance

• Cela marque le début de la période de transition avant Regenesis

• Le déploiement de contrats Cairo 1.0 sur le Mainnet sera activé seulement après quelques semaines d’exécution sur le Testnet, une fois que nous aurons assuré le bon fonctionnement du nouveau système.

Nous sommes heureux d'annoncer que le très attendue Starknet alpha v0.11.0 est disponible sur le Testnet ! Pourquoi est-ce une étape importante pour Starknet ? Dans Starknet v0.11.0, vous pouvez déclarer, déployer et exécuter des contrats intelligents Cairo 1.0. Nous introduisons également un nouvel call système permettant une transition en douceur des contrats existants vers une implémentation Cairo 1.0.

Cairo 1.0 améliore Starknet sur deux aspects différents. Tout d'abord, il améliore l'expérience de développement en offrant un langage de programmation plus riche, introduisant (entre autres) des types/generics/traits/error handling à Cairo.

Deuxièmement, Cairo 1.0 joue un rôle clé dans le parcours de décentralisation de Starknet : les contrats Cairo 1.0 envoyés dans Starknet alpha v0.11.0 sont compilés vers Sierra. Sierra garantit que chaque exécution de contrat est vérifiable, ce qui est une propriété cruciale pour un Starknet décentralisé.

Une autre amélioration importante dans cette version est une réduction de 5 fois du coût de calcul. Cela rendra Starknet encore plus adapté aux applications gourmande en calcul. Plus de détails ci-dessous.

Starknet alpha v0.11.0 marque le début de la période de transition, qui permettra de se préparer à l’évènement Regenesis de Starknet. Le plan de Regenesis de Starknet a été publié il y a quelques mois et vise à passer d'un système basé sur Cairo 0 à un système basé sur Cairo 1.0.

Pendant la période de transition, les contrats existants de Cairo 0 (s'ils sont mis à jour) ont la possibilité de conserver leur adresse et leur stockage, et de passer sans problème à une implémentation en Cairo 1.0 (voir la section suivante).

En tant qu'utilisateur de Starknet, cela signifie que vous n'avez besoin de mettre à jour votre portefeuille qu'une fois que la nouvelle implémentation Cairo 1.0 de votre compte sera disponible (vous pourrez le faire à tout moment jusqu'à l’évènement Regenesis lui-même). Aucune interruption de service n'est prévue, toutes les applications décentralisées du système continueront de fonctionner normalement.

Après l’évènement Regenesis, Starknet cessera de prendre en charge les contrats restants de Cairo 0 dans l'ensemble du système. Cela sera communiqué en avance et les développeurs auront suffisamment de temps pour migrer leurs contrats. La période de transition devrait durer quelques mois, et les développeurs d'applications décentralisées peuvent déjà commencer à migrer leur implémentation vers Cairo 1.0. À la fin de la période de Transition, l’évènement Regenesis aura lieu.

Avec la transition vers Cairo 1.0, les contrats existants de Cairo 0 sont obsolètes et ne seront plus pris en charge après Regenesis. Pour permettre aux contrats de Cairo 0 mis à niveau de continuer à fonctionner, même après Regenesis, et de conserver l'état construit jusqu'à ce moment, nous avons ajouté un nouveau call système : [replace_class](https://docs.starknet.io/documentation/starknet_versions/upcoming_versions/#replace_class_syscall). Les contrats mis à niveau n'ont aucun problème à passer à une implémentation en Cairo 1.0, mais le proxy sous-jacent (le contrat qui détient l'état réel) sera toujours bloqué avec l'implémentation Cairo 0. Le call système replace_class résout ce problème en permettant au contrat proxy de remplacer sa classe sous-jacente, c'est-à-dire de conserver la même adresse et le même stockage, mais de remplacer l'implémentation.

Aujourd'hui, les frais de transaction sur Starknet comportent deux composantes majeurs : le calcul et les données on-chain. L'élément de calcul des frais de transaction Starknet est déterminé par le coût marginal de vérification de sa preuve sur L1 (voir la documentation pour plus de détails).

Initialement, nos 200 millions d’étapes Cairo dans une preuve qui nécessite 5 millions de gas pour la vérification ont conduit à une estimation naïve de 0,05 gaz par étapes Cairo. Depuis lors, nous sommes passés à des preuves récursives qui permettent une réduction significative du coût de vérification L1 (seule la racine d'un arbre de récursion atteint L1). Il est maintenant temps de mettre à jour nos estimations initiales en conséquence : le prix de chaque étape Cairo sur L2 sera réduit de 5 fois, et coûtera désormais 0,01 gaz.

Cette réduction de coût est significative pour les applications gourmande en calcul, par exemple les contrats de compte avec des signatures non natives. Les transactions simples verront une légère réduction des coûts (~ 5 %). Dans les futures versions, nous traiterons le deuxième composant : les coûts des données on-chain. Une fois que des alternatives aux données on-chain seront introduites dans Starknet (alias Volition), la réduction des coûts sera ressentie à tous les niveaux.

La première phase de la gouvernance de Starknet a été lancée (plus de détails ici). Les membres de la communauté peuvent désormais participer à façonner Starknet grâce à un canal supplémentaire, à savoir le vote sur les changements du protocole.

Les premières phases de la gouvernance de Starknet se concentreront sur les mises à jour du protocole Starknet. Chaque mise à jour de version de Starknet sera d'abord déployée sur le Testnet ; les électeurs auront une période de 6 jours pour examiner et tester la version mise à jour car celle-ci fonctionnera sur Goerli. Pendant ce temps, une proposition Snapshot sera ouverte, et la communauté pourra voter pour approuver la nouvelle version en vue de son déploiement sur Mainnet.

Si la proposition obtient une majorité de votes 'YES' pendant la période de vote de 6 jours, la proposition est acceptée et Starknet Mainnet sera mis à jour en conséquence.

Starknet alpha v0.11.0 est la première version de Starknet soumise à un vote. Le vote pour Starknet alpha v0.11.0 sera ouvert pendant six jours à partir du déploiement sur le Testnet.

Liens pertinents :

• Espace Snapshot

• Page de découverte de la délégation

• Thread sur Starknet alpha v0.11.0 sur le forum communautaire

Sierra (Safe Intermediate Representation) est une représentation intermédiaire qui se compile en Cairo assembly (CASM). Avant Starknet alpha v0.11.0, un développeur compilerait Cairo 0 en CASM et enverrait le résultat au séquenceur Starknet. Avec Cairo 1.0, les développeurs compilent leur code vers Sierra et envoient cette représentation intermédiaire au séquenceur. Le séquenceur le compile ensuite en CASM. Sierra est garanti pour compiler en "safe CASM", c'est-à-dire un sous-ensemble de CASM qui ne peut pas échouer, rendant chaque exécution vérifiable. Cela garantit au séquenceur de pouvoir facturer des frais même pour les transactions annulée/échouée, protégeant ainsi contre les attaques DOS. Pour plus d'informations, consultez la documentation.

Starknet alpha 0.11.0 utilisera la version Cairo 1.0-alpha.6. Cette version est proche de la parité des fonctionnalités avec Cairo 0, avec toutes les calls système Starknet déjà présents.

Notez que le séquenceur Starknet utilise une version de compilateur fixe, ce qui signifie que les améliorations du langage ne seront peut-être pas immédiatement disponibles dans Starknet et le seront uniquement après une mise à jour de la version Starknet. Plus précisément, si les améliorations affectant la compilation Cairo 1.0 → Sierra peuvent prendre effet immédiatement, les changements dans le compilateur Sierra → CASM (voir la documentation pour plus de détails) devront attendre une mise à niveau de Starknet.

Nouveau type de transaction - Declare v2

Nous ajoutons un nouveau type de transaction pour déclarer des classes Cairo 1.0. Cette nouvelle version de transaction declare est similaire à la version existante, mais avec deux distinctions importantes :

• L'objet de classe envoyé représente maintenant Sierra plutôt que CASM, c'est-à-dire que la sémantique de la classe est définie par la représentation Sierra.

• L'utilisateur signe également le hachage de la classe compilée. Il s'agit d'une étape cruciale jusqu'à ce que la compilation Sierra → CASM soit prouvée dans le cadre de Starknet OS.

Pour plus de détails, consultez la documentation.

Du point de vue du développeur, l'expérience reste la même. Après avoir écrit votre code Cairo 1.0, vous pouvez utiliser CLI (Command-Line Interface) pour déclarer la classe.

Notez qu'initialement, les transactions declare v2 ne seront pas acceptées sur Starknet Mainnet. Après une période d'expérimentation sur le Testnet, le nouveau type de transaction sera activé sur Mainnet et les classes Cairo 1.0 deviendront disponibles.

Poseidon est là

Poseidon est une famille de fonctions de hachage conçues pour avoir des circuits algébriques très efficaces. En tant que telles, elles peuvent être très utiles dans les systèmes de preuve ZK tels que les STARKs et les SNARKs. À partir de Starknet alpha v0.11.0, les développeurs pourront utiliser Poseidon. De plus, certaines des calculs de hachage qui font partie du protocole Starknet passeront à Poseidon (notamment le hachage de classe, le hachage de classe compilé et certaines parties de l'engagement de l'état utiliseront Poseidon, voir la documentation pour plus de détails). À l'avenir, plus de composants internes passeront à l'utilisation de la fonction de hachage Poseidon.

Vous pouvez trouver la version exacte et les paramètres utilisés dans Starknet ici.

Changements divers

Comme pour les versions précédentes de Starknet, une mise à jour a également des implications pour nos API et autres composants de bas niveau. Nous répertorions ci-dessous ceux-ci et abordons les changements spécifiques qui ont été apportés :

• Les transactions invoke et declare de la version v0 ne sont plus prises en charge.

• Les messages de L1 à L2 nécessitent désormais des frais. Autrement dit, les messages envoyés avec un frais nul ne seront pas traités par le séquenceur Starknet.

• Le format des données on-chain a été modifié.

• Changements d'API (tous les changements ne sont pas répertoriés ici, veuillez vous référer à la documentation pour une liste exhaustive) :

• ajout d'un nouvel endpoint get_compiled_class_by_class_hash

• get_class_by_hash renvoie à la fois les classes Cairo 0 / Cairo 1.0 (en fonction du hachage demandé).

• get_state_update a une nouvelle section pour les classes remplacées, et les déclarations sont divisées entre les classes Cairo 0 et Cairo 1.

• estimate_fee et simulate_tx peuvent maintenant ignorer la validation.

• Une

Maintenant que toute l'infrastructure liée à Cairo 1.0 est en place, vous pouvez vous attendre à :

• De nouvelles améliorations de langage pour Cairo 1.0

• Des améliorations de performance : comme promis, nous continuons à avancer vers une augmentation significative des TPS (transactions par seconde). La prochaine étape de notre feuille de route consiste à passer au séquenceur Rust, qui est développé en open source sous la licence Apache 2.0. Le nouveau séquenceur utilisera le CairoVM en Rust et le nœud complet Papyrus, formant ainsi le Trio de Performance.

• Offchain Data Availability ! Dans cette version, nous avons géré la composante computationnelle des coûts de transactions. Dans les prochaines versions, nous nous occuperons des coûts des données on-chain, qui en moyenne sont aujourd'hui le coût dominant pour les transactions.