J'ai eu une réunion hier avec un responsable d'équipe d'ingénierie talentueux qui supervisera le développement d'"EchoNet" pour le mois prochain (ou les mois suivants). "EchoNet" est un projet interne. Les utilisateurs de Starknet ne le ressentiront jamais. Le marketing ne le mentionnera pas. Pourtant, cela m'excite énormément. Le sens - il va répercuter toutes les transactions du mainnet vers un environnement de test qui a le nouveau candidat à la version, et détectera automatiquement tout écart d'exécution par rapport au mainnet actuel. Cela mettra en lumière de nombreux cas particuliers qui pourraient causer des divergences avant qu'une version ne soit publiée. EchoNet nous aidera grandement à continuer et à faire évoluer SN avec de belles fonctionnalités, tout en maintenant la stabilité qu'une chaîne mature doit avoir. Avoir un testnet pour des vérifications de bout en bout n'est plus suffisant.

L'équipe a mis à jour aujourd'hui l'environnement d'intégration interne vers 0.14.1. Le Testnet, puis le Mainnet, sont attendus dans quelques semaines. 0.14.1 est un pas de taille moyenne pour Starknet, mais aujourd'hui je me concentre sur le fait qu'il représente un grand changement de mentalité dans le développement de Starknet. Nous avons eu de grands changements disruptifs dans le passé, obligeant les applications à travailler dur pour rester à jour. Mais à mesure que Starknet mûrit et vise à être le meilleur endroit pour construire, cela ne peut pas continuer. 0.14.1 représente cela, et voici pourquoi Avec la sortie de S-Two, certains hachages qui avaient été choisis pour s'adapter à Stone sont devenus relativement coûteux. Ces hachages sont utilisés partout, du hachage des données d'appel aux lectures et écritures. 0.14.1 n'a pas dit : "changeons tous les hachages que nous pouvons pour qu'ils soient les moins chers et forçons tout le monde à s'adapter". Il dit : migrons, prudemment, uniquement les endroits où les développeurs ne sentiront pas et qui sont principalement en coulisses. Coordonnons ensuite avec les SDK pour garantir que les développeurs ne ressentent vraiment rien (tant qu'ils mettent à jour leur SDK de manière assez régulière). En fait, préparons à l'avance une liste de transactions visant uniquement à migrer ces hachages, dans le cadre du processus de mise à niveau, pour garantir que toute tx qui était valide auparavant le restera, sans que personne n'ait besoin de lever le petit doigt. Je ne peux pas garantir qu'il n'y aura jamais un autre changement disruptif dans Starknet. Mais je peux garantir que cet état d'esprit est là pour rester.

Commençons le partage de pensées transparent avec une question et un titre accrocheur. Le titre "STRK burning" semble être un sujet brûlant dont les gens parlent. Si vous en faites partie - avez-vous pris en compte que les frais actuels payés pour le séquençage des transactions ne disparaîtront pas car ils doivent couvrir les coûts d'exécution et de preuve, donc un brûlage significatif de STRK signifie que le réseau est significativement plus coûteux ? En d'autres termes : préféreriez-vous payer X% de plus pour que X% des STRK payés en tant que frais (~50-100K par jour, actuellement) soient brûlés ? Pourquoi ? Partie transparente : En partie à cause de la question ci-dessus, le brûlage de STRK n'est actuellement pas dans le plan de travail de novembre. J'aimerais comprendre le sentiment autour du brûlage avant que nous ne priorisions à nouveau les choses.