Introduction
Taken from the intro page, AWS Node Runner is an open source project maintained by AWS DLT and blockchain solution architects. You can read more about it here. The project contains deployment and infrastructure blueprints that allows for easy deployment of self-managed blockchain nodes and node clusters on AWS.
*In comparison, there is an AWS service called Amazon Managed Blockchain (AMB) which is a managed service and supports limited blockchain networks. There are also the 3rd party RPC API/Node Providers like Alchemy and Infura.
As Ethereum’s 10 year anniversary was nearing, i decided to embark on a small experiment to try out some node deployments with the AWS Node Runner project. This article documents my learnings and i’m hoping they will be interesting to you :)
Ethereum Single RPC node setup
Ethereum | AWS Blockchain Node Runners
CDK Deploy
Following the instructions in the link above, the first choice to be made was whether to do the single node setup or the HA setup; and of course in the interest of COST for the POC, single node will do for me. The project is based on Typescript AWS CDK and has 2 deployment layers — common components and node resources (consistent across the supported networks). i.e.
npx cdk deploy eth-common
npx cdk deploy eth-single-node --json --outputs-file single-node-deploy.json
The .env file within lib/eth is the only configuration needed:
^What i used, reducing the instance size slightly
Troubleshooting
Even after waiting for some time, RPC responses are returning 0 (hex 0x0) for everything! Whats going on?!
Without exploring the codebase, here’s what i found exploring the deployed server:
^ 2 Docker containers for Consensus client and Execution client.
Read more here on how these 2 clients form an Eth Node: https://ethereum.org/en/developers/docs/nodes-and-clients/
It turns out that Lighthouse is having a critical error loading checkpoint state fromhttps://beaconstate.info/ which was declared by default in the noderunner .env file. After some exploration, it turns out that there’s nothing wrong with the Beacon Chain checkpoint sync endpoint.
Instead, within this file /home/bcuser/docker-compose.yml, i found that the image versions used for both Geth and Lighthouse containers were not the latest!
After updating the versions, removing old containers and creating the new containers, it finally worked:
cd /home/bcuser && sudo docker compose up -d
#the docker template files for the different client combinations are found in /opt/node
#docker-compose-geth-lighthouse.yml
#docker-compose-reth-lighthouse.yml
Monitoring Dashboard
The Node Runner blueprint comes with a monitoring dashboard deployed by the CDK:
This 3 hour chart shows how it wasn’t moving for awhile and then finally syncing started. We can see the infrastructure metrics and how many blocks behind the node is.
After a few more hours, the sync is mostly done now:
Base Single RPC node setup — Snapshot Download Nightmare
Base | AWS Blockchain Node Runners
Base is an Ethereum Layer 2, incubated by Coinbase and built on the open-source Optimism OP Stack. Read more here: https://www.coinbase.com/en-gb/developer-platform/discover/protocol-guides/guide-to-base
CDK Deploy
^From Noderunner Base Blueprint page
^Similar to Ethereum and all other noderunner blueprints, we just need to configure the .env file and run the 2 layers of cdk deploy. I dropped the instance type from 2xlarge to xlarge and included the private IP of my Ethereum node from the previous section.
Troubleshooting/What goes on in the node?
Notice the IO and the network-in metrics! The node is downloading a base snapshot. During my first try my instance stopped from a cost-saver automation which i did not turn off and the process and script stopped. After locating the script and rerunning it, it restarted the download, wasting a few hours.
I then redeployed the CDK stack, this time declaring a BASE_SNAPSHOT_URL pointing to the latest version (same URL in the end) and tried to let it run its course… After checking in the next day after 17 hours, i noticed the following:
Download progress was about ~700GB
I finally decided to check the download size and it translates to a MASSIVE 4.6TB snapshot
Wget failed due to insufficient disk space. The .env default EBS volume size was 1000GB which apparently was not enough.
At this point i decided i had enough “fun” with Base; that size of EBS racks up quite a hefty sum for exploratory learning.
BNB Smart Chain (BSC) Single RPC node setup
Bsc | AWS Blockchain Node Runners
CDK Deploy
I used a much smaller instance type (4xl->xl), lesser storage (4TB->1TB) and the Fast Snapshot instead of default:
^Default .env
^Modified .env
The fast snapshot is significantly smaller than full:
Deploy CDK stacks:
npx cdk deploy bsc-common
npx cdk deploy bsc-single-node --json --outputs-file single-node-deploy.json
For BSC, i faced no troubles at all with the setup despite downsizing from default configuration. As you can see from the monitoring dashboard below, sync was completed in less than 4 hours (inclusive of fast snapshot download)
Key Takeaways
This quick foray into blockchain nodes was quite an interesting experiment for me. I learned how each blockchain has unique requirements — from Ethereum’s dual-client architecture and sync processes to Base’s massive 4.6TB snapshots and storage requirements. The software stacks are rapidly evolving, requiring constant vigilance for updates. While using managed services for building applications is great, running your own infrastructure has no substitute when the goal is to understand what goes on under the hood (although i only just scratched the surface with this) :)
*On top of Eth and Base, i also read up cursorily on a number of the Noderunner blueprints and unfortunately could not play around with Solana which is a non EVM chain and whose Agave clients generate significant outbound traffic that would blow my budget up (AWS charges for outbound internet data transfer and not inbound).
Top comments (0)