search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

[Rendezvous] Draft proof-of-work requirement #334

Closed thomaseizinger closed 3 years ago

thomaseizinger commented 3 years ago

This is a draft for the proof of work requirement that is to be defined in the rendezvous protocol.

I've considered a number of designs and ended up with what is presented here. I am not sure how much people will like the additional messages but it solves an important problem: The PoW must be unique to a single registration and the best way to achieve that IMO is for the rendezvous point to hand out a challenge to the client. Given that REGISTER is sent by the client, there isn't really any opportunity before the register response to send back a challenge which is why I opted to introduce a dedicated status code that requests proof of work from the client.

The main consequence of this is that it allows rendezvous points to not require proof of work for the first few registrations for example or whilst they are under low load. I am not sure we need this flexibility but it is there with the current design.

If however we want proof of work with every registration anyway, then the additional message is a bit of a waste and it would be ideal if the client could just include the proof of work with the original REGISTER message. Unfortunately, I could come up with a way of making the PoW unique to this registration. ttl is a relative value and therefore, a PoW that is calculated once could be reused over and over again at a later point in time.

mxinden commented 3 years ago

Pinging author and interest group. Does one of you want to take a look at this proposal? Also see https://github.com/libp2p/specs/issues/337 for a general discussion on whether to introduce proof of work to the Rendezvous protocol.

@vyzo, @daviddias, @whyrusleeping, @Stebalien, @jacobheun, @yusefnapora, @vasco-santos

vyzo commented 3 years ago

we have had on and off discussions about PoW and we are not convinced its the right thing to do. I think its much better to have many rendezvous points and use verified randomness in picking the one to use.

On Mon, Jun 21, 2021, 13:17 Max Inden @.***> wrote:

Pinging author and interest group. Does one of you want to take a look at this proposal? Also see #337 https://github.com/libp2p/specs/issues/337 for a general discussion on whether to introduce proof of work to the Rendezvous protocol.

@vyzo https://github.com/vyzo, @daviddias https://github.com/daviddias, @whyrusleeping https://github.com/whyrusleeping, @Stebalien https://github.com/Stebalien, @jacobheun https://github.com/jacobheun, @yusefnapora https://github.com/yusefnapora, @vasco-santos https://github.com/vasco-santos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/pull/334#issuecomment-864915422, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAI4SWA44FXKCVPX5U5563TT4GT7ANCNFSM46WLAE7A .

thomaseizinger commented 3 years ago

we have had on and off discussions about PoW and we are not convinced its the right thing to do. I think its much better to have many rendezvous points and use verified randomness in picking the one to use.

Right, thanks for clarifying! I'll close this then and send another PR that incorporates this knowledge into the spec.

thomaseizinger commented 3 years ago

we have had on and off discussions about PoW and we are not convinced its the right thing to do. I think its much better to have many rendezvous points and use verified randomness in picking the one to use.

Right, thanks for clarifying! I'll close this then and send another PR that incorporates this knowledge into the spec.

Opened a follow-up PR: https://github.com/libp2p/specs/pull/342.