interesting
/
go-ethereum
mirror of https://github.com/ethereum/go-ethereum.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: update les page (#25048) 

* update les page

* fix typos

* rm extra space

* reword light-server -> mainnet sentence

* fixes

Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
This commit is contained in:
Joseph Cook 2022-06-09 15:33:45 +01:00 committed by GitHub
parent d6eceee791
commit cd60a63ed8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 33 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
docs/_interface/les.md
View File

@ -3,46 +3,59 @@ title: Light client
sort_key: B
---
*Note*: Light client is an experimental feature. Please consider this before using it with large funds.
Running a full node is the most trustless, private, decentralized and censorship resistant way to interact with Ethereum. It is also the best choice for the health of the network, because a decentralized network relies on having many individual nodes that independently verify the head of the chain. In a full node a copy of the blockchain is stored locally enabling users to verify incoming data against a local source of truth. However, running a full node requires a lot of disk space and non-negligible CPU allocation and takes hours (for snap sync) or days (for full sync) to sync the blockchain from genesis. Geth also offers a light mode that overcomes these issues and provides some of the benefits of running a node but requires only a fraction of the resources.
In addition to the full client, geth supports a light mode which has several advantages for end users:
Read more about the reasons to run nodes on [ethereum.org](https://ethereum.org/en/run-a-node/).
- Syncing takes minutes instead of hours (for snap sync) or days (for full sync)
- It uses significantly less storage, e.g. less than 1Gb for a node light-synced to mainnet
- It is lighter on CPU and possibly other resources
- It is hence suitable for resource-contrained devices
- It can catch up much quicker after having been offline for a while
## Light node vs full node
What's the catch you might ask? They are heavily dependant on as of now altruistic light servers. These are full nodes that volunteer to serve data to light clients and which can be easily overwhelmed as the number of clients increase.
Running Geth in light mode has the following advantages for users:
They also have slightly different security guarantees. Because they don't keep the Ethereum state, they can't validate the blocks in the same way as the full nodes. Instead they fetch block headers and check their Proof-of-Work, assuming the heaviest chain is valid. What this means for you is that if you want to be on the safe side it's advisable to wait for a few blocks worth of confirmations before trusting the validity of a recently mined transaction.
- Syncing takes minutes rather than hours/days
- Light mode uses significantly less storage
- Light mode is lighter on CPU and other resources
- Light mode is suitable for resource-constrained devices
- Light mode can catch up much quicker after having been offline for a while
#### Light server
However, the cost of this performance increase is that a light Geth node depends heavily on full-node peers that choose, for altruistic reasons, to run light servers. There is no monetary incentive for full nodes to run light servers and it is an opt-in, rather than opt-out function of a Geth full node. For those reasons light servers are rather rare and can quickly become overwhelmed by data requests from light clients. The result of this is that **Geth nodes run in light mode often struggle to find peers**.
By enabling light serving on your full node you'll help the network and light clients. Naturally you might want to cap the amount of resources you dedicate to serving light clients. That's why the same flag that enables this feature also requires you to specify how much resources to dedicate to serving clients. `--light.serve <num>` takes a percentage as value. Number bigger than 100 indicate you want to dedicate more than one thread to this feature, e.g. `--light.serve 200` for 2 cores.
A light client can be used to query data from Ethereum and submit transactions, acting as a locally-hosted Ethereum wallet. However they have different security guarantees than full nodes. Because they don't keep local copies of the Ethereum state, light nodes can't validate the blocks in the same way as the full nodes. Instead they fetch block headers by requesting them from full nodes and check their proof-of-work (PoW), assuming the heaviest chain is valid. This means that it is sensible to wait until a few additional blocks have been confirmed before trusting the validity of a recently-mined transaction.
Something else you need to note is that since v1.9.14 geth unindexes old transactions to save space. This limits what clients can request. A node with unindexed transactions also can't serve lesv4 clients due to lack of support. Please keep this in mind and if possible disable unindexing by adding `--txlookuplimit 0`.
### Running a light server
E.g. the whole command could see as follows:
Full node operators that choose to enable light serving altruistically enable other users to run light clients. This is good for Ethereum because it makes it easier for a wider population of users to interact with Ethereum without using trusted intermediaries. However, there is naturally a limit to how much resource a node operator is able and willing to dedicate to serving light clients. Therefore, the command that enables light serving requires arguments that define the upper bound on resource allocation. The value given is in percent of a processing thread, for example `--light.serve 300` enables light-serving and dedicates three processing threads to it.
```sh
Recent versions of Geth (>`1.9.14`) unindex older transactions to save disk space. Indexing is required for looking up transactions in Geth's database. Therefore, unindexing limits the data that can be requested by light clients. This unindexing can be disabled by adding `--tx.txlookuplimit 0` to make the maximum data available to light clients.
The whole command for starting Geth with a light server could look as follows:
```shell
geth --light.serve 50 --txlookuplimit 0
```
#### Light client
### Running a light client
To run a light client you specify sync mode to be light. In addition to syncing you probably also want to interact with the node, say through RPC. So Let's enable that too:
Running a light client simply requires Geth to be started in light mode. It is likely that a user would also want to interact with the light node using, for example, RPC. This can be enabled using the `--http` command.
```sh
```shell
geth --syncmode light --http --http.api "eth,debug"
```
Now you can request data from the RPC endpoint just like as in a full node and the light client will fetch the necessary data from servers in the background. You can also send transactions. But note that light clients do not join the main ethereum network (`eth`) so they can't propagate transactions themselves but rather give this to light servers which propagate it on their behalf.
Data can be requested from this light Geth instance in the same way as for a full node (i.e. using the [JSON-RPC-API](/docs/rpc/server) using tools such as [Curl](https://curl.se/) or Geth's [Javascript console](/docs/interface/javascript-console)). Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
##### Ultra light client
It's also possible to send transactions. However, light clients are not connected directly to Ethereum Mainnet but to a network of light servers that connect to Ethereum Mainnet. This means a transaction submitted by a light client is received first by a light server that then propagates it to full-node peers on the light-client's behalf. This reliance on honest light-servers is one of the trust compromises that comes along with running a light node instead of a full node.
Geth has an even lighter sync mode called ultra light client (ULC). The difference is that an ULC doesn't check the Proof-of-Work in block headers. The assumption is that you have access to one or more light servers you are running yourself or that you trust. The command looks as follows:
### Ultra light clients
Geth has an even lighter sync mode called ultra light client (ULC). The difference between light mode and ultra-light mode is that a ULC doesn't check the PoW in block headers. There is an assumption that the ULC has access to one or more trusted light servers. This option has the greatest trust assumptions but the smallest resource requirement.
To start an ultra-light client, the enode addresses of the trusted light servers must be passed to the `--ulc.servers` command and the sync mode is `light`:
```sh
geth --syncmode light --ulc.servers "enode://...,enode://..." --http --http.api "eth,debug"
```
## Summary
Running a full node is the most trustless way to interact with Ethereum. However, Geth provides a low-resource "light" mode that can be run on modest computers and requires much less disk space. The trade-offs are additional trust assumptions and a small pool of light-serving peers to connect to.