3 ms·
Fewer full nodes can download and keep up. But light weight ethereum clients[1] shouldn’t have an issue. [1] https://github.com/ethereum/wiki/wiki/Light-client
by otoburb 8y ago
Fewer full nodes can download and keep up. But light weight ethereum clients[1] shouldn’t have an issue.
[1] https://github.com/ethereum/wiki/wiki/Light-client-protocol https://github.com/ethereum/wiki/wiki/Light-client-protocol
- thinkmassive 8y agoPeople running light clients should also be running their own full nodes, otherwise the shortage of peers will only get worse https://github.com/ethereum/go-ethereum/issues/15454 https://github.com/ethereum/go-ethereum/issues/15454
- shazow 8y agoUltimately, all full nodes will also be light clients--that is the nature of the upcoming sharding changes. It does not make sense to have a full node for every light client. A full node is perfectly capable of safely serving hundreds or thousands of light clients. Also there are several initiatives towards incentivizing more light clients. I am working on one: https://vipnode.org/ https://vipnode.org/
- thinkmassive 8y agoI wasn't implying a full node for every light client, of course that doesn't make sense. People using light clients in their products, like a wallet or DApp, are probably adding tens to thousands of light clients. When you add that load to the network, you should also deploy a few full nodes, and probably add them as static peers if you want the application to work well.
- thinkmassive 8y ago> Also there are several initiatives towards incentivizing more light clients. I am working on one: https://vipnode.org/ https://vipnode.org/ This looks cool, I may have to give it a try!