ARK Core v2: mise à jour des avancées

Depuis notre dernier message, l’équipe ARK a développé, testé et optimisé la version v2 et nous souhaitons vous informer de notre statut actuel.

Les progrès ont été remarquables et de nombreux changements ont eu lieu au cours des deux dernières semaines. Nous allons également passer en revue certains des défis auxquels nous sommes toujours confrontés.

Statistiques

Au cours des 2 dernières semaines (du 24 juillet au 7 août), 11 développeurs ont effectué 102 validations dans le référentiel Core.

Progrès & Plan

Après la décision d’abandonner la compatibilité descendante avec v1, les tests ont immédiatement commencé sur la v2. Au départ, nous avons essayé d’utiliser les anciens paramètres de la genèse v1 pour obtenir rapidement une configuration pré-générée et observer comment certains des nœuds v1 encore actifs interagiraient avec v2. Certains nœuds v2 ajoutaient effectivement des nœuds homologues v1 à la liste, ce qui ne devrait pas se produire. Suite à cela, une nouvelle fonctionnalité a été implémentée « Peer Common Blocks » qui analyse les blocs d’autres peers et reconnaît automatiquement si un pair est valide (sur la bonne chaîne) ou non. Par exemple, l’homologue A a l’identifiant de bloc XYZ, puis vérifie l’homologue B pour l’ID de bloc XYZ. Si le pair B l’a, il le téléchargera à partir de ce peer. Sinon, le peer est suspendu.

La deuxième étape consistait à démarrer la v2 à partir de zéro, avec un nouveau bloc de genèse et une nouvelle configuration (new nethash) pour tester si les choses sont correctement générées lors du démarrage d’un nouveau réseau. C‘est donc devenu notre nouveau v2 DevNet principal, actuellement en cours d’exécution, qui est constamment testé et amélioré.

Compatibilité avec le portefeuille de bureau

Depuis la dernière mise à jour, nous avons travaillé à rendre le portefeuille de bureau actuel compatible avec les modifications apportées par le nouveau cœur. Tout sur Core a été fait “from scratch”, ce qui signifie également qu’une nouvelle version de l’API v2 est née. Cela apporte de nouvelles fonctionnalités et de meilleures pratiques pour l’écriture d’API, ainsi que la documentation de l’API.

Comme le portefeuille de bureau dépend du client JavaScript, une partie a été réécrite pour assurer la compatibilité. Ce nouveau portefeuille de bureau a été testé et tous les types de transactions fonctionnent bien sur la nouvelle version de v2 DevNet.

Le nouveau portefeuille sera publié simultanément en tant que DevNet public. Si vous souhaitez participer aux tests, vous devrez mettre à jour et enregistrer un délégué. Vous pourrez toujours utiliser votre délégué sur MainNet où il n’y aura aucun changement.

Défis

Il y a encore des bugs à régler avant d’ouvrir v2 au public (bien que techniquement cela soit déjà disponible). Un problème majeur à résoudre est celui de la gestion des pools de transactions. Bien que les choses se passent correctement pour un utilisateur normal (envoi, vote, révocation, enregistrement d’un délégué, enregistrement de la deuxième phrase secrète), le pool de transactions ne peut pas suivre si vous spammez le pool de transactions par lots de quelques centaines de transactions. Il commence les transactions en double dans le pool, provoquant une réaction en chaîne à mesure que de nouvelles transactions entrent, la majorité n’étant pas confirmée. Par exemple, l’envoi de 100 transactions en une seule demande dupliquera la demande et ne confirmera qu’une fraction des transactions.

Le deuxième problème concerne les problèmes liés à la propagation par les peers. Lors du démarrage de Core, il semble que la collection de peers associés au réseau ne soit pas complète, ce qui a un impact négatif sur le réseau lui-même et bloque la diffusion.

Enfin, un problème mineur, la productivité et l’approbation d’un délégué ne sont pas correctement calculés dans certains cas en raison de la taille maximale d’entier de JavaScript. Ce sera corrigé en implémentant BigNumber.JS pour toutes les opérations numériques.

Correction de bugs dans les 14 derniers jours

• Supprimez les vérifications inutiles pour les transactions valides dans un tableau supposé vide.
• Condition des nouveaux peers pour accepter les peers autres que «moi-même».
• Fixez l’API P2P avant de démarrer le moniteur pour pouvoir être pingé par les peers.
• Correction de diverses erreurs dans la protection des transactions.
• Créer un bloc de génèse de test unitaire uniquement après la configuration.
• Ignorer les adresses IPv6 locales lors de la recherche de réseaux via le client API.
• Télécharger la vérification de la taille sur des peers aléatoires.
• État du gestionnaire du portefeuille de la pool et problèmes mineurs.
• Obtenir l’identifiant de bloc des données.
• Ajouter les blocs ronds en cours avant d’appliquer le tour.
• Appliquez les blocs manqués au portefeuille dans SPV.
• Mark porte-monnaie sale quand il manque des blocs.
• Déplacement de la logique de requête pour séquencer la connexion.
• Balance non confirmée changée pour équilibrer dans le modèle, et résoudre le problème avec la valeur étant indéfinie.
• Le transfert de données et le vote du commandant dans le CLI du testeur ont été corrigés.

Nouvelles fonctionnalités et améliorations dans les 14 derniers jours

• Ajout de la limitation à l’API P2P à la demande pour éviter les DDOS.
• Une version minimale des peers a été implémentée, ce qui permet de rejeter les homologues qui n’exécutent pas la version minimale spécifiée du cœur. Il existe une option permettant de remplacer cette règle par une liste blanche d’homologues spécifiques dans votre fichier de configuration.
• Ajout d’une option pour répertorier les peers dans le fichier de configuration.
• Implémenter un moyen de trouver de bons pairs via la bibliothèque client JavaScript et de se connecter aux plus sains.
• Vérifiez les blocs communs lors du téléchargement des blocs.
• Stocker les ID de bloc récents.
• Nouvelle méthode pour obtenir des blocs pour un round (*tour).
• Blocs de chargement du round en cours au début.
• Amélioration de la complexité informatique lors de la suppression de transactions falsifiées.
• Ajout du message de consignation pour les blocs manquants ainsi que des pairs suspendus par règle de liste noire ou limite de limitation.
• La logique de traitement des blocs a été réécrite.

Quand pouvons-nous nous attendre à ce que les autres s’impliquent?

Dès que nous aurons résolu le problème du pool de transactions, nous lancerons publiquement le DevNet v2. Cela se produira probablement dans les prochains jours et sera suivi d’un article de blog avec toutes les instructions nécessaires. On prévoit également d’installer V2 sur MainNet dès que possible.

Nous vous remercions sincèrement de votre patience et vous demandons votre compréhension alors que nous franchissons ces quelques derniers obstacles et ouvrons la voie à une nouvelle version stable d’ARK Core v2.

Comment puis-je aider au développement?

Si vous voulez aider, impliquez-vous et gagnez de l’ARK supplémentaire, assurez-vous de lire et d’obtenir un code de lecture sur ARK GitHub Development Bounty :

• Référentiel ARK Core : https://github.com/ArkEcosystem/core
• Problèmes ouverts d’ARK Core: https://github.com/ArkEcosystem/core/issues

Suivez-nous sur les réseaux sociaux ( Twitter | Facebook | Reddit ) et restez à l’écoute de notre blog sur Medium et sur Steemit .

→ https://ark.io/
Article original de BoldNinja —
Traduit (avec le ❤) par Antoine Breuil pour Ark & ARK.io Espace Francophone