Setting up the new ARK Core has never been easier! If you want to have your own instance up and running, this guide will help you set one up in a few minutes with some basic Linux knowledge.
This guide is structured in a few sections:
- 1. Short Guide for Setting Up Relay Node —for those that have some basic knowledge about ARK and Linux, this is a simple, command based guide to get you up and running in no time.
- 2. Longer Guide For Setting Up Relay Node — this is a more in depth step by step guide that covers all aspects of setting up a Relay Node.
- 3. Configuring And Starting the Forging Process—those who want to be delegates will need to configure and start a separate Forger process in order to be able to confirm new blocks to run an active delegate.
- 4. Making A Snapshot —snapshot functionality makes a backup of the current DB state so you can recover from it and get synced in no time. This should be done regularly in case you need to recover due to any unforeseen circumstance or to get you up and running quickly on additional servers.
- 5. Restoring From Snapshot —process for restoring from a previously made snapshot.
- 6. Rollback Blockchain — if you want to rollback your blockchain to some previous state (eg. you forked or are testing something).
- 7. Copying Snapshots Between Servers — if you want to move a snapshot to a different server, either as independent backup or get your second node up and running quickly.
Extra security guide: if you want to secure your server with additional security countermeasures, please give this “How To Secure Your ARK Node ” guide a read.
Preparations
To start with the ARK Core install process, we recommend that you start with a clean server having at least the following minimum requirements.
Minimum Requirements for Running Relay Node
- Ubuntu 16.x / 18.x.
- 1 CPU (if you are going to run a Forger at least 2 dedicated CPUs).
- 2–4 GB RAM (if you are going to run a Forger at least 8GB RAM).
- at least 20 GB drive (we strongly recommend running it on SSD drive as there are a lot of read and write operations to the DB).
1. Short Guide for Setting Up Relay Node
For those who are familiar with Linux and ARK, running these commands will install and initialize ARK Core. Login to your newly created server and run these commands in sequence. There is more detailed information in the section following the commands:
adduser ark
usermod -aG sudo ark
su ark
cd ~
bash <(curl -s https://raw.githubusercontent.com/ArkEcosystem/core/master/install.sh)ark relay:start
TIP : All of the CLI commands with a description can be viewed at CLI Commands or by running
ark helpcommand.
Checking to see if everything is working:
Now we want to see if the ARK Relay process has started the synchronization process. You can do that by running one of these two commands:
- Running ark command:
ark relay:log
- Running a pm2 command:
pm2 logs
If the process has started, you will see a lot of messages like this, with actual data.
[YYYY-DD-MM hh:mm:ss][DEBUG]: Delegate () allowed to forge block 👍
Note that depending on the network you use, synchronization of the blockchain can take upwards of 10 hours (on Public Network).
Once the syncing finishe,s you will see messages ‘Delegate allowed to forge’ about every 8 seconds. You can always check the current height of the blockchain on our Explorer .
2. Longer Guide For Setting Up Relay Node
Please follow this extensive guide at our official ARK Core docs here .
3. Configuring and Starting the Forger Process
This part should only be followed if you intend to run a delegate or are planning to become one. First you need to make sure you register your ARK address as a delegate. You can do this inside the Desktop Wallet, by clicking on your wallet (make sure you have enough funds in the address you want to register) and click on the 3 dots in the upper right corner in the wallet address for which you wish to register the delegate, and click on ‘Register delegate’, sign the tx, and let it confirm. After that, we need to configure it on our relay node we previously configured. Login to your server and run this command:
ark config:forger
This will bring up an interactive menu where you have two options of setting up your forger passphrase, ‘Encrypted BIP38’ or ‘Plain BIP39’.
Chose the preferred method using the up and down arrow keys, confirm it with the enter key, and configure according to the screen instructions. Note that when writing a BIP39 passphrase (12 words) make sure you either paste it from the file or write it as it was shown when you generated it — all lower case, words separated by space, no space at the end.
? What method would you like to use to store your passphrase? › - Use arrow-keys. Return to submit.
❯ Encrypted BIP38 (Recommended)
Plain BIP39
- Encrypted BIP38 will encrypt your BIP39 passphrase with your custom password and save the encrypted passphrase. In order to decrypt it you will need to provide your set password so back it up as well. Once you set this up you will need to confirm with the “y” and “enter” keys.
- Plain BIP39 will save your 12 word passphrase in plain format. Once you set this up you will need to confirm with the “y” and “enter” keys.
An example of setting up Encrypted BIP38 passphrase:
ark config:forger✔ What method would you like to use to store your passphrase? › Encrypted BIP38 (Recommended)✔ Please enter your delegate passphrase …
you will write your 12 word passphrase (all lower case, 12 words, separated by space)✔ Please enter your desired BIP38 password …
your desired password to decrypt your passphrase✔ Can you confirm? …
pressing 'Y' + enter to confirm ✔ Prepare configuration
✔ Validate passphrase
✔ Prepare crypto
✔ Loading private key
✔ Encrypt BIP38
An example of setting up Plain BIP39 passphrase:
ark config:forger✔ What method would you like to use to store your passphrase? ›Plain BIP39✔ Please enter your delegate passphrase …
you will write your 12 word passphrase (all lower case, 12 words, separated by space)✔ Can you confirm? …
pressing 'Y' + enter to confirm✔ Prepare configuration
✔ Validate passphrase
✔ Write BIP39 to configuration
Note: passphrase (encrypted or not) is saved in file delegates.json in:
/home/ark/.config/ark-core//delegates.json(where you replace <network> with network you operate on (mainnet, devnet, testnet). You can also run commandark env:pathsto get this information.
Once you set this up you need to start the Forger process by writing:
ark forger:start
When the process has started, you will get a message:
Starting ark-forger... done
This will initiate and read your passphrase and start the Forger process. You can check Forger logs by writing one of this commands:
pm2 logs ark-forger// OR RUNark forger:log
If you set it up successfully, after your node is fully synced, you should see an output similar to this, but with your own delegate name and your delegate’s public key:
2|ark-forg | [2019-03-20 12:12:36][DEBUG]: Loaded 1 delegate: undefined (02297e602dcb3e6ee81205e9e0a7754d50cf3791b06b01fb6e9dde17059b1fb1ba)
2|ark-forg | [2019-03-20 12:12:36][INFO]: Forger Manager started with 1 forger
This is it — you have now successfully set up a Relay and Forger!
4. Making a Snapshot
Snapshot functionality is a built-in feature of the Core that you can easily use with the integrated CLI. Snapshot makes a backup of the current DB state so you can recover from a previously made snapshot and get synced much faster than syncing from 0.
This function should be done at least once per month if you need to recover due to some failure down the road (database corruption, database integrity failure, …) or to quickly set up on additional servers.
Making use of this feature makes most sense once your node is fully synced (up to latest height). To make latest snapshot run this command:
ark snapshot:dump
This will start up the snapshot process. Don’t interrupt it, as it might take a while, depending on the size of the blockchain. You’ll see a message, something along these lines, as time goes on:
[2019-03-20 12:57:40][INFO]: Snapshots: Database connected
[2019-03-20 12:57:40][INFO]: Starting to export table blocks to folder 1-7739750, codec: lite, append:false, skipCompression: false
[2019-03-20 13:01:55][INFO]: Snapshot: blocks done. ==> Total rows processed: 7739750, duration: 255150 ms
[2019-03-20 13:01:55][INFO]: Starting to export table transactions to folder 1-7739750, codec: lite, append:false, skipCompression: false
After it’s done, you’ll see this message informing you that the process to create the snapshot was shut down and you can now continue:
[2019-03-20 13:03:18][INFO]: Snapshot: transactions done. ==> Total rows processed: 2089576, duration: 82323 ms
[2019-03-20 13:03:18][DEBUG]: Closing snapshots-cli database connection
[2019-03-20 13:03:18][INFO]: Core is trying to gracefully shut down to avoid data corruption
This is it! You just made a backup of the blockchain.
You can see a list of all completed snapshots in this filepath (replace <network> with the network you operate on — mainnet,devnet,testnet):
ls /home/ark/.local/share/ark-core//snapshotsexample:ls /home/ark/.local/share/ark-core/mainnet/snapshots//In our example it made backup of blockchain 1-7739750 which means from height 1 to height 7739750
Useful tip: next time you want to make a snapshot, you can just append data to one of the previously made snapshots to save time. Lets use our snapshot we made in the previous step (directory filename 1–7739750) and append the difference of current height to it to have an up-to-date snapshot ready. We’ll run the command, replacing the filename with yours, which can be obtained by running the command from previous paragraphls /home/ark/.local/share/ark-core//snapshotsto list files. Let’s run this to append data to previous backup:
ark snapshot:dump --blocks=1-7739750//replace 1-7739750 with your own folder from previously created snapshot.
You should get message like this if you ran it correctly:
[2019-03-20 13:16:45][INFO]: Snapshots: Database connected
[2019-03-20 13:16:45][INFO]: Copying snapshot from 1-7739750 to a new file 1-7739894 for appending of data
[2019-03-20 13:16:52][INFO]: Starting to export table blocks to folder 1-7739894, codec: lite, append:true, skipCompression: false
[2019-03-20 13:16:52][INFO]: Snapshot: blocks done. ==> Total rows processed: 144, duration: 18 ms
[2019-03-20 13:16:52][INFO]: Starting to export table transactions to folder 1-7739894, codec: lite, append:true, skipCompression: false
[2019-03-20 13:16:52][INFO]: Snapshot: transactions done. ==> Total rows processed: 248, duration: 43 ms
[2019-03-20 13:16:52][DEBUG]: Closing snapshots-cli database connection
[2019-03-20 13:16:52][INFO]: Core is trying to gracefully shut down to avoid data corruption
We do recommend that you also take full (complete, unappended) snaps regularly as well as appending in case a snapshot gets corrupted after appending.
We now have a new and up-to-date snapshot!
5. Restoring from Snapshot
The process for restoring from a previously made snapshot is pretty straightforward. We’ll again make use of the integrated CLI Snapshot.
First, let’s stop the ARK Relay process, if we have it currently running, with:
ark relay:stop
After that we’ll run the restore command:
ark snapshot:restore --blocks=//replace with your previously made latest snapshot in our case lets use 1-7739894 so we'd run this command to restore:ark snapshot:restore --blocks=1-7739894
You will see a message similar to this. It will take some time, so leave it running:
[2019-03-20 13:22:09][INFO]: Snapshots: Database connected
[2019-03-20 13:22:09][INFO]: Starting to import table blocks from /home/ark/.local/share/ark-core/mainnet/snapshots/1-7739894/blocks.lite, codec: lite, skipCompression: false
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0% | ETA: 0s | 1/7739894 | Duration: 0s(node:4996) ExperimentalWarning: Readable[Symbol.asyncIterator] is an experimental feature. This feature could change at any time
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0% | ETA: 0s | 1/7739894 | Duration: 34s[2019-03-20 13:23:51][INFO]: Import from folder 1-7739894 completed. Last block in database: 7,739,947
[2019-03-20 13:23:51][INFO]: Rolling back chain to last finished round with last block height 7,739,913
[2019-03-20 13:23:51][DEBUG]: Closing snapshots-cli database connection
[2019-03-20 13:23:51][INFO]: Core is trying to gracefully shut down to avoid data corruption
After it is completed, we need to start the relay process again for it to resync (if applicable) back to current height:
ark relay:start
6. Rollback Blockchain
The rollback function is specifically useful if you forked, your node cannot seem to process new blocks, and you want to resync from the network from specified height.
First, let’s stop the ARK Relay process with:
ark relay:stop
After that, we’ll make use of Snapshot command rollback— for this case we can use two commands:
Rolling back to a specific height
ark snapshot:rollback --height=//where we replace with a height we want to rollback to and start to sync from the network. In our case lets say current blockchain height is 7,740,000 and if we want to go back 2,000 blocks we'll input 7739000 in so we'll run. We'd run:ark snapshot:rollback --height=7738000
You’ll see a message similar to this:
ark snapshot:rollback --height=7738000[2019-03-20 13:49:18][INFO]: Snapshots: Database connected
[2019-03-20 13:49:18][INFO]: Starting the process of blockchain rollback to block height of 7,738,000
[2019-03-20 13:49:18][INFO]: 1259 transactions from rollbacked blocks safely exported to file rollbackTransactionBackup.7738001.7740137.json
[2019-03-20 13:49:18][INFO]: Rolling back chain to last finished round 151,725 with last block height 7,737,975
[2019-03-20 13:49:18][DEBUG]: Closing snapshots-cli database connection
[2019-03-20 13:49:18][INFO]: Core is trying to gracefully shut down to avoid data corruption
After it is finished, we need to start the relay process again for it to resync from the previously rolled back state and sync back up to the current height by running:
ark relay:start
Rolling back to a specific number of blocks
ark snapshot:rollback --number=//where we replace with a number of blocks we want to rollback to and start to sync from the network. In our case lets say current blockchain height is 7,740,000 and if we want to go back 2,000 blocks we'll input 2000 in so we'll run. We'd run:ark snapshot:rollback --number=2000
You’ll see a message similar to this:
ark snapshot:rollback --number=2000[2019-03-20 13:49:18][INFO]: Snapshots: Database connected
[2019-03-20 13:49:18][INFO]: Starting the process of blockchain rollback to block height of 7,738,000
[2019-03-20 13:49:18][INFO]: 1259 transactions from rollbacked blocks safely exported to file rollbackTransactionBackup.7738001.7740137.json
[2019-03-20 13:49:18][INFO]: Rolling back chain to last finished round 151,725 with last block height 7,737,975
[2019-03-20 13:49:18][DEBUG]: Closing snapshots-cli database connection
[2019-03-20 13:49:18][INFO]: Core is trying to gracefully shut down to avoid data corruption
After it is finished, we need to start the relay process again for it to resync from the previously rolled back state and sync back up to the current height by running:
ark relay:start
Let it sync back, and you are back in business!
7. Copying Snapshots Between Servers
If you want to copy a snapshot to another server you own to bring it quickly into sync or to store a copy in a different location, we can make use of SCP (Secure Copy Protocol) which supports secure file transfers between different hosts.
SCP allows files to be copied to / from / between different hosts. It uses SSH protocol for transfers and provides the same authentication and level of security as SSH.
If you want to copy files from one server to another, we’ll run this command where we need to replace with the network you operate on (in our example mainnet), with snapshot name we are copying in our example it will be 1–7739894, with username of the server we are copying to and with its IP address:
scp -r /home/ark/.local/share/ark-core//snapshots/ @IP:/home/ark/.local/share/ark-core//snapshots/// to put this into a practical example:scp -r /home/ark/.local/share/ark-core/mainnet/snapshots/1–7739894 [email protected]:/home/ark/.local/share/ark-core/mainnet/snapshots/1–7739894
After this, you will enter yes to confirm you want to connect to the server and add it to the list of known hosts.
The authenticity of host ‘’ can’t be established.
ECDSA key fingerprint is
Are you sure you want to continue connecting (yes/no)? yes
After that, you will be prompted for the password of the server you are connecting to:
Warning: Permanently added '' (ECDSA) to the list of known hosts.
ark@'s password: inputpasswordhere
Your files will begin copying from one server to another. Wait until it completes, and you are good to go! If you wish to restore from the snapshot on your second server, login to that server and follow “Restoring from the Snapshot” above.
