Frequently Asked Questions from Witnet Node Operators

Here we cover some frequently asked questions regarding running a node on the Witnet Decentralized Oracle Network.

If you can’t find an answer to your question here, feel free to reach out to the community on Telegram or Discord.

Contents:

1. My node is not finding peers. What should I do?
- What is Inbound Sybil Rejection and why was it implemented?
- What can I do to help my nodes to sync?

2. My node has been running, but it has not mined a block or gained reputation yet. What should I do?
- When will my node mine its first block?
- Why is reputation a part of the Block Mining mechanism?
- My node had reputation, but now it’s gone. What happened?

3. My node states that it’s “not active” — what should I do?

4. What are the hardware requirements for running a Witnet node?

5. My nodes are getting outgoing connections, but no incoming connections. What should I do?

1. My node is not finding peers. What should I do?

This is probably because your node is facing a bucketing issue (for example Inbound Sybil Rejection).

What is “Inbound Sybil Rejection” and why was it implemented?

Each Witnet node will only accept incoming connections from diverse IP ranges, i.e. a connection from IP 1.2.3.4 will be rejected if a connection from 1.2.5.6. has already been established.

It was implemented in order to guarantee a neutral view of the network consensus, and reduce the risk of nodes (and the network) crashing if some unreliable but well-connected nodes or popular machines (e.g. cheaper VPS services) fail. This happened during Testnet 9.0b, which you can read about here.

What can I do to help my nodes to sync?

Sometimes it’s just a matter of time before your node finds a diverse enough peer range to connect to. You can speed up this process by:

1. Restarting your node/s a few times
2. Running the addPeers command — this adds addresses to the node’s peers and try to connect to them. You can find a list of active node IPs to connect to here.

If running lots of nodes on the same IP or from a popular VPS provider, then sometimes the node cannot find a sufficiently diverse peer set. In this case, you can either:

1. Wait until the network grows. As new IPs join the network and the network becomes more diversified, new connections may be possible. There is no guarantee of a timeline for this.
2. Run nodes from other IPs.

2. My node has been running, but it has not mined a block or gained reputation yet. What should I do?

Don’t worry; that’s perfectly normal. There are several thousand nodes running on the current network, so it can take some time to mine your first block. Be patient; if your node is synced and has peers, there’s nothing more you can do.

When will my node mine its first block?

There’s quite a lot of mechanism to get your head around, but here’s a rough starter:

1. Your node needs to mine a block before it becomes active and participate in Data Requests. Eligibility to mine a block is randomized amongst all nodes (using a VRF), and is unrelated to reputation. However, more than one node may be eligible to mine, and if nodes with 0 reputation propose the same block as those with a reputation > 0 (and the block proposals are valid), then the reputed node will be selected.
2. As you can see, already having reputation increases your chances of mining, but if all block proposers eligible to mine have either 0 reputation or >0 reputation (for example, all block proposers are fresh nodes, so 0), then the “winning” block proposer is selected at random. This is what you’re waiting for, and where the luck comes in. It’s your node’s golden ticket 🎫.
3. Once active (i.e. it’s recently mined a block), the node can participate as a “witness” and fulfill data requests. If it does this honestly, it can continuously “earn” reputation points.
4. Of course, we want to prevent “reputation oligarchs”, so the reputation points have a shelf-life — i.e. they expire after a certain period — at which point they are redistributed to those nodes that honestly perform upcoming Data Requests. This means that nodes can’t infinitely accumulate and passively hodl all the reputation points; they must remain active in the network.

There’s more to it than this, but hopefully you can start to see why getting the first block is the most challenging part, and once your node gets going, it becomes easier.

Why is reputation a part of the Block Mining mechanism?

1. The network is designed to reward and retain early participants and honest nodes. Node operators benefit from “network loyalty” (i.e if they continuously and honestly participate, they remain an active participant in the network)
2. This mechanism is crucial to prevent attacks such as Sybil attacks. If you want to read more about this, please read this article.

My node had reputation, but now it’s gone. What happened?

Don’t worry — that’s normal. To ensure that reputation is not hoarded by any particular node or group of nodes (which could, for example, result in a 51% attack on the network), and to encourage nodes to continue to participate in the network, all reputation points expire after a fixed number of epochs. These expired reputation points (alongside reputation points subtracted from “dishonest nodes”) are redistributed amongst nodes participating honestly in the following network request.

Reputation epochs are not tied to human time, but instead to the velocity of the network, based on the number of requests being fulfilled (the more requests being fulfilled, the quicker reputation points will expire). Each reputation points awarded will expire after the same number of epochs, regardless of the node it was awarded to.

3. My node’s status is “not active” — what should I do?

If your node is active, all that means is that it recently mined a block. Your node can (and will) move between active and not active states depending on its recent activity.

Your node can be running perfectly fine, and can even have mined blocks in the past, and still be in a not active state.

4. What are the hardware requirements for running a Witnet node?

As per the suggestions in the Witnet documentation, as a minimum, we recommend allocating each node:

• 2GB of RAM
• 200–1000 GB of disk space. The Witnet chain can grow up to 50GB per year, so this depends on the amount of time you will be running a node
• a stable internet connection

Remember: due to the Inbound Sybil Rejection implementation that we discussed in Q1, you cannot run too many nodes from one IP. At the moment, we recommend not running more than 5–10 nodes from a single IP, though this limit will most likely climb as the Witnet network grows over time.

5. My nodes are getting outgoing connections, but no incoming connections. What should I do?

Make sure your ports are open — you can find out how to open your ports on “next steps” in our documentation, and check the ports are open using this tool.

If your ports are open, but you’re running several nodes off the same machine using docker, and they all have the same ports ascribed, they all will announce the address of the first node so it’s impossible for the network to discover the rest of the nodes.

Nodes self-declare their external addresses. But the docker containers have no possible way to know what external ports you are using for them, so they all declare the same port (21337)

You’ll need to change the external port (i.e. the port on the left hand side) on the public_addr setting inside the witnet.toml file for each of them(e.g. 22337:21337, 23337:21337 and so on).