Two-Node Setup of a Private Ethereum on AWS with Contract Deployment (Part 1)
From time to time I plan to emulate an Ethereum environment. The idea behind is to observe how Ethereum nodes work to each other, and how different accounts interact in transaction and contract deployment. For testing, most contract deployment example nowadays is mainly on testrpc or testnet, but how the contract works among nodes is still new to me.
I deploy this two-node setup on AWS. As I do not use any special features on AWS, it should be applicable to another cloud environment.
My setup is inspired by the work from JJ’s World (link), and after testing this for several times with modification, I document the whole process I have done, and share some experience here about the whole process.
I also use the Voting contract developed by Mahesh Murthy (link). This is a simple contract that best illustrates how a contract works in the chain.
This by no means is a detailed step-by-step guide. I omit certain steps and make reference to some work done by others. For example, the detailed operation of AWS EC2, including launching a new instance with a setup like access key, security group, etc. can be found here (link).
There are two parts in this setup.
Part 1: Create a 2-node ethereum network with private blockchain, and accounts on the two nodes can send ether to each other.
Part 2: Deploy a contract from one node, and both accounts can access and execute functions on this contract.
Step 1: Launch two EC2 instances.
Use t2.medium (2 vCPU, 4 GB RAM) with default 8G SSD. Pick Ubuntu OS. Make sure that the two nodes are with the same security group, which allows TCP 30303 (or 30000-30999 as I may use more ports on this range). Port 30303 by default is for peering among nodes.
Step 2: Install geth client on Node 1
Access to Node 1 with ssh and proper key. Follow the recommended process (link) for geth installation. Install from PPA is good enough.
and verify it with $ which geth and you will see that geth is installed properly.
Step 3: Prepare the Genesis.json
This same Genesis.json is applied to both nodes, as it is to ensure both nodes having the same genesis block. Here is the Genesis.json I used, which is adopted from here (link). I take out the initial allocation as I don’t need to modify the address on this file in each new setup. Each account will gain some ethers once it starts mining.
Keep this file somewhere and later scp to the nodes, or just copy and paste with an editor on both nodes.
Step 4: Init the geth with Genesis.json
Step 5: Launch geth now
It is good practice to have two screens in parallel (or a split terminal). One screen is the console while another shows the log. Open a new terminal and ssh to Node 1, and keep reading the log.
Step 6: Create an Account on Node 1
Now we have an account on this node (always check it with > eth.accounts or > eth.coinbase). And currently, there is no ether in the account balance as we have not allocated any in Genesis.json.
Step 7: Start Mining
We can begin mining process.
- From the log terminal, we will see “Generating DAG in progress” and after an epoch, a block is being mined.
- Once a block is mined, 5 ethers are added to the account balance. This is a good indicator whether mining is successful or not.
- If we keep mining, the amount of account balance keeps increasing as more new blocks are mined.
Feel free to keep mining, or we can turn it off by > miner.stop().
Now Node 1 is ready. Let’s work on Node 2.
Step 8: Repeat Step 2-6 on Node 2
Make sure the same Genesis.json is used when init the blockchain on Node 2.
Do not start mining as we want Node 2 on the same blockchain as Node 1 (through Peering).
Step 9: Peering
Now we begin peering the two nodes. There are several ways to peer. Here I am using “admin addPeer” to do the peering: in Node 2, add Node 1 enode information for peering.
First, check both nodes that there is no peering.
Obtain enode information from Node 1
We will get something like this:
Add this information to Node 2. Change the [::] with the Private Address of Node 1.
After that check, both nodes and they are peering each other.
The left-hand-side is Node 1 and right-hand-side is Node 2. Note that after > addPeer() on Node 2, two nodes are peered. We do not need to do the same thing on Node 1.
Also, from the log, we see that, after peering, we see “Block synchronization started” and “Imported new chain segment” on Node 2 log (bottom-right terminal).
Step 10: Send Ethers Between Accounts
As both nodes are in the same ethereum blockchain, we will send some ethers between the accounts. In this example, 10 ethers are sent from the account of Node 1 to account of Node 2. This is one of the best ways to verify if the setup is successful.
Note that we see “pending transaction” as this transaction is not mined yet. Once we start mining in Node 1, the transaction is done and account balance on Node 2 is now 10 ethers.
And we see 45 ethers in Node 1 (not the expected 20-10=10 ethers). It is because Node 1 keeps receiving mining reward (5 ethers per block). The balance will keep increasing until we stop mining.
Now we complete the first part: we build a two-node private ethereum blockchain on AWS. You can go directly to next part to deploy contract, r stop the process and EC2 instance for future use. In case peering is changed for any reasons, you can re-peering the nodes with Step 9 above.