Basic Primer: Blockchain Consensus Protocol

Basic Primer: Blockchain Consensus Protocol guide. A blockchain is a decentralized peer-to-peer system with no central authority figure. While this creates a system that is devoid of corruption from a single source, it still creates a major problem.

• How are any decisions made?
• How does anything get done?

Think of a normal centralized organization.

All the decisions are taken by the leader or a board of decision makers. This isn’t possible in a blockchain because a blockchain has no “leader”. For the blockchain to make decisions, they need to come to a consensus using “consensus mechanisms”.

So, how do these consensus mechanisms work and why did we need them? What are some of the consensus mechanisms used in cryptocurrencies?

We will answer these questions in this guide. Basic Primer: Blockchain Consensus Protocol

What are consensus mechanisms?

This is how Wikipedia defines consensus decision-making:

“Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the “favourite” of each individual. Consensus is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment.”

In simpler terms, consensus is a dynamic way of reaching agreement in a group. While voting just settles for a majority rule without any thought for the feelings and well-being of the minority, a consensus on the other hand makes sure that an agreement is reached which could benefit the entire group as a whole.

From a more idealistic point-of-view, Consensus can be used by a group of people scattered around the world to create a more equal and fair society.

A method by which consensus decision-making is achieved is called “consensus mechanism”.

So now what we have defined what a consensus is, let’s look at what the objectives of a consensus mechanism are (data taken from Wikipedia).

• Agreement Seeking: A consensus mechanism should bring about as much agreement from the group as possible.
• Collaborative: All the participants should aim to work together to achieve a result that puts the best interest of the group first.
• Cooperative: All the participants shouldn’t put their own interests first and work as a team more than individuals.
• Egalitarian: A group trying to achieve consensus should be as egalitarian as possible. What this basically means that each and every vote has equal weightage. One person’s vote can’t be more important than another’s.
• Inclusive: As many people as possible should be involved in the consensus process. It shouldn’t be like normal voting where people don’t really feel like voting because they believe that their vote won’t have any weightage in the long run.
• Participatory: The consensus mechanism should be such that everyone should actively participate in the the overall process.

Now that we have defined what consensus mechanisms are and what they should aim for, we need to think of the other elephant in the room.

Which consensus mechanisms should be used for an entity like blockchain.

Before bitcoin, there were loads of iterations of peer-to-peer decentralized currency systems which failed because they were unable to answer the biggest problem when it came to reaching a consensus. This problem is called “Byzantine Generals Problem”.

What is the Byzantine Generals Problem?

Image Courtesy: Medium

Ok so imagine that there is a group of Byzantine generals and they want to attack a city. They are facing two very distinct problems:

• The generals and their armies are very far apart so centralized authority is impossible, which makes coordinated attack very tough.
• The city has a huge army and the only way that they can win is if they all attack at once.

In order to make successful coordination the armies on the left of the castle send a messenger to the armies on the right of the castle with a message that says “ATTACK WEDNESDAY.” However, suppose the armies on the right are not prepared for the attack and say, “NO. ATTACK FRIDAY” and send back the messenger through the city back to the armies on the left.

This is where we face a problem.

A number of things can happen to the poor messenger. He could get captured, compromised, killed and replaced with another messenger by the city. This would lead to the armies getting tampered information which may result in an uncoordinated attack and defeat.

This has clear references to blockchain as well. The chain is a huge network; how can you possibly trust them? If you were sending someone 4 Ether from your wallet, how would you know for sure that someone in the network isn’t going to tamper with it and change 4 to 40 Ether?

What these generals need, is a consensus mechanism which can make sure that their army can actually attack as a unit despite all these setbacks.

We are now going to go through a list of consensus mechanisms which can solve the Byzantine Generals problem.

#1 Proof Of Work

Satoshi Nakamoto, Bitcoin’s creator, was able to bypass the problem by inventing the proof of work protocol.

First let’s see how it work in context of the Byzantine Generals problem.

Suppose the army on the left want to send a message called “ATTACK MONDAY” to the army on the right, they are going to follow certain steps.

• Firstly, they will append a “nonce” to the original text. The nonce can be any random hexadecimal value.
• After that, they hash the text appended with a nonce and see the result. Suppose, hypothetically speaking, the armies have decided to only share messages which, on hashing, gives a result which starts with 5 zeroes.

• If the hash conditions are satisfied, they will send the messenger with the hash of the message. If not, then they will keep on changing the value of the nonce randomly until they get the desired result. This action is extremely tedious and time consuming and takes a lot of computation power.

• If the messenger does get caught by the city and the message is tampered with, according to hash function properties, the hash itself will get drastically changed. If the generals on the right side, see that the hashed message is not starting with the required amount of 0s then they can simply call off the attack.

However, there is a possible loophole.

No hash function is 100% collision free. So what if the city gets the message, tampers with it and then accordingly change the nonce until they get the desired result which has the required number of 0s? This will be extremely time consuming but it is still possible. To counter this, the generals are going to use strength in numbers.

Suppose, instead of just one general on the left sending messages to one general on the right, there are 3 generals on the left who have to send a message to the ones on the right. In order to do that, they can make their own message and then hash the cumulative message and then append a nonce to the resulting hash and hash it again. This time, they want a message which starts with six 0s.

Obviously, this is going to be extremely time consuming, but this time, if the messenger does get caught by the city, the amount of time that they will take to tamper the cumulative message and then find the corresponding nonce for the hash will be infinitely more. It may even take years. So, eg. if instead of one messenger, the generals send multiple messengers, by the time the city is even halfway through the computation process they will get attacked and destroyed.

The generals on the right have it pretty easy. All they have to do is to append the message with the correct nonce that will be given to them, hash them, and see whether the hash matches or not. Hashing a string is very easy to do. That in essence is the process behind proof-of-work.

• The process behind finding the nonce for the appropriate hash target should be extremely difficult and time consuming.
• However, the process of checking the result to see if no malpractice has been committed should be very simple.

So, if we are to summarize how Proof Of Work Protocol works with the blockchain.

• The miners solve cryptographic puzzles to “mine” a block in order to add to the blockchain.
• This process requires immense amount of energy and computational usage. The puzzles have been designed in a way which makes it hard and taxing on the system.
• When a miner solves the puzzle, they present their block to the network for verification.
• Verifying whether the block belongs to the chain or not is an extremely simple process.

The proof-of-work mechanism definitely answered a lot of questions when it came to solving the Byzantine General’s Problem, but unfortunately there are some issues with proof-of-work.

• First and foremost, proof of work is an extremely inefficient process because of the sheer amount of power and energy that it eats up.
• People and organizations that can afford faster and more powerful ASICs usually have better chance of mining than the others.
• As a result of this, bitcoin isn’t as decentralized as it wants to be. Let’s check the hashrate distribution graph:Image Credit: Blockchain.info

As you can see, ~65% of the hashrate is divided among 5 mining pools alone!

• Theoretically speaking, these big mining pools can simply team up with each other and launch a 51% on the bitcoin network.

Notable Crypto That Uses This Protocol: Bitcoin

#2 Proof Of Stake

Ethereum is soon planning to move on from Proof of Work (POW) to Proof of Stake (POS).

Proof of stake will make the entire mining process virtual and replace miners with validators.

This is how the process will work:

• The validators will have to lock up some of their coins as stake.
• After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it.
• If the block gets appended, then the validators will get a reward proportionate to their bets.

As you can see, the POS protocol is a lot more resource-friendly than POW. In POW you NEED to waste a lot of resources to go along with the protocol, it is basically resource wastage for the sake of resource wastage.

The Biggest Roadblock to Proof of Stake

Ethereum developers always planned to eventually move on to proof of stake, that was always their plan. However, before they could do so, they had to address one of the biggest flaws of proof of stake(POS).

Consider this scenario for a moment:

Suppose we have a situation like the one above.  There is a main blue chain and a red chain which sort of branches from the main itself. What is there to stop a malicious miner from mining on the red blocks and force a hardfork?

In a proof-of-work(POW) system, this risk can be mitigated.

Suppose malicious miner Alice wants to mine on the red chain. Even if she dedicates all of her hash power to it, she won’t get any other miner to join her on the new chain. Everyone else will still continue to mine on the blue chain, because it is more profitable and risk-free to mine on the longer chain.

Now remember, POW is extremely expensive resource-wise.

It makes no sense for a miner to waste so much resource on a block that will be rejected by the network anyway. Hence chain splits are avoided in a proof of work system because of the amount of money that the attacker will have to waste.

However, things look a little different when you bring in POS.

If you are a validator, then you can simply put your money in both the red chain and blue chain without any fear of repercussion at all. No matter what happens, you will always win and have nothing to lose, despite how malicious your actions maybe.

This is called the “Nothing at Stake” problem.

In order to incorporate the POS consensus system, cryptocurrencies need to address this issue and Ethereum is going to do this in a very interesting way by adapting their Casper protocol.

Casper is the POS protocol that Ethereum has chosen to go with. While there has been an entire team busy creating it, Vlad Zamfir is often credited as being the “Face of Casper”.

Image Credit: Blocknomi.

So how is Casper different from other Proof of Stake protocols?

Casper has implemented a process by which they can punish all malicious elements. This is how POS under Casper would work:

• The validators stake a portion of their Ethers as stake.
• After that, they will start validating the blocks. Meaning, when they discover a block which they think can be added to the chain, they will validate it by placing a bet on it.
• If the block gets appended, then the validators will get a reward proportionate to their bets.
• However, if a validator acts in a malicious manner and tries to do a “nothing at stake”, they will immediately be reprimanded and all of their stake is going to get slashed.

As you can see, Casper is deigned to work in a trustless system and be more Byzantine Fault Tolerant.

Anyone who acts in a malicious/Byzantine manner will get immediately punished by having their stake slashed off. This is where it differs from most other POS protocols. Malicious elements have something to lose so it is impossible for there to be nothing at stake.

Flawlessly implementing Casper and Proof Of Stake will be critical if Ethereum plans to scale up.

Notable Crypto That Uses This Protocol: Ethereum (in the near future)

#3 Delegated Proof Of Stake

Now we come to an interesting form of Proof Of Stake called DPOS or Delegated Proof Of Stake. EOS is using this consensus mechanism to scale up to millions of transactions per second.

If they can actually pull it off, then they will have DPOS to thank.

Firstly, anyone who holds tokens on a blockchain integrated in the EOS software can select the block producers through a continuous approval voting system. Anyone can participate in the block producer election and they will be given an opportunity to produce blocks proportional to the total votes they receive relative to all other producers.

How does it work?

• Blocks are produced in the rounds of 21.
• At the start of every round 21 block producers are chosen. Top 20 are automatically chosen while the 21st one is chosen proportional to the number of their votes relative to the other producers.
• The producers are then shuffled around using a pseudorandom number derived from the block time. This is done to ensure that a balance connectivity to all other producers is maintained.
• To ensure that regular block production is maintained and that block time is kept to 3 seconds, producers are punished for not participating by being removed from consideration. A producer has to produce at least one block every 24 hours to be in consideration.

The DPOS system doesn’t experience a fork because instead of competing to find blocks, the producers will have to co-operate instead. In the event of a fork, the consensus switches automatically to the longest chain.

Confirming Transactions in DPOS?

A DPOS blockchain typically has 100% block producer participation. A transaction is usually confirmed within 1.5 seconds from the time of broadcast by a 99.9% certainty. In order to have absolute certainty over the validity of a transaction, a node need only to wait for 15/21 (i.e. a 2/3 majority) producers to arrive to a consensus.

So what happens in the event of a fork caused by negligence or malicious intent?

All the nodes will, by default, not switch to a fork which doesn’t include any blocks not finalized by 15/21 producers. This will stand true regardless of chain length. Each block must gain a 15/21 approval to be considered a part of the chain.

Because of the short block creation time, it is possible to warn nodes of whether they are in the major or minor chain within 9 seconds. The reason why that is so is simple. Remember, the average time elapsed between each block is 3 seconds.

If a node misses 2 consecutive blocks there is a 95% chance that they in a minority fork.

If a node misses 3 blocks, then there is a 99% chance of them being on a minority chain.

What is TAPOS?

Transaction As Proof Of Stake or TAPOS is a feature of the EOS software. Every transaction in the system is required to have the hash of the recent block header. This does the following:

• Prevent transaction replay on different chains.
• Signaling the network that a user and their stake is on a particular fork.

This prevents validators from acting maliciously on other chains.

Ok, so that sounds pretty fascinating.

You have a Proof-of-stake protocol which is fast and efficient.

Where is the catch?

For that, let’s bring in the insights of Ethereum co-founder Vitalik Buterin. According to him, the DPOS system fails the co-ordination game.

What is Co-ordination game theory?

Consider this matrix:

Now, if you see this matrix, there are two Nash Equilibria: (A,A) and (B,B), deviation from either of the state won’t benefit them. The idea of this game is how can you convince people to go from (A,A) to (B,B)? If there are a small group of people involved then that is relatively simple, you can simply coordinate via phone or emails. But, this changes when we are talking about a huge group of people.

The fundamental difference between prisoner’s dilemma and co-ordination problem is that in prisoner’s dilemma, both the players had to choose (B,B) because that was the choice that had the most payoff even though (A,A) is a morally better solution. In Co-ordination problem, it is not about the morality or the payoff, it is about the incentive for a person to go from one state to another. Why should a huge group of people change the way they do things?

A co-ordination game fails when only minority of the group change their state and the majority don’t and inversely, it is a success when majority of the group changes their state. Let’s see that with an example.

• Suppose we want to change the language to a symbol based language. Eg:
• Original statement: “Give me your number?”
• New statement: “#?”

If only you speak using this language, it will be a failure because the majority won’t understand what you are talking about and you will be shunned from conversations aka the payoff for you is very low and you have no incentive to change.

However, if the majority of your society shifts to this language and use it exclusively, you will have to change your language otherwise you will never be able to fit in. Now the incentive for you to join is high.

The DPOS system could use the co-ordination game theory to its disadvantage. There could be a scenario where a certain situation is favoured by the block producers which are not in accordance with the the rest of the nodes.

Suppose the master nodes want to transition the chain from state A to state B. It could be a very hard task for them to help the entire chain do the same transition along with them especially if the other nodes are opposed to state B.

Only time will tell if EOS can properly and flawlessly integrate DPOS or not.

Notable Crypto That Uses This Protocol: EOS

#4 Delegated Byzantine Fault Tolerance (dBFT)

Now we come to Consensus mechanism of choice for NEO.

Imagine that there is a country “Blockgeeks” and this country has a lot of citizens. Each of these citizens would elect a Delegate to represent them and to make them happy. The job of these delegates is to pass laws that will make the citizens happy, if they are not good at their job then the citizens can simply vote for another delegate the next time.

So how do the delegates pass laws?

One of the delegates is randomly chosen as a speaker.

The Speaker then look at all the demands of the citizens and creates a law. They then calculate a “Happiness Factor” of these laws to see if the number is enough to satisfy the citizen’s needs or not. They then pass that down to the delegates.

The delegates then individually check the Speaker’s calculations. If the the speaker’s number matches the Delegate’s then they give their approval, if not then they give their disapproval.

66% of the delegates need to give their approval for the law to pass. If the majority is not sealed, then a new leader is chosen and the process starts again.

So, let’s see how this applies in the blockchain.

The citizens are whoever owns NEO tokens aka ordinary nodes.

Delegates are the bookkeeping nodes. In order to be a bookkeeping node you need to satisfy a certain amount of qualifications: having special equipment, dedicated internet connections and a certain amount of GAS (1000 according to basiccrypto’s article).

• The “demands of the citizens” are basically the various transactions made by the token holders.
• The “law” is the current block that is to be added to the blockchain.
• The “happiness factor” is the hash of the current block.

Now, there are two cases where the one of the participants may act in a malicious manner. Let’s check it out:

Case #1: The Speaker is malicious

Image credit: basiccrypto Steemit article

In this case, the speaker has sent a malicious message B to two delegates and an accurate message to one.  This scenario can be easily mitigated because of the majority rule. The two delegates will see that their hash is not matching up with that of the speaker while one delegate will see that their hash matches up perfectly. However, 2 out of 3 will disapprove the proposal and consensus won’t be reached. The speaker will henceforth be removed.

Case 2: One of the delegates is malicious

Image credit: basiccrypto Steemit article

The speaker sends the correct message to all the delegates, however one of the delegates decides to act in a malicious manner and declares that their number isn’t matching up with the speaker’s.

However, since 2 out of the 3 delegates are non-malicious, they will approve the law which will then be passed since a 66% consensus has been reached.

So as can be seen, dBFT presents a very interesting form of consensus mechanism.

Notable Crypto That Uses This Protocol: NEO

These are 4 of the most common consensus mechanisms that are used in cryptocurrencies. However, there are some more that you can checkout which provide interesting alternatives. They are:

• Proof Of Activity.
• Proof Of Burn.
• Proof Of Elapsed Time.
• Proof Of Capacity.

Conclusion: Basic Primer: Blockchain Consensus Protocol

Without consensus mechanisms we wouldn’t have a Byzantine Fault Tolerant decentralized peer-to-peer system.

It is as simple as that. While, proof of work and proof of stake are definitely the more popular choices, there are newer mechanisms coming up every now and then. There is no “perfect” consensus mechanism, and chances are that there never will be, but it is interesting to see these newer cryptocurrencies coming out with their own protocols.

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).

Read Part Two Here

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.

Experience Sharing I first tried t2.micro as it is the free-tier offer. However, mining was not successful (“DAG” loop without ether reward). I next tried t2.small and mining worked. However, when I deployed contract (see Part 2), the rpc was unstable. Finally, I found t2.medium good enough for my setup. I usually STOP the instance after testing (to save money). Please note that the public IP address of the EC2 instance will be changed after you START it back. This does not have an impact on our setup here as I am using the private IP address of these instances for peering. Private IP address remains even after I STOP/START the instance. In any case if Public IP address is needed, the peering still works, but you may need to change the peering address every time.

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.

Node 1 

$ sudo apt-get install software-properties-common
$ sudo add-apt-repository -y ppa:ethereum/ethereum
$ sudo apt-get update
$ sudo apt-get install ethereum

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.

Genesis.json
{

"config": {

"chainId": 15,

"homesteadBlock": 0,

"eip155Block": 0,

"eip158Block": 0

},

"nonce": "0x0000000000000042",

"mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",

"difficulty": "0x200",

"alloc": {},

"coinbase": "0x0000000000000000000000000000000000000000",

"timestamp": "0x00",

"parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",

"gasLimit": "0xffffffff",

"alloc": {

}

}

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

Node 1 

$ geth init 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.

Node 1 $ geth --nodiscover console 2>> eth.log
another terminal $ tail -F eth.log

Experience Sharing In many examples, it is recommended to use –datadir to specify the directory for private ethereum blockchain. This is good practice when you are interacting with different chains. My example is an isolated environment. Therefore I omit this option, and my private chain is stored in the directory ~/.ethereum/.

Step 6: Create an Account on Node 1

Node 1 geth
 
> personal.newAccount()

> eth.getBalance(eth.accounts[0]) OR > web3.fromWei(eth.getBalance(eth.accounts[0]), “ether”)

Now we have an account on this node (always check it with > eth.accounts[0] 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.

1. From the log terminal, we will see “Generating DAG in progress” and after an epoch, a block is being mined.
2. Once a block is mined, 5 ethers are added to the account balance. This is a good indicator whether mining is successful or not.
3. If we keep mining, the amount of account balance keeps increasing as more new blocks are mined.

Node 1 geth 

> miner.start()
> eth.getBalance(eth.accounts[0])

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.

Node 1 > admin.peers
Node 2 > admin.peers

Obtain enode information from Node 1

Node 1 > admin.nodeInfo.enode

We will get something like this:

"enode://c667fdf1f6846af74ed14070ef9ffeee33e98ff8ab0dd43f67415868974d8205e0fb7f55f6f37e9e1ebb112adfc0b88755714c7bc83a7ac47d30f8eb53118687@[::]:30303?discport=0"

Add this information to Node 2. Change the [::] with the Private Address of Node 1.

Node 2 

> admin.addPeer("enode://c667fdf1f6846af74ed14070ef9ffeee33e98ff8ab0dd43f67415868974d8205e0fb7f55f6f37e9e1ebb112adfc0b88755714c7bc83a7ac47d30f8eb53118687@172.31.62.34:30303?discport=0")

After that check, both nodes and they are peering each other.

Node 1 > admin.peers
Node 2 > admin.peers

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).

Experience Sharing Make sure to use the same Genesis.json to initiate the blockchain. In one trial I forgot to init step and peering was unsuccessful. AWS EC2 instance comes with a private IP address and a public IP address. Both works fine in add peering, but using private IP address is more convenient as it is not changed after instance STOP/START.

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.

Node 1 

> web3.fromWei(eth.getBalance(eth.coinbase), “ether”)
> personal.unlockAccount(eth.coinbase)
> eth.sendTransaction({from: eth.coinbase, to: "0xabc65de992289401dcff3a70d4fcfe643f7d2271", value: web3.toWei(10, “ether”)})
> miner.start()

Node 2 > web3.fromWei(eth.getBalance(eth.coinbase), “ether”)

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.

Closing

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.