Initialement publié en anglais par StarkWare le 5 octobre, 2021.

Introduction : Mechanisme de frais

• StarkNet Alpha 0.8.0 présente la version initiale du mécanisme de frais (optionnel jusqu’à StarkNet Alpha 0.9.0)

• Une nouvelle API appelle à estimer les frais de transaction pour obtenir la trace de la transaction, permettant une meilleure visibilité et des capacités de débuggage

• Amélioration des performances du séquenceur StarkNet

• Annulation du message L1→L2

Comme indiqué dans notre roadmap, suite aux dernières fonctionnalités ajoutées sur StarkNet, notre attention se tourne vers l’amélioration des performances et la conception des protocoles (y compris les frais, l’abstraction de compte, la décentralisation, etc…) StarkNet Alpha 0.8.0 démarre le processus d’ajout de frais de transaction et d’amélioration des performances du séquenceur.

La roadmap pour StarkNet comprend un mécanisme de frais, et en progressant avec cette version, nous faisons un pas important vers la pleine performance de la plateforme.

L’ajout du mécanisme de frais est un élément essentiel dans la conception de la performance by design de StarkNet. Sans frais minimaux, nous risquons d’être confrontés à des transactions infinies : ce qui rendrait impossible la performance du système, quelles que soient les optimisations du séquenceur.

StarkNet Alpha prend désormais en charge la première version du mécanisme de frais. Ce mécanisme est essentiel, même à ce stade précoce, et même sur Testnet, pour deux raisons principales :

1. Il permet aux développeurs de commencer à optimiser leurs contrats selon le modèle de coûts de StarkNet.

2. C’est une contrepartie essentielle à l’amélioration des performances du système, car elle empêche le spamming en envoyant d’innombrables transactions.

Cette version présente les éléments nécessaires pour que les développeurs intègrent le paiement des frais dans leurs outils et applications. Les développeurs peuvent désormais estimer les frais de transaction en appelant ’estimate_fee' et effectuer le paiement des frais dans le cadre de l’exécution de la transaction.

Comme cette fonctionnalité n’est pas rétrocompatible, nous n’appliquerons pas le paiement de la taxe à ce stade, mais seulement à partir de la version 0.9.0, qui devrait sortir dans quelques semaines. Cette transition progressive permettra aux utilisateurs et aux développeurs de s’adapter au nouveau modèle.

Sur la version 0.8.0, les frais seront perçus en fonction de la complexité de calcul seulement, tandis que StarkWare continuera à subventionner les coûts de communication de L1. Au cours des prochaines semaines, nous mettrons à jour le mécanisme de frais afin d’y inclure les coûts d’exploitation et de communication de L1. Le paiement sera perçu atomiquement lors de l’exécution de la transaction sur StarkNet L2. Voir la documentation sur les frais pour une description détaillée.

Il est important de noter que nous travaillerons en étroite collaboration avec la communauté des développeurs pour peaufiner et développer le mécanisme de frais au fur et à mesure de l’évolution de StarkNet.

Nous avons lancé le Faucet L2 Goerli ETH pour permettre aux utilisateurs de payer des frais sur Testnet. Ce Faucet envoie de petites quantités d’ETH L2 Goerli à votre adresse sur StarkNet Goerli que vous pouvez utiliser pour payer les frais de transaction.

Nous avons ajouté la possibilité de récupérer la trace d’exécution d’une transaction vers l’API de StarkNet. Dans la trace de la transaction, tous les appels internes sont visibles, accompagnés d’informations telles que les ressources d’exécution consommées, la valeur de retour, les événements émis et les messages envoyés. Ce nouvel appel simplifie la compréhension du comportement d’un contrat ou des transactions de debuggage. De plus, des outils tels que Voyager ou StarkTx pourraient intégrer ces données et fournir aux utilisateurs une analyse plus détaillée, en particulier pour l’interaction des contrats de compte.

Pour obtenir la trace, vous pouvez utiliser ’get_transaction_trace' dans le CLI de StarkNet. Pour voir un exemple de comment l’utiliser, consultez le tutoriel.

Une fonctionnalité supplémentaire de cette version est la possibilité d’annuler les messages L1→L2. Pourquoi est-ce utile ? Imaginez un scénario où un utilisateur transfère un actif de L1 à L2. Le flux commence lorsque l’utilisateur envoie l’actif sur un bridge StarkNet et génère le message L1→L2 correspondant. Maintenant, imaginez que la consommation de messages L2 ne fonctionne pas (cela pourrait se produire à cause d’un bug dans le contrat Cairo de dApps). L’utilisateur pourrait ainsi perdre la possession de son actif pour toujours.

Afin d’atténuer ce risque, nous autorisons le contrat qui a initié le message L1→L2 à l’annuler après avoir déclaré son intention de le faire et attendu un délai raisonnable (voir la documentation).

Cette version réduit significativement le temps nécessaire à un séquenceur pour exécuter un flux de transactions Cairo entrantes.

Ce n’est que la première étape ! Notre prochaine étape majeure en matière de performances, qui sera introduite prochainement (0.9.0), est l’exécution parallèle du séquenceur, et beaucoup d’autres optimisations sont attendues plus tard.

Lisez la documentation technique ici.

Allez sur starknet.io, pour toutes les informations StarkNet, la documentation, les tutoriels et les mises à jour.

Rejoignez le Discord de Starknet pour le support de développement, les annonces concernant l’écosystème, et faire partie de la communauté.

Visitez “StarkNet Shamans” pour rester informé et participer à toutes les discussions de recherche StarkNet.

Traduction faite par @Theyozz

Initialement publié en anglais par StarkWare le 5 octobre, 2021.

Introduction : Mechanisme de frais

• StarkNet Alpha 0.8.0 présente la version initiale du mécanisme de frais (optionnel jusqu’à StarkNet Alpha 0.9.0)

• Une nouvelle API appelle à estimer les frais de transaction pour obtenir la trace de la transaction, permettant une meilleure visibilité et des capacités de débuggage

• Amélioration des performances du séquenceur StarkNet

• Annulation du message L1→L2

Comme indiqué dans notre roadmap, suite aux dernières fonctionnalités ajoutées sur StarkNet, notre attention se tourne vers l’amélioration des performances et la conception des protocoles (y compris les frais, l’abstraction de compte, la décentralisation, etc…) StarkNet Alpha 0.8.0 démarre le processus d’ajout de frais de transaction et d’amélioration des performances du séquenceur.

La roadmap pour StarkNet comprend un mécanisme de frais, et en progressant avec cette version, nous faisons un pas important vers la pleine performance de la plateforme.

L’ajout du mécanisme de frais est un élément essentiel dans la conception de la performance by design de StarkNet. Sans frais minimaux, nous risquons d’être confrontés à des transactions infinies : ce qui rendrait impossible la performance du système, quelles que soient les optimisations du séquenceur.

StarkNet Alpha prend désormais en charge la première version du mécanisme de frais. Ce mécanisme est essentiel, même à ce stade précoce, et même sur Testnet, pour deux raisons principales :

1. Il permet aux développeurs de commencer à optimiser leurs contrats selon le modèle de coûts de StarkNet.

2. C’est une contrepartie essentielle à l’amélioration des performances du système, car elle empêche le spamming en envoyant d’innombrables transactions.

Cette version présente les éléments nécessaires pour que les développeurs intègrent le paiement des frais dans leurs outils et applications. Les développeurs peuvent désormais estimer les frais de transaction en appelant ’estimate_fee' et effectuer le paiement des frais dans le cadre de l’exécution de la transaction.

Comme cette fonctionnalité n’est pas rétrocompatible, nous n’appliquerons pas le paiement de la taxe à ce stade, mais seulement à partir de la version 0.9.0, qui devrait sortir dans quelques semaines. Cette transition progressive permettra aux utilisateurs et aux développeurs de s’adapter au nouveau modèle.

Sur la version 0.8.0, les frais seront perçus en fonction de la complexité de calcul seulement, tandis que StarkWare continuera à subventionner les coûts de communication de L1. Au cours des prochaines semaines, nous mettrons à jour le mécanisme de frais afin d’y inclure les coûts d’exploitation et de communication de L1. Le paiement sera perçu atomiquement lors de l’exécution de la transaction sur StarkNet L2. Voir la documentation sur les frais pour une description détaillée.

Il est important de noter que nous travaillerons en étroite collaboration avec la communauté des développeurs pour peaufiner et développer le mécanisme de frais au fur et à mesure de l’évolution de StarkNet.

Nous avons lancé le Faucet L2 Goerli ETH pour permettre aux utilisateurs de payer des frais sur Testnet. Ce Faucet envoie de petites quantités d’ETH L2 Goerli à votre adresse sur StarkNet Goerli que vous pouvez utiliser pour payer les frais de transaction.

Nous avons ajouté la possibilité de récupérer la trace d’exécution d’une transaction vers l’API de StarkNet. Dans la trace de la transaction, tous les appels internes sont visibles, accompagnés d’informations telles que les ressources d’exécution consommées, la valeur de retour, les événements émis et les messages envoyés. Ce nouvel appel simplifie la compréhension du comportement d’un contrat ou des transactions de debuggage. De plus, des outils tels que Voyager ou StarkTx pourraient intégrer ces données et fournir aux utilisateurs une analyse plus détaillée, en particulier pour l’interaction des contrats de compte.

Pour obtenir la trace, vous pouvez utiliser ’get_transaction_trace' dans le CLI de StarkNet. Pour voir un exemple de comment l’utiliser, consultez le tutoriel.

Une fonctionnalité supplémentaire de cette version est la possibilité d’annuler les messages L1→L2. Pourquoi est-ce utile ? Imaginez un scénario où un utilisateur transfère un actif de L1 à L2. Le flux commence lorsque l’utilisateur envoie l’actif sur un bridge StarkNet et génère le message L1→L2 correspondant. Maintenant, imaginez que la consommation de messages L2 ne fonctionne pas (cela pourrait se produire à cause d’un bug dans le contrat Cairo de dApps). L’utilisateur pourrait ainsi perdre la possession de son actif pour toujours.

Afin d’atténuer ce risque, nous autorisons le contrat qui a initié le message L1→L2 à l’annuler après avoir déclaré son intention de le faire et attendu un délai raisonnable (voir la documentation).

Cette version réduit significativement le temps nécessaire à un séquenceur pour exécuter un flux de transactions Cairo entrantes.

Ce n’est que la première étape ! Notre prochaine étape majeure en matière de performances, qui sera introduite prochainement (0.9.0), est l’exécution parallèle du séquenceur, et beaucoup d’autres optimisations sont attendues plus tard.

Lisez la documentation technique ici.

Allez sur starknet.io, pour toutes les informations StarkNet, la documentation, les tutoriels et les mises à jour.

Rejoignez le Discord de Starknet pour le support de développement, les annonces concernant l’écosystème, et faire partie de la communauté.

Visitez “StarkNet Shamans” pour rester informé et participer à toutes les discussions de recherche StarkNet.

Traduction faite par @Theyozz