Initialement publié en anglais par StarkWare le 7 juillet, 2022

Tout ce que vous devez savoir sur pourquoi et comment cela va se produire.

StarkNet se prépare à l’évènement Regenesis sur Ethereum Mainnet. Cet article présente notre réflexion actuelle sur la forme que cela prendra, ainsi que pourquoi cela est nécessaire et quel sera son impact.

Nous tenons à partager les informations sur la réinitialisation de l'état. Nous visons à ce qu'il ne s'agisse que d'un dérangement mineur pour les utilisateurs, et certainement pas d'un bouleversement majeur.

La clé du développement rapide de l'écosystème a été la sortie de StarkNet Alpha avant que tout ne soit parfait, et une forte utilisation des feedbacks pour résoudre les problèmes et améliorer certaines choses. La réinitialisation de l'état nous permettra d'éliminer tout le code et les flux superflus de StarkNet OS et du protocole. Cela nous permet de nous assurer que le système StarkNet en production est aussi léger et sécurisé que possible.

Ce n'est pas quelque chose dont nous allons faire une habitude, mais plutôt un cas unique, c'est pourquoi nous l'appelons la RFE - la Réinitialisation Finale de l'Etat. Dramatique, n’est-ce pas ? Notre objectif est que cette réinitialisation d'état soit la dernière avant que StarkNet ne sorte de l’Alpha et entre en production. Nous ne savons toujours pas si cela se produira immédiatement après la RFE ou non, mais c'est une condition prérequis pour y parvenir.

Construire StarkNet a été un voyage à haute vitesse que nous avons partagé avec la communauté des développeurs en publiant de nouvelles versions à une cadence mensuelle. Cela n'a jamais eu de sens de viser tout de suite la perfection; la voie que nous avons suivie était clairement de s'améliorer sur la base de retours rapides. Cela correspondait à l'esprit d'une plate-forme tournée vers la décentralisation et la gouvernance communautaire.

C'est pourquoi nous avons choisi de publier StarkNet Alpha sur un testnet public il y a un an et avons continué à développer des fonctionnalités externalisées via des mises à jour fréquentes. Parfois, nous avons choisi une certaine conception, l'avons essayé, puis nous en avons choisi une autre après avoir décidé qu'elle fonctionnait mieux.

Nous ne savions pas avec certitude que c'était la bonne approche, mais nous nous sentons légitimé par la réalité du terrain aujourd'hui. Une communauté de développeurs remarquable, active et passionnée a été intégrée au processus le plus tôt possible et a été profondément impliquée dans la formation du réseau.

Nous avons donc aujourd'hui un StarkNet qui a été façonné avec amour et remodelé en une plateforme extrêmement légère. Enfin, presque.

Il est toujours alourdi par le code et les fonctionnalités obsolètes qui ont servi à un objectif ou à un autre pendant la phase de construction initiale, mais qui maintenant ne sont plus qu'un fardeau. Ainsi, bien que toutes les fonctionnalités dont nous avons besoin prennent une forme très légère, le code porte beaucoup de poids mort.

Le but de la régénération est de faire tomber ce poids superflu - un peu comme au moment où un nouveau bâtiment perd des tonnes d'échafaudages.

En retardant la RFE le plus possible, nous augmentons son impact positif. En effet, cela nous permettra de réduire aussi le poids supplémentaire qui sera généré par les fonctionnalités déjà planifiées ou en cours de développement. Pourtant, nous savons que retarder le RFE retarde la mise en production des applications et crée plus de travail à la fin pour assurer une migration parfaitement fluide. Sur la base de ce compromis, nous pesons encore quelques facteurs pour décider de la meilleure date possible, mais nous envisageons de le faire au quatrième trimestre de 2022. Nous publierons plus de détails dans un prochain article qui parlera des fonctionnalités particulières qui sont encore nécessaires.

L’Alpha de StarkNet actuelle fonctionnera aussi longtemps que nécessaire. En parallèle, nous déploierons une nouvelle version allégée de StarkNet Alpha qui repartira de zéro, avec un nouvel état. Cela signifie que dans la nouvelle instance, tous les contrats et comptes devront être redéployés et les actifs devront être migrés de l'ancien StarkNet Alpha vers le nouveau.

L'impact ne devrait pas être si important, et nous nous efforçons de le minimiser. Néanmoins, certaines actions seront nécessaires :

• Pour les actifs de type ERC-20, nous proposerons des solutions d'interopérabilité qui rendront le processus transparent du point de vue de l'utilisateur.

• Pour les actifs plus complexes tels que les NFT et autres, nous visons à proposer des blocs de construction que les applications pourront utiliser pour fournir une migration transparente à leurs utilisateurs. Par exemple, nous fournirons un outil qui permet de prouver sur le nouveau StarkNet qu'un événement a été émis dans l'ancien StarkNet. Cela permettra de burn des NFT avec des métadonnées dans l'ancien StarkNet pour pouvoir les mint à une adresse spécifique dans le nouveau StarkNet.

Lorsque nous disons que la réinitialisation de l'état est finale, nous disons que nous, en tant que StarkWare, n’en effectuerons pas une autre. Évidemment, nous sommes fiers qu'un processus de décentralisation soit en cours, dont la nature est que nous ne pouvons pas faire de promesses à long terme sur le réseau, qui sera justement entre les mains de la communauté.

La communauté pourra-t-elle mandater une autre réinitialisation après une décentralisation complète ? En théorie, oui, mais à mesure que l'adoption et l'utilisation de StarkNet se développe, la difficulté d'une telle opération augmente et les bénéfices devront être suffisants pour compenser cette difficulté. Nous espérons sincèrement qu'aucune régénération supplémentaire ne sera nécessaire.

Nous ne disons pas cela pour faire douter les développeurs ou les utilisateurs sur le fait que StarkNet restera à la pointe avec des modifications significatives du protocole apportées au fur et à mesure que les besoins se présentent. Les bâtiments subissent de nombreuses rénovations et modifications, mais le déblaiement de la terre déterrée des fondations est un événement unique.

Il en va de même pour StarkNet. Il a atteint l'excellence en tant que chantier de construction désordonné avec un surplus de code éparpillé. Il est temps de faire le rangement d'une vie pour préparer le réseau aux développements futurs.

Comme toujours, nous apprécions vos retours, vos avis sincères et vos mêmes de qualité.

Initialement publié en anglais par StarkWare le 7 juillet, 2022

Tout ce que vous devez savoir sur pourquoi et comment cela va se produire.

StarkNet se prépare à l’évènement Regenesis sur Ethereum Mainnet. Cet article présente notre réflexion actuelle sur la forme que cela prendra, ainsi que pourquoi cela est nécessaire et quel sera son impact.

Nous tenons à partager les informations sur la réinitialisation de l'état. Nous visons à ce qu'il ne s'agisse que d'un dérangement mineur pour les utilisateurs, et certainement pas d'un bouleversement majeur.

La clé du développement rapide de l'écosystème a été la sortie de StarkNet Alpha avant que tout ne soit parfait, et une forte utilisation des feedbacks pour résoudre les problèmes et améliorer certaines choses. La réinitialisation de l'état nous permettra d'éliminer tout le code et les flux superflus de StarkNet OS et du protocole. Cela nous permet de nous assurer que le système StarkNet en production est aussi léger et sécurisé que possible.

Ce n'est pas quelque chose dont nous allons faire une habitude, mais plutôt un cas unique, c'est pourquoi nous l'appelons la RFE - la Réinitialisation Finale de l'Etat. Dramatique, n’est-ce pas ? Notre objectif est que cette réinitialisation d'état soit la dernière avant que StarkNet ne sorte de l’Alpha et entre en production. Nous ne savons toujours pas si cela se produira immédiatement après la RFE ou non, mais c'est une condition prérequis pour y parvenir.

Construire StarkNet a été un voyage à haute vitesse que nous avons partagé avec la communauté des développeurs en publiant de nouvelles versions à une cadence mensuelle. Cela n'a jamais eu de sens de viser tout de suite la perfection; la voie que nous avons suivie était clairement de s'améliorer sur la base de retours rapides. Cela correspondait à l'esprit d'une plate-forme tournée vers la décentralisation et la gouvernance communautaire.

C'est pourquoi nous avons choisi de publier StarkNet Alpha sur un testnet public il y a un an et avons continué à développer des fonctionnalités externalisées via des mises à jour fréquentes. Parfois, nous avons choisi une certaine conception, l'avons essayé, puis nous en avons choisi une autre après avoir décidé qu'elle fonctionnait mieux.

Nous ne savions pas avec certitude que c'était la bonne approche, mais nous nous sentons légitimé par la réalité du terrain aujourd'hui. Une communauté de développeurs remarquable, active et passionnée a été intégrée au processus le plus tôt possible et a été profondément impliquée dans la formation du réseau.

Nous avons donc aujourd'hui un StarkNet qui a été façonné avec amour et remodelé en une plateforme extrêmement légère. Enfin, presque.

Il est toujours alourdi par le code et les fonctionnalités obsolètes qui ont servi à un objectif ou à un autre pendant la phase de construction initiale, mais qui maintenant ne sont plus qu'un fardeau. Ainsi, bien que toutes les fonctionnalités dont nous avons besoin prennent une forme très légère, le code porte beaucoup de poids mort.

Le but de la régénération est de faire tomber ce poids superflu - un peu comme au moment où un nouveau bâtiment perd des tonnes d'échafaudages.

En retardant la RFE le plus possible, nous augmentons son impact positif. En effet, cela nous permettra de réduire aussi le poids supplémentaire qui sera généré par les fonctionnalités déjà planifiées ou en cours de développement. Pourtant, nous savons que retarder le RFE retarde la mise en production des applications et crée plus de travail à la fin pour assurer une migration parfaitement fluide. Sur la base de ce compromis, nous pesons encore quelques facteurs pour décider de la meilleure date possible, mais nous envisageons de le faire au quatrième trimestre de 2022. Nous publierons plus de détails dans un prochain article qui parlera des fonctionnalités particulières qui sont encore nécessaires.

L’Alpha de StarkNet actuelle fonctionnera aussi longtemps que nécessaire. En parallèle, nous déploierons une nouvelle version allégée de StarkNet Alpha qui repartira de zéro, avec un nouvel état. Cela signifie que dans la nouvelle instance, tous les contrats et comptes devront être redéployés et les actifs devront être migrés de l'ancien StarkNet Alpha vers le nouveau.

L'impact ne devrait pas être si important, et nous nous efforçons de le minimiser. Néanmoins, certaines actions seront nécessaires :

• Pour les actifs de type ERC-20, nous proposerons des solutions d'interopérabilité qui rendront le processus transparent du point de vue de l'utilisateur.

• Pour les actifs plus complexes tels que les NFT et autres, nous visons à proposer des blocs de construction que les applications pourront utiliser pour fournir une migration transparente à leurs utilisateurs. Par exemple, nous fournirons un outil qui permet de prouver sur le nouveau StarkNet qu'un événement a été émis dans l'ancien StarkNet. Cela permettra de burn des NFT avec des métadonnées dans l'ancien StarkNet pour pouvoir les mint à une adresse spécifique dans le nouveau StarkNet.

Lorsque nous disons que la réinitialisation de l'état est finale, nous disons que nous, en tant que StarkWare, n’en effectuerons pas une autre. Évidemment, nous sommes fiers qu'un processus de décentralisation soit en cours, dont la nature est que nous ne pouvons pas faire de promesses à long terme sur le réseau, qui sera justement entre les mains de la communauté.

La communauté pourra-t-elle mandater une autre réinitialisation après une décentralisation complète ? En théorie, oui, mais à mesure que l'adoption et l'utilisation de StarkNet se développe, la difficulté d'une telle opération augmente et les bénéfices devront être suffisants pour compenser cette difficulté. Nous espérons sincèrement qu'aucune régénération supplémentaire ne sera nécessaire.

Nous ne disons pas cela pour faire douter les développeurs ou les utilisateurs sur le fait que StarkNet restera à la pointe avec des modifications significatives du protocole apportées au fur et à mesure que les besoins se présentent. Les bâtiments subissent de nombreuses rénovations et modifications, mais le déblaiement de la terre déterrée des fondations est un événement unique.

Il en va de même pour StarkNet. Il a atteint l'excellence en tant que chantier de construction désordonné avec un surplus de code éparpillé. Il est temps de faire le rangement d'une vie pour préparer le réseau aux développements futurs.

Comme toujours, nous apprécions vos retours, vos avis sincères et vos mêmes de qualité.