Light Clients Workshop ====================== ### Overview Our goal in the meeting was to identify the major problems related to light clients and the required future research directions. It was decided that we'll establish a permanent working group that will collaborate via the [ethereum/light-clients](https://gitter.im/ethereum/light-clients) Gitter channel in the future. Some initial discussions regarging the blockchain sync algorithm already took place within the first two weeks after the meeting and this document will summarize them as well. ### Attendees * Zahary Karadjov (Status) * Felfoldi Zsolt (EF) * Gary Rong (EF) * Adrian Manning (Lighthouse) * Dmitrii Shmatko (Harmony) * Boris Petrov (Status) * Fredrik Harrysson (Parity Technologies) * Raul Jordan (Prysmatic) ## How light a light client can be? We felt that our most important initial goal would be to determine and optimise the minimal hardware and bandwidth requirements for staying in sync with the beacon chain. In the first weeks after the meeting, several of the implementation teams published block validation benchmark results: https://github.com/sigp/lighthouse/tree/bench_block_validation https://github.com/prysmaticlabs/prysm/issues/573 https://github.com/status-im/nim-beacon-chain/issues/8 The Nimbus team investigated the most minimalistic form of validation (involving checking only the BLS signatures of the active validators) on computationally weak devices such as the Raspberry Pi 3b+: https://gitter.im/status-im/nimbus?at=5be5c303e8add80e63c86fba It's worth noting that a light client may decide to validate only a subset of the blocks while being idle and only a subset of the signatures. This is discussed in more detail in the presentation of beacon chain sync algorithm. ### Beacon chain sync Before going forward, please get familiar with the following background material: https://ethresear.ch/t/casper-ffg-and-light-clients/2957 We recommend supporting the following sync algorithms: * **Full Sync** downloads all beacon blocks in consecutive order. * **Light Sync** aims to quickly reach and download only the latest block. Light sync should be the recommended mode for most clients. Full Sync is more appropriate only for archival nodes. Both sync algorithms starts from the assumption that the client will have a known recent finalized state (i.e. less than 4 months old). This is the known [weak subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/ ) requirement needed to deal with long-range attacks. If such a state is not available, the clent must obtain a recent hash of the state from a trusted source. We recommend the implementation of a community-managed well-known source (e.g a web URL or a mutable Swarm resouce) that will provide the required data along with signatures from many independent trusted parties (e.g EF, software vendors, blockchain explorers, etc). By definition, the known state includes the list of validators at a particular time and the head hash of the validator change log stored in the `validator_set_delta_hash_chain` field of the `BeaconState`. To advance its state, the client sends requests of the form "Please send me the validator change log starting from my known state up to the latest point where a supermajority of the known validators have signed a new validator change log hash". The contents of the returned change log can be applied to produce a new validator set and the client can repeat the query until it reaches the latest block. This seems like a relatively complicated query to compute, but the good news is that the same answer can be given to multiple clients, so it can be easily cached. The way you would do this is that you'll create checkpoints in the validator change log every time enough validators are removed to make the supermajority of the previous checkpoint no longer valid. When a client makes a query starting from a particular known state, the server will first send the nearest cached checkpoint and then all the following ones will be valid as well. Please note that the density of these checkpoints will depend on the rate of change in the validator set. To recap, the light sync algorithm can be summarized like this: 1. If you have a state older than 4 months, obtain the latest trusted snapshot. 2. Sync the validator set changes following the scheme above. 3. Obtain the latest block of the beacon chain (the timestamp/height of the block and the signatures of the known validators will be enough to authenticate it) 4. Sync any shards of interest through their known block hashes Our work group will produce more detailed specifications once the initial experimental implementations have reached sufficient progress. ## Future research directions ### Incentivation for Light Client servers We felt that more research is required into incentivizing the operators of full nodes serving data to light clients. Our group will work on specifications aiming to define standard protocols for implementing payment channels, slashing conditions, Quality of Service contracts and so on. ### The implications of stateless execution for the programming model of Ethereum The stateless execution requires that all transactions are able to statically produce an access list of all the storage locations that are going to be touched during execution. In the presense of the semi-undeterministic randomness avialable to the application developers, we believe this will create some challenges for the development tools that require further research. Furthermore, the size of the computed access lists may have to be incorporated in the gas cost models. ### Applying STARKs Our group will collaborate with the StarkWare team to identify ways STARKs can be used in future to authentice in a succinct way the validity of a recent state without needing to execute the light sync algorithm.