StarkNet Regenesis - Le Plan

Initialement publié par StarkWare le 29 septembre, 2022

TL;DR

  • Nous partageons un plan détaillé pour Regenesis, qui a été façonné par de longues discussions avec la communauté StarkNet. Remerciements spéciaux à Kuba@SWM.

  • Regenesis suivra la sortie de Cairo 1.0, rendant le système plus sécurisé en permettant des contrats StarkNet plus simples et plus sûrs

  • Les utilisateurs devraient être prêts à mettre à niveau leur portefeuille pendant la phase de transition.

  • Les développeurs devront porter leurs contrats vers Cairo 1.0

Introduction

StarkNet Alpha progresse vers Regenesis, une étape importante vers la production. Dans cette mise à niveau, nous voulons partager plus de détails sur la principale motivation de Regenesis – Cairo 1.0 et commencer à expliquer ce qu’il exigera aux utilisateurs et aux développeurs. Après Regenesis, StarkNet ne fonctionnera qu’avec les contrats basés sur Cairo 1.0, et commencera à partir d’un nouveau bloc de genèse avec l’état existant.

Qu’est-ce que Regenesis exigera des utilisateurs ? Une simple mise à niveau de leur portefeuille. Qu’exigera-t-il aux constructeurs des dapps de StarkNet ? Porter leurs contrats vers Cairo 1.0, et suivre une simple directive de mise à niveau. Spécifiquement, il n’y aura pas de redémarrage à partir d’un état propre et nous resterons avec la même instance StarkNet, ce qui signifie qu’il n’y aura pas besoin de migration.

Le plan de Regenesis est de préserver complètement l’état des applications et de ne pas subir de temps d’arrêt pour les applications. Ainsi, les applications qui suivent les lignes directrices que nous fournirons pourront être lancées sur StarkNet Alpha Mainnet immédiatement sans perturber leur fonctionnement et leurs utilisateurs pendant le processus de Regenesis. Nous nous engageons à travailler avec la communauté et à fournir tout le soutien nécessaire pour rendre ce processus aussi fluide que possible.

Nous prenons cette orientation à la suite de discussions approfondies avec la communauté, dont une suggestion importante venant de l’équipe de Software Mansion.

Pourquoi Regenesis ?

Cairo 1.0 et Sierra

La principale motivation de Regenesis est de capitaliser sur les nouvelles possibilités offertes par Cairo 1.0 – à savoir la protection DOS des séquenceurs, la résistance à la censure et le comptage du gas, qui sont essentiels pour StarkNet en tant que réseau décentralisé.

Cairo 1.0 veillera à ce que chaque transaction soit prouvée. Cela permettra à StarkNet d’inclure les transactions annulées dans des blocs, et de générer une preuve de leur exécution. Ce mécanisme permettra aux séquenceurs d’être payés sur l’exécution des transactions annulées, augmentant ainsi la protection DOS contre les acteurs malveillants. En outre, Cairo 1.0 prendra en charge les compteurs de gas, ce qui permettra à StarkNet de passer à un marché de tarification plus intuitif. Enfin, cela permettra à StarkNet d’introduire des transactions forcées depuis L1, et renforcera les capacités de résistance à la censure du réseau.

Pour profiter de ces avantages, les contrats Cairo v0 et Cairo 1.0 ne peuvent pas être mélangés. Les déclarations incorrectes ne peuvent pas être prouvées comme étant incorrectes, et le suivi de gas ne peut pas se produire, si nous avons des morceaux de contrats Cairo v0. Pour cela, nous devrons éliminer progressivement le code Cairo v0 de l’état StarkNet, voilà pourquoi Regenesis.

Après Regenesis, nous aurons un système StarkNet entièrement basé sur Cairo 1.0.

Simplifier le Code et le Protocole

StarkNet, alors qu’il était encore en Alpha, a déjà subi de nombreux changements. Chaque version à ce niveau a modifié le système d’exploitation StarkNet, les blocs et la structure des transactions. Cela a rendu une partie du code obsolète. Pourtant, les full nodes et les fournisseurs d’infrastructure (tels que les indexeurs et les explorers d’état) doivent connaître et implémenter tous les comportements passés des versions Alpha de StarkNet afin de synchroniser avec l’état en toute confiance. Sans Regenesis, ce fardeau pourrait être un facteur dissuasif majeur pour les développeurs qui envisageraient de construire de tels services pour StarkNet.

Par conséquent, avant de passer en production, et en prévision d’un monde décentralisé avec de nombreuses implémentations d’outils d’infrastructure, nous avons l’intention de réduire la complexité du protocole. Nous y parviendrions en n’exigeant aucune infrastructure future d’exécuter un code StarkNet 0.x, et en marquant le premier bloc après la période de transition comme point de genèse.

Quand Regenesis ? La chronologie globale

Regenesis suivra la sortie de Cairo 1.0, prévue pour la fin de 2022. Au premier trimestre de 2023, StarkNet sera mis à niveau pour prendre en charge Cairo 1.0, et nous visons à migrer vers un réseau entièrement basé sur Cairo 1.0 d’ici la fin du premier trimestre Q1.

Les utilisateurs et les applications devront effectuer la transition au cours de cette période.

Alors, que dois-je savoir ?

Les développeurs d’applications doivent être conscients des aspects suivants de Regenesis :

  • Assurez-vous que votre contrat est prêt pour la mise à niveau. Tous les détails techniques du plan sont partagés dans le forum communautaire StarkNet. Une fois les détails finalisés, nous partagerons une ligne directrice concise.

  • Assurez-vous que vous êtes prêt à porter votre code vers Cairo 1.0. Voir la section suivante pour tous les détails les plus récents.

Porter votre contrat vers Cairo 1.0

Cairo 1.0 est très prometteur pour les développeurs de StarkNet. Une amélioration par rapport à Cairo existant qui sera plus sûr, meilleur et plus facile pour la rédaction de contrats, avec une meilleure syntaxe, un système complet arrivé à maturité (natif uint256 quelqu’un ?) et plus encore. Les développeurs devront porter leurs contrats StarkNet existants à la syntaxe Cairo 1.0. Cependant, comme la logique et la structure du code resteront les mêmes, cet effort devrait être négligeable par rapport à l’effort qu’il a fallu pour développer l’application au départ.

Dans ce contexte, il est intéressant de noter que vous pouvez choisir de revérifier la version Cairo 1.0 de votre application. Si votre application a déjà fait l’objet d’un audit par le passé, le processus de re-audit sera nettement moins coûteux et plus simple, puisque les auditeurs connaissent déjà votre logique.

Nous publierons toute la documentation autour de Cairo 1.0, ainsi que des tutoriels et des ateliers au cours du quatrième trimestre 2022 (Q4).

Je suis un utilisateur de StarkNet. Que devrais-je faire ?

En tant qu’utilisateur, vous devrez probablement prendre quelques mesures au cours de Regenesis. À tout le moins, vous devrez mettre à niveau votre contrat de compte. Ne pas le faire au cours de la période de transition (quelques mois) entraînera la perte de votre compte. Selon le chemin de mise à niveau choisi par les développeurs des applications StarkNet que vous utilisez, vous devrez peut-être prendre des mesures supplémentaires.

Nous rappelons à tous que StarkNet est toujours en phase Alpha, et que les utilisateurs doivent rester attentifs aux communications de StarkNet et des applications qu’ils utilisent. Il est de votre responsabilité de vous assurer de passer rapidement au nouveau système. Être un adoptant précoce n’est pas toujours facile, et nous comptons sur vous pour faire votre part !

Pour conclure

Cairo 1.0 est juste au coin de la rue, offrant de nombreux avantages et améliorations passionnants pour StarkNet et ses développeurs. Pour les récolter, un événement Regenesis du réseau est nécessaire. Heureusement, nous avons un design en tête qui rend ce processus le moins perturbateur possible, totalement transparent pour les utilisateurs et assez simple pour les applications.

Nous vous invitons à participer à la discussion communautaire et à vous assurer d’exprimer votre opinion et vos préoccupations, ainsi qu’à vous tenir au courant des étapes que vous devrez suivre en tant que développeur d’applications sur StarkNet.

Traduction faite par @cleminso

Subscribe to Starknet France
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.