C: We need to reduce the total data stored by individual nodes.B: We need an index to lookup blocks by number and transactions by hash.A: We need a concise view of the canonical chain.Trying to build a light client on this protocol exposes three main issues: So, the network contains all of the data we need, but it is not architected for our use case. Still, the network makes it compulsory for clients to hold the full history. Receipts are generated locally as part of block execution. They also have no ongoing need to request this data, as they receive new blocks and headers via separate gossip messages. Once a client is fully synced, it no longer has any need for this data beyond serving JSON-RPC requests. The ETH protocol is optimized for new clients joining the network to be able to efficiently retrieve the full history of the chain. It can be modeled as an append-only file with each new block adding a header and the corresponding transactions, uncles, and receipts. The chain history is a relatively simple data set to work with. The full specification of the ETH protocol can be found here. In the current ETH protocol, which all Ethereum clients use to communicate, there are message pairs that nodes can use to request this information from each other: The term "chain history" refers to all of the historical headers, blocks, and receipts. In this post, we'll cover what the chain history is and what problems need to be solved to make it available in a suitable manner for a functional light client. Various research efforts have demonstrated that the functionality can be built as long as you have access to the necessary data. There's currently no reliable lightweight way to interact with the protocol without using a centralized provider. Ethereum went live a little more than five years ago. 5 min read You should read part 1 first.
0 kommentar(er)
