diff --git a/docs/node-operators/cli.md b/docs/node-operators/cli.md index 0ecafcb9..e5e2ea23 100644 --- a/docs/node-operators/cli.md +++ b/docs/node-operators/cli.md @@ -7,7 +7,7 @@ The cli subcommand provides a human-friendly command-line interface to the node See all the available options by running the help command using docker, binary or cargo. ```console tab="Docker" -docker exec witnet_node ./witnet node --help +docker exec witnet_node witnet node --help ``` ```console tab="Binary" @@ -21,7 +21,7 @@ cargo run -- node --help To get more information about any specific command, simply add `--help` at the end. For instance, this will show the available options for the `blockchain` command: ```console tab="Docker" -docker exec witnet_node ./witnet node blockchain --help +docker exec witnet_node witnet node blockchain --help ``` ```console tab="Binary" @@ -37,7 +37,7 @@ The path of this file can be set using the `-c` or `--config` flag. This flag must appear before `node`. ```console tab="Docker" -docker exec witnet_node ./witnet node -c witnet.toml node blockchain +docker exec witnet_node witnet node -c witnet.toml node blockchain ``` ```console tab="Binary" @@ -52,7 +52,7 @@ You can use the `-n` flag to easily overwrite the node address. This flag must appear after the command name. ```console tab="Docker" -docker exec witnet_node ./witnet node -c witnet.toml node blockchain -n "127.0.0.1:1234" +docker exec witnet_node witnet node -c witnet.toml node blockchain -n "127.0.0.1:1234" ``` ```console tab="Binary" @@ -66,7 +66,7 @@ cargo run -- -c witnet.toml node blockchain -n "127.0.0.1:1234" If there is any error, the process will return a non-zero exit code. ```text tab="Docker" -docker exec witnet_node ./witnet node node blockchain +docker exec witnet_node witnet node node blockchain Error: Connection refused (os error 111) ``` @@ -83,7 +83,7 @@ Error: Connection refused (os error 111) The executable implements the usual logging API, which can be enabled using `RUST_LOG=witnet=debug`: ```text tab="Docker" -$ docker exec witnet_node ./witnet node blockchain +$ docker exec witnet_node witnet node blockchain INFO 2019-01-03T12:04:43Z: witnet::json_rpc_client: Connecting to JSON-RPC server at 127.0.0.1:21338 ERROR 2019-01-03T12:04:43Z: witnet: Error: Connection refused (os error 111) ``` @@ -110,7 +110,7 @@ This is the address used for mining blocks, resolving data requests, and receiving value transfer transactions. ```console tab="Docker" -docker exec witnet_node ./witnet node address +docker exec witnet_node witnet node address ``` ```console tab="Binary" @@ -134,8 +134,8 @@ Get total balance of a given Witnet address. Balances are shown in wits. * `--address=address`: address for which to get balance. If omitted, defaults to the node's own address. ```console tab="Docker" -docker exec witnet_node ./witnet node balance -docker exec witnet_node ./witnet node balance --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr +docker exec witnet_node witnet node balance +docker exec witnet_node witnet node balance --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr ``` ```console tab="Binary" @@ -159,7 +159,7 @@ Example output: Print out detailed information about a block being queried by its hash. ```console tab="Docker" -docker exec witnet_node ./witnet node block 9372e2ed0c637a9733e92d7e0d4f1aa1f297c43a80bc3be57fc7d7738efb0ef4 +docker exec witnet_node witnet node block 9372e2ed0c637a9733e92d7e0d4f1aa1f297c43a80bc3be57fc7d7738efb0ef4 ``` ```console tab="Binary" @@ -183,7 +183,7 @@ Example output: List block hashes in the local block chain, matched with their epochs. ```console tab="Docker" -docker exec witnet_node ./witnet node blockchain +docker exec witnet_node witnet node blockchain ``` ```console tab="Binary" @@ -201,19 +201,19 @@ This method accepts two optional arguments: ```console tab="Docker" # Get all the block hashes from the genesis block -docker exec witnet_node ./witnet node blockchain --epoch=0 --limit=0 +docker exec witnet_node witnet node blockchain --epoch=0 --limit=0 # Get the block hashes from epochs [0, 19] -docker exec witnet_node ./witnet node blockchain --epoch=0 --limit=20 +docker exec witnet_node witnet node blockchain --epoch=0 --limit=20 # Get the block hashes from the last 10 epochs -docker exec witnet_node ./witnet node blockchain --epoch=-10 --limit=0 +docker exec witnet_node witnet node blockchain --epoch=-10 --limit=0 # Get the block hash from 10 epochs ago -docker exec witnet_node ./witnet node blockchain --epoch=-10 --limit=1 +docker exec witnet_node witnet node blockchain --epoch=-10 --limit=1 # Get the block hash from the last block -docker exec witnet_node ./witnet node blockchain --epoch=-1 --limit=1 +docker exec witnet_node witnet node blockchain --epoch=-1 --limit=1 ``` ```console tab="Binary" @@ -261,7 +261,7 @@ block for epoch #76229 had digest 8dd75bb0d5475a93c27c4166677fbb3bc154e6731c7e07 Show information about a data request. ```console tab="Docker" -docker exec witnet_node ./witnet node dataRequestReport 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d +docker exec witnet_node witnet node dataRequestReport 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d ``` ```console tab="Binary" @@ -289,7 +289,7 @@ Tally: RadonTypes::RadonFloat(10172.642950000001) If you want to see the request move forwards through its different stages in real time you can use the `watch` command while it is being resolved: ```console tab="Docker" -watch --color docker exec witnet_node ./witnet node dataRequestReport 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d +watch --color docker exec witnet_node witnet node dataRequestReport 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d ``` ```console tab="Binary" @@ -310,7 +310,7 @@ The following arguments must be provided. * `--fee=fee`: miner fee in nanoWits. ```console tab="Docker" -docker exec witnet_node ./witnet node joinTransaction --value=100 --fee=1 +docker exec witnet_node witnet node joinTransaction --value=100 --fee=1 ``` ```console tab="Binary" @@ -326,7 +326,7 @@ cargo run -- node joinTransaction --value=100 --fee=1 Get the list of peer addresses known to the node. These addresses are tagged as: ```console tab="Docker" -docker exec witnet_node ./witnet node knownPeers +docker exec witnet_node witnet node knownPeers ``` ```console tab="Binary" @@ -342,7 +342,7 @@ cargo run -- node knownPeers Export the node's master private key. Please keep this totally secret. Anyone with knowledge of this key has full access to all your wit tokens. ```console tab="Docker" -docker exec witnet_node ./witnet node masterKeyExport +docker exec witnet_node witnet node masterKeyExport ``` ```console tab="Binary" @@ -358,7 +358,7 @@ cargo run -- node masterkeyExport Display local node stats. ```console tab="Docker" -docker exec witnet_node ./witnet node nodeStats +docker exec witnet_node witnet node nodeStats ``` ```console tab="Cargo" @@ -405,7 +405,7 @@ Data Request mining stats: Display a transaction output, as referred by it's "output pointer", that is, `:`. ```console tab="Docker" -docker exec witnet_node ./witnet node output 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d:0 +docker exec witnet_node witnet node output 33c656101dd1dfa2258415d6487c648152b95983d1151f46a679b5d1902f6a8d:0 ``` ```console tab="Binary" @@ -423,7 +423,7 @@ Outbound connections are those initiated on our side, and inbound connections ar A node that does not announce a public address (IP and port) will normally have no inbound connections, as there is no way for other nodes to discover a valid network route to it. ```console tab="Docker" -docker exec witnet_node ./witnet node peers +docker exec witnet_node witnet node peers ``` ```console tab="Binary" @@ -440,7 +440,7 @@ The `raw` command allows sending raw JSON-RPC requests from the command line. It can be used in an interactive way (don't forget the `-i` flag when using Docker): each line of user input will be sent to the JSON-RPC server without any modifications: ```console tab="Docker" -$ docker exec -i witnet_node ./witnet node raw +$ docker exec -i witnet_node witnet node raw ``` ```console tab="Binary" @@ -474,7 +474,7 @@ bye Alternatively, the input can be read from a file using pipes, as is usual in Unix-like environments. For instance, the `bitcoin_price.json` data request example from the [witnet-rust reposity](https://github.com/witnet/witnet-rust/tree/master/examples) can be easily deployed into the network using the `raw` command like this: ``` tab="Docker" -cat examples/bitcoin_price.json | docker exec -i witnet_node ./witnet node raw +cat examples/bitcoin_price.json | docker exec -i witnet_node witnet node raw {"jsonrpc":"2.0","result":"06e19d996a6776d6cd1ca215f6acd0975d71e64a9dacc06fcfdd7b2538cdbf6d","id":"1"} ``` @@ -495,8 +495,8 @@ Displays the reputation score associated with a given Witnet address. * `--address=address`: address for which to get reputation score. If omitted, defaults to the node's own address. ```console tab="Docker" -docker exec witnet_node ./witnet node reputation -docker exec witnet_node ./witnet node reputation --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr +docker exec witnet_node witnet node reputation +docker exec witnet_node witnet node reputation --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr ``` ```console tab="Binary" @@ -522,7 +522,7 @@ Adding the flag `--all` flag lists all the nodes having non-zero reputation. ```console tab="Docker" -docker exec witnet_node ./witnet node reputation --all +docker exec witnet_node witnet node reputation --all ``` ```console tab="Binary" @@ -555,7 +555,7 @@ the output until the timestamp is reached. 0 means no time-lock. On success, returns the transaction hash: ``` tab="Docker" -docker exec witnet_node ./witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=1234 --fee=1 +docker exec witnet_node witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=1234 --fee=1 {"jsonrpc":"2.0","result":"a6c26804cf76e08ab379ea63e4aa046095dade2ae52fb3ecac90817583e61349","id":"1"} ``` @@ -572,7 +572,7 @@ cargo run -- node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --v On error, returns the error message: ``` tab="Docker" -docker exec witnet_node ./witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=9999999999999999999 --fee=1 +docker exec witnet_node witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=9999999999999999999 --fee=1 {"jsonrpc":"2.0","error":{"code":-32603,"message":"Cannot build a transaction transferring more value than the current available balance: 9999999999999999999 + 1 > 39649999949502"},"id":"1"} ``` @@ -589,7 +589,7 @@ cargo run -- node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --v Example with time lock set to 2019-10-01 ``` tab="Docker" -docker exec witnet_node ./witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=1234 --fee=1 --time-lock=1569888000 +docker exec witnet_node witnet node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --value=1234 --fee=1 --time-lock=1569888000 {"jsonrpc":"2.0","result":"e5b55ec4930f32383e63de9316238f369ee26d89d4375521071a885fc46b4c17","id":"1"} ``` @@ -608,7 +608,7 @@ cargo run -- node send --address=twit1ulyzvnknjnndkfva636erkkp83wxhhwdfhptsr --v Send a serialized data request. An example of how to create such a request can be found in the [tutorial](https://docs.witnet.io/tutorials/bitcoin-price-feed/introduction/). ```console tab="Docker" -docker exec witnet_node ./witnet node sendRequest --hex "data request output serialized in hexadecimal format" +docker exec witnet_node witnet node sendRequest --hex "data request output serialized in hexadecimal format" ``` ```console tab="Cargo" @@ -624,7 +624,7 @@ witnet node sendRequest --hex "data request output serialized in hexadecimal for Run a Witnet node server. ```console tab="Docker" -docker exec witnet_node ./witnet node server +docker exec witnet_node witnet node server ``` ```console tab="Binary" @@ -646,7 +646,7 @@ The following arguments must be provided: * `--fee=fee`: miner fee in nanoWits. ```console tab="Docker" -docker exec witnet_node ./witnet node joinTransaction --value=100 --size=3 --fee=1 +docker exec witnet_node witnet node joinTransaction --value=100 --size=3 --fee=1 ``` ```console tab="Binary" @@ -662,7 +662,7 @@ cargo run -- node joinTransaction --value=100 --size=3 --fee=1 Print out detailed information about a transaction being queried by its hash. ```console tab="Docker" -docker exec witnet_node ./witnet node transaction f6ebdd2e3f52af8404ae3dfbf87fcfc85803a8c14a35966acca6e18585acb8f5 +docker exec witnet_node witnet node transaction f6ebdd2e3f52af8404ae3dfbf87fcfc85803a8c14a35966acca6e18585acb8f5 ``` ```console tab="Binary" @@ -686,7 +686,7 @@ Example output: Get the unspent transaction outputs of the node. This shows how many UTXOs are available for your node to spend or collateralize. ```console tab="Docker" -docker exec witnet_node ./witnet node utxos +docker exec witnet_node witnet node utxos ``` ```console tab="Binary" diff --git a/docs/try/next-steps.md b/docs/try/next-steps.md new file mode 100644 index 00000000..b7416ae2 --- /dev/null +++ b/docs/try/next-steps.md @@ -0,0 +1,245 @@ +# I got my Witnet node running. What's next? + +## The first minutes and hours in your node's life + +As soon as the `witnet_node` container is up, it will do the following things in order: + +1. Try to **open connections to other nodes** in the network. It needs 12 "outbound" connections. This should take from several seconds to a few minutes. +2. Discover what is the **tip of the block chain**, and **download all the blocks** from that chain. This can take from several minutes to several hours. The synchronization time depends heavily on how long the block chain is, but also on your Internet bandwidth, CPU speed, memory size and speed, and storage drive write throughput. +3. Go into **_Synced_ status**. In Synced status, your node will **validate transactions and blocks** in real time, and it will try itself to **propose block candidates** and participate in **resolving _data requests_**. + +## What to expect from your node's balance and reputation + +- Getting your first block proposal accepted by the network and minting your first wit tokens is not easy, and can take from a few minutes up to 48 hours (or more!) due to the probabilistic nature of the [cryptographic sortition] algorithm that rules the system. +- As with minting blocks, being assigned a request for the first time can take some time: from several minutes up to 48 hours (or more!). Once you have resolved at least one request, your node will earn reputation and it will start getting assignments more often. + +!!! warning "Don't panic" + Note that it is **perfectly normal** for a node to show 0 "balance", "reputation", "blocks included" or "accepted commits" for the first days of it being up. + Please be patient, new identities in the system are subject to a slow start for critical security reasons. + +## Monitoring your node's progress + +Here are some useful commands that you can use to keep track of how your node is performing in the network. +A complete documentation of all the CLI methods is available in the [node operator docs][CLI]. + +### nodeStats + +Among other information, this shows the synchronization state of your node, as well as counters for proposed and accepted blocks and participations in resolving data requests ("commitments"). + +```console tab="Docker" +docker exec witnet_node witnet node nodeStats +``` + +```console tab="Cargo" +cargo run --release -- node nodeStats +``` + +```console tab="Binary" +witnet node nodeStats +``` + +### balance + +The `balance` command will print your node's current balance. + +```console tab="Docker" +docker exec witnet_node witnet node balance +``` + +```console tab="Cargo" +cargo run --release -- node balance +``` + +```console tab="Binary" +witnet node balance +``` + + +### reputation + +The `reputation` command will print your node's current reputation score. + +```console tab="Docker" +docker exec witnet_node witnet node reputation +``` + +```console tab="Cargo" +cargo run --release -- node reputation +``` + +```console tab="Binary" +witnet node reputation +``` + + +!!! tip "Reputation is tricky" + Despite its name, the *reputation* metric that exists in the Witnet protocol is not as vital as reputation is in real life. + The reputation score of a node gives a rough idea about its performance, but it is heavily influenced by randomness and luck. + It is perfectly normal that the reputation score goes up and down over time, sometimes smoothly, sometimes more abruptly. + Likewise, there is probably nothing wrong if your node shows 0 reputation points or is marked as "not active". + Do not get too obsessed about it! + +## Check ports and incoming connections + +To check if the listening port is correctly opened to the Internet, you can use +a [port forwarding testing][port-test] tool or try to open a connection to +your public IP from a device that is not in the same network as your node: + +```sh tab="Telnet" +# If you get stuck when running this command, it is indeed a good sign that +# the connection was stablished. To exist a Telnet session, press "Ctrl + ]", +# then write "quit" and press Enter. +telnet your_public_ip 21337 +``` + +```console tab="GNU Netcat" +nc -vz your_public_ip:21337 +``` + +The final check to verify that your port is correctly forwarded is using the +`peers` method to look if any of the peer connections is tagged as "inbound": + +```console tab="Docker" +docker exec witnet_node witnet node peers +``` + +```console tab="Cargo" +cargo run --release -- node peers +``` + +```console tab="Binary" +witnet node peers +``` + +!!! tip "Multiple nodes in the same device or network" + Multiple Witnet nodes can run in the same device or network and still get + incoming connections. This is possible by forwarding a different external + port (e.g. `22337`) to the port of your second node. + + However, your second node may require setting an additional parameter in + its configuration file so that it is aware of the new port. Please read + below how to customize the configuration file. The parameter you need to + adjust is `public_addr`. + +## Back up your private master key + +Doing a backup of the private master key of your node is a great way to keep +your wit tokens safe. + +This command will print your master key into your console terminal: + +```console tab="Docker" +docker exec witnet_node witnet node masterKeyExport +``` + +```console tab="Cargo" +cargo run --release -- node masterKeyExport +``` + +```console tab="Binary" +witnet node masterKeyExport +``` + +You can add the `--write` flag to write a backup of your master key into a file +in the configuration directory of your node (`~/.witnet/config` by default): + +```console tab="Docker" +docker exec witnet_node witnet node masterKeyExport --write +``` + +```console tab="Cargo" +cargo run --release -- node masterKeyExport --write +``` + +```console tab="Binary" +witnet node masterKeyExport --write +``` + +It is recommended to **move or copy the resulting file into a safe place**. Writing +it into a piece of paper and keeping it somewhere safe from light, water, fire +(and eyes) is the best option. + +**Please keep this totally secret**. Anyone with knowledge of this key has full access to +all your wit tokens. + +**Importing master keys is only allowed when creating a new node**, as overwriting a +existing key could be dangerous. The process is quite simple: + +```console tab="Docker + nano" +mkdir -p ~/.witnet/config + +nano ~/.witnet/config/master.key + +# Now enter your master key into the file editor, save with Ctrl+O and exit with Ctrl+X + +docker run -d \ + --name witnet_node \ + --volume ~/.witnet:/.witnet \ + --publish 21337:21337 \ + --restart always \ + witnet/witnet-rust \ + node server --master-key-import /.witnet/config/master.key +``` + +```console tab="Docker + vim" +mkdir -p ~/.witnet/config + +vim ~/.witnet/config/master.key + +# Now enter your master key into the file editor, save and exit by typing Escape, then ":wq" and Enter + +docker run -d \ + --name witnet_node \ + --volume ~/.witnet:/.witnet \ + --publish 21337:21337 \ + --restart always \ + witnet/witnet-rust \ + node server --master-key-import /.witnet/config/master.key +``` + +```console tab="Binary" +witnet node server --master-key-import ~/.witnet/config/master.key +``` + +!!! danger "Never use the same master key on multiple nodes at once" + Operating multiple nodes with the same master key is a terrible idea. + You may find your nodes exposed to double-spend issues and severe slashing. + +## Customize configuration if needed + +A custom `witnet.toml` configuration file can be used to adjust some parameters +of the node. The configuration file itself contains detailed explanations for each +parameter. + +If you created your node following this guide, your `witnet.toml` file will +be found in the `~/.witnet/config` folder, right in your user's directory. + +You can easily edit the configuration file like this: + +```console tab="Vim (Mac OS)" +vim ~/.witnet/config/witnet.toml +``` + +```console tab="Vim (GNU/Linux)" +vim ~/.witnet/config/witnet.toml +``` + +```console tab="Nano (GNU/Linux)" +nano ~/.witnet/config/witnet.toml +``` + + +## Long term maintenance of your node + +There are some operations that are recommended from time to time to make sure your node is in perfect order: + +- Give a look to the result of the `nodeStats`, `balance` and `reputation` commands. +- Check that you are getting incoming connections as explained above. +- Keep an eye on announcements for software and networks upgrades through the Witnet Community [Discord] and [Telegram] to make sure that you are running the latest release, which should give your node the best performance, liveness and security. +- Restart your node once in a while (e.g. `docker restart witnet_node`) so that the node can perform some housekeeping operations. This helps reducing memory footprint and optimize disk space. + +[cryptographic sortition]: https://medium.com/witnet/cryptographic-sortition-in-blockchains-the-importance-of-vrfs-ad5c20a4e018 +[CLI]: /node-operators/cli +[Discord]: https://discord.gg/X4uurfP +[Telegram]: https://t.me/witnetio +[port-test]: https://www.yougetsignal.com/tools/open-ports/ \ No newline at end of file diff --git a/docs/try/run-a-node.md b/docs/try/run-a-node.md index 57928d4f..b0424733 100644 --- a/docs/try/run-a-node.md +++ b/docs/try/run-a-node.md @@ -17,16 +17,15 @@ Hardware requirements are [listed in the node operators docs][hardware-requireme ## Up and running in 1 minute, using Docker The most convenient method for running a Witnet node is through the -`witnet/witnet-rust` Docker image. +`witnet/witnet-rust` Docker image. For alternate installation methods or +more complex setups, take a look at the [docker-compose] and [systemd] integrations. -Firstly, you need to install Docker on the device you will +Firstly, you need to [install Docker][docker] on the device you will be running the node from. Note: some GNU/Linux distributions require some [extra steps][docker-extra-steps] to get Docker up and running. -The Witnet docker image downloads and runs a witnet-rust node in the latest -Testnet in just a matter on seconds. - -To start a node, use: +The Witnet docker image downloads and runs a Witnet node in the latest +Testnet in just a matter on seconds. To start a node, use: ```console tab="Multiline" docker run -d \ @@ -41,54 +40,41 @@ docker run -d \ docker run -d --name witnet_node --volume ~/.witnet:/.witnet --publish 21337:21337 --restart always witnet/witnet-rust ``` -## Now what? - -As soon as the `witnet_node` container is up, it will do the following things in order: - -1. Try to **open connections to other nodes** in the network. It needs 8 "outbound" connections. This should take from several seconds to a few minutes. -2. Discover what is the **tip of the block chain**, and **download all the blocks** from that chain. This can take from several minutes to several hours. The synchronization time depends heavily on how long the block chain is, but also on your Internet bandwidth, CPU speed, memory size and speed, and storage drive write throughput. -3. Go into **_Live_ status**. In Live status, your node will **validate transactions and blocks** in real time, and it will try itself to **propose block candidates**. Getting your first block proposal accepted by the network is not easy, and can take from a few minutes up to 48 hours (or more!) due to the probabilistic nature of the [cryptographic sortition] algorithm that rules the system. -4. While in Live status, your node will also try to participate in **resolving _data requests_**. As with minting blocks, being assigned a request for the first time can take some time: from several minutes up to 48 hours (or more!). Once you have resolved at least one request, your node will earn reputation and it will start getting assignments more often. - -## How to interact with your node - -You can check if your node is doing well at any time through the node's own command line interface (CLI). -Using the CLI example below, you can find out how many _[nanowits]_ your node has minted: +!!! warning "Raspberry Pi users" + For some reason, Raspbian on Raspberry Pi (all versions) requires your containers to operate + in privileged mode. When running the command above, simply add the `--privileged` flag: + ```console + docker run -d --privileged --name witnet_node --volume ~/.witnet:/.witnet --publish 21337:21337 --restart always witnet/witnet-rust + ``` -```bash -docker exec witnet_node ./witnet node getBalance -``` +## Now what? -The node operators docs contain a [quick cheatsheet listing all the -supported CLI commands][CLI]. +There are two **important** things you should do now to make the most of +your Witnet node: -!!! tip "" - Do not worry if your balance is 0 for the first hours or days! - That is perfectly normal. Getting your first block proposal accepted - by the network can take quite a while. As your node proves some - reliability over time, it will mint blocks more often. +1. [Open ports](#open-your-ports) as explained below. +2. Follow the [Next Steps][next] guide to learn how to check the node + status, progress and statistics. ## Open your ports! The best way to contribute to the growth and sustainability of the Witnet network is by **opening up the listening port of your node**, -so that other nodes in the network can download block -chain data from you and **your transactions can be broadcasted more -quickly**. +so that other nodes in the network can download block chain data from +you and **your transactions can be broadcasted more quickly**. For this feature to be effective, you will also need your IP address to -be static and public. If you are operating a node in your home network, -you can request your ISP to assign you a static IP address and disable -[CGN] on it. +be public (and ideally, static). If you are operating a node in your home +network, you can request your ISP to assign you a static IP address or at +least disable [CGN] on it. Depending on your setup, this will normally imply changing the settings on your router or firewall so as to **forward all incoming connections to port `21337` from your external IP** into the IP of the device or interface where the node is running. -To check if the port is correctly opened, you can telnet your external -IP with `telnet "IP" 21337` from the Internet. You should see an incoming -connection on the logs for which the handshake timeouts. +You can find out how to verify that your ports are open in the [Next Steps][next] +guide. ## What about Witnet data requests? @@ -100,30 +86,6 @@ user-friendly editor in the [Sheikah desktop app][Sheikah] that will enable to compose data requests and RADON scripts visually. In the meantime, you can play around with [this community-built request editor][witnet.tools]. -## Customize configuration - -A custom `witnet.toml` file can be used to configure parameters of the node. -Settings like the JSON-RPC server socket address and the directory path of -the database files can be customized. More details and a file example can -be [found here][toml]. - -The path to the TOML file can be set when starting the node (please remember -to replace the path in the example): - -```console tab="Multiline" -docker run -d \ - --name witnet_node \ - --volume ~/.witnet:/.witnet \ - --volume /path/to/custom/witnet.toml:/witnet.toml \ - --publish 21337:21337 \ - --restart always \ - witnet/witnet-rust -``` - -```console tab="One-liner" -docker run -d --name witnet_node --volume ~/.witnet:/.witnet --volume /path/to/custom/witnet.toml:/witnet.toml --publish 21337:21337 --restart always witnet/witnet-rust -``` - [ethereum]: /try/use-from-ethereum [roadmap]: /community/roadmap [CLI]: /node-operators/cli @@ -135,4 +97,7 @@ docker run -d --name witnet_node --volume ~/.witnet:/.witnet --volume /path/to/c [toml]: https://github.com/witnet/witnet-rust/blob/master/docs/configuration/toml-file.md [witnet.tools]: https://witnet.tools/tools/ide [nanowits]: /overview/glossary -[cryptographic sortition]: https://medium.com/witnet/cryptographic-sortition-in-blockchains-the-importance-of-vrfs-ad5c20a4e018 \ No newline at end of file +[docker-compose]: /node-operators/docker-compose-service +[systemd]: /node-operators/systemd-service +[docker]: https://docs.docker.com/get-docker/ +[next]: /try/next-steps/ \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index d2a26600..ac4d79cd 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -9,6 +9,7 @@ nav: - Software: overview/software.md - Quickstart: - Run a Node: try/run-a-node.md + - Next Steps: try/next-steps.md #- Use the Sheikah wallet / IDE: try/sheikah.md - Connect your Ethereum contracts to external APIs: try/use-from-ethereum.md - Tutorial: