mirror of
https://github.com/logos-messaging/docs.waku.org.git
synced 2026-01-02 12:53:12 +00:00
feat: upgrade docusaurus and preset version
This commit is contained in:
jinhojang6
parent
1bebfcb396
commit
ad0b0edc11
@ -83,7 +83,7 @@
|
||||
"IPFS",
|
||||
"cheatsheet",
|
||||
"hacken",
|
||||
"statusteam",
|
||||
"statusteam"
|
||||
],
|
||||
"flagWords": [],
|
||||
"ignorePaths": [
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
[](https://docs.waku.org/)
|
||||
|
||||
The Waku Documentation Portal can be accessed at <https://docs.waku.org/> and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
The Waku Documentation Portal can be accessed at [https://docs.waku.org/](https://docs.waku.org/) and was built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -88,8 +88,8 @@ yarn clear
|
||||
|
||||
## CI/CD
|
||||
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at <https://docs.waku.org/>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at <https://dev-docs.waku.org/>.
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/docs.waku.org/) `master` and pushes to `deploy-master` branch, which is hosted at [https://docs.waku.org/](https://docs.waku.org/).
|
||||
- [CI builds](https://ci.infra.status.im/job/website/job/dev-docs.waku.org/) `develop` and pushes to `deploy-develop` branch, which is hosted at [https://dev-docs.waku.org/](https://dev-docs.waku.org/).
|
||||
|
||||
The hosting is done using [Caddy server with Git plugin for handling GitHub webhooks](https://github.com/status-im/infra-misc/blob/master/ansible/roles/caddy-git).
|
||||
|
||||
@ -101,4 +101,3 @@ Information about deployed build can be also found in `/build.json` available on
|
||||
2. Make your changes, push them to the origin, and open a Pull Request against the develop branch.
|
||||
3. After approval, merge the pull request, and verify the changes on the staging server (e.g., https://dev.vac.dev).
|
||||
4. When ready to promote changes to the live website, rebase the master branch on the staging changes: git checkout master; git pull origin master; git rebase origin/develop; git push.
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ Check out our [Learn section](/learn/waku-network), [YouTube channel](https://ww
|
||||
8. **Social Media Platforms**: Beyond chat messengers, use Waku for decentralised, censorship-resistant social media platforms like news feeds and multimedia sharing.
|
||||
|
||||
:::tip
|
||||
Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: https://ideas.waku.org/ and [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
Looking for what to build with Waku? Discover a collection of sample ideas and use cases for inspiration, curated by our community at: [https://ideas.waku.org/](https://ideas.waku.org/) and [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
:::
|
||||
|
||||
## Case studies
|
||||
@ -89,5 +89,5 @@ Waku is implemented in multiple SDKs, allowing it to integrate with different la
|
||||
| [@waku/create-app](https://www.npmjs.com/package/@waku/create-app) | Starter kit to bootstrap your next `@waku/sdk` project from various example templates | [Scaffold DApps Using @waku/create-app](/guides/js-waku/use-waku-create-app) |
|
||||
|
||||
:::tip
|
||||
Explore some example apps built using Waku at https://examples.waku.org/ and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
Explore some example apps built using Waku at [https://examples.waku.org/](https://examples.waku.org/) and view a list of projects and workshops from previous hackathons at [Awesome Waku](https://github.com/waku-org/awesome-waku/).
|
||||
:::
|
||||
|
||||
@ -3,6 +3,9 @@ title: Bootstrap Nodes and Discover Peers
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This guide provides detailed steps to bootstrap your your node using [Static Peers](/learn/concepts/static-peers) and discover peers in the Waku Network using [DNS Discovery](/learn/concepts/dns-discovery).
|
||||
|
||||
:::info
|
||||
@ -33,7 +36,7 @@ import { createLightNode } from "@waku/sdk";
|
||||
|
||||
// Bootstrap node using static peers
|
||||
const node = await createLightNode({
|
||||
bootstrapPeers: ["[PEER MULTIADDR]"],
|
||||
bootstrapPeers: ["[PEER MULTIADDR]"],
|
||||
});
|
||||
```
|
||||
|
||||
@ -42,26 +45,25 @@ For example, consider a node that connects to two static peers on the same local
|
||||
```js
|
||||
// Define the list of static peers to bootstrap
|
||||
const peers = [
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
];
|
||||
|
||||
// Bootstrap node using the static peers
|
||||
const node = await createLightNode({
|
||||
bootstrapPeers: peers,
|
||||
bootstrapPeers: peers,
|
||||
});
|
||||
```
|
||||
|
||||
Alternatively, you can dial a particular node like this:
|
||||
Alternatively, you can dial a particular node like this:
|
||||
|
||||
```js
|
||||
// Define the list of static peers to bootstrap
|
||||
const peers = [
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
];
|
||||
|
||||
|
||||
const node = await createLightNode();
|
||||
|
||||
// In case nodes are using IP address and / or `ws` protocol - additional configuration is needed:
|
||||
@ -73,7 +75,7 @@ const node = await createLightNode({
|
||||
});
|
||||
*/
|
||||
|
||||
const promises = peers.map(multiaddr => node.dial(multiaddr));
|
||||
const promises = peers.map((multiaddr) => node.dial(multiaddr));
|
||||
|
||||
await Promise.all(promises);
|
||||
```
|
||||
@ -114,21 +116,16 @@ const enrTree = "enrtree://[PUBLIC KEY]@[DOMAIN NAME]";
|
||||
|
||||
// Define node requirements
|
||||
const NODE_REQUIREMENTS = {
|
||||
store: 3,
|
||||
lightPush: 3,
|
||||
filter: 3,
|
||||
store: 3,
|
||||
lightPush: 3,
|
||||
filter: 3,
|
||||
};
|
||||
|
||||
// Bootstrap node using DNS Discovery
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
],
|
||||
},
|
||||
libp2p: {
|
||||
peerDiscovery: [wakuDnsDiscovery([enrTree], NODE_REQUIREMENTS)],
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
@ -139,14 +136,11 @@ import { enrTree } from "@waku/dns-discovery";
|
||||
|
||||
// Bootstrap node using DNS Discovery
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree["PROD"], enrTree["TEST"]],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
],
|
||||
},
|
||||
libp2p: {
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery([enrTree["PROD"], enrTree["TEST"]], NODE_REQUIREMENTS),
|
||||
],
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
@ -161,28 +155,23 @@ import { enrTree, wakuDnsDiscovery } from "@waku/dns-discovery";
|
||||
|
||||
// Define the list of static peers to bootstrap
|
||||
const peers = [
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
"/ip4/0.0.0.0/tcp/60002/ws/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H",
|
||||
"/ip4/0.0.0.0/tcp/60003/ws/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ",
|
||||
];
|
||||
|
||||
// Define node requirements
|
||||
const NODE_REQUIREMENTS = {
|
||||
store: 3,
|
||||
lightPush: 3,
|
||||
filter: 3,
|
||||
store: 3,
|
||||
lightPush: 3,
|
||||
filter: 3,
|
||||
};
|
||||
|
||||
// Bootstrap node using DNS Discovery and static peers
|
||||
const node = await createLightNode({
|
||||
libp2p: {
|
||||
bootstrapPeers: peers,
|
||||
peerDiscovery: [
|
||||
wakuDnsDiscovery(
|
||||
[enrTree["PROD"]],
|
||||
NODE_REQUIREMENTS,
|
||||
),
|
||||
],
|
||||
},
|
||||
libp2p: {
|
||||
bootstrapPeers: peers,
|
||||
peerDiscovery: [wakuDnsDiscovery([enrTree["PROD"]], NODE_REQUIREMENTS)],
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
@ -198,4 +187,4 @@ await node.waitForPeers();
|
||||
|
||||
// Retrieve array of peers connected to the node
|
||||
console.log(node.libp2p.getPeers());
|
||||
```
|
||||
```
|
||||
@ -53,8 +53,8 @@ import { createEncoder } from "@waku/message-encryption/symmetric";
|
||||
|
||||
// Create a symmetric message encoder
|
||||
const encoder = createEncoder({
|
||||
contentTopic: contentTopic, // message content topic
|
||||
symKey: symmetricKey, // symmetric key for encrypting messages
|
||||
contentTopic: contentTopic, // message content topic
|
||||
symKey: symmetricKey, // symmetric key for encrypting messages
|
||||
});
|
||||
|
||||
// Send the message using Light Push
|
||||
@ -101,8 +101,8 @@ import { createEncoder } from "@waku/message-encryption/ecies";
|
||||
|
||||
// Create an ECIES message encoder
|
||||
const encoder = createEncoder({
|
||||
contentTopic: contentTopic, // message content topic
|
||||
publicKey: publicKey, // ECIES public key for encrypting messages
|
||||
contentTopic: contentTopic, // message content topic
|
||||
publicKey: publicKey, // ECIES public key for encrypting messages
|
||||
});
|
||||
|
||||
// Send the message using Light Push
|
||||
@ -151,16 +151,16 @@ const alicePublicKey = getPublicKey(alicePrivateKey);
|
||||
|
||||
// Create a symmetric encoder that signs messages
|
||||
const symmetricEncoder = createSymmetricEncoder({
|
||||
contentTopic: contentTopic, // message content topic
|
||||
symKey: symmetricKey, // symmetric key for encrypting messages
|
||||
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
|
||||
contentTopic: contentTopic, // message content topic
|
||||
symKey: symmetricKey, // symmetric key for encrypting messages
|
||||
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
|
||||
});
|
||||
|
||||
// Create an ECIES encoder that signs messages
|
||||
const ECIESEncoder = createECIESEncoder({
|
||||
contentTopic: contentTopic, // message content topic
|
||||
publicKey: publicKey, // ECIES public key for encrypting messages
|
||||
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
|
||||
contentTopic: contentTopic, // message content topic
|
||||
publicKey: publicKey, // ECIES public key for encrypting messages
|
||||
sigPrivKey: alicePrivateKey, // private key for signing messages before encryption
|
||||
});
|
||||
|
||||
// Send and receive your messages as usual with Light Push and Filter
|
||||
@ -183,25 +183,25 @@ const bobPrivateKey = generatePrivateKey();
|
||||
|
||||
// Create an encoder that signs messages
|
||||
const encoder = createEncoder({
|
||||
contentTopic: contentTopic,
|
||||
symKey: symmetricKey,
|
||||
sigPrivKey: bobPrivateKey,
|
||||
contentTopic: contentTopic,
|
||||
symKey: symmetricKey,
|
||||
sigPrivKey: bobPrivateKey,
|
||||
});
|
||||
|
||||
// Modify the callback function to verify message signature
|
||||
const callback = (wakuMessage) => {
|
||||
// Extract the message signature and public key of the signature
|
||||
// You can compare the signaturePublicKey with Alice public key
|
||||
const signature = wakuMessage.signature;
|
||||
const signaturePublicKey = wakuMessage.signaturePublicKey;
|
||||
// Extract the message signature and public key of the signature
|
||||
// You can compare the signaturePublicKey with Alice public key
|
||||
const signature = wakuMessage.signature;
|
||||
const signaturePublicKey = wakuMessage.signaturePublicKey;
|
||||
|
||||
// Verify the message was actually signed and sent by Alice
|
||||
// Alice's public key can be gotten from broadcasting or out-of-band methods
|
||||
if (wakuMessage.verifySignature(alicePublicKey)) {
|
||||
console.log("This message was signed by Alice");
|
||||
} else {
|
||||
console.log("This message was NOT signed by Alice");
|
||||
}
|
||||
// Verify the message was actually signed and sent by Alice
|
||||
// Alice's public key can be gotten from broadcasting or out-of-band methods
|
||||
if (wakuMessage.verifySignature(alicePublicKey)) {
|
||||
console.log("This message was signed by Alice");
|
||||
} else {
|
||||
console.log("This message was NOT signed by Alice");
|
||||
}
|
||||
};
|
||||
|
||||
await subscription.subscribe([encoder], callback);
|
||||
@ -233,4 +233,4 @@ const restoredPrivateKey = hexToBytes(privateKeyHex);
|
||||
You have successfully encrypted, decrypted, and signed your messages using `Symmetric` and `ECIES` encryption methods. Have a look at the [eth-pm](https://github.com/waku-org/js-waku-examples/tree/master/examples/eth-pm) example for a working demo.
|
||||
:::
|
||||
|
||||
<!-- [flush-notes](https://github.com/waku-org/js-waku-examples/tree/master/examples/flush-notes) and -->
|
||||
<!-- [flush-notes](https://github.com/waku-org/js-waku-examples/tree/master/examples/flush-notes) and -->
|
||||
@ -31,4 +31,4 @@ Before using `@waku/sdk` in a NodeJS environment, take into account these limita
|
||||
|
||||
## Future developments
|
||||
|
||||
There are plans to release a NodeJS package based on [nwaku](/guides/nwaku/run-node) to streamline the process of using Waku Network features in NodeJS applications. You can track the progress and updates here: <https://github.com/waku-org/nwaku/issues/1332>.
|
||||
There are plans to release a NodeJS package based on [nwaku](/guides/nwaku/run-node) to streamline the process of using Waku Network features in NodeJS applications. You can track the progress and updates here: [https://github.com/waku-org/nwaku/issues/1332](https://github.com/waku-org/nwaku/issues/1332).
|
||||
|
||||
@ -49,4 +49,4 @@ We welcome and appreciate the contributions of templates for the `@waku/create-a
|
||||
4. Finally, submit a pull request to the [js-waku-examples](https://github.com/waku-org/js-waku-examples) repository.
|
||||
5. Our team will carefully review and merge your submission upon approval.
|
||||
|
||||
Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to <https://github.com/waku-org/bounties>.
|
||||
Waku also provides bounties to encourage community members to contribute to the network and earn rewards. To participate in the bounty program, head to [https://github.com/waku-org/bounties](https://github.com/waku-org/bounties).
|
||||
|
||||
@ -7,9 +7,9 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## Application-level config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| ----------------- | --------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) |
|
||||
| Name | Default Value | Description |
|
||||
| ----------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `config-file` | | Loads configuration from a TOML file (cmd-line parameters take precedence) |
|
||||
| `protected-shard` | `newSeq[ProtectedShard](0)` | Shards and its public keys to be used for message validation, shard:pubkey. Argument may be repeated |
|
||||
|
||||
## Log config
|
||||
@ -21,21 +21,21 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## General node config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
|
||||
| `cluster-id` | `0` | Cluster id that the node is running in. Node in a different cluster id is disconnected |
|
||||
| `agent-string` | `nwaku` | Node agent string which is used as identifier in network |
|
||||
| `nodekey` | | P2P node private key as 64-char hex string |
|
||||
| `listen-address` | `defaultListenAddress()` | Listening address for LibP2P (and Discovery v5, if enabled) traffic |
|
||||
| `tcp-port` | `60000` | TCP listening port |
|
||||
| `ports-shift` | `0` | Add a shift to all port numbers |
|
||||
| `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:<IP\> |
|
||||
| `ext-multiaddr` | | External multiaddresses to advertise to the network. Argument may be repeated |
|
||||
| `ext-multiaddr-only` | `false` | Only announce external multiaddresses |
|
||||
| `max-connections` | `50` | Maximum allowed number of libp2p connections |
|
||||
| Name | Default Value | Description |
|
||||
| --------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `cluster-id` | `0` | Cluster id that the node is running in. Node in a different cluster id is disconnected |
|
||||
| `agent-string` | `nwaku` | Node agent string which is used as identifier in network |
|
||||
| `nodekey` | | P2P node private key as 64-char hex string |
|
||||
| `listen-address` | `defaultListenAddress()` | Listening address for LibP2P (and Discovery v5, if enabled) traffic |
|
||||
| `tcp-port` | `60000` | TCP listening port |
|
||||
| `ports-shift` | `0` | Add a shift to all port numbers |
|
||||
| `nat` | any | Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:IP |
|
||||
| `ext-multiaddr` | | External multiaddresses to advertise to the network. Argument may be repeated |
|
||||
| `ext-multiaddr-only` | `false` | Only announce external multiaddresses |
|
||||
| `max-connections` | `50` | Maximum allowed number of libp2p connections |
|
||||
| `relay-service-ratio` | `"60:40"` | This percentage ratio represents the relay peers to service peers. For example, 60:40, tells that 60% of the max-connections will be used for relay protocol and the other 40% of max-connections will be reserved for other service protocols (e.g., filter, lightpush, store, metadata, etc.) |
|
||||
| `peer-store-capacity` | | Maximum stored peers in the peerstore |
|
||||
| `peer-persistence` | `false` | Enable peer persistence |
|
||||
| `peer-store-capacity` | | Maximum stored peers in the peerstore |
|
||||
| `peer-persistence` | `false` | Enable peer persistence |
|
||||
|
||||
## DNS addrs config
|
||||
|
||||
@ -47,31 +47,30 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## Relay config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| -------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `relay` | `true` | Enable relay protocol: true\|false |
|
||||
| `relay-peer-exchange` | `false` | Enable gossipsub peer exchange in relay protocol: true\|false |
|
||||
| `rln-relay` | `false` | Enable spam protection through rln-relay: true\|false |
|
||||
| `rln-relay-cred-path` | | The path for persisting rln-relay credential |
|
||||
| `rln-relay-membership-index` | | The index of the onchain commitment to use |
|
||||
| `rln-relay-dynamic` | `false` | Enable waku-rln-relay with on-chain dynamic group management: true\|false |
|
||||
| `rln-relay-id-key` | | Rln relay identity secret key as a Hex string |
|
||||
| `rln-relay-id-commitment-key` | | Rln relay identity commitment key as a Hex string |
|
||||
| `rln-relay-eth-client-address` | `ws://localhost:8540/` | WebSocket address of an Ethereum testnet client e.g., `ws://localhost:8540/` |
|
||||
| `rln-relay-eth-contract-address` | | Address of membership contract on an Ethereum testnet |
|
||||
| `rln-relay-eth-private-key` | | Private key for broadcasting transactions |
|
||||
| `execute` | `false` | Runs the registration function on-chain. By default, a dry-run will occur |
|
||||
| `rln-relay-cred-password` | | Password for encrypting RLN credentials |
|
||||
| `rln-relay-tree-path` | | Path to the RLN merkle tree sled db (https://github.com/spacejam/sled) |
|
||||
| `rln-relay-bandwidth-threshold` | `0 # to maintain backwards compatibility` | Message rate in bytes/sec after which verification of proofs should happen |
|
||||
| `staticnode` | | Peer multiaddr to directly connect with. Argument may be repeated |
|
||||
| `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false |
|
||||
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead |
|
||||
| `shard` | | Shard to subscribe to. Argument may be repeated |
|
||||
| `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding |
|
||||
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
|
||||
| `reliability` | `false` | Enable experimental reliability protocol true\|false |
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| -------------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `relay` | `true` | Enable relay protocol: true\|false |
|
||||
| `relay-peer-exchange` | `false` | Enable gossipsub peer exchange in relay protocol: true\|false |
|
||||
| `rln-relay` | `false` | Enable spam protection through rln-relay: true\|false |
|
||||
| `rln-relay-cred-path` | | The path for persisting rln-relay credential |
|
||||
| `rln-relay-membership-index` | | The index of the onchain commitment to use |
|
||||
| `rln-relay-dynamic` | `false` | Enable waku-rln-relay with on-chain dynamic group management: true\|false |
|
||||
| `rln-relay-id-key` | | Rln relay identity secret key as a Hex string |
|
||||
| `rln-relay-id-commitment-key` | | Rln relay identity commitment key as a Hex string |
|
||||
| `rln-relay-eth-client-address` | `ws://localhost:8540/` | WebSocket address of an Ethereum testnet client e.g., `ws://localhost:8540/` |
|
||||
| `rln-relay-eth-contract-address` | | Address of membership contract on an Ethereum testnet |
|
||||
| `rln-relay-eth-private-key` | | Private key for broadcasting transactions |
|
||||
| `execute` | `false` | Runs the registration function on-chain. By default, a dry-run will occur |
|
||||
| `rln-relay-cred-password` | | Password for encrypting RLN credentials |
|
||||
| `rln-relay-tree-path` | | Path to the RLN merkle tree sled db (https://github.com/spacejam/sled) |
|
||||
| `rln-relay-bandwidth-threshold` | `0 # to maintain backwards compatibility` | Message rate in bytes/sec after which verification of proofs should happen |
|
||||
| `staticnode` | | Peer multiaddr to directly connect with. Argument may be repeated |
|
||||
| `keep-alive` | `false` | Enable keep-alive for idle connections: true\|false |
|
||||
| `pubsub-topic` | | Default pubsub topic to subscribe to. Argument may be repeated. **Deprecated!** Please use `shard` and/or `content-topic` instead |
|
||||
| `shard` | | Shard to subscribe to. Argument may be repeated |
|
||||
| `num-shards-in-network` | | Number of shards in the network. Used to map content topics to shards when using autosharding |
|
||||
| `content-topic` | | Default content topic to subscribe to. Argument may be repeated |
|
||||
| `reliability` | `false` | Enable experimental reliability protocol true\|false |
|
||||
|
||||
## Store and message store config
|
||||
|
||||
@ -86,12 +85,12 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## Store Sync
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| -------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `store-sync` | `false` | Enable/disable waku store sync protocol |
|
||||
| `store-sync-interval` | `300` 5 minutes | Interval between store synchronization attempts |
|
||||
| `store-sync-range` | `3600` 1 hour | Amount of time to sync |
|
||||
| `store-sync-relay-jitter` | `20` seconds | Sync range offset to account for relay's message propagation jitter |
|
||||
| Name | Default Value | Description |
|
||||
| ------------------------- | --------------- | ------------------------------------------------------------------- |
|
||||
| `store-sync` | `false` | Enable/disable waku store sync protocol |
|
||||
| `store-sync-interval` | `300` 5 minutes | Interval between store synchronization attempts |
|
||||
| `store-sync-range` | `3600` 1 hour | Amount of time to sync |
|
||||
| `store-sync-relay-jitter` | `20` seconds | Sync range offset to account for relay's message propagation jitter |
|
||||
|
||||
## Filter config
|
||||
|
||||
@ -106,8 +105,8 @@ Here are the available node configuration options, along with their default valu
|
||||
## Light push config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------- | ------------- | --------------------------------------------------------- |
|
||||
| `lightpush` | `false` | Enable lightpush protocol: true\|false |
|
||||
| --------------- | ------------- | --------------------------------------------------------- | ----- |
|
||||
| `lightpush` | `false` | Enable lightpush protocol: true | false |
|
||||
| `lightpushnode` | | Peer multiaddr to request lightpush of published messages |
|
||||
|
||||
## REST HTTP config
|
||||
@ -132,12 +131,12 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## DNS discovery config
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| --------------------------- | ------------------------ | ---------------------------------------------------------- |
|
||||
| `dns-discovery` | `false` | Enable discovering nodes via DNS |
|
||||
| `dns-discovery-url` | | URL for DNS node list in format 'enrtree://<key\>@<fqdn\>' |
|
||||
| `dns-discovery-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query. Argument may be repeated |
|
||||
| `rendezvous` | `true` | Enable waku rendezvous discovery server |
|
||||
| Name | Default Value | Description |
|
||||
| --------------------------- | ------------------------ | ------------------------------------------------------------ |
|
||||
| `dns-discovery` | `false` | Enable discovering nodes via DNS |
|
||||
| `dns-discovery-url` | | URL for DNS node list in format `'enrtree://<key\>@<fqdn\>'` |
|
||||
| `dns-discovery-name-server` | `["1.1.1.1", "1.0.0.1"]` | DNS name server IPs to query. Argument may be repeated |
|
||||
| `rendezvous` | `true` | Enable waku rendezvous discovery server |
|
||||
|
||||
## Discv5 config
|
||||
|
||||
@ -170,9 +169,9 @@ Here are the available node configuration options, along with their default valu
|
||||
|
||||
## Non-relay, request-response protocol DOS protection configuration
|
||||
|
||||
| Name | Default Value | Description |
|
||||
| ---------------------------- | ------------- | ------------------------------------------------------ |
|
||||
| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br />Formatted as:`<protocol>:volume/period<time-unit>`<br />- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br />-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br />-volume must be an integer value, representing number of requests over the period of time allowed.<br />-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br />- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br />- In case of multiple set of the same protocol limit, last one will take place.<br />- if config is not set, - which is the default - means unlimited requests are allowed.<br />-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br /><br />Examples:<br />`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br />`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br />`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br />`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. |
|
||||
| Name | Default Value | Description |
|
||||
| ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `rate-limit` | | This is a repeatable option. Each can describe a specific rate limit configuration for a particular protocol.<br />Formatted as:`<protocol>:volume/period<time-unit>`<br />- if protocol is not given, settings will be taken as default for un-set protocols. Ex: `80/2s`<br />-Supported protocols are: `lightpush`\|`filter`\|`px`\|`store`\|`storev2`\|`storev3`<br />-volume must be an integer value, representing number of requests over the period of time allowed.<br />-period\<time-unit\> must be an integer with defined unit as one of `h`\|`m`\|`s`\|`ms`<br />- `storev2` and `storev3` takes precedence over `store` which can easy set both store protocols at once.<br />- In case of multiple set of the same protocol limit, last one will take place.<br />- if config is not set, - which is the default - means unlimited requests are allowed.<br />-filter has a bit different approach. It has a default setting applied if not overridden. Rate limit setting for filter will be applied per subscriber-peers, not globally - it must be considered when changing the setting.<br /><br />Examples:<br />`--rate-limit="100/1s"` - default for all protocols if not set otherwise.<br />`--rate-limit="lightpush:0/0s"` - lightpush protocol will not be rate-limited.<br />`--rate-limit="store:130/1500ms"` - both store-v3 and store-v2 will apply 130 request per each 1500ms separately.<br />`--rate-limit="px:10/1h"` PeerExchange will serve only 10 requests every hour.<br />`--rate-limit="filter:8/5m"` - will allow 8 subs/unsubs/ping requests for each subscriber within every 5 min. |
|
||||
|
||||
:::tip
|
||||
To configure your node using the provided configuration options, have a look at the [Node Configuration Methods](/guides/nwaku/config-methods) guide.
|
||||
|
||||
@ -81,7 +81,7 @@ docker-compose logs -f nwaku
|
||||
|
||||
## Monitor the node
|
||||
|
||||
Visit <http://localhost:3000/d/yns_4vFVk/nwaku-monitoring> to view your node metrics in real time.
|
||||
Visit [http://localhost:3000/d/yns_4vFVk/nwaku-monitoring](http://localhost:3000/d/yns_4vFVk/nwaku-monitoring) to view your node metrics in real time.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -9,14 +9,14 @@ The following features are currently experimental and under research and initial
|
||||
|
||||
We aim to enable an incentivised spam protection technique to enhance `Relay` by using [Rate Limit Nullifiers (RLN)](https://rfc.vac.dev/vac/32/rln-v1/). In this advanced method, peers are limited to a certain messaging rate per epoch, and an immediate financial penalty is enforced for spammers who break this rate. You can find more details in the [RLN Relay blog post](https://vac.dev/rln-relay).
|
||||
|
||||
We have prepared a PoC implementation of this method in JS: <https://examples.waku.org/rln-js/>
|
||||
We have prepared a PoC implementation of this method in JS: [https://examples.waku.org/rln-js/](https://examples.waku.org/rln-js/)
|
||||
|
||||
## Prevention of denial of service (DoS) and node incentivisation
|
||||
|
||||
Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can be tracked from here: <https://github.com/vacp2p/research/issues/148>.
|
||||
Denial of service signifies the case where an adversarial peer exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system. RnD on DoS attack mitigation can be tracked from here: [https://github.com/vacp2p/research/issues/148](https://github.com/vacp2p/research/issues/148).
|
||||
|
||||
In a nutshell, peers have to pay for the service they obtain from each other. In addition to incentivising the service provider, accounting also makes DoS attacks costly for malicious peers. The accounting model can be used in `Store` and `Filter` to protect against DoS attacks.
|
||||
|
||||
Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: <https://vac.dev/building-privacy-protecting-infrastructure>
|
||||
Additionally, along with RLN, this gives node operators who provide a useful service to the network an incentive to perform that service. Read more here: [https://vac.dev/building-privacy-protecting-infrastructure](https://vac.dev/building-privacy-protecting-infrastructure)
|
||||
|
||||
You can also read more about the ongoing challenges the Waku team is working on here: <https://github.com/waku-org/research>
|
||||
You can also read more about the ongoing challenges the Waku team is working on here: [https://github.com/waku-org/research](https://github.com/waku-org/research)
|
||||
|
||||
@ -22,7 +22,7 @@ Anonymity means an adversary cannot connect an actor to their actions or data. T
|
||||
|
||||
The spam protection feature in `Relay` ensures that no adversary can flood the system with many messages, intentionally or not, regardless of the content's validity or usefulness. This protection is achieved through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) of `GossipSub v1.1`. Peers assign scores to their connections based on their behaviour and remove peers with low scores.
|
||||
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/learn/concepts/protocols#rln-relay), which can be explored further at: <https://github.com/vacp2p/research/issues/148>.
|
||||
Ongoing research is being conducted, including developing [Rate Limit Nullifiers (RLN)](/learn/concepts/protocols#rln-relay), which can be explored further at: [https://github.com/vacp2p/research/issues/148](https://github.com/vacp2p/research/issues/148).
|
||||
|
||||
## [Data confidentiality, integrity, and authenticity](https://rfc.vac.dev/waku/standards/core/10/waku2/#data-confidentiality-integrity-and-authenticity)
|
||||
|
||||
|
||||
@ -5,12 +5,14 @@ title: RLN Key Benchmarks
|
||||
## Introduction
|
||||
|
||||
Since RLN has been chosen as the spamming protection mechanism for waku, we must understand the practical implications of using it. This issue explains the main differences between `relay` and `rln-relay` and gives some benchmarks after running simulations using `waku-simulator`, in a network with the following characteristics:
|
||||
|
||||
- 100 nwaku nodes, each one with a valid rln membership and publishing a message every 10 seconds to a common topic.
|
||||
- rln contract deployed in Ethereum Sepolia
|
||||
- 10.000 memberships registered in the contract
|
||||
- pure relay (store and light protocols disabled)
|
||||
|
||||
The main deltas `rln` vs `rln-relay` are:
|
||||
|
||||
- New `proof ` field in `WakuMessage` containing 384 extra bytes. This field must be generated and attached to each message.
|
||||
- New validator, that uses `proof` to `Accept` or `Reject` the message. The proof has to be verified.
|
||||
- New dependency on a blockchain, Ethereum, or any EVM chain, to keep track of the members allowed to publish.
|
||||
@ -18,6 +20,7 @@ The main deltas `rln` vs `rln-relay` are:
|
||||
But what are the practical implications of these?
|
||||
|
||||
## TLDR:
|
||||
|
||||
- Proof generation is constant-ish. 0.15 second for each proof
|
||||
- Proof verification is constant-ish, 0.012 seconds. In a network with 10k nodes and D=6 this would add an overhead delay of 0.06 seconds.
|
||||
- Gossipsub scoring drops connections from spammer peers, which acts as the punishment (instead of slashing). Validated in the simulation.
|
||||
@ -33,7 +36,7 @@ Seems that proof generation times stay constant no matter the size of the messag
|
||||
|
||||
On the other hand, rln also adds an overhead in the gossipsub validation process. On average it takes `0.012 seconds` to verify the proof. It seems that when we increase the message size, validation time seems to increase a bit, which can be for any other reason besides rln itself (eg deserializing the message might take longer).
|
||||
|
||||
This number seems reasonable and shouldn't affect that much the average delay of a message. Assuming a d-regular graph, with `10k` nodes and `D=6`, we can have up to `log(total_nodes)/log(D)=5` hops. So in the worst case, rln will add a network latency of `0.012*5 = 0.06 seconds`
|
||||
This number seems reasonable and shouldn't affect that much the average delay of a message. Assuming a d-regular graph, with `10k` nodes and `D=6`, we can have up to `log(total_nodes)/log(D)=5` hops. So in the worst case, rln will add a network latency of `0.012*5 = 0.06 seconds`
|
||||
|
||||
|
||||
|
||||
@ -48,13 +51,15 @@ In the following simulation, we can see `100` nwaku interconnected nodes, where
|
||||
## RLN tree sync
|
||||
|
||||
Using RLN implies that waku should now piggyback on a blockchain (the case study uses Ethereum Sepolia) and has to stay up to date with the latest events emitted by the rln smart contract. These events are used to locally construct a tree that contains all members allowed to create valid proofs to send messages. Some numbers:
|
||||
|
||||
- A tree with 10k members takes `2Mbytes` of space. Negligible.
|
||||
- A tree with 10k members takes `<4 minutes to synchronize. Assumable since it's done just once.
|
||||
- A tree with 10k members takes `<4` minutes to synchronize. Assumable since it's done just once.
|
||||
- With a block range of 5000 blocks for each request, we would need `520 requests` to synchronize 1 year of historical data from the tree. Assumable since most of the free endpoints out there allow 100k/day.
|
||||
|
||||
## Performance relay vs. rln-relay
|
||||
|
||||
Same simulation with 100 nodes was executed `with rln` and `without rln`:
|
||||
|
||||
- Memory consumption is almost identical
|
||||
|
||||
**with rln**
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
---
|
||||
displayed_sidebar: null
|
||||
sidebar_class_name: hidden
|
||||
pagination_prev: null
|
||||
pagination_next: null
|
||||
|
||||
@ -68,22 +68,22 @@ const config = {
|
||||
type: "search",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "guides",
|
||||
label: "Guides",
|
||||
to: "/",
|
||||
activeBaseRegex: "^/$|^/guides/",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "learn",
|
||||
label: "Learn",
|
||||
to: "/learn/waku-network",
|
||||
activeBaseRegex: "^/learn/",
|
||||
},
|
||||
{
|
||||
type: "docSidebar",
|
||||
position: "left",
|
||||
sidebarId: "research",
|
||||
label: "Research",
|
||||
to: "/research",
|
||||
activeBaseRegex: "^/research/",
|
||||
},
|
||||
{
|
||||
href: "https://discord.waku.org",
|
||||
|
||||
22
package.json
22
package.json
@ -5,7 +5,7 @@
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
"start": "docusaurus start",
|
||||
"build": "node fetch-content.js && docusaurus build",
|
||||
"build": "docusaurus build",
|
||||
"swizzle": "docusaurus swizzle",
|
||||
"deploy": "docusaurus deploy",
|
||||
"clear": "docusaurus clear",
|
||||
@ -16,22 +16,22 @@
|
||||
"check:spell": "cspell \"**/*.{md,mdx}\""
|
||||
},
|
||||
"dependencies": {
|
||||
"@acid-info/docusaurus-fathom": "^1.0.0-alpha.111",
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.0-alpha.143",
|
||||
"@docusaurus/core": "^2.4.1",
|
||||
"@docusaurus/preset-classic": "^2.4.1",
|
||||
"@docusaurus/theme-mermaid": "^2.4.1",
|
||||
"@acid-info/docusaurus-fathom": "^1.0.3-beta.2",
|
||||
"@acid-info/logos-docusaurus-preset": "^1.0.3-beta.11",
|
||||
"@docusaurus/core": "3.8.1",
|
||||
"@docusaurus/preset-classic": "3.8.1",
|
||||
"@docusaurus/theme-mermaid": "3.8.1",
|
||||
"@emotion/react": "^11.11.0",
|
||||
"@emotion/styled": "^11.11.0",
|
||||
"@mdx-js/react": "^1.6.22",
|
||||
"@mdx-js/react": "^3.0.0",
|
||||
"add": "^2.0.6",
|
||||
"dotenv": "^16.0.3",
|
||||
"prism-react-renderer": "^1.3.5",
|
||||
"react": "^17.0.2",
|
||||
"react-dom": "^17.0.2"
|
||||
"prism-react-renderer": "^2.3.0",
|
||||
"react": "^19.0.0",
|
||||
"react-dom": "^19.0.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "^2.4.1",
|
||||
"@docusaurus/module-type-aliases": "3.8.1",
|
||||
"@tsconfig/docusaurus": "^1.0.5",
|
||||
"cspell": "^6.16.0",
|
||||
"docusaurus-plugin-sass": "^0.2.2",
|
||||
|
||||
@ -44,27 +44,27 @@ html[data-theme="dark"] .header-github-link:before {
|
||||
}
|
||||
|
||||
.case-study-container a {
|
||||
display: block;
|
||||
width: 100%;
|
||||
margin-bottom: 20px;
|
||||
display: block;
|
||||
width: 100%;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
.case-study-container a img {
|
||||
width: 100%;
|
||||
height: auto;
|
||||
width: 100%;
|
||||
height: auto;
|
||||
}
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.case-study-container a {
|
||||
display: inline-block;
|
||||
width: 48%;
|
||||
margin-bottom: 20px;
|
||||
margin-right: 2%;
|
||||
}
|
||||
.case-study-container a {
|
||||
display: inline-block;
|
||||
width: 48%;
|
||||
margin-bottom: 20px;
|
||||
margin-right: 2%;
|
||||
}
|
||||
|
||||
.case-study-container a:nth-child(2n) {
|
||||
margin-right: 0;
|
||||
}
|
||||
.case-study-container a:nth-child(2n) {
|
||||
margin-right: 0;
|
||||
}
|
||||
}
|
||||
|
||||
.external-link {
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user