Fluffy client: an extremely light client for Ethereum
How can we design the network so that the client only needs to contribute a small amount of data to the network, so that the entire network (these contributions) can have a lot of meaning?
—— Piper Merriam
We are pleased to announce that Nimbus will be joining the Ethereum Foundation's "Portal Network" team as one of the launch clients of the Portal Network.
One sentence summary: "Portal Network" is a cross-client project under development to reimagine Ethereum's light client and develop a usable and practical light client experience.
To quote the specification directly:
The "Portal Network" is a project in development to allow lightweight access to the protocol for devices with limited resources.
The term "gateway" means that these networks can observe the status quo of the operation of the protocol, but are indifferent to the operation of the core Ethereum protocol.
The portal network will consist of one or more decentralized peer-to-peer networks that collectively provide the data and functionality required to expose a standard JSON-RPC API.
These networks are specially designed to ensure that these clients only need to pay the minimum network bandwidth, CPU, RAM and mechanical hard disk resources to join.
The term "portal network" is also used to describe software that participates in these networks and exposes the standard JSPN-PRC API.
In particular, our goal is to work with EF to develop a new set of Ethereum protocols around the existing Ethereum protocols, which can specifically serve this new method of accessing Ethereum data.
The overall goal is to provide an operating model for Ethereum that can serve common usage patterns, rather than tracking full state in real time (which is what the current client does).
What we are discussing is to develop a perfect client for wallets, a very light client that can contribute to the network, but does not require synchronizing the blockchain (that is, it can be restarted after offline, and after installation available immediately).
It's also not as difficult as it sounds. I imagine most wallets embed light clients directly, e.g. @ethstatus will integrate an @ethnimbus light client. So there may be a situation where most users start running light clients without even knowing it.
May 24, 2021
So one of our ultimate goals is to have this kind of client knocked right into the Status app.
background
background
The portal network is rooted in the original goal of developer Piper Merriam and the Trinity team: to develop a lightweight client on top of the existing network. It was born because they realized that the existing network was not flexible enough for the type of clients they envisioned.
In Piper's words:
When we started developing the Trinity client, our goal was to develop a lightweight client. But after spending nearly three years understanding the protocol in depth and exploring ways to develop the client we envisioned, we finally came to the conclusion that it couldn't be done on the existing network.
This is the original intention of the portal network. We're going to go back to what we want the client to look like, and then design the network functionality necessary for it to work.
first level title
Motivation (light client perspective)
The existing DevP2P LES network is designed with a client/server architecture, with light clients as clients and full nodes as servers (so far, the term "light client" refers to existing DevP2P LES a client of the network).
Because this architecture assigns all the load to the full node, and the operating cost of the full node is already high, so node operators are reluctant to enable this function.
So, while the current network design achieves its original goals well, it fails badly from a light client perspective.
How do we solve this problem? As Piper's Trinity team discovered, reality shows that there is no easy solution to this problem. Existing networks are not flexible enough for efficient light client designs.
design
design
A light-client-friendly network must be designed so that nodes can participate in the network and contribute to the network with only a small amount of storage space and a small amount of work, instead of requiring each node to bear a high load (ie: in The complete history of the blockchain is kept in memory).
In other words, such a network must allow light clients to actually contribute to the network, such that every time additional clients join the network, it increases the capacity of the network.
Specifically, this means coming up with a network design that reduces the validation overhead of your sporadically requested data, and reduces the underlying overhead of passing messages across the network.
The portal network aims to do this by splitting the overall structure of the Ethereum protocol into three separate networks: Gossip (transactions and blocks) state and history; the initial development focus is on the state network.
These networks will coexist with the ETH protocol - but unlike the ETH protocol, they don't have to be completely invulnerable, but they need to be able to work almost non-stop.
The hope is that these new networks, over time, can become more tightly integrated with existing networks. As an example, we can imagine a world where full-featured clients could use a network of history portals to give node operators the additional option of storing only the history they care about (perhaps 200 MB) instead of the entire blockchain (greater than 200 GB). The same goes for status data.
All in all, this modular architecture - where data (state and blockchain history) is shared in a P2P fashion, while transactions and blocks are propagated via gossip - allows light clients to choose how much state to store/serve data and historical data.
first level title
JSON RPC Notes
Chinese translationChinese translation): Most wallets, including ours, standardize on the JSON RPC API.
Correct functioning of the Status wallet requires the following JSON RPC endpoints:
eth_blockNumber is used to track the top of the chain
eth_getBalance and eth_getTransactionCount are used to obtain account information
eth_call is used to read contract information
eth_estimateGas and eth_gasPrice are used to estimate the gas fee
eth_sendRawTransaction is used to send user's transaction
eth_getTransactionReceipt Get the receipt after the transaction is on-chain
Access account and contract storage items (state) to support: eth_call, eth_estimateGas, eth_getBalance and eth_getTransactionCount
Access the gossip network (Gossip) to follow the top of the chain and eth_sendRawTransaction
History of the access chain (history), used for eth_getTransactionReceipt
If we further sort out the necessary components to realize the wallet function, we can get the following lower-level requirements:
Opening up lightweight access to state, gossip, and history, Portal Networks opens the door to wallet-embeddable light clients that can meet these needs without syncing the blockchain or sacrificing privacy and security sex.
first level title
Project status
We have started developing a mode of operation for Nimbus, originally named nlpn but now renamed fluffy , that will exist and run alongside the Ethereum 1 client.
fluffy will enable the nimbus-eth1 client to operate as a very light client node in the network.
Initial work was to develop the Portal Wire protocol, a secondary protocol built on top of the Node Discovery v5.1 protocol.
Next step
Next step
The next step is to transfer data through the Portal Wire protocol. We are dealing with state data.
This requires "bridge nodes" to input state data for the portal network. The current approach is to use a Nethermind client plugin as a custom JSON-PRC API to provide data to portal nodes willing to act as bridge nodes. This work has already started (draft specification here).
resource
resource
The Nimbus Portal Network Client (nlpn) can be found in our nimbus-eth1 repository: https://github.com/status-im/nimbus-eth1/tree/master/fluffy
The Portal Wire protocol has been added to the nim-eth codebase as a secondary protocol for node discovery protocol v5.1: https://github.com/status-im/nim-eth
Specifications: https://github.com/ethereum/stateless-ethereum-specs/
Website: https://www.ethportal.net/
Some stuff about the first Portal Wire protocol tests with ddht and trin: https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
Blog series by Piper Merriam: The winding road to functional light clients
A video lecture on the topic
Note: Conveniently, all the infrastructure necessary to implement functional light clients will also naturally extend to stateless clients, so there will be a lot of overlap with stateless Ethereum. In fact, enabling stateless clients to serve most JSON-PRC APIs is one of the core motivations of the portal network.
