vacp2p
/
rfc-index
mirror of https://github.com/vacp2p/rfc-index.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update and rename RELAY.md to relay.md

This commit is contained in:
Jimmy Debe 2024-02-01 20:26:26 -05:00 committed by GitHub
parent 8e14d584bf
commit 0904a8b592
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
waku/standards/core/11/RELAY.md → waku/standards/core/11/relay.md
View File

@ -20,7 +20,7 @@ As such the scope is limited to defining a separate [`protocol id`](https://gith
# Security Requirements # Security Requirements
The `11/WAKU2-RELAY` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model). The `11/WAKU2-RELAY` protocol is designed to provide the following security properties under a static [Adversarial Model](#adversarial-model).
Note that data confidentiality, integrity, and authenticity are currently considered out of scope for `11/WAKU2-RELAY` and must be handled by higher layer protocols such as [`14/WAKU2-MESSAGE`](/spec/14). Note that data confidentiality, integrity, and authenticity are currently considered out of scope for `11/WAKU2-RELAY` and must be handled by higher layer protocols such as [`14/WAKU2-MESSAGE`](../14/message.md).
<!-- May add the definition of the unsupported feature: <!-- May add the definition of the unsupported feature:
Confidentiality indicates that an adversary should not be able to learn the data carried by the `WakuRelay` protocol. Confidentiality indicates that an adversary should not be able to learn the data carried by the `WakuRelay` protocol.
@ -99,7 +99,7 @@ The `Message` protobuf defines the format in which content is relayed between pe
- The `from` field MUST NOT be used, following the [`StrictNoSign` signature policy](#signature-policy). - The `from` field MUST NOT be used, following the [`StrictNoSign` signature policy](#signature-policy).
- The `data` field MUST be filled out with a `WakuMessage`. - The `data` field MUST be filled out with a `WakuMessage`.
See [`14/WAKU2-MESSAGE`](/spec/14) for more details. See [`14/WAKU2-MESSAGE`](../14/message.md) for more details.
- The `seqno` field MUST NOT be used, following the [`StrictNoSign` signature policy](#signature-policy). - The `seqno` field MUST NOT be used, following the [`StrictNoSign` signature policy](#signature-policy).
@ -120,7 +120,7 @@ The following usage requirements apply:
- The `topicid` field MUST contain the pubsub topic. - The `topicid` field MUST contain the pubsub topic.
> Note: The `topicid` refering to pubsub topic and > Note: The `topicid` refering to pubsub topic and
`topicId` refering to content-topic are detailed in [23/WAKU2-TOPICS](https://rfc.vac.dev/spec/23/). `topicId` refering to content-topic are detailed in [23/WAKU2-TOPICS](../../../informational/23/topics.md).
## Signature Policy ## Signature Policy
@ -140,7 +140,7 @@ The direct connections of a publisher might be able to figure out which `Message
The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. <!-- TODO: more investigation on traffic analysis attacks and their success probability--> The possibility of such inference may get higher when the `data` field is also not encrypted by the upper-level protocols. <!-- TODO: more investigation on traffic analysis attacks and their success probability-->
- **Subscriber-Topic Unlinkability:** - **Subscriber-Topic Unlinkability:**
To preserve subscriber-topic unlinkability, it is recommended by [`10/WAKU2`](/spec/10) to use a single PubSub topic in the `11/WAKU2-RELAY` protocol. To preserve subscriber-topic unlinkability, it is recommended by [`10/WAKU2`](../10/waku2.md) to use a single PubSub topic in the `11/WAKU2-RELAY` protocol.
This allows an immediate subscriber-topic unlinkability where subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID. This allows an immediate subscriber-topic unlinkability where subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID.
This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/) where k is proportional to the system size (number of participants of Waku relay protocol). This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/) where k is proportional to the system size (number of participants of Waku relay protocol).
However, note that `11/WAKU2-RELAY` supports the use of more than one topic. However, note that `11/WAKU2-RELAY` supports the use of more than one topic.
@ -154,7 +154,7 @@ Spam protection is partly provided by GossipSub v1.1 through [scoring mechanism]
At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score. At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score.
`11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers. `11/WAKU2-RELAY` aims at enabling an advanced spam protection mechanism with economic disincentives by utilizing Rate Limiting Nullifiers.
In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate. In a nutshell, peers must conform to a certain message publishing rate per a system-defined epoch, otherwise, they get financially penalized for exceeding the rate.
More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](/spec/17). More details on this new technique can be found in [`17/WAKU2-RLN-RELAY`](../17/rln-relay.md).
<!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code --> <!-- TODO havn't checked if all the measures in libp2p GossipSub v1.1 are taken in the nim-libp2p as well, may need to audit the code -->
- Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously: - Providing **Unlinkability**, **Integrity** and **Authenticity** simultaneously:
@ -170,11 +170,11 @@ Copyright and related rights waived via
# References # References
1. [`10/WAKU2`](/spec/10) 1. [`10/WAKU2`](../10/waku2.md)
1. [`14/WAKU2-MESSAGE`](/spec/14) 1. [`14/WAKU2-MESSAGE`](../14/message.md)
1. [`17/WAKU-RLN`](/spec/17) 1. [`17/WAKU-RLN`](../17/rln-relay.md)
1. [GossipSub v1.0](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md) 1. [GossipSub v1.0](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md)
@ -192,6 +192,6 @@ Copyright and related rights waived via
1. [PubSub interface for libp2p (r2, 2019-02-01)](https://github.com/libp2p/specs/blob/master/pubsub/README.md) 1. [PubSub interface for libp2p (r2, 2019-02-01)](https://github.com/libp2p/specs/blob/master/pubsub/README.md)
1. [Waku v1 spec](https://specs.vac.dev/waku/waku.html) 1. [Waku v1 spec](../6/waku1.md)
1. [Whisper spec (EIP627)](https://eips.ethereum.org/EIPS/eip-627) 1. [Whisper spec (EIP627)](https://eips.ethereum.org/EIPS/eip-627)