mirror of
https://github.com/vacp2p/vac.dev.git
synced 2026-01-08 22:28:01 -05:00
Update Links (#163)
* Update 2022-07-22-relay-anonymity.mdx * Update 2022-07-22-relay-anonymity.mdx * Update 2019-07-19-p2p-data-sync-for-mobile.mdx * Update 2019-08-02-vac-overview.mdx * Update 2019-10-04-remote-log.mdx * Update 2019-12-03-fixing-whisper-with-waku.mdx * Update 2020-02-14-waku-update.mdx * Update 2020-02-7-dns-based-discovery.mdx * Update 2020-02-7-dns-based-discovery.mdx * Update 2020-07-01-waku-v2-pitch.mdx * Update 2020-09-28-waku-v2-update.mdx * Update 2020-11-10-waku-v2-ethereum-messaging.mdx * Update 2021-03-03-rln-relay.mdx * Update 2021-06-04-presenting-js-waku.mdx * Update 2021-08-06-coscup-waku-ethereum.mdx * Update 2021-10-25-waku-v1-vs-waku-v2.mdx * Update 2022-04-12-introducing-nwaku.mdx * Update 2022-05-09-ambient-peer-discovery.mdx * Update 2022-05-17-noise.mdx * Update 2022-11-04-building-privacy-protecting-infrastructure.mdx * Update 2022-11-08-waku-for-all-decentralize-applications.mdx * Update 2023-04-03-waku-as-a-network.mdx * Update 2023-04-03-waku-as-a-network.mdx * Update 2023-04-24-device-pairing-in-js-waku-and-go-waku.mdx * Update 2023-11-07-rln-relay.mdx * Update 2024-05-03-rln-light-verifiers.mdx * Update 2024-05-13-rln-v3.mdx
This commit is contained in:
@@ -16,7 +16,7 @@ Introducing and discussing ambient peer discovery methods currently used by Waku
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
[Waku v2](https://rfc.vac.dev/spec/10/) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
[Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2) comprises a set of modular protocols for secure, privacy preserving communication.
|
||||
Avoiding centralization, these protocols exchange messages over a P2P network layer.
|
||||
In order to build a P2P network, participating nodes first have to discover peers within this network.
|
||||
This is where [_ambient peer discovery_](https://docs.libp2p.io/concepts/publish-subscribe/#discovery) comes into play:
|
||||
@@ -129,7 +129,7 @@ If Waku v2 would do the same, only a small subset of the retrieved nodes would s
|
||||
A first naive solution for Waku v2 discv5 discovery is
|
||||
|
||||
- retrieve a random node set, which is achieved by querying for a set of randomly chosen node IDs
|
||||
- filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
|
||||
- filter the returned nodes on the query path based on Waku v2 capability via the [Waku v2 ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
|
||||
- repeat until enough Waku v2 capable nodes are found
|
||||
|
||||
This query process boils down to random walk discovery, which is very resilient against attacks, but also very inefficient if the number of nodes supporting the desired capability is small.
|
||||
@@ -186,7 +186,7 @@ Our current solution and future plans for solving this issue are covered in the
|
||||
|
||||
### Simple Solution: Separate Discovery Network
|
||||
|
||||
The simple solution we currently use for [Waku v2 discv5](https://rfc.vac.dev/spec/33/) is a separate discv5 network.
|
||||
The simple solution we currently use for [Waku v2 discv5](https://rfc.vac.dev/waku/standards/core/33/discv5) is a separate discv5 network.
|
||||
All (well behaving) nodes in this network support Waku v2, resulting in a very high query efficiency.
|
||||
However, this solution reduces resilience because the difficulty of attacking a DHT scales with the number of participating nodes.
|
||||
|
||||
@@ -338,7 +338,7 @@ To mitigate information leakage by transmitting peer lists, we plan to only repl
|
||||
|
||||
## References
|
||||
|
||||
- [Waku v2](https://rfc.vac.dev/spec/10/)
|
||||
- [Waku v2](https://rfc.vac.dev/waku/standards/core/10/waku2)
|
||||
- [libp2p gossipsub](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/README.md)
|
||||
- [unstructured P2P network](https://en.wikipedia.org/wiki/Peer-to-peer#Unstructured_networks)
|
||||
- [ambient peer discovery](https://docs.libp2p.io/concepts/publish-subscribe/#discovery)
|
||||
@@ -351,13 +351,13 @@ To mitigate information leakage by transmitting peer lists, we plan to only repl
|
||||
- [Merkle trees](https://en.wikipedia.org/wiki/Merkle_tree)
|
||||
- [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack)
|
||||
- [eclipse attack](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman)
|
||||
- [Waku v2 ENR](https://rfc.vac.dev/spec/31/)
|
||||
- [Waku v2 ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
|
||||
- [Discv5 topic discovery](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-theory.md#ad-placement-and-topic-radius)
|
||||
- [Discv5 paper](https://github.com/harnen/service-discovery-paper)
|
||||
- [Discv5 vs Sybil and eclipse attacks](https://github.com/ethereum/devp2p/blob/6b0abc3d956a626c28dce1307ee9f546db17b6bd/discv5/discv5-rationale.md#sybil-and-eclipse-attacks)
|
||||
- [peer exchange idea](https://github.com/libp2p/specs/issues/222)
|
||||
- [Rendezvous protocol](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/rendezvous/README.md)
|
||||
- [Waku v2 discv5](https://rfc.vac.dev/spec/33/)
|
||||
- [Waku v2 discv5](https://rfc.vac.dev/waku/standards/core/33/discv5)
|
||||
- [Gossipsub peer exchange](https://github.com/libp2p/specs/blob/10712c55ab309086a52eec7d25f294df4fa96528/pubsub/gossipsub/gossipsub-v1.1.md#prune-backoff-and-peer-exchange)
|
||||
- [NAT traversal](https://docs.libp2p.io/concepts/nat/)
|
||||
- [UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)
|
||||
|
||||
Reference in New Issue
Block a user