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:
Jimmy Debe
2025-03-04 14:01:14 -05:00
committed by GitHub
parent fba3a2d7c3
commit 062761386f
24 changed files with 107 additions and 106 deletions

View File

@@ -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)