It’s always fun to hear about new grants as they’re awarded, but what happens after the announcement? In this series, we check in on projects that are well underway – or already at the finish line. Read on to learn about some recent milestones and achievements by grantees!
Nimbus for Fluffy Portal Client and Portal Network Development
Nimbus is best known to most people as a beacon chain client, notable for its low resource requirements with only ~750mb of memory required to run a full consensus node. But outside the spotlight cast by The Merge, the talented team behind Nimbus (a part of the Status organization) is doing much more to make participation in the Ethereum network accessible to anyone, on any device. The Portal Network is an in-progress, cross-team initiative to redefine how resource-constrained devices participate in the Ethereum network, and the Nimbus team have had an essential role in bringing it to life.
Light client efforts have been ongoing for years, and have focused on designing clients to use minimal resources. Many clients now offer some form of light client; Nimbus recently added a standalone light client, which supplies the information to follow the head of the beacon chain without requiring a full sync. However, the potential of Ethereum light clients is ultimately limited by the design of the network itself. The current light client network relies on a client/server architecture: light clients download block headers and other data as needed, but don’t contribute anything. Light clients rely on full nodes to serve the data they need, but not many full nodes opt to serve this data, making it a limited and unreliable resource.
Recognizing that different applications require access to different data and functionality, the Portal Network is designed for flexibility. Rather than bundling all functionality together, it combines several subprotocols, with each dedicated to a specific function. Portal clients can connect to all the subprotocols, or only a subset, depending on their needs. Just as importantly, a device running a portal client can contribute whatever resources it has available (e.g. storing a small amount of state or relaying peer-to-peer messages). In other words, every client is also a server, able to access the information it needs while adding capacity to the network according to its capabilities. More clients online means a stronger network, not a zero-sum competition for limited resources.
The Nimbus team has been integral to the design and development of the Portal Network. They’ve been the first to implement most pieces of network functionality through development of Fluffy, a Nimbus implementation designed specifically for the Portal Network and one of three clients anticipated to be available when the Portal Network comes online (two others are being developed by Ethereum Foundation teams). Fluffy was the first client able to both store and serve content and acted as the backbone to initial test networks, helping to inform necessary changes to the network specifications as issues were encountered during implementation.
The team is aiming for Fluffy to be light enough to run from inside a wallet, and ultimately to integrate it into the Status mobile app. The prospect of running a full client from within a wallet or dapp has huge implications, not only for the health of the network but also for decentralization and privacy as it reduces reliance on the centralized infrastructure that most wallets currently use to access Ethereum data.
If this busy team has their way, you’ll have an Ethereum client in your back pocket before you know it! Periodic updates on Fluffy and Portal Network development are posted to HackMD and the Nimbus blog. You can also follow Nimbus on Twitter @ethnimbus; watch Github for progress on the Fluffy and Nimbus clients (did we mention they’re also working on an execution client?), or connect with the team via Discord, Status or Gitter.
Paul Miller for Ethereum-Cryptography Improvements
Gathering these common cryptography tools under one roof relieved some serious pain points for developers; but Paul Miller saw room to improve further by reducing both the number of dependencies and the overall size of the codebase. It’s no surprise that Paul was eager to take this on – he has a long track record of building tools to help developers build more efficiently and securely, including Chokidar, a cross-platform file-watching service; and noble-secp256k1, a JS implementation of the secp256k1 elliptic curve.
When Paul started work on ethereum-cryptography, the install package came with 38 dependencies and 3.46 megabytes of source code. Not all of this code winds up in production, but an end user of a dapp built with this library was still downloading up to 793kb, roughly 24,000 lines of code. Paul set out to build a more compact and secure library that would provide the same functionality, rewriting many of the cryptography implementations and subjecting the new version to a formal audit. This overhaul resulted in some serious boosts to efficiency and security:
- External dependencies reduced from 38 to 5
- Directory size reduced from 10.2MB to 650KB
- Source code reduced from 23,799 lines to 5,225 lines
- NPM traffic reduced from 3.6MB to 324KB uncached
- Audit performed by Cure53 and all vulnerabilities addressed
To learn more, check out the v1.0.0 release post, or dig into some of the technical insights that arose during the rebuild. You can dig into ethereum-cryptography on Github; keep up with Nomic Foundation on Twitter or check out their blog; and follow Paul on Twitter @paulmillr or his personal Github.
Are you working on something you think could change Ethereum for the better? Head to our website to learn more about the Ecosystem Support Program and apply for support.
The article above came directly from the Ethereum Foundation Blog, found at https://blog.ethereum.org/