As we’re getting closer to reintroducing native light client support as well as ULC into the app, a big item that remains on the TODO list is to secure a viable reward mechanism for those serving the community with honest blockchain data.
To kick-start this project, I’ve written down an idea that we could use in the medium term to complement alternatives, such as people running their own private LES servers or using trusted services such as vipnode.
The project is in large parts inspired by the work we’ve already done on ULC, as well as the Swap/Swear/Swindle framework from the Swarm project, and the aim is to create a service network that can serve ULC and the lightest of all light clients.
In short, providers put down a stake, and agents known as Wardens audit the data on behalf of the ULC client.
I’d like to invite interested parties to a discussion at a time and location to be determined based on interest, potentially in Prague.
Ping here with comments or questions, or just jot them down directly in the hackmd. The hardest problem yet remains to be solved: a project name!
“Can we use a circular setup here? how does that affect security and stake?”
Am I right that if we use “circular setup”, it’d be possible to make something like this:
ULC client sends a single request to a random warden
request from ULC client can looks like [GetBlockHeaders|GetBlockBodies|GetReceipts, [hash1, hash2…], [warden_address1, warden_address_2…]]
the warden that received a request must resend it to all wardens listed in the request and get all signs (or M of N)
the warden send to the client the response with signs that user can check
the wardens get paid only if the user gets the response with all asked signs.
In that scheme, a user sends only one request to the Net and delegates reaching a consensus to a set of wardens.
“circular setup” means that wardens sign off each other - that the message ping-pongs between two wardens. Imagine data D, signed by W1, then D+W1 gets signed by W2, then D+W1+W2 gets signed by W1 again, to attest to the honesty of W2, resulting in a message D+W1+W2+W1.
It’s questionable how much security that brings, ie the only thing you get is that the stake of W1 now secures the stake of W2 - it does not bring additional stake into the pool, so need to work out how valuable exactly that last signature is.
What you’re describing is found under Fronting service in the doc - and indeed, any of the wardens or les servers could act as fronts in the network. I kept them apart so as to make initial analysis more simple.
There’s also an interesting alternative setup where the LES-Server is responsible for making payments to Wardens, for example by rewarding them for catching intentional errors (and using a statistics-based approach so that the fees even out). The ULC-Client would still have to pick the Wardens but it might simplify the number of payment channels that the client has to open.