go-waku/docs/operators/how-to/run.md

7.5 KiB

Running go-waku

# Run with default configuration
./build/waku

# See available command line options
./build/waku --help

Default configuration

By default a go-waku node will:

  • generate a new private key and libp2p identities after every restart. See this tutorial if you want to generate and configure a persistent private key.
  • listen for incoming libp2p connections on the default TCP port (60000)
  • enable relay protocol
  • subscribe to the default pubsub topic, namely /waku/2/default-waku/proto
  • enable store protocol, but only as a client. This implies that the nwaku node will not persist any historical messages itself, but can query store service peers who do so. To configure store as a service node, see this tutorial.

Note: The filter and lightpush protocols are not enabled by default. Consult the configuration guide on how to configure your nwaku node to run these protocols.

Some typical non-default configurations are explained below. For more advanced configuration, see the configuration guide. Different ways to connect to other nodes are expanded upon in our connection guide.

Finding your listening address(es)

Find the log entry beginning with Listening on. It should be printed at INFO level when you start your node and contains a list of all publically announced listening addresses for the nwaku node.

For example

2022-07-25T07:26:01.150-0400    INFO    gowaku.node2    listening       {"node": "16Uiu2HAkxFXYTRHWTnT1oT2BA8foKopFSXNfvXzbfvcuF6e88qf4", "multiaddr": ["/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAkxFXYTRHWTnT1oT2BA8foKopFSXNfvXzbfvcuF6e88qf4", "/ip4/127.0.0.1/tcp/60001/ws/p2p/16Uiu2HAkxFXYTRHWTnT1oT2BA8foKopFSXNfvXzbfvcuF6e88qf4"]}

indicates that your node is listening on the TCP transport addresses

/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAkxFXYTRHWTnT1oT2BA8foKopFSXNfvXzbfvcuF6e88qf4

and websocket address

/ip4/127.0.0.1/tcp/60001/ws/p2p/16Uiu2HAkxFXYTRHWTnT1oT2BA8foKopFSXNfvXzbfvcuF6e88qf4

You can also query a running node for its listening addresses using a get_waku_v2_debug_v1_info JSON-RPC API call.

For example

curl -d '{"jsonrpc":"2.0","id":"id","method":"get_waku_v2_debug_v1_info", "params":[]}' --header "Content-Type: application/json" http://localhost:8545

returns a response similar to

{
  "result": {
    "enrUri": "enr:-Iu4QJecqtDmg5JBwhEGCifJE-nfBUPvJpV1_Q7CtbJqX85pc8TV5xNIJKohJHnOtbQjycQV0OSzJeCsUB2a7hnfEP0BgmlkgnY0gmlwhMCoAG2Jc2VjcDI1NmsxoQJyDYLm_cOh10d-9TP34svDeh_AsrfmoDqrlpDeoNOmg4N0Y3CC6mCFd2FrdTIB",
    "listenAddresses": [
      "/ip4/192.168.0.109/tcp/60000/p2p/16Uiu2HAm36tQZYF9ijH9PzgZKcJDxyKz93iue4RjpBLkvcbo6mhU",
      "/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAm36tQZYF9ijH9PzgZKcJDxyKz93iue4RjpBLkvcbo6mhU"
    ]
  },
  "error": null,
  "id": "id"
}

Finding your discoverable ENR address(es)

A nwaku node can encode its addressing information in an Ethereum Node Record (ENR) according to 31/WAKU2-ENR. These ENR are most often used for discovery purposes.

ENR for DNS discovery and DiscV5

Find the log entry containing the text enr record.

For example

2022-07-25T07:27:15.007-0400    INFO    gowaku.node2    enr record      {"node": "16Uiu2HAmSBY66Awj56ssci4tJ3bEmcG8oRpufZwqe4Ueb46i7bWg", "enr": "enr:-KO4QJmGMGthIh_kCubluVD9jZLPDcqNgLgDYJxruIULs2elNcZxnIYqEZD-f9f-zsY2QMqEVosMxShxwTG8BkzkWQ8BgmlkgnY0gmlwhMCoAG2KbXVsdGlhZGRyc4wACgTAqABtBuph3QOJc2VjcDI1NmsxoQPI-z2SDgsKlci7pAYysALdIFv9ySJlRpynQbZdlJoU4YN0Y3CC6mCFd2FrdTIB"}

indicates that your node addresses are encoded in the ENR

enr:-KO4QJmGMGthIh_kCubluVD9jZLPDcqNgLgDYJxruIULs2elNcZxnIYqEZD-f9f-zsY2QMqEVosMxShxwTG8BkzkWQ8BgmlkgnY0gmlwhMCoAG2KbXVsdGlhZGRyc4wACgTAqABtBuph3QOJc2VjcDI1NmsxoQPI-z2SDgsKlci7pAYysALdIFv9ySJlRpynQbZdlJoU4YN0Y3CC6mCFd2FrdTIB

Typical configuration (relay node)

The typical configuration for a go-waku node is to run the relay protocol, subscribed to the default pubsub topic /waku/2/default-waku/proto, and connecting to one or more existing peers. We assume below that running nodes also participate in Discovery v5 to continually discover and connect to random peers for a more robust mesh.

Connecting to known peer(s)

A typical run configuration for a go-waku node is to connect to existing peers with known listening addresses using the --staticnode option. The --staticnode option can be repeated for each peer you want to connect to on startup. This is also useful if you want to run several nwaku instances locally and therefore know the listening addresses of all peers.

As an example, consider a nwaku node that connects to two known peers on the same local host (with IP 0.0.0.0) with TCP ports 60002 and 60003, and peer IDs 16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H and 16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ respectively. The Discovery v5 routing table can similarly be bootstrapped using a static ENR. We include an example below.

./build/waku \
  --staticnode=/ip4/0.0.0.0/tcp/60002/p2p/16Uiu2HAkzjwwgEAXfeGNMKFPSpc6vGBRqCdTLG5q3Gmk2v4pQw7H \
  --staticnode=/ip4/0.0.0.0/tcp/60003/p2p/16Uiu2HAmFBA7LGtwY5WVVikdmXVo3cKLqkmvVtuDu63fe8safeQJ \
  --discv5-discovery=true \
  --discv5-bootstrap-node=enr:-JK4QM2ylZVUhVPqXrqhWWi38V46bF2XZXPSHh_D7f2PmUHbIw-4DidCBnBnm-IbxtjXOFbdMMgpHUv4dYVH6TgnkucBgmlkgnY0gmowhCJ6_HaJc2VjcDI1NmsxoQM06FsT6EJ57mzR_wiLu2Bz1dER2nUFSCpaFzCccQtnhYN0Y3CCdl-DdWRwgiMohXdha3UyDw

Connecting to the wakuv2.prod network

You can use DNS discovery to bootstrap connection to the existing production network. Discovery v5 will attempt to extract the ENRs of the discovered nodes as bootstrap entries to the routing table.

./build/waku \
  --dns-discovery=true \
  --dns-discovery-url=enrtree://ANTL4SLG2COUILKAPE7EF2BYNL2SHSHVCHLRD5J7ZJLN5R3PRJD2Y@prod.waku.nodes.status.im \
  --discv5-discovery=true

Connecting to the wakuv2.test network

You can use DNS discovery to bootstrap connection to the existing test network. Discovery v5 will attempt to extract the ENRs of the discovered nodes as bootstrap entries to the routing table.

./build/waku \
  --dns-discovery=true \
  --dns-discovery-url=enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@test.waku.nodes.status.im \
  --discv5-discovery=true

Typical configuration (relay and store service node)

Often go-waku nodes choose to also store historical messages from where it can be queried by other peers who may have been temporarily offline. For example, a typical configuration for such a store service node, connecting to the wakuv2.test fleet on startup, appears below.

./build/waku \
  --store=true \
  --persist-messages=true \
  --db-path=/mnt/go-waku/data/db1/ \
  --store-capacity=150000 \
  --dns-discovery=true \
  --dns-discovery-url=enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@test.waku.nodes.status.im \
  --discv5-discovery=true

See our store configuration tutorial for more.

Interact with a running go-waku node

A running go-waku node can be interacted with using the Waku v2 JSON RPC API.

Note: Private and Admin API functionality are disabled by default. To configure a nwaku node with these enabled, use the --rpc-admin:true and --rpc-private:true CLI options.