Move PoC challenge construction to Consensus Group (HIP draft) #41
Conversation
| Currently the network is a sea of undifferentiated nodes, all running more or less the same version of erlang lip2p. | ||
| Under this proposal, we will be moving to a network that has nodes with differing capacities (to some extent, we have this today with seed nodes). | ||
| Given that many of these nodes will have small memory and little to no persistent storage, it's probable that we'll need to be able to make informed decisions about what network peers we retain knowledge about. | ||
| In order to inform those decisions, I think that libp2p peers should start to declare some sort of service information, e.g. "can answer ARP requests", "full node", "poc capable", etc. |
There was a problem hiding this comment.
libp2p already allows nodes to advertise the "handler protocols" available on a connection as part of the stream negotiation (there's a ls command)
There was a problem hiding this comment.
Yeah, I meant to have it serialized in the peer, so you could look it up/index it locally without having to contact the remote node.
0099-group-challenge.md
Outdated
|
|
||
|
|
||
| ## Request Generation | ||
| [request-generation]: #request-generation |
There was a problem hiding this comment.
There's not much about the actual generation of a request here. In the current model the request is generated from the combination of chain entropy and a secret ephemeral key generated by the challenger, which is only revealed in the receipt. How do we plan to replicate this on the consensus group?
There was a problem hiding this comment.
that's a good question. I'd forgotten that particular detail when I wrote this. Maybe the right solution is that everyone in the group races at random? First to deliver a key and path to a spot wins?
There was a problem hiding this comment.
I think there's a lot of ways we could do this and we should try to decide on the best way. For example the consensus members could simply propose a set of ephemeral keys per block, and we pick a subset of those (depending on the poc rate), combine them with the block hash and use that use for pathing. We could also still allow the challenger to submit a key, or we could do some wild secure multiparty compute over elliptic curves (likely a huge amount of work).
evanmcc
force-pushed
the
pevm/group-challenge-hip
branch
from
4e1e2f9
to
0da0cca
Compare
|
OK, I've marked it as non-draft, but I'd like to do a design review with @Vagabond tomorrow before we merge it and move to broader discussion, if that's OK. |
|
Sounds good to me
|
|
@evanmcc let me know if this one feels closer to being merge'able. No worries if not, just trying to keep things moving along. Thanks! |
jamiew
changed the title
jamiew
changed the title
jamiew
changed the title
|
Oof, sorry, a rogue git cleanup script accidentally deleted & closed. Restoring & re-opening |
jamiew
changed the title
|
I've spent a fair amount of time thinking about this and how it interacts with upcoming proposals, and I no longer think that it's required. |
Summary: A proposal to move the role of PoC challenger into the consensus group to enable lighter-weight gateways.
Rendered view: https://github.com/helium/HIP/blob/pevm/group-challenge-hip/0099-group-challenge.md