Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Light Client #66

Open
piotr-dziubecki opened this issue Oct 29, 2021 · 0 comments
Open

Light Client #66

piotr-dziubecki opened this issue Oct 29, 2021 · 0 comments
Assignees
Labels
Epic P2 priority two
Milestone

Comments

@piotr-dziubecki
Copy link
Contributor

piotr-dziubecki commented Oct 29, 2021

What is a Light client?

(from Tendermint specs)

A light client is a lightweight (hence the name) alternative to a full node. Full nodes often are resource-heavy because they execute transactions and verify results (and do a lot of other stuff). Light clients, on the opposite, have low resource requirements since they only verify results (without executing transactions). Full nodes often store a lot of data (blocks, transaction results, etc.). Light clients only store a few latest headers.
A light client is a client, which connects to a full node, requests new block headers, and verifies that those headers can be trusted.

Light clients are assumed to be initialized once from a trusted source with a trusted header and validator set. The light client protocol allows a client to then securely update its trusted state by requesting and verifying a minimal set of data from a network of full nodes (at least one of which is correct).

source

(from Solana docs)

A ‘light client’ is a cluster participant that does not itself run a validator. This light client would provide a level of security greater than trusting a remote validator, without requiring the light client to spend a lot of resources verifying the ledger.

Rather than providing transaction signatures directly to a light client, the validator instead generates a Merkle Proof from the transaction of interest to the root of a Merkle Tree of all transactions in the including block. This Merkle Root is stored in a ledger entry which is voted on by validators, providing it consensus legitimacy.

source

@piotr-dziubecki piotr-dziubecki added this to the 2.1.0 milestone Feb 4, 2022
@piotr-dziubecki piotr-dziubecki added the P2 priority two label Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic P2 priority two
Projects
Status: No status
Development

No branches or pull requests

3 participants