AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-08 23:28:15 -05:00
Code Issues Packages Projects Releases Wiki Activity

15/WAKU2-BRIDGE: Update (#113)

Browse Source 
Updating format, adding references and some information.

---------

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
This commit is contained in:
Jimmy Debe
2025-01-28 20:21:01 -05:00
committed by GitHub
parent 7a01711ffc
commit c3d5fe6f88
1 changed files with 63 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
waku/standards/core/15/bridge.md
View File

@@ -7,24 +7,38 @@ tags: waku-core
editor: Hanno Cornelius <hanno@status.im> editor: Hanno Cornelius <hanno@status.im>
--- ---
A bridge between Waku v1 and Waku v2. ## Abstract
## Bridge This specification describes how [6/WAKU1](/waku/standards/legacy/6/waku1.md)
traffic can be used with [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
## Wire Format
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt).
A bridge requires supporting both Waku versions: A bridge requires supporting both Waku versions:
* Waku v1 - using devp2p RLPx protocol * [6/WAKU1](/waku/standards/legacy/6/waku1.md) - using devp2p RLPx protocol
* Waku v2 - using libp2p protocols * [10/WAKU2](/waku/standards/core/10/waku2.md) - using libp2p protocols
Packets received on the Waku v1 network SHOULD be published just once on the ## Publishing Packets
Waku v2 network. More specifically, the bridge SHOULD publish
this through the Waku Relay (PubSub domain).
Publishing such packet will require the creation of a new `Message` with a Packets received on [6/WAKU1](/waku/standards/legacy/6/waku1.md) networks
new `WakuMessage` as data field. The `data` and `topic` field from the Waku v1 SHOULD be published just once on [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
`Envelope` MUST be copied to the `payload` and `contentTopic` fields of the More specifically, the bridge SHOULD publish
`WakuMessage`. Other fields such as nonce, expiry and ttl will be dropped as this through [11/WAKU2-RELAY](/waku/standards/core/11/relay.md) (PubSub domain).
they become obsolete in Waku v2.
When publishing such packet,
the creation of a new `Message` with a new `WakuMessage` as data field is REQUIRED.
The `data` and
`topic` field, from the [6/WAKU1](/waku/standards/legacy/6/waku1.md) `Envelope`,
MUST be copied to the `payload` and `content_topic` fields of the `WakuMessage`.
See [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md#wire-format)
for message format details.
Other fields such as `nonce`, `expiry` and
`ttl` will be dropped as they become obsolete in [10/WAKU2](/waku/standards/core/10/waku2.md).
Before this is done, the usual envelope verification still applies: Before this is done, the usual envelope verification still applies:
@@ -32,37 +46,54 @@ Before this is done, the usual envelope verification still applies:
* PoW verification * PoW verification
* Size verification * Size verification
Bridging SHOULD occur through the `WakuRelay`, but it MAY also be done on other Waku Bridging SHOULD occur through the [11/WAKU2-RELAY](/waku/standards/core/11/relay.md),
v2 protocols (e.g. `WakuFilter`). The latter is however not advised as it will but it MAY also be done on other [10/WAKU2](/waku/standards/core/10/waku2.md) protocols
increase the complexity of the bridge and because of the (e.g. [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)).
[Security Considerations](#security-considerations) explained further below. The latter is however not advised as it will
increase the complexity of the bridge and
because of the [Security Considerations](#security-considerations) explained further below.
Packets received on the Waku v2 network SHOULD be posted just once on the Waku Packets received on [10/WAKU2](/waku/standards/core/10/waku2.md) networks,
v1 network. The Waku v2 `WakuMessage` contains only the `payload` and SHOULD be posted just once on [6/WAKU1](/waku/standards/legacy/6/waku1.md) networks.
`contentTopic` fields. The bridge MUST create a new Waku v1 `Envelope` and The [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md) contains only the `payload` and
copy over the `payload` and `contentFilter` fields to the `data` and `topic` `contentTopic` fields.
fields. Next, before posting on the network, the bridge MUST set a new expiry The bridge MUST create a new [6/WAKU1](/waku/standards/legacy/6/waku1.md) `Envelope` and
and ttl and do the PoW nonce calculation. copy over the `payload` and `contentFilter`
fields to the `data` and `topic` fields.
Next, before posting on the network,
the bridge MUST set a new `expiry`, `ttl` and do the PoW `nonce` calculation.
### Security Considerations ### Security Considerations
As mentioned above, a bridge will be posting new Waku v1 envelopes, which As mentioned above,
requires doing the PoW nonce calculation. a bridge will be posting new [6/WAKU1](/waku/standards/legacy/6/waku1.md) envelopes,
which requires doing the PoW `nonce` calculation.
This could be a DoS attack vector, as the PoW calculation will make it more This could be a DoS attack vector,
expensive to post the message compared to the original publishing on the Waku v2 as the PoW calculation will make it more expensive to post the message
network. Low PoW setting will lower this problem, but it is likely that it is compared to the original publishing on [10/WAKU2](/waku/standards/core/10/waku2.md) networks.
still more expensive. Low PoW setting will lower this problem,
but it is likely that it is still more expensive.
For this reason, bridges SHOULD probably be run independently of other nodes, so For this reason, it is RECOMMENDED to run bridges independently of other nodes,
that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2 so that a bridge that gets overwhelmed does not disrupt regular Waku v2 to v2
traffic. traffic.
Bridging functionality SHOULD also be carefully implemented so that messages do Bridging functionality SHOULD also be carefully implemented so that messages do
not bounce back and forth between the two networks. The bridge SHOULD properly not bounce back and forth between the [10/WAKU2](/waku/standards/core/10/waku2.md) and
track messages with a seen filter so that no amplification can be achieved here. [6/WAKU1](/waku/standards/legacy/6/waku1.md) networks.
The bridge SHOULD properly track messages with a seen filter,
so that no amplification occurs.
## Copyright ## Copyright
Copyright and related rights waived via Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/). [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## References
* [6/WAKU1](/waku/standards/legacy/6/waku1.md)
* [10/WAKU2](/waku/standards/core/10/waku2.md)
* [11/WAKU2-RELAY](/waku/standards/core/11/relay.md)
* [14/WAKU2-MESSAGE](/waku/standards/core/14/message.md)
* [12/WAKU2-FILTER](/waku/standards/core/12/filter.md)