C’est toujours amusant d’entendre parler de nouvelles subventions au fur et à mesure qu’elles sont accordées, mais que se passe-t-il après l’annonce ? Dans cette série, nous vérifions les projets qui sont bien avancés – ou déjà sur la ligne d’arrivée. Lisez la suite pour en savoir plus sur certains jalons récents et les réalisations des bénéficiaires !
Nimbus pour Client de portail Fluffy et développement du réseau de portails
Nimbus est surtout connu de la plupart des gens en tant que client de la chaîne de balises, remarquable pour ses faibles besoins en ressources avec seulement ~750 Mo de mémoire requis pour exécuter un nœud de consensus complet. Mais en dehors des projecteurs jetés par The Merge, la talentueuse équipe derrière Nimbus (une partie du Organisation du statut) fait beaucoup plus pour rendre la participation au réseau Ethereum accessible à tous, sur n’importe quel appareil. La Réseau portail est une initiative inter-équipes en cours visant à redéfinir la manière dont les appareils à ressources limitées participent au réseau Ethereum, et l’équipe Nimbus a joué un rôle essentiel pour lui donner vie.
Les efforts des clients légers se poursuivent depuis des années et se sont concentrés sur la conception de clients utilisant un minimum de ressources. De nombreux clients proposent désormais une forme de client léger ; Nimbus a récemment ajouté un client léger autonome, qui fournit les informations pour suivre la tête de la chaîne de balises sans nécessiter une synchronisation complète. Cependant, le potentiel des clients légers Ethereum est finalement limité par la conception du réseau lui-même. La réseau client léger actuel s’appuie sur une architecture client/serveur : les clients légers téléchargent les en-têtes de bloc et d’autres données selon les besoins, mais n’apportent rien. Les clients légers s’appuient sur des nœuds complets pour servir les données dont ils ont besoin, mais peu de nœuds complets choisissent de servir ces données, ce qui en fait une ressource limitée et peu fiable.
Reconnaissant que différentes applications nécessitent un accès à différentes données et fonctionnalités, le réseau de portails est conçu pour la flexibilité. Plutôt que de regrouper toutes les fonctionnalités, il combine plusieurs sous-protocoles, chacun étant dédié à une fonction spécifique. Les clients du portail peuvent se connecter à tous les sous-protocoles, ou seulement à un sous-ensemble, selon leurs besoins. Tout aussi important, un appareil exécutant un client de portail peut apporter toutes les ressources dont il dispose (par exemple, stocker une petite quantité d’état ou relayer des messages d’égal à égal). En d’autres termes, chaque client est également un serveur, capable d’accéder aux informations dont il a besoin tout en ajoutant de la capacité au réseau en fonction de ses capacités. Plus de clients en ligne signifie un réseau plus fort, pas une compétition à somme nulle pour des ressources limitées.
L’équipe Nimbus a fait partie intégrante de la conception et du développement du réseau de portails. Ils ont été les premiers à implémenter la plupart des fonctionnalités réseau grâce au développement de Duveteux, une implémentation de Nimbus conçue spécifiquement pour le réseau de portails et l’un des trois clients qui devraient être disponibles lorsque le réseau de portails sera en ligne (deux autres sont en cours de développement par les équipes de la Fondation Ethereum). Fluffy a été le premier client capable à la fois de stocker et de diffuser du contenu et a agi comme l’épine dorsale des réseaux de test initiaux, aidant à informer les modifications nécessaires des spécifications du réseau lorsque des problèmes ont été rencontrés lors de la mise en œuvre.
L’équipe vise à ce que Fluffy soit suffisamment léger pour fonctionner depuis l’intérieur d’un portefeuille, et finalement pour l’intégrer dans le Application mobile d’état. La perspective d’exécuter un client complet à partir d’un portefeuille ou d’une application a d’énormes implications, non seulement pour la santé du réseau, mais également pour la décentralisation et la confidentialité, car elle réduit la dépendance à l’infrastructure centralisée que la plupart des portefeuilles utilisent actuellement pour accéder aux données Ethereum.
Si cette équipe occupée réussit, vous aurez un client Ethereum dans votre poche arrière avant de vous en rendre compte ! Des mises à jour périodiques sur le développement de Fluffy et Portal Network sont publiées sur Hack MD et le Nimbe Blog. Vous pouvez également suivre Nimbus sur Twitter @ethnimbus; Regardez GithubGenericName pour les progrès sur les clients Fluffy et Nimbus (avons-nous mentionné qu’ils travaillent également sur un client d’exécution?), ou connectez-vous avec l’équipe via Discorde, Statut ou Gitter.
Paul Miller pour Ethereum-Cryptographie Améliorations
Ethereum-Cryptographie est l’une des bibliothèques Ethereum les plus utilisées, contenant des primitives cryptographiques essentielles utilisées pour développer des applications Ethereum en JavaScript et TypeScript. C’était lancé en 2020 par Fondation Nomic pour améliorer l’expérience des développeurs Ethereum en regroupant les dépendances de cryptographie spécifiques à Ethereum dans une seule bibliothèque, éliminant ainsi le besoin des dépendances basées sur le nœud-gyp souvent gênantes sur lesquelles les développeurs comptaient auparavant.
Le regroupement de ces outils de cryptographie courants sous un même toit a soulagé de sérieux problèmes pour les développeurs ; mais Paul Miller a vu qu’il était possible de s’améliorer davantage en réduisant à la fois le nombre de dépendances et la taille globale de la base de code. Il n’est pas surprenant que Paul ait été impatient de s’en charger – il a une longue expérience dans la création d’outils pour aider les développeurs à construire plus efficacement et en toute sécurité, y compris Chokidar, un service de surveillance de fichiers multiplateforme ; et noble-secp256k1une implémentation JS de la courbe elliptique secp256k1.
Lorsque Paul a commencé à travailler sur Ethereum-cryptography, le package d’installation était fourni avec 38 dépendances et 3,46 mégaoctets de code source. Tout ce code n’est pas mis en production, mais un utilisateur final d’une dapp construite avec cette bibliothèque téléchargeait encore jusqu’à 793 Ko, soit environ 24 000 lignes de code. Paul a entrepris de construire une bibliothèque plus compacte et sécurisée qui fournirait les mêmes fonctionnalités, en réécrivant de nombreuses implémentations de cryptographie et en soumettant la nouvelle version à un audit formel. Cette refonte a entraîné de sérieux gains d’efficacité et de sécurité :
- Dépendances extérieures réduites de 38 à 5
- Taille du répertoire réduite de 10,2 Mo à 650 Ko
- Code source réduit de 23 799 lignes à 5 225 lignes
- Trafic NPM réduit de 3,6 Mo à 324 Ko non mis en cache
- Audit interprété par Guérir53 et toutes les vulnérabilités traitées
Pour en savoir plus, consultez la v1.0.0 poste de libérationou creuser dans certains des aperçus techniques survenus lors de la reconstruction. Vous pouvez creuser dans Ethereum-cryptographie sur Github ; suivez Nomic Foundation sur Twitter ou consultez leur Blog; et suivez Paul sur Twitter @paulmillr ou son personnel GithubGenericName.
Travaillez-vous sur quelque chose qui, selon vous, pourrait améliorer Ethereum ? Dirigez-vous vers notre site Internet pour en savoir plus sur le programme de soutien aux écosystèmes et demander un soutien.
Source https://blog.ethereum.org/en/2022/06/01/may-22-grantee-roundup