Titres Titres
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 Développement du client Fluffy Portal et 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 de The Merge, la talentueuse équipe derrière Nimbus (une partie de l’organisation Status) fait beaucoup plus pour rendre la participation au réseau Ethereum accessible à tous, sur n’importe quel appareil. Le réseau de portails 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. Le réseau actuel des clients légers repose 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 concurrence à 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 du réseau grâce au développement de Fluffy, 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 Ethereum équipes de la Fondation). 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 à l’intérieur d’un portefeuille, et finalement pour l’intégrer dans l’application mobile Status. 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 HackMD et le blog Nimbus. Vous pouvez également suivre Nimbus sur Twitter @ethnimbus; surveillez Github pour connaître les progrès des clients Fluffy et Nimbus (avons-nous mentionné qu’ils travaillent également sur un client d’exécution ?), ou connectez-vous avec l’équipe via Discord, Status ou Gitter.
Paul Miller pour Améliorations Ethereum-Cryptographie
Ethereum-Cryptography 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. Il a été lancé en 2020 par Nomic Foundation 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 les nœuds-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 occuper – 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-secp256k1, une 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 effectué par Cure53 et toutes les vulnérabilités traitées
Pour en savoir plus, consultez la publication de la version v1.0.0 ou explorez certaines des informations techniques apparues lors de la reconstruction. Vous pouvez creuser dans la cryptographie Ethereum sur Github ; suivez Nomic Foundation sur Twitter ou consultez leur blog; et suivez Paul sur Twitter @paulmillr ou son Github personnel.
Travaillez-vous sur quelque chose qui, selon vous, pourrait améliorer Ethereum ? Rendez-vous sur notre site Web pour en savoir plus sur le programme de soutien des écosystèmes et demander de l’aide.
