Skip to main content

FAQ: full node

1. Why should someone run a full node? Are there any incentives?​

Someone building a use case on Hathor should run a full node to guarantee the integration will not be impacted by the limitations present in Hathor's public full nodes. That public full nodes have limits on the APIs and they may be overloaded if many people are using them.

Besides, the incentive to run a node is not only to be able to build/integrate with Hathor but also to help with the security and decentralization of the network where it is building its use case.

In summary, there are no rewards for running a node but just like with BTC it increases the security of transactions conducted by a user. This is important if someone plans to conduct multiple transactions in a day. It also contributes to the overall security of HTR's network.

2. How can I run docker compose with the full node and wallet headless?​

A detailed walkthrough of how to run the full node and wallet headless in a Docker container using the docker compose is available in the Docker Compose section of the Full Node Guide.

3. Why should I not run requests for a full node while it is still syncing?​

During the syncing process, the full node downloads blocks and transactions from the network. As long as data is not fully available, the full node will not be able to reply to any request.

info

If any requests are sent to the full node during synchronization, an HTTP 503 (Service Unavailable) error will be returned as a response.

4. What are the steps and the system requirements for running a full node?​

There are two main ways to run a full node. The Full Node guide describes how to run a full node in Docker as well as how to run it from source code. For connecting a full node to the mainnet, it is needed to generate a peer ID and share it with the Hathor team. Details of how to run this procedure are available in each above-mentioned section of the Full Node guide.

A minimum setup for running a full node must comprise

  • 16GB RAM
  • 2 vCPU
  • 20+ GB storage

5. Besides using the /v1a/status endpoint of the full node API, how can I check if the node is healthy and in sync with the network?​

It is possible to parse the JSON response of /v1a/status to check if the node is in sync, by extracting the latest synced timestamp from this section and comparing it with the current timestamp. An example of such a JSON is:

dag {
   first_timestamp:1578075305,
   latest_timestamp:1642716622
}

Besides, be aware that the API will not respond while the node is initializing.

6. Do I have to clone the full node repository and get the source code for running it locally in order to change the WS_MAX_SUBS_ADDRS_EMPTY parameter?​

There are two limits you must be aware of when running a full node for a use case that handles multiple addresses. One is the maximum quantity of empty addresses subscribed (WS_MAX_SUBS_ADDRS_EMPTY) and the other one is the maximum subscribed addresses (WS_MAX_SUBS_ADDRS_CONN).

You can edit these configurations by cloning the full node repository or using a docker container. Roadmaps describing both operations are available in the Running from Source Code and Running in Docker sections of the Full Node guide.

More details about how to run a full node with custom configs may also be found in the Custom Configuration section of the Full Node guide.

7. How can I inform a custom config file when running a full node in a Docker container?​

A complete walkthrough of how to run a full node with custom configurations in a Docker container is available in the Custom configuration section of the full nodes guide.

8. Besides using database snapshots with RocksDB and waiting for a full sync, is there another way to speed up the full node restart?​

Currently, there is no other way. The full node needs to reload the database and populate indexes when restarted. There are some projects to speed up the full node initialization and they should be done in the future.

9. Are there rate limits to use the public full nodes (e.g. mint NFTs in batch)?​

For sake of safety and availability, public nodes have severe restrictions on the transactions rate and APIs. For implementing use cases and exploring the full capabilities of a full node it is strongly recommended to run a local full node.

A complete walkthrough of how to run a full node can be found in the Running in Docker and Running from Source Code sections of the Full Node guide.

10. How can I run a full node in a private VPC on AWS?​

The full node will need outbound access to other nodes (usually allowed by default) and it will benefit from having inbound rules to enable other nodes to try to connect to it. But, be careful to not expose all ports (restrict inbound rules to only the port that the node will listen with --listen tcp:<PORT>).

Another detail is that you don't need to expose port 40403 of your full node to connect to the network. However, it is generally good practice to expose a port that will allow more nodes to connect to your nodes and thus reducing the overall latency for receiving transactions/blocks. Also, it doesn't have to be port 40403, you can use any port: --listen tcp:50504 will use port 50504.

info

You will usually need at least one inbound rule to expose your full node in a private VPC on AWS. This rule must allow IPv4 access to port 40403 for any source (0.0.0.0/0), assuming you are using -listen tcp:40403 on your node.

11. How can I get a new address from the full node wallet?​

The full node wallet is deprecated and shouldn't be used. We suggest using the headless wallet or the wallet lib.

More details about how to get addresses from the headless wallet are available in the Getting Addresses of the Wallet Headless guide.