Les développeurs de Neo Core finalisent l'étendue de v3.9, avancent les tests et le travail de conception de CryptoLib

Source : CryptoNewsNet Titre original : Les développeurs de Neo Core finalisent la portée de v3.9, avancent les tests et le travail de conception de CryptoLib Lien original : https://cryptonews.net/news/blockchain/32063611/ Lors du dernier appel du Core de Neo, les développeurs ont avancé les tests pour les modifications des frais d'exécution et de la liste blanche, affiné les plans pour le support BLS compatible avec Ethereum dans le contrat natif CryptoLib, et évalué un nouveau mécanisme de gouvernance pour gérer les fonds bloqués. La réunion a également exploré des options pour garantir que les candidats validateurs exploitent de vrais nœuds, y compris des conceptions basées sur le staking et le slashing.

S'assurer que les candidats validateurs exploitent de vrais nœuds

Les développeurs ont commencé par une discussion sur la manière de prouver que les candidats au Conseil opèrent des nœuds fonctionnels, une exigence sur la voie de l'aplanissement des récompenses GAS. Deux grandes approches sont à l'étude : un schéma léger de preuve de travail pour les candidats, et un modèle de staking et de slashing dans lequel les candidats verrouillent des NEO et peuvent être pénalisés s'ils échouent aux contrôles de vivacité dans un délai imparti.

Parce que les nœuds de consensus exposent déjà la vivacité via le comportement de changement de vue, les nouveaux mécanismes sont destinés à la vérification des candidats. D'autres détails de conception seront affinés dans l'issue correspondante.

Progrès vers Neo v3.9.0

Les développeurs ont convenu que la branche v3.9.0 est presque terminée. Une proposition d'inclure le support de la signature de messages arbitraires, porté de Flamingo, a été discutée. Étant donné que la fonctionnalité dépend d'une demande de tirage supplémentaire et d'une spécification claire pour les sémantiques des messages signés, elle pourrait être programmée pour une version ultérieure si la documentation n'est pas finalisée à temps.

Un élément, NEP-25, ne sera pas expédié dans la version v3.9.0. Des changements prévus dans la norme devraient retarder le développement d'un à deux mois, donc les contributeurs ont convenu de le reporter pour éviter de retarder la sortie.

Test des changements fusionnés : frais d'exécution et liste blanche

Les changements de facteur de frais d'exécution et le support de transaction gratuite basé sur la liste blanche ont déjà été intégrés pour la v3.9.0. Un problème dédié définira une liste de contrôle de test pour ces fonctionnalités avant que les binaires finaux ne soient publiés.

Une revue plus large de plusieurs contributeurs a été encouragée, en particulier pour les demandes de tirage qui touchent au comportement au niveau du protocole. L'intention est de réduire le risque de comportements divergents entre les explorateurs, les portefeuilles et les implémentations de nœuds alternatives une fois la mise à jour déployée.

Repenser le support BLS compatible Ethereum dans CryptoLib

Les développeurs ont également examiné la proposition d'ajouter des alias compatibles avec Ethereum pour BLS12-381 dans le contrat natif CryptoLib.

Deux préoccupations principales ont été identifiées. Les nouvelles méthodes fonctionnent sur des tableaux d'octets, tandis que les fonctionnalités existantes de CryptoLib exposent des points BLS par le biais d'interfaces d'interopérabilité avec des aides à la sérialisation dédiées. La sérialisation et la désérialisation répétées pour chaque opération sont inefficaces et non conformes à la conception actuelle de l'API.

La direction préférée est d'aligner le support BLS compatible avec Ethereum avec le style d'interface établi en ajoutant des méthodes de sérialisation pour le format Ethereum tout en exécutant des opérations sur les représentations des points BLS internes. La compatibilité avec le format de sérialisation d'Ethereum est la principale exigence, pas une surface API miroir. Les détails d'implémentation seront affinés à la fois dans le nœud C# et neo-go pour garantir un comportement cohérent.

Outil de gouvernance pour les fonds bloqués

Le groupe a également examiné un changement de gouvernance qui permettrait au Conseil Neo de déplacer des fonds hors des comptes bloqués après une période définie, nécessitant 19 des 21 signatures.

Le mécanisme est destiné aux cas où des fonds sont gelés dans des portefeuilles malveillants ou compromis. Il n'est pas destiné à récupérer des actifs pour les utilisateurs qui ont perdu leurs clés privées et ne peuvent pas prouver leur propriété.

Un vote déterminera la période de blocage par défaut, avec des options telles que six mois, un an ou deux ans. Une fois finalisée, la fonctionnalité devrait fournir un processus plus clair pour gérer les adresses sanctionnées.