Skip to content
This repository has been archived by the owner on Dec 5, 2024. It is now read-only.

Add "light client" support #602

Open
btiernay opened this issue Nov 20, 2016 · 8 comments
Open

Add "light client" support #602

btiernay opened this issue Nov 20, 2016 · 8 comments
Labels

Comments

@btiernay
Copy link

It would be great if one could subscribe to the network in a purely passive mode, without the need to sync. One use case is discussed here:

http://ethereum.stackexchange.com/questions/10125/is-it-possible-to-avoid-sync-in-ethereumj-but-still-register-a-listener

@Swaxxx
Copy link

Swaxxx commented Nov 7, 2017

Hello
I'm working on a project using your lib, and this feature is required by my client. I would like to know if this ticket is still active, or if there's another way to do that using EthereumJ.
Thank you

@mkalinin
Copy link
Contributor

mkalinin commented Nov 8, 2017

Hello @Swaxxx
The ticket is still relevant. And I hope this feature will be introduced in a close future

@adridadou
Copy link
Contributor

Any plans or ETA for this?

@zilm13
Copy link
Collaborator

zilm13 commented Jun 11, 2018

@adridadou we couldn't validate state root / receipts matching for incoming blocks if we don't have state, what do you propose? I have an idea to make something like light client for casper using EthereumJ, but no sense for that until Casper goes to Mainnet.

@adridadou
Copy link
Contributor

I understand. I am interested in the feature but I haven't looked too deep into the details of it.
Maybe I'm missing something but shouldn't it be better to implement the LES protocol ?
https://github.com/ethereum/wiki/wiki/Light-client-protocol

This way you can use the network of servers that serve light clients and AFAIK the verification piece is solved there no?

@zilm13
Copy link
Collaborator

zilm13 commented Jun 12, 2018

@adridadou looks cool!
As I see both Geth and Parity already support it. I didn't dive deeper to understand verification part but looks like it's solved. I couldn't provide any schedule or priority, but now we know that there is well established protocol for it.

@adridadou
Copy link
Contributor

Glad I could help!
Yes the protocol seems pretty stable now and I think it will help us using a standard protocol instead of implementing our own.

I understand that you have no schedule but I hope this will help.
The geth and parity ppl are usually very helpful about that.

I think it make sense here also to split the task in two:

  1. The LES client, i.e. the actual light client
  2. The LES server, a full node to serve light clients

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants
@adridadou @mkalinin @btiernay @zilm13 @Nashatyrev @Swaxxx and others