Authorizing Transactions With Metamask

One of the ways that you can manage your Proton chain's wallet is to link it to an Ethereum account that you control. This can also act as a fail-safe lifeline in the event that you cannot access your Proton private key but do have access to your Ethereum wallet. That is because just like WebAuth can use your mobile device to authorize transactions on your desktop computer (or another device), you can also simply sign transactions with your Ethereum wallet. This is a brief tutorial on how to link an ETH account via Metamask  Wallet to an XPR account via WebAuth Wallet.

Linking an Ether Key

This guild assumes you have WebAuth installed on your mobile device. Navigate in your browser to webauth.com/login and click "login with mobile".

Click mobile, open your phone's WebAuth wallet. and scan the QR code that pops up, and you will be logged in.

Once logged in, click the little key shaped icon. I already have an Ethereum key added, as well as a couple of phones.

Next, click "Add new device", and select "Ethereum". You will see Metamask open, which will allow you to select an account to link.

After clicking "confirm", your key will be linked to your WebAuth, allowing you to authorize transactions using your Metamask wallet.

Conclusion

Having an Etherum key linked allows you to authorize transactions all across the XPR/Proton and Metal ecosystems using Metamask. It's very useful when trading on MetalX, for example, because I don't have to open my phone every time i want to sign a transaction.

That's all for today. Thanks for reading The Luminary Edition.

Overview

In the previous post, I explained how to configure nodeos for a state history node on the Proton chain. This post explains how to complete the rest of the process, and assumes you have a proton node that is fully synchronized with the entire state history already indexed to the head block.

The Process

• Installation of the remaining requirements
• Configuration of Hyperion for Proton Chain, your brand's URL, logo, contact data, alerts, etc
• Run ./run proton-indexer in ABI scan mode (took about 10 hours or so in my case)
• Modify the config/chains/proton-chain.json file after ABI scan completes
• Run the index scan. This must be done in batches. How many depends on when you're reading this and what kind of hardware you've got. In my case, it's looking like it'll be something like 17 - 24 batches, each taking a few hours to complete.
• When this is completed, launch  ./run proton-api, and place it behind a reverse proxy server such as Nginx for public access under a subdomain of your entity's domain.

Installing Requirements

This series is basically intended to offer some guidance because the official Hyperion documentation is a little daunting, and the PDF file found in the proton.start repository is somewhat outdated. However, so far, and with a little luck and God willing, I think that it's sufficient to say that between those two documents and the blogs from EOSphere, the infomation is out there. Don't be afraid to ask for help, but most if not all of the information that you need can be found in the Hyperion docs, EOSphere blogs, and the Proton PDF guild.

Hyperion documentation | Proton's Hyperion Guild | EOSphere Blog

If you're stumbling across this post and have not yet set up your state history node, see the part 1 of this series for detailed instructions setting that up.

After your nodeos instance is synchronized with a full state history block log, you need to install a whole bunch of programs, including:

• Elasticsearch 8.7+ - Required for historical data indexing.
• Kibana 8.7+ - Optional, for visualizing Elasticsearch data.
• RabbitMQ (v 3.12+) - Required for message queuing between indexer stages.
• Redis - Required for caching and inter-process communication.
• MongoDB Community Server - Conditionally Required. Needed only if enabling state tracking features (features.tables.* or features.contract_state.enabled in chain config). See MongoDB section below for details.
• Node.js v22 - Required runtime environment.
• PM2 - Required process manager for Node.js applications.
• NODEOS (spring 1.1.2 or leap 5.0.3 recommended) - Required Antelope node with State History Plugin (SHIP) enabled.

Although it's recommended to manually install everything, I've found that the automated installation shell script actually works fine, although you will need to manually install the correct version of NodeJs, which as of the time I am writing this, according to the Hyperion documentation, is 22. The installation script installed version 24.

It also installed node locally, rather than globally, and while that may have worked, I was trying to follow the PDF in the proton.start, which stated that node should be installed globally with sudo. In any case, after I ran the installation script, I installed node version 22 globally and removed from my eos user's bashrc the PATH updates pointing to the local version 24 of nodejs. After doing that, I ran as eos user with sudo the following commands (referanced from the xpr.start PDF):

sudo npm install pm2@latest -g
sudo pm2 startup

Next, I read through the manual installation process found on the official Hyperion documentation, linked above, ensuring that the installer script didn't miss anything. I would suggest doing the same, as there are some important settings particularly for ElasticSearch that need to be changed. Other than ElasticSearch, the installer pretty much took care of everything. However, for security reasons, you will want to change and note the passwords for mongo and rabbitmq.

Take care to note the credentials for mongo and rabbitmq, as well as the password found in the file named elastic.pass found in your eos user's . ~/.hyperion-installer directory, as you'll need them later.

At this point, I cloned the Hyperion repository and began to figure out how to configure it.

git clone https://github.com/eosrio/hyperion-history-api.git
cd hyperion-history-api
npm ci

When I ran npm ci, I got an error about a missing library. The solution ended up being to make use of a third party repository and install the missing library. This will likely be an issue if you are on Ubuntu 22 as recommended, so if npm ci throws, just go ahead and run these commands:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install --only-upgrade libstdc++6

Now, running npm ci will work.

Configuring Hyperion

Now, you can install the program, and create the connections.json file automatically with the hype-config tool found in the repository that you just cloned.

Install the program:

sudo npm install

Creating the connections config file:

./hyp-config connections init

You will be prompted for the connection information for all of the components, and other than the passwords that you hopefully changed, and including the elastic system password, you can accept the default options. Note that apparently when the Proton PDf file was written, the hyp-config tool must not have existed, and so far it seems you can safely use the tool to generate that file.  If I recall correctly, no fields needed to be updated in the connections.json file.

To make sure that all worked, run ./hyp-config connections test to ensure that everything works. In my case, everything did work. I skipped over the section of the PDF that says "Edit ecosystem.config.js file located in the hyperion-history-api directory", because I didn't find this anywhere in the current Hyperion documentation, and went on to configuring the chain, as per the Hyperion documentation.

http=http://127.0.0.1:8888
ship=ws://127.0.0.1:8080
./hyp-config chains new proton --http $http --ship $ship

That command should produce config/chains/proton.config.json, which you will need to edit. I changed all of the fields that were different from the configuration present in the PDF file. I suppose it is safe to post that configuration here. I added comments to the fields that must be changed after the first index run, they're marked with a preceding _comment :

Warning: The proton PDF has a mistake in it that caused me a lot of banging my head against the wall: ds_pool_size cannot be 1 if you have ds_queues 2. Set scaling.ds_pool_size to 2.

{
  "api": {
    "enabled": true,
    "pm2_scaling": 1,
    "chain_name": "proton",
    "server_addr": "0.0.0.0",
    "server_port": 7000,
    "stream_port": 1234,
    "stream_scroll_limit": -1,
    "stream_scroll_batch": 500,
    "server_name": "hyperion.luminaryvisn.com",
    "provider_name": "Luminary Visions, LLC",
    "provider_url": "https://www.luminaryvisn.com",
    "chain_api": "http://127.0.0.1:8888",
    "push_api": "https://api.luminaryvisn.com",
    "chain_logo_url": "https://i.postimg.cc/0y5zcgwL/proton-xpr-logo.png",
    "explorer": {
      "home_redirect": false,
      "upstream": "",
      "theme": ""
    },
    "_comment_enable_caching": "set to true after bulk indexing",
    "enable_caching": false,
    "cache_life": 1,
    "limits": {
      "get_actions": 1000,
      "get_voters": 100,
      "get_links": 1000,
      "get_deltas": 1000,
      "get_trx_actions": 200
    },
    "access_log": false,
    "chain_api_error_log": false,
    "log_errors": false,
    "custom_core_token": "XPR",
    "enable_export_action": false,
    "disable_rate_limit": false,
    "rate_limit_rpm": 1000,
    "rate_limit_allow": [],
    "_comment_disable_tx_cache": "set to false after bulk indexing",
    "disable_tx_cache": true,
    "tx_cache_expiration_sec": 3600,
    "v1_chain_cache": [
      {
        "path": "get_block",
        "ttl": 3000
      },
      {
        "path": "get_info",
        "ttl": 500
      }
    ],
    "node_max_old_space_size": 1024,
    "node_trace_deprecation": false,
    "node_trace_warnings": false
  },
  "indexer": {
    "enabled": true,
    "start_on": 1,
    "stop_on": 0,
    "rewrite": false,
    "purge_queues": true,
    "_comment_live_reader": "set to true after bulk indexing",
    "live_reader": false,
    "live_only_mode": false,
    "_comment_abi_scan_mode": "IMPORTANT set to false after initial ABI scan",
    "abi_scan_mode": true,
    "fetch_block": true,
    "fetch_traces": true,
    "fetch_deltas": true,
    "disable_reading": false,
    "disable_indexing": false,
    "process_deltas": true,
    "node_max_old_space_size": 4096,
    "node_trace_deprecation": false,
    "node_trace_warnings": false
  },
  "settings": {
    "preview": false,
    "chain": "proton",
    "eosio_alias": "eosio",
    "parser": "3.2",
    "auto_stop": 0,
    "index_version": "v1",
    "debug": false,
    "bp_logs": false,
    "bp_monitoring": false,
    "ipc_debug_rate": 60000,
    "allow_custom_abi": false,
    "rate_monitoring": true,
    "max_ws_payload_mb": 256,
    "ds_profiling": false,
    "auto_mode_switch": false,
    "use_global_agent": false,
    "index_partition_size": 10000000,
    "max_retained_blocks": 0,
    "es_replicas": 0
  },
  "blacklists": {
    "actions": [],
    "deltas": []
  },
  "whitelists": {
    "actions": [],
    "deltas": [],
    "max_depth": 10,
    "root_only": false
  },
  "scaling": {
    "readers": 2,
    "ds_queues": 2,
    "ds_threads": 1,
    "ds_pool_size": 2,
    "indexing_queues": 1,
    "ad_idx_queues": 1,
    "dyn_idx_queues": 1,
    "max_autoscale": 4,
    "batch_size": 10000,
    "resume_trigger": 5000,
    "auto_scale_trigger": 20000,
    "block_queue_limit": 10000,
    "max_queue_limit": 50000,
    "routing_mode": "heatmap",
    "polling_interval": 10000
  },
  "features": {
    "streaming": {
      "_comment_enable": "set to true after abi scan",
      "enable": true,
      "_comment_trace": "set to true after abi scan",
      "traces": true,
      "deltas": false
    },
    "tables": {
      "proposals": true,
      "accounts": true,
      "voters": true,
      "permissions": true,
      "user_resources": false
    },
    "contract_state": {
      "contracts": {}
    },
    "index_deltas": true,
    "index_transfer_memo": true,
    "index_all_deltas": true,
    "deferred_trx": false,
    "failed_trx": false,
    "resource_limits": false,
    "resource_usage": false
  },
  "prefetch": {
    "read": 50,
    "block": 100,
    "index": 500
  },
  "hub": {
    "enabled": false,
    "instance_key": "",
    "custom_indexer_controller": ""
  },
  "plugins": {},
  "alerts": {
    "triggers": {
      "onApiStart": {
        "enabled": true,
        "cooldown": 30,
        "emitOn": [
          "http"
        ]
      },
      "onIndexerError": {
        "enabled": true,
        "cooldown": 30,
        "emitOn": [
          "telegram",
          "email",
          "http"
        ]
      }
    },
    "providers": {
      "telegram": {
        "enabled": false,
        "botToken": "",
        "destinationIds": [
          1
        ]
      },
      "http": {
        "enabled": false,
        "server": "http://localhost:6200",
        "path": "/notification",
        "useAuth": false,
        "user": "",
        "pass": ""
      },
      "email": {
        "enabled": false,
        "sourceEmail": "sender@example.com",
        "destinationEmails": [
          "receiverA@example.com",
          "receiverB@example.com"
        ],
        "smtp": "smtp-relay.gmail.com (UPDATE THIS)",
        "port": 465,
        "tls": true,
        "user": "",
        "pass": ""
      }
    }
  }
}

Of course, you'll want to change some of those fields to match your own entity's upstream API server address, name, logo, etc. In the json file above, take note of the fields commented which must be changed after the first ABI synchronization phase completes. To be clear, the example above is configured for the ABI sync process, which must happen before the indexing phase. the fields below the lines starting with _comment are the boolean variables which need to inverted after the ABI scan is completed.

Before starting the ABI scan, you ought to test that worked correctly:

./hyp-config chains list
./hyp-config chains test proton

Creating Another ZFS Partition For Elasticsearch's Data

When my node was about 60% synced, I noticed that my main file system was going to run out of space.

eos@hyperion:~/hyperion-history-api$ df                                                                  
Filesystem                1K-blocks      Used  Available Use% Mounted on                                                                                                                                           
tmpfs                       6543464      1652    6541812   1% /run                                                                                                                                                 
/dev/md3                  919652204 508491096  364371684  59% /                                          
tmpfs                      32717304         0   32717304   0% /dev/shm                                   
tmpfs                          5120         0       5120   0% /run/lock                                  
/dev/md2                    1011148    137932     804508  15% /boot                                      
/dev/nvme1n1p1               522984      5120     517864   1% /boot/efi                                                                                                                                            
tmpfs                       6543460         4    6543456   1% /run/user/1000                                                                                                                                       
datavolume               2781099904       128 2781099776   1% /data/hyperion                                                                                                                                       
datavolume/blocks        2911697536 130597760 2781099776   5% /data/hyperion/blocks                      
datavolume/state-history 3494311552 713211776 2781099776  21% /data/hyperion/state-history   

Depending on the unique hardware setup that you have, now may be a good time to do what I just did and moved my elastic data from /var/lib/elasticsearch, which was on my server's core file system which is only 1 terabyte to another ZFS data volume that I created once I realized that with each batch of blocks I indexed, my internal file system's available space was declining while my /data disc, which is about 4 terabytes, stayed the same size. Out of all of the components required to run this gigantic system, Elasticsearch is far the most resource hungry.

If you are running a dedicated server that has one huge disc, you don't need to worry about this. However, if you set up a server with one smaller and one larger raid array like I did, you may want to tell Elasticsearch to store it's database on the larger disc. I ended up doing this when I was about 60% through the batched block index process, so I had to create another volume and then use rsync to copy all the existing data to that volume. If you haven't started indexing yet, skip that part*.

sudo zfs create datavolume/elasticsearch
sudo zfs set atime=off datavolume/elasticsearch
sudo zfs set recordsize=16K datavolume/elasticsearch
sudo zfs set compression=lz4 datavolume/elasticsearch
sudo zfs set primarycache=metadata datavolume/elasticsearch
sudo zfs set logbias=throughput datavolume/elasticsearch
sudo chown -R elasticsearch:elasticsearch /data/hyperion/elasticsearch
sudo chmod 750 /data/hyperion/elasticsearch
# Make sure elastic is NOT running
sudo systemctl stop elasticsearch
# Double check
sudo systemctl status elasticsearch
# Copy all existing indices, logs, and metadata if required *
sudo rsync -aHAX --info=progress2 /var/lib/elasticsearch/ /data/hyperion/elasticsearch/

Edit /etc/elasticsearch/elasticsearch.yml and change path.data from /var/lib/elasticsearch to    /data/hyperion/elasticsearch.

path.data: /data/hyperion/elasticsearch

Now start Elasticsearch and make sure that everything works correctly.

sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

I haven't deleted the contents of /var/lib/elasticsearch just yet, but I did just start another batch and everything seems to be working fine so far, so, at some point I will end up rm -f'ing that directory to get back all that precious disc space. (Which as of this moment, which is after the ABI scan process appears to be about 375 gigabytes with my database indexed to from 200000000, and a current latest block of 348559941. I am currently running a batch from 200000000 to 250000000, which is a potentially dicey range, so, and by the way, I also disabled the live_reader boolean parameter in the proton-chain.json config file, because I realized that I may as well wait till I am synced to the latest block before indexing currently produced blocks in order to conserve system resources. Don't worry about this yet, first , you need to  do the ABI scan.)

The ABI Indexing Process

Assuming that no errors are thrown, you should be good to begin the ABI indexing process.

./run.sh proton-indexer

Currently, I am waiting for that process to finish. I will continue updating this after it does.

12 Hours Later

The Long Process of Batched Indexing

Now, according to the folks in the block producer telegram channel, I must change those JSON fields that I noted in the config I pasted above to their opposite boolean parameters (perhaps except live_reader) and run this again, and again ... and again. I've been encouraged by the guys in the chat is to do this next run in batches, by adjusting the start block and end block like 0-10000000, 10000000-20000000, etc.

I was told that this part would take a long time. Anyway, here's what that looks like:

This seems to be going fast, so maybe I'll increase that block interval, or better yet, write a shell script to handle this. After only 10 minutes or so:

So, you'll need to run this, increase the start_block and end_block fields in the chains/proton-chain.json incrementally with a range that suits the requirements of your system, and then rinse and repeat until you get to the head block. You can find the head block by querying your nodeos endpoint:

By the way, I believe that it is best to not enable live_reader until after you have all of the historical blocks indexed. Note that you may see messages like "No blocks are being processed, please check your state history node" when the live_reader is disabled:

You will know when you see the "parallel workers finished the requested range" messages that a batch has completed, as seen in the image below.

It's never a bad idea to check RabbitMq before stopping the indexer. When it's indexing to Elasticsearch, you'll see plenty of activity such as this:

After seeing the message logs indicating the workers have stopped, check RabbitMq, you should see much less going on:

For the sake of completeness, I'll add this screenshot which is what a finished batch looks like once the configured range has completed, without new blocks being indexed:

When you get to this point, gracefully stop the program with this command, ./stop proton-indexer.

Wait for the stop script to complete, double check the RabbitMq interface, note the last indexed block in the output, as this+1 will be your next start_block if you accidentally shut down prematurely instead of your current end_block that you were targeting + 1. Control + c the output and edit your config/chains/proton-chain.json file to increment the next target block range, and then run the indexer again. When shut down, you won't see anything on RabbitMq.

./run.sh proton-indexer

In the second batch, I set my start_block to 10000000 and end block to 30000000, effectively doubling the batch size because my system seems to be able to handle it. While indexing, a range of 20000000 blocks, my system's CPU usage is nearly maxed, and the process takes just a little longer, and the resource consumption gets a little higher with each iteration, due to the ever expanding nature of the blockchain.

Run through this process. As of right now, if you batch in increments of 20000000, you'll have to do this ~ 17 times. I am about 50% done the process as of this moment. The system resources become ever-more demanding as you go. Once I got to block

After this process is completed, you need to start the api with ./run proton-api. Finally, configure an nginx reverse proxy with TLS enabled serving https to 127.0.0.1:7000. Configure your DNS like you're setting up any other web service. Our indexer will be reachable at https://hyperion.luminaryvisn.com as soon as I finish indexing my node, which ought to be within the next few days.

Some Final Thoughts

Hyperion isn't as daunting to set up as it seems. It is however quite a complex process, but once you do it, you'll see that it's really not so bad. I got through it between the documentation and blog posts linked in this post, as well the very friendly community in the block producers telegram channel. The EOSphere blogs I somehow missed till a little later in the process and are very useful and more comprehensive than this blog. This blog is specifically for the Proton Network.

Because this system is so resource intensive and complex, it's a good idea to run this behind a content distribution network so that you have a WAF in front of it. The internet is still like the wild west, so I would recommend at least using Cloudflare – you don't necessary need to even pay for that, and when configured properly can save you a lot of hassle. In fact, this is arguably one of the best use cases for a CDN, as all data on a blockchain in intended to be public, and CDN's when used for services that require privacy may pose a risk.

After I am done indexing, there will probably be a couple of other things that I will need to do before exposing the Hyperion api to the public. If you made it this far, I am confident that you can set up a reverse proxy, but I will write a third post to conclude this series, explaining how to do all of that.

Additionally, I am certain that there will be maintenance required from time to time, and I am currently assuming that I did everything correctly thus far. If that turns out not to be the case, I'll update this post or add that to my final post of this series, depending on whichever makes more sense.

Until then, thank you as always for reading The Luminary Edition, and remember to Vote Luminary Vision! After all, we are now about to be one of a minority of block producers that are providing Hyperion state history resources, which the network is currently in need of more of, as existing services are reported to be strained at the moment. Luminary Vision is investing in the network, because we're passionate about The Proton Chain.

PS – if you are considering becoming a block producer on Proton, Telos, EOS, or any other chain that uses the EOS stack, you can always hire me to do so. Feel free to reach out to either me or my client on Telegram or by email. You can find us lurking in the Proton community Telegram channels.

Scant Documentation

The documentation that exists explaining how to set up a Hyperion state history node is incredibly outdated, with the last revision being in 2020. I figured that it would be helpful to document the process of setting this up. Surely, that will save someone some serious hassle.

The intended audience of this article is a Linux administrator with basic knowledge of nodeos, aka LEAP (or SPRING in the case of native EOS). Because the only people reading this will surely already know their way around a POSIX compliant shell, I will skip over providing copy and paste code for some of the really easy stuff like extracting a tarball. If you can't do that or don't know what a tarball is, you are on the wrong website. However, if you, like myself, wanted to contribute to the Proton Chain ecosystem by running Hyperion state history node, congratulations, thank you, welcome to the XPR community (never to be confused with XRP – blasphemy!!!), and I do hope that this tutorial will save you as much time as it would have saved me.

System Requirements

Out of all of the dedicated servers that you'll need in order to successfully become a block producer on the XPR/Proton chain network, your Hyperion infrastructure will be the most expensive. If you're not prepared to spend $250+ a month on another dedicated server, just forget it.

Other than the massive storage needss, the specifications are about the same as your API or BP node, except you'll want ideally 128 gigs of RAM (to be super future proof), or at least 64 gigs – 32 is not quite enough for a state history node, unlike a producer node.

Interesting note about producer nodes: despite the high RAM requirements, my producer never uses more than 20% of it's RAM. Even that is rare. Nor does it use more than perhaps 10% of it's CPU, but good Lord, don't think that means you can cheap out and downgrade! For whatever reason, your producer needs to be badass as Batman, and I recommend running the most powerful intel CPU you can afford (within reason) for the producer (at LEAST, 8 cores at around 4 gigahertz, 16 is better!).

You'll of course want a powerful CPU, preferably an Intel but AMD's will work, just make sure you have at least 8 physical cores, and really I'd recommend at least 12. In my experience, Intel CPU's are always going to offer better performance no matter what you're doing. I highly recommend using an Intel for your producer node, however, you can save a little money and opt for an AMD CPU for your Hyperion node, as it's not as mission critical as the thing that actually produces the blocks is.

Finally, you'll need as much storage as possible. I was told that as of this moment, which is late October of 2025, a Hyperion node takes up 2 TB of space. So you'll definitely want at least a 4 TB (8 would be even better, as it will only ever grow as time goes on), separate NMVE drive to store your `state-history` and `blocks` directories, as well as at least a 1 TB NVME for your base system, perhaps 2 TB would be better here as well, because you may want space to provide state history archives for download. For the larger disc, make sure you're using at least RAID-1 and configure ZFS to optimize performance.

Setting up the separate data volume

In my case, I had two NVME's in RAID1 to set up:

/dev/nvme2n1
/dev/nvme3n1

• Install ZFS

  sudo apt-get install zfsutils-linux 

• Locate the Disk 2 device name

   lsblk 

• Create ZFS Pool called "datavolume" on device "sdb"

   sudo zpool create datavolume mirror /dev/nvme2n1 /dev/nvme3n1

Verify status

zpool status

  pool: datavolume
 state: ONLINE
config:
        NAME          STATE     READ WRITE CKSUM
        datavolume    ONLINE
          nvme2n1     ONLINE
          nvme3n1     ONLINE

Configure various ZFS settings for optimization

• Enable compression and disable access time updates

   sudo zfs set compression=lz4 datavolume
   sudo zfs set atime=off datavolume

• Set ARC caching mode

   sudo zfs set primarycache=all datavolume 

• Set the main mountpoint

   sudo zfs set mountpoint=/data/hyperion datavolume 

• Now create sub-datasets

sudo zfs create -o mountpoint=/data/hyperion/blocks datavolume/blocks
sudo zfs create -o mountpoint=/data/hyperion/state-history datavolume/state-history

• Disable compression on state-history:

   sudo zfs set compression=none datavolume/state-history 

Verify status:

zfs get mountpoint,compression,atime,primarycache datavolume
zpool status

You should see something like this again:

zpool status
NAME        PROPERTY      VALUE           SOURCE
datavolume  mountpoint    /data/hyperion  local
datavolume  compression   lz4             local
datavolume  atime         off             local
datavolume  primarycache  all             local
  pool: datavolume
 state: ONLINE
config:

	NAME         STATE     READ WRITE CKSUM
	datavolume   ONLINE       0     0     0
	  mirror-0   ONLINE       0     0     0
	    nvme2n1  ONLINE       0     0     0
	    nvme3n1  ONLINE       0     0     0

errors: No known data errors

The ZFS filesystem will reduce wear on the NVME discs and help conserve space, if I understand correctly. Now, set up nodeos like you normally would. I like to create a new user and place the home directory of that user in /opt/xpMainNet.

Configure Nodeos (LEAP)

• Verify binary's integrity and then install (recommended)
  Import the maintainer keys (run as root)

cd /tmp
wget https://github.com/arhag.gpg
gpg --import arhag.gpg
wget https://github.com/ericpassmore.gpg
gpg --import ericpassmore.gpg
wget https://github.com/spoonincode.gpg
gpg --import spoonincode.gpg
wget https://github.com/AntelopeIO/leap/releases/download/v5.0.3/leap_5.0.3_amd64.deb
wget https://github.com/AntelopeIO/leap/releases/download/v5.0.3/leap_5.0.3_amd64.deb.asc
gpg --verify leap_5.0.3_amd64.deb.asc leap_5.0.3_amd64.deb

• You should see several GOOD SIGNATURE messages, indicating the binary's integrity has been confirmed.

• Proceed with installation (as root)

apt install ./leap_5.0.3_amd64.deb
useradd -m /opt/XPRMainNet -s /bin/bash eos
usermod -a -G sudo eos
passwd eos # set a strong pass. remove sudo from user after we're done 

• As user eos now

su eos
cd /opt/XPRMainNet && git clone https://github.com/XPRNetwork/xpr.start.git ./

• Now symlink the /data/state-history and /data/blocks to your data directory and proceed as normal like your setting up a non-producing node

Next, we'll enable the state history plugin & sync from a backup. Ultimately, you want the entire history of the blockchain on your node. It can take a long time to generate that data from scratch, so ideally you want to download archives of the state-history, block logs , and then finally you need a snapshot that was taken before the height of the block log that matches the state-history. By the way, make sure you delete blocks/reversible from the archive, because that doesn't happen automatically for some reason.

You can get a state history archive from bloxprod's website taken on October 18th, 2025 as of the time I wrote this, and saltant has a snapshot from July, 2025 as well. I downloaded the statehistory.xz and blocks.xz from the aforementioned, respective sites, extracted them into my symlinked ZFS volume directories, as well as the earlier snapshot from July, took a deep breath, and started nodeos with the snapshot flag, and my history node started synchronizing. It only took about 3 hours to catch up to the present.

Grab the state history and blocks archives with wget or curl:

Downloads from Bloxprod

Grab the July snapshot with wget or curl:

Downloads from Saltant

Extract the archives in their respective directories, data/blocks, data/state-history, and snapshots/snapshot.bin.

If the resources above don't work whenever you're reading this, find us on telegram in the block producers chat and we will assist you. Start nodeos with the --snapshot option. Apparently, it's no longer necessary to provide the flags that disable replay optimization.

I recommend configuring everything via the ini file except the snapshot, which must be provided from the command line. Finally, start her up and wait for synchronization to occur.

./start.sh --snapshot snapshots/snapshot.bin
tail -f stderr.txt

Ultimately, once synced, you want to query get_info via the api on 127.0.0.1:8000 and make sure the first available block is 1:

curl -k http://localhost:8888/v1/chain/get_info

{
  "server_version": "d133c641",
  "chain_id": "384da888112027f0321850a169f737c33e53b388aad48b5adace4bab97f437e0",
  "head_block_num": 347190879,
  "last_irreversible_block_num": 347190551,
  "last_irreversible_block_id": "14b1b517f24dab92b00c097c41f5c887d9b9ee290eddb6cefd8253d69b24ea6f",
  "head_block_id": "14b1b65f92f0e8f5e48c732e6687806a2caf4b3cc022ad18ba2ed1bf36aae1bb",
  "head_block_time": "2025-10-24T03:51:55.500",
  "head_block_producer": "saltant",
  "virtual_block_cpu_limit": 200000000,
  "virtual_block_net_limit": 1048576000,
  "block_cpu_limit": 200000,
  "block_net_limit": 1048576,
  "server_version_string": "v5.0.3",
  "fork_db_head_block_num": 347190879,
  "fork_db_head_block_id": "14b1b65f92f0e8f5e48c732e6687806a2caf4b3cc022ad18ba2ed1bf36aae1bb",
  "server_full_version_string": "v5.0.3-d133c6413ce8ce2e96096a0513ec25b4a8dbe837",
  "total_cpu_weight": "1074161312000",
  "total_net_weight": "1041519891000",
  "earliest_available_block_num": 1,
  "last_irreversible_block_time": "2025-10-24T03:49:11.500"

In the next post of this series on setting up a Hyperion history node for Proton Chain, aka XPR Network, I'll run through installing and configuring all of the required components. This information is out there, but the only known, complete guild is a PDF file that is at least five years old. Fortunately, Hyperion has descent instructions for this process. However, as I mentioned, the official instructions for the proton chain are somewhat outdated, thus I've been pouring over documentation for and asking a lot of questions in the block producer telegram channel.

At the moment I am pretty close to initiating the index process for my node. After I tie up a few lose ends and confirm I've got everything right, I will retroactively retrace my steps and document them in my next blog post. Thanks for reading.

It was recently brought to my attention that a handful of block producer nodes on Proton Mainnet  (including the one that I administer) were "producing empty blocks". An empty block is exactly what it sounds like – a block that contains no data. Apparently, someone was flooding the network with invalid transactions. These transactions were reverting and thus were not being included in the blocks produced by the BP's.

Normally, this isn't particularly problematic, but in this case it was because certain BP's were being overwhelmed by the abnormally high number of invalid transactions, and rather than discarding them and including valid transactions in the block the BP produced, some BP's were simply discarding all transactions and producing blocks with no transactions included at all.

The BP's that were suscpectable to this issue were those that were either running their BP and API nodes on the same server, or, as was in my particular case, seperating the API and producer node by using virtual machines that were hosted on the same bare metal server.

During the last decade that I've been doing Linux administatrion, I've never encountered a situation quite like this. I tend to KVM quite a bit, and it has always been a viable solution for nanaging system resources in their own isolated enviroments. But in this case, the sheer scale of the attack on the XPR network was overwhelming the host system. After all, virtual machines share the system resources of their host.

As you may have assumed, the solution was to spin up another dedicated server and host the block producer on that machine, while migrating the API from KVM and running it straight on the bare metal of the original system. After doing this,  we were no longer producing empty blocks.

If you are configuring a Proton mainnet node, it would be a good move to isolate your producer and API servers physically – they must each run on their own bare metal dedicated servers! Doing this will save you from dealing with unforeseen issues.

Additionally, BP's were instructed to enable some additional settings in their `config.ini`.

disable-subjective-p2p-billing = false
disable-subjective-api-billing = false
subjective-account-decay-time-minutes = 60

That took care of it! No more empty blocks.

Our companies next project is becoming a NEAR validator, so I will be documenting that process. There is currently a "Staking Wars" challenge going on. Those whom win will become validators and may even receive the NEAR that they will be staking.

Before I begin documenting the process, I would like to draw your attention to some things that initially confused me. Don't follow these instructions. Rather, follow these instructions:  

https://github.com/near/stakewars-iii/blob/main/challenges

The former link talks about using either the testnet or guildnet when you should in fact be using the shardnet. I didn't initially understand this and so I had to redo the entire thing.

The first thing you need to do is get a server. The specifications are as follows:

Pretty much any modern CPU will have those features so what you should pay particular attention to is the RAM, cpu cores, and storage space. I would recommend using either Debian or Ubuntu for an operating system.

After you have got a server up and running, you can get your test network node up and running. The first thing, as always you ought to do after setting up your ssh keys is update the system.

sudo apt update && sudo apt -y upgrade

After the system is up to date, the first step is to install nodejs. There are several ways of doing this, but I opted to download the binaries because the version 17.xx is specified. I downloaded the latest 17.xx binary from the directory, hosted here: https://nodejs.org/dist/v17.9.1/

Next, we need to install it. Extract the binaries and then copy them to somewhere and add it to your system path.

tar -xf *.xz
node-v17.9.1-linux-x64.tar.gz
node-v17.9.1-linux-x64 /usr/local/lib/node/nodejs
cat < _EOF_ >> ~/.profile
export NODEJS_HOME=/usr/local/lib/node/nodejs
export PATH=$NODEJS_HOME/bin:$PATH
_EOF_

Note: ensure that `.profile` is being loaded with your `.bashrc`. If not just add a line to your ~/bash_rc:

source ~/.profile

Next, we need to install near-cli. It's very simple:

sudo npm install -g near-cli

Then confirm that it is working:

near validators current

You should see some output. See screenshot above. Now we have a ton of dependencies to install:

sudo apt install -y git binutils-dev libcurl4-openssl-dev zlib1g-dev libdw-dev libiberty-dev cmake gcc g++ python3 docker.io protobuf-compiler libssl-dev pkg-config clang llvm cargo python3-pip clang build-essential make awscli ccze jq

Next, we need to install rust:

export PATH="$USER_BASE_BIN:$PATH"
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

And then near-core – I just went with the latest version available.

source $HOME/.cargo/env
git clone https://github.com/near/nearcore
cd nearcore
git fetch origin --tags
git checkout tags/1.28.0-rc.3 -b mynode
make neard

After it's successfully installed, we need to set it up and then run it:

./target/release/neard --home ~/.near init --chain-id testnet --download-genesis

When that completes, we need to replace the configuration file:

rm ~/.near/config.json
wget -O ~/.near/config.json https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/testnet/config.json

Finally we need to download the latest snapshot from ec2:

aws s3 --no-sign-request cp s3://near-protocol-public/backups/testnet/rpc/latest .
LATEST=$(cat latest)
aws s3 --no-sign-request cp --no-sign-request --recursive s3://near-protocol-public/backups/testnet/rpc/$LATEST ~/.near/data

When that is complete, we can start up the node and let is synchronize with the network:

cd nearcore
./target/release/neard --home ~/.near run

After it is synced up (which should not take very long), lets configure near daemon to run as service:

cat << __EOF>> >/etc/systemd/system/neard.service
[Unit]
Description=NEARd Daemon Service

[Service]
Type=simple
User=<USER>
#Group=near
WorkingDirectory=/home/<USER>/.near
ExecStart=/home/<USER>/nearcore/target/release/neard run
Restart=on-failure
RestartSec=30
KillSignal=SIGINT
TimeoutStopSec=45
KillMode=mixed

[Install]
WantedBy=multi-user.target

__EOF__

sudo systemctl enable neard
sudo systemctl start neard
sudo systemctl reload neard
# test log functionality
journalctl -n 100 -f -u neard | ccze -A

Now we need to create a wallet and then a staking pool.

To create a wallet, head over to https://wallet.shardnet.near.org/. Then you need to login. Simply run:

near login

Open that link in the same browser as the one in which you created and are signed into your wallet. It will look as if it didn't work, but it did:

Finally, type in the name of your account (you.shardnet.near) and then you should be good.

You probably need to generate a validator key next. Pick a name for your staking pool. I called mine simply "luminaryvision" which is what my username is. Then you need to copy it to correct directory:

near generate-key <pool_id>
cp ~/.near-credentials/shardnet/YOUR_WALLET.json ~/.near/validator_key.json

This is the command that I ran to do so:

near call factory.shardnet.near create_staking_pool '{"staking_pool_id": "luminaryvision", "owner_id": "luminaryvision", "stake_public_key": "ed25519:76R8JC14uVckoEJbX13rww5RmZ6GXoKcQtY6mr3ZxTHA", "reward_fee_fraction": {"numerator": 1, "denominator": 100}, "code_hash":"DD428g9eqLL8fWUxv8QSpVFzyHi1Qd16P8ephYCTmMSZ"}' --accountId="luminaryvision.shardnet.near" --amount=2048 --gas=300000000000000

Now in this example:

• "luminaryvision" is the name of my pool as well as my account name
• The field starting with "ed25519" is my public key.
• The numerator field which I set to 1 is
• Account_id is your account's id (duh)
• The gas is the fee you want to pay for this tx.

Afterwards, you need to send a "ping" transaction:

near call luminaryvision.factory.shardnet.near ping '{}' --accountId luminaryvision.shardnet.near --gas=200000000000000

If that goes through, then we are almost done! The last thing that this guild will show  you is how to check your node to ensure it is configured correctly. Start by looking at your logs:

journalctl -n 100 -f -u neard | ccze -A

Next, you can check the version of your node by querying the RPC server:

curl -s http://127.0.0.1:3030/status | jq .version

Here are some useful commands and their explanations:

near view luminaryvision.factory.shardnet.near get_accounts '{"from_index": 0, "limit": 10}' --accountId luminaryvision.shardnet.near # check stake and delegation
curl -s -d '{"jsonrpc": "2.0", "method": "validators", "id": "dontcare", "params": [null]}' -H 'Content-Type: application/json' 127.0.0.1:3030 | jq -c '.result.prev_epoch_kickout[] | select(.account_id | contains ("luminaryvision.factory.shardnet.near"))' | jq .reason  # if a validator is kicked, this will tell you why
curl -r -s -d '{"jsonrpc": "2.0", "method": "validators", "id": "dontcare", "params": [null]}' -H 'Content-Type: application/json' 127.0.0.1:3030 | jq -c '.result.current_validators[] | select(.account_id | contains ("POOL_ID"))' # check produced vs expected blocks

At this point you should be able to see your node on the list of validators:

If so, congrats! We have reached the end of the tutorial. One last thing – be sure to watch for new pinned posts in the stake wars channel of the discord community.

One final thought is you should put your kernels governor into performance mode:

$ echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance

I hope you found this helpful or interesting.

Proton is so mysterious and scary at times. The first time that I tried to claim validator rewards, I thought that I accidentally sent them the wrong account. Thus I figured that a post about how to do this correctly would be useful.

Voter Rewards

To claim voter rewards, unlock your wallet and run the following command (replacing luminaryvisn with your producer name):

./cleos.sh push transaction '{
  "delay_sec": 0,
  "max_cpu_usage_ms": 0,
  "actions": [
    {
      "account": "eosio",
      "name": "voterclaim",
      "data": {
        "owner": "luminaryvisn"
      },
      "authorization": [
        {
          "actor": "luminaryvisn",
          "permission": "owner"
        }
      ]
    }
  ]
}'

Validator Rewards

Eoseo allows us very granular control over permissions. Here we are creating a new permission called "claimer" using our active key:

./cleos.sh set account permission luminaryvisn claimer '{"threshold":1,"keys":[{"key":"EOS83tLDZorE8eQDhKrZdUG21DG1jctGhEJDEKpsfKJ6kjbQHtCjg","weight":1}]}' "active"

Now, we configure the permission we just created called "claimer" to be able to claim rewards and do nothing else:

./cleos.sh set action permission luminaryvisn eosio claimrewards claimer

Finally we are able to claim rewards:

./cleos.sh system claimrewards luminaryvisn -p luminaryvisn@claimer

We can only do this every 24 hours and just because the command appears to execute, doesn't mean that you actually had any rewards to claim.

I created a script to automatically perfrom these actions for you. Set it up as a cron job to run every day. Apparently you can claim every 24 hours plus 1 second, so it may not actually be able to claim on every single run. Note that you may want to use another keypair when you create the permission (for security reasons) – at some point, there will be another blog post about that.

In this series of the Luminary Edition, I will document the process of configuring your main network block producer node. Note that in order to launch a node on the main network, you must successfully run on the test network for at least two weeks. If you've been approved then congratulations, and I hope you find this blog helpful. This post with cover configuring your block producer node.

Server Specifications

You will need a really powerful server to run this on. The specs that we chose to start with are as follows:

• 12 core cpu AMD cpu @3.8 ghz
• 64 gigs of ram
• 500 gig ssd
• 4 TB raid ssd

Installing Eoseo

As I mentioned my last post, compiling the software takes forever so I was going to deploy with per-compiled binaries. This was an Ubuntu 21 system.

root@ns106991:/tmp# dpkg -i eosio_2.0.5-1-ubuntu-18.04_amd64.deb
Selecting previously unselected package eosio.
(Reading database ... 71870 files and directories currently installed.)
Preparing to unpack eosio_2.0.5-1-ubuntu-18.04_amd64.deb ...
Unpacking eosio (2.0.5-1) ...
dpkg: dependency problems prevent configuration of eosio:
 eosio depends on libicu60; however:
  Package libicu60 is not installed.
 eosio depends on libtinfo5; however:
  Package libtinfo5 is not installed.

dpkg: error processing package eosio (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 eosio

But I ran into an issue, so I tried to compile it from source.

mkdir /opt/EOSIO  
cd /opt/EOSIO  

git clone https://github.com/eosio/eos --recursive    
cd eos  

git checkout v2.0.5  
git submodule update --init --recursive   

Run the build script ...

./scripts/eosio_build.sh -P -y
EOSIO Version: 2.0.5
Sun Mar 13 01:18:09 UTC 2022
User: root
Current branch: HEAD
No installation location was specified. Please provide the location where EOSIO is installed.

EOSIO will be installed to: /root/eosio/2.0
=====================================================================================
======================= Starting EOSIO Dependency Install ===========================
Architecture: Linux
OS name: Ubuntu
OS Version: 20.04
CPU cores: 12
Physical Memory: 65G
Disk space total: 3666G
Disk space available: 3476G
 - You must be running 16.04.x or 18.04.x to install EOSIO.

On the test network, I was able to use the latest Ubuntu long term release, but the build script insists on using this older version. It is not worth the time to hack it, so just be sure to use Ubuntu 18.04.1.

./scripts/eosio_build.sh -P -y
./scripts/eosio_install.sh

mkdir /opt/bin
mkdir /opt/bin/v2.0.5
cp /opt/EOSIO/eos/build/programs/nodeos/nodeos /opt/bin/v2.0.5/
cp /opt/EOSIO/eos/build/programs/cleos/cleos /opt/bin/v2.0.5/
cp /opt/EOSIO/eos/build/programs/keosd/keosd /opt/bin/v2.0.5/
ln -sf /opt/bin/v2.0.5 /opt/bin/bin

This time the software installed okay. At this point I would advise making a full system backup of your server. This will come in handy if you decide to configure a history node in the future. The next step is to download the boilerplate and configure everything in the config.ini file.

mkdir /opt/ProtonMainNet
cd /opt/ProtonMainNet
git clone https://github.com/ProtonProtocol/proton.start.git ./

If you have not already, you need to create a new account for your node. Then you need to edit your config.ini, editing these fields

• server address: p2p-server-address = ENTER_YOUR_NODE_EXTERNAL_IP_ADDRESS:9876
• if BP: your producer name: producer-name = YOUR_BP_NAME
• if BP: add producer keypair for signing blocks (this pub key should be used in regproducer action):
  signature-provider = YOUR_PUB_KEY_HERE=KEY:YOUR_PRIV_KEY_HERE
• replace p2p-peer-address list with fresh generated on monitor site: https://monitor.protonchain.com/#p2p
• Check chain-state-db-size-mb value in config, it should be not bigger than you have RAM:
  chain-state-db-size-mb = 16384

Here is what mine looked like after succesful configuration:

################################################################################
# Proton tools
#
# Created by http://CryptoLions.io
# 
# https://github.com/ProtonProtocol/proton.start
#
#
################################################################################


    ###########--producer--#########################
    #
    agent-name = luminaryvisn
    plugin = eosio::producer_plugin
    producer-name = luminaryvisn
    signature-provider = EOS83tLDZorE8eQDhKrZdUG21DG1jctGhEJDEKpsfKJ6kjbQHtCjg=KEY:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    #
    ############################################################### 

    
    http-server-address = 0.0.0.0:8888
    p2p-listen-endpoint = 0.0.0.0:9876
    p2p-server-address = xxxxxxxxxxxxxxx:9876
    
    chain-state-db-size-mb = 62767 # I have 64 gigs ram so set this just under
    reversible-blocks-db-size-mb = 1024
    
    contracts-console = true
    
    p2p-max-nodes-per-host = 100
    
    chain-threads = 8
    http-threads = 6
    #wasm-runtime = wabt
    http-validate-host = false
    verbose-http-errors = true
    abi-serializer-max-time-ms = 2000

    #produce-time-offset-us = 250000
    last-block-time-offset-us = -300000
    # eosio2.0
    http-max-response-time-ms = 100
    #Only!! for performance eosio 2.0+
    eos-vm-oc-compile-threads = 4
    eos-vm-oc-enable = 1
    wasm-runtime = eos-vm-jit
    #END        
        

    # Safely shut down node when free space
    chain-state-db-guard-size-mb = 128
    reversible-blocks-db-guard-size-mb = 2


    access-control-allow-origin = *
    access-control-allow-headers = Origin, X-Requested-With, Content-Type, Accept
    # access-control-allow-headers =
    # access-control-max-age =
    # access-control-allow-credentials = false


    # actor-whitelist =
    # actor-blacklist =
    # contract-whitelist =
    # contract-blacklist =
    # filter-on =


    # SSL
    # Filename with https private key in PEM format. Required for https (eosio::http_plugin)
    # https-server-address =
    # Filename with the certificate chain to present on https connections. PEM format. Required for https. (eosio::http_plugin)
    # https-certificate-chain-file =
    # Filename with https private key in PEM format. Required for https (eosio::http_plugin)
    # https-private-key-file =

    ###########################################################################
    # State History (For 1.8.0-rc1+ add to start params --disable-replay-opts )
    # plugin = eosio::state_history_plugin
    # state-history-dir = state-history
    # trace-history = true
    # chain-state-history = true
    # state-history-endpoint = 0.0.0.0:8080
    # debug mode info (https://github.com/EOSIO/eos/pull/7298)
    # #trace-history-debug-mode
    ############################################################################

    allowed-connection = any
    
    # allowed-connection = specified
    # peer-private-key = ["!!NEW_KEY_PUB!!","!!NEW_KEY_PRIV!!"] #create new key for private peers
    # peer-key = "!![PUBKEY]!!" 
   
   
    max-clients = 150
    connection-cleanup-period = 30
    sync-fetch-span = 2000
    enable-stale-production = false

    
    pause-on-startup = false
    max-irreversible-block-age = -1
    txn-reference-block-lag = 0
    


    # peer-key =
    # peer-private-key =

    plugin = eosio::producer_plugin
    #plugin = eosio::producer_api_plugin
    plugin = eosio::chain_plugin
    plugin = eosio::chain_api_plugin

#p2p-peer-address = 
#p2p-peer-address = proton.cryptolions.io:9876
#p2p-peer-address = proton.eu.eosamsterdam.net:9103
#p2p-peer-address = proton.lynxsweden.org:9576
#p2p-peer-address = p2p-proton.eosarabia.net:9876
#p2p-peer-address = peer1.proton.pink.gg:48011
#p2p-peer-address = proton-p2p.eos.barcelona:9850
#p2p-peer-address = proton.lynxsweden.org:9576
#p2p-peer-address = proton.eosdublin.io:9877
#p2p-peer-address = peer.proton.alohaeos.com:9876
#p2p-peer-address = peer1-proton.eosphere.io:9876
#p2p-peer-address = proton.eosvenezuela.io:9777
#p2p-peer-address = p2p.proton.eostribe.io:19880
#p2p-peer-address = proton.greymass.com:19875
#p2p-peer-address = proton.eosio.cr:9879
p2p-peer-address = proton.cryptolions.io:9876
p2p-peer-address = proton.cryptolions.io:9876
p2p-peer-address = proton.eosdublin.io:9877

I also uncommented the producer plugin line. Configure your systems firewall to allow ssh traffic and tcp traffic on ports 8888 and 9876:

sudo ufw allow ssh
sudo ufw allow tcp/8888
sudo ufw allow tcp/9876
sudo ufw enable

You should also take additional steps to harden the security of your server before placing the private keys on here. Be sure the change the permissions of the config.ini to read only by user:

chmod 600 config.ini

Obviously you ought to be running all of this under a seperate unix user without superuser permissions.

After configuring the .ini file, you need to start the node and allow it to synchronize. I tried to restore from the latest snapshot to save time, but that gave me a strange error about "snapshot can only used to initialize an empty database" which is odd because whatever database it is refering to ought to be empty as this a brand new install.

Wait for your node to synchronize. You can check the status like:

curl http://localhost:8888/v1/chain/get_info | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   796  100   796    0     0   777k      0 --:--:-- --:--:-- --:--:--  777k
{
  "server_version": "de78b49b",
  "chain_id": "384da888112027f0321850a169f737c33e53b388aad48b5adace4bab97f437e0",
  "head_block_num": 119682260,
  "last_irreversible_block_num": 119681926,
  "last_irreversible_block_id": "07223386041237476f36dd168e92c02dbf10828308ad317bed4642a8d96a4e59",
  "head_block_id": "072234d42901571c1a8bb4ce2999b357d288ab1a7d434bb35f4b3a0f40683833",
  "head_block_time": "2022-03-16T22:54:22.500",
  "head_block_producer": "eosbarcelona",
  "virtual_block_cpu_limit": 200000000,
  "virtual_block_net_limit": 1048576000,
  "block_cpu_limit": 199900,
  "block_net_limit": 1048576,
  "server_version_string": "v2.0.5",
  "fork_db_head_block_num": 119682260,
  "fork_db_head_block_id": "072234d42901571c1a8bb4ce2999b357d288ab1a7d434bb35f4b3a0f40683833",
  "server_full_version_string": "v2.0.5-de78b49b5765c88f4e005046d1489c3905985b94"
}

To know the synchronization progess, note the head block time. Finally, you can run this command to register as a block producer and you will offially be live:

eos@ns106991:/opt/ProtonMainNet/protonNode$ ./cleos.sh system regproducer luminaryvisn PUB_K1_83tLDZorE8eQDhKrZdUG21DG1jctGhEJDEKpsfKJ6kjbRQLnCT "luminaryvisn.com" 0
executed transaction: 1cfa23e3bc5c33aca5a546c9f89723b41ec76389043ce120e985c0c229906651  160 bytes  399 us
#         eosio <= eosio::regproducer           {"producer":"luminaryvisn","producer_key":"EOS83tLDZorE8eQDhKrZdUG21DG1jctGhEJDEKpsfKJ6kjbQHtCjg","u...
warning: transaction executed locally, but may not be confirmed by the network yet         ] 

The next thing on our list is configuring the bp.json file which tells the network where to find your company logo and other contact details. There is a generator which you can use to create it. This needs to be at the root of the domain that you registered. See example:  https://luminaryvisn.com/bp.json

You should see your logo and contact details show up on the network monitor if this is configured correctly.

Remember to put your systems kernel in performance mode as well:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance

That is all for now. Stay tuned for the next series which will go over configuring a history node, claiming rewards, and anything else that comes up.

In this article I will detail the process of configuring a node on the proton test network. Although there are several guilds on the internet available, I did not find one that was very comprehensive, and spent much time Googling my way through issues. So here I will document the process as comprehensively as I can, taking care to note the things that I wish that I knew ahead of time and had to figure out for myself.

Server Specifications

The specifications for running on the test network are not as intense as the main network, however my client and I found that our execution time was too low when we tried starting with a cheaper server. Our first server was reasonably fast - quad core, 8 gigs of ram, but it was not cutting it. Thus we ended up upgrading our server (and there will be a separate post about that process soon).

The specs we ended up settling on are as follows:

• 32 gigs of ram
• Intel 8 core processor at 4.2 ghz
• 500 GB SSD
• I added an 8 gig swap file
• one gigabit line

We got this box from OVH, it was only $120 per month if I recall correctly.

Installation

At the time of this writing, you want to use an Ubuntu 18 box for compatibility with the software. While I am sure you could get away with running this on any Linux distribution that you'd like, for the sake of simplicity I recommend Ubuntu 18 (LTS release).

After you deploy your server, you should harden its security. Of course this is more important on the main network than the test network, but you may as well get in this habit now. Turn off SSH password authentication and set up a firewall, at least.

The installation instructions can be found here:

GitHub - ProtonProtocol/proton-testnet.start

Contribute to ProtonProtocol/proton-testnet.start development by creating an account on GitHub.

GitHubProtonProtocol

For the most part, the installation instructions are reasonably straightforward. However, I do have a few suggestions to make this go easier.

The Process

First, do not bother compiling the software yourself. It takes forever and a half.

Let's begin. SSH to your box as root, and create a new user called "proton" or something. Add to sudo group, grab the latest compiled binaries, and install:

useradd -d /opt/ProtonTestnet proton
usermod -a -G sudo proton
passwd proton
sudo su proton
mkdir /opt/bin
mkdir /opt/bin/v2.1.0
cp /usr/opt/eosio/v2.1.0/bin/nodeos /opt/bin/v2.1.0/
cp /usr/opt/eosio/v2.1.0/bin/cleos /opt/bin/v2.1.0/
cp /usr/opt/eosio/v2.1.0/bin/keosd /opt/bin/v2.1.0/
ln -sf /opt/bin/v2.1.0/ /opt/bin/bin

Now that the software is installed, we need to configure our node.

mkdir /opt/ProtonTestnet
cd /opt/ProtonTestnet
git clone https://github.com/ProtonProtocol/proton-testnet.start.git ./

We need to create an account. To do that, you need to go to the proton testnet monitor and follow these instructions:

Click “Create Keypair” button located at the top left of the page, copy and save both public and private key. also you can create key pair using cleos command:

./cleos.sh create key

Click “Create Account” at the top left of the page, enter an account name, submit your previously saved public key in both Owner and Active Public Key field, complete the captcha, and hit create.

Edit the config.ini file:

server address: p2p-server-address = ENRT_YOUR_NODE_EXTERNAL_IP_ADDRESS:9876

replace p2p-peer-address list with fresh generated on monitor site: https://monitor.testnet.protonchain.com/#p2p

Check chain-state-db-size-mb value in config, it should be not bigger than you have RAM:
chain-state-db-size-mb = 16384

your producer name: producer-name = YOUR_BP_NAME
signature-provider = YOUR_PUB_KEY_HERE=KEY:YOUR_PRIV_KEY_HERE

comment out eos-vm-oc-enable and eos-vm-oc-compile-threads (EOSVM OC is not to be used on a block signing node)

After you have your config.ini setup correctly, you need to create a wallet. The process is pretty straightforward:

cd /opt/ProtonTestnet/protonNode
./cleos.sh wallet create --file pass.txt
./cleos.sh wallet import
./cleos.sh wallet unlock
cd ../Wallet
./start_wallet.sh

Now, you can register as producer ... but actually, before you can do that, you need to request approval to register as a producer. Please see the medium article on how to do this here. Keep in mind that this process does not actually seem to broadcast the transaction required to do this – rather it generates the command that you can run with cleos to do so.

When you get the command, you broadcast it like this:

./cleos.sh -u https://protontestnet.greymass.com push transaction '{
  "delay_sec": 0,
  "max_cpu_usage_ms": 0,
  "actions": [
    {
      "account": "eosio.msig",
      "name": "propose",
      "data": {
        "proposer": "luminaryvisn",
        "proposal_name": "thanks",
        "requested": [
          {
            "actor": "luminaryvisn",
            "permission": "active"
          }
        ],
        "trx": {
          "max_net_usage_words": 0,
          "max_cpu_usage_ms": 0,
          "delay_sec": 0,
          "context_free_actions": [],
          "actions": [
            {
              "account": "eosio.proton",
              "name": "reqperm",
              "authorization": [
                {
                  "actor": "luminaryvisn",
                  "permission": "active"
                }
              ],
              "data": "30B1DBFE9AE9A48E0772656770726F64"
            }
          ],
          "transaction_extensions": [],
          "expiration": "2022-03-15T17:57:09.000",
          "ref_block_num": 64677,
          "ref_block_prefix": 1145945814
        }
      },
      "authorization": [
        {
          "actor": "luminaryvisn",
          "permission": "owner"
        }
      ]
    }
  ]
}'

```

Then you need to wait for your request to be approved. Finally afterwards you can actually register ...

./cleos.sh system regproducer YOU_ACCOUNT PUBKEY "URL" 0

Finally, our node needs to be synchronized. Just restore from a snapshot and save yourself a ton of time. You should do this in a tmux session:

sudo apt -y install zstd
cd /opt/ProtonTestnet/protonNode/snapshots/
wget https://backup.cryptolions.io/ProtonTestNet/snapshots/latest-snapshot.bin.zst
unzstd latest-snapshot.bin.zst
cd /opt/ProtonTestnet/protonNode
./start.sh --snapshot /opt/ProtonTestnet/protonNode/snapshots/latest-snapshot.bin

Now you are in business. You need to demonstrate that you can run successfully for at least two weeks – UPDATE: You are also required to continuously run your testnet node even after you are approved for the main network!

Make sure you are active in the telegram channel, and do not be afraid to ask for votes – at some point you will want to request that your node be placed in the "top 21" so that you may determine whether it is working correctly or not.

You can check your execution time and other stats on various testnet monitors such as https://api.monitor.testnet.protonchain.com. Keep in mind that your execution time needs to be below 35 milliseconds.

Make sure that you set up your bp.json file so that your avatar and other information is shown on the monitors. There is a handy generator available that you can use. Place it at the root of your entity's domain. For example, ours is here:

https://luminaryvisn.com/bp.json

That's pretty much it! With a little luck, eventually you will be approved to go actually produce blocks on the main network, as we just were!

Final Considerations

The first thing that you should do is back up your keys! You will need them in the event that there is something wrong with your node and you need to unregister as producer. I would advise backing them up in multiple locations, both locally on a USB drive and remotely, encrypted in the cloud.

Stay tuned for my next article in this series, which details the process of configuring a node for the main network.