Jette un coup d'œil derrière le voile de développement de la prochaine couche MetaChain : Dans ce billet, nous expliquons le processus de développement et apportons quelques réponses à des questions courantes 👇. Dans le développement de logiciels, les nouvelles versions suivent généralement cette feuille de route : Alpha → Beta → Release Candidate (RC) → Stable Node (nœud stable) Alors que la plupart des projets commencent généralement par une étape alpha, DeFiChain a opté pour une approche différente en passant par une série de phases bêta pour mettre l'accent sur le déploiement de nouvelles fonctionnalités. Qu'est-ce qu'une RC et quel est son calendrier ? Une version admissible désignée par le terme anglais Release Candidate (RC) est conçue pour ressembler aux versions finales d'une version, prête à être déployée sans nécessiter d'autres modifications, tout en permettant une certaine flexibilité pour l'amélioration de tout autre test de logiciel. Comme les échanges et les programmes affiliés nécessitent suffisamment de temps pour les mises à jour, une RC devrait idéalement fonctionner de façon optimale sur une période de 10 à 14 jours. Si une version ne répond pas à ces normes, elle doit rester dans le domaine bêta. Quand y aura-t-il un déploiement de nœuds stables ? Lorsque la stabilité est confirmée, la feuille de route prévoit le lancement de la version candidate avant la publication d'une amélioration du réseau TestNet dans un délai de 2 à 3 jours. Une fois la stabilité confirmée sur l'ensemble des systèmes et services intégrés, DeFiChain passera à la vitesse supérieure et se concentrera sur le lancement du nœud stable, avec en point d'orgue un hard fork après une période d'attente prédéfinie. Quels sont les bloqueurs actuels ? La nature standardisée de l'EVM et de ses intégrations associées signifie qu'ils doivent respecter des directives opérationnelles spécifiques. Cela devient encombrant lorsqu'on tente de le faire coïncider avec des systèmes préexistants, tels que ceux ancrés dans le Bitcoin. Le parcours de couches MetaChain fait écho à ces complexités, l'objectif étant d'assimiler une machine virtuelle raw-space avec DeFiChain. Les obstacles ne manquent pas lorsqu'on tente d'intégrer l'EVM à une blockchain centrée sur l'UTXO. Il s'agit notamment de techniques de génération de hachage variables ou d'altérations de l'état au-delà des transactions typiques. En outre, la machine virtuelle DeFi (DVM) présente un ensemble unique de défis. Bien qu'avoir une base de code immaculée comme point de départ soit idéal, la réalité est que la DVM, dérivée d'une base de code centrée sur Bitcoin, a évolué avec de multiples couches au fil du temps. De plus, la base de code de DeFiChain exploite la puissance de deux langages principaux : C++ et Rust. Bien que Rust se targue d'une sécurité au moment de la compilation pour signaler les erreurs potentielles avant la compilation, l'intégrer à C++ présente des obstacles. Ces défis se répercutent également sur l'"endiannesse" et le stockage des données au niveau du système. Une autre dimension en cours d'évaluation est le "domaine de transfert". Les transactions traditionnelles de la blockchain fonctionnent selon un mécanisme "push", vérifiant la propriété des actifs et les transférant. Cependant, l'architecture rigoureuse de l'EVM ne facilite pas une poussée directe de l'EVM vers la DVM. Une autre méthode "pull" est en cours d'exploration, exigeant de nouvelles façons de prouver la propriété sans exposer les clés privées. D'une manière générale, l'équipe est confrontée à ces principaux défis : 👉 Aborder l'endiannesse et aligner les hachages sur les normes. 👉 Fusionner de façon transparente Rust et C++ sans compromettre la stabilité. 👉 Réussir tous les tests unitaires. 👉 Instituer des transactions "pull" sécurisées. 👉 Développer des explorateurs de blockchain adaptés aux machines virtuelles Ethereum (EVM). Nous espérons que cela offre des éclaircissements sur l'état actuel de la couche MetaChain.