This is in continuation to Ethereum Ecosystem (part-1) in which we've covered Understanding Ethereum System, Ethereum System State, Code Execution and Full Node.

Gas

It is one of the key mechanism underlying the security of Ethereum system. Ethereum, being a complete programming language and an open-source blockchain, tempts untrusted parties to send 'untrusted' codes that is executed in a programing language by every single computer in the entire network may be forever. It is known in computer science that it is mathematically impossible to create an algorithm which can tell whether or not any given program can just be going to keep on running forever. This is known as 'Halting problem'. As per the definition, given a program, if you start running it, there is absolutely no way guarantee to tell it in advance that when is the program going to stop.

Concept of gas is introduced to provide security from the hackers (untrusted parties) to Ethereum. It is one of the methods to prevent attacks on the Ethereum system. The basic idea is charging the transactional fees for every transaction. Number of computational steps of the code when executed are counted, and charged accordingly. It means, heavier the code, higher the transactional fee.

How concept of gas in Ethereum provides security from halting problem?

It is implemented in Ethereum in a specific way is that every block in the Ethereum blockchain has a gas limit. Every transaction assigns itself a budget. It specifies a gas price (an amount of ether that they are willing to pay per unit of gas) and the maximum amount of gas to be consumed.

After determine the gas budget, the transaction goes to contract and the code starts executing. There are two possible outcomes.

Within limit - Code starts executing, finishes its computational steps and stops. In this case, only for the computational steps that it uses, everything is fine.
Over the limit - Code starts executing, it goes through a number of computational steps and gas runs out. In this case, execution is halted there itself, all the execution get reverted and its declared as a failed transaction. But the transaction still has to pay for the gas. This is done to avoid weird attacks on contract.

This concepts helps determine that it will be able to execute within some amount of time irrespective of the weird code of your transaction. Gas is the deterministic method to get the computational resource control. For every transaction, an account not only has to pay for the computational steps but also for the operations that takes up storage (the transactional fees). So, heavier the code higher the transactional fee. Gas is designed to encourage the usage of Ethereum system responsibly.

Ethereum Miner sees these transactions and select the transaction including the highest gas price and include them in its block. They try to target particular uncle rate. Concept of uncle says that more the blockchain gets clogged up, it results in more blocks propagation, more blocks get lost and don't end up being in the main chain. It can actually be calculated that how much of this been happening and miners can target a particular amount to which its happening. If it’s more than 20% waste from blocks falling of the network, then the gas limit should go down.

Gas Limit

Allowed gas limit is 4.7 million gas per block. It isn’t just charged for the computational steps but also counted for
writing to the state
reading to the state
bytes in transactions
Voting mechanism (can upvote / downvote gas limit by 0.0976% every block)
Default strategy
4712388 minimum (it keeps changing depending on voting)
Target 150% of long-term EMA of gas usage

Transactions

Transactions basically contains seven sets of values.

Nonce (anti-replay-attack) - Every transaction has to have a unique incrementing nonce. The first transaction has to have nonce = 1, second nonce = 2, third nonce = 3 and so forth. The reason this is done so is to prevent replay attacks.
Gas price (amount of ether per unit gas)
Start gas (maximum gas consumable)
To (destination address)
Value (amount of ETH to send)
Data (readable by contract code) – It is just a field of data. The transaction sender can fill the data with whatever they want, it’s an array of bytes, no limits on length. But if more data in transaction is included, it increases the transactional fee for it. You need to pay extra 68 gas for every byte of the transaction data that is included.
v, r, s (ECOSA signature value)- 'r' and 's' are related to cryptography signature. 'v' is the extra flag needed to do public key recovery. So, instead of checking signature against the public key, it's getting public key from the signature.

Receipts

Receipts are objects that get hashed into the Ethereum blockchain. Every transaction has a corresponding receipt. These receipts have few pieces of data-

Intermediate state root – It’s the hash that represent the entire state after the transaction gets executed.
Cumulative gas used – Total amount of gas used in that particular block including that transaction
Logs – These are special feature of Ethereum. Its a different kind of storage.
Logs are append only and not readable by contracts - If there is a transaction in a particular block and it create some logs, those logs get hashed in that particular block but they can't be accessed by contracts and they appear just in that block, they are not in any kind of persistent state. So, no one can either store or print the logs.
Logs are 10 times cheaper than storage and gas consumption.
Logs have a data field and up to four “topics” (32 bytes); plus data.
Purpose of logs are to allow efficient light clients access to event records (eg. Domain name changed, transactions occurred, etc).
Bloom filter protocol to allow easier searching by topic.

Ethereum Virtual Machine

Stack - 32 to1024 bytes
Memory - Infinitely extendable. But, more expanded, more gas to be paid.
Storage - Permanent contract storage. Read / Write to it.
Environment variables – ex. EVM can access the block number, the time, the mining difficulty, the previous block hash and other data.
Logs – Virtual Machine can create log.
Sub- calling – There is an opcode by which the virtual machine can itself call other contracts.

High-Level Languages

If you are a contract writer, you are not going to write in virtual machine directly. You are going to write it in HLL eg., Serpent, Solidity, LLL etc. you write your code in these languages and it compile it downs into Ethereum code. The Ethereum Virtual Machine code is completely compiled fast execute blockchain.

The ABI

Every time a function of a contract is called in Ethereum; it actually gets complied into a transaction which is encoded with an algorithm called the ABI.

Function calls are compiled into transaction data
First 4 bytes: function id
Next 32 bytes: first argument
Next 32 bytes: second argument

RLP

Everything in Ethereum rely on one Serialization algorithm called “Recursive Length Prefix” (RLP) encoding. Basically, this algorithm is used for blocks, transactions, network protocol etc. in Ethereum system.

A cool new mining algorithm (Ethash)

Full node mining strategy – Rebuild the full DAG every 30000 blocks, quickly compute mixhashes.
Light node verification strategy – Rebuild only the cache every 30000 blocks, more slowly compute mixhash once by computing 256 DAG nodes on the fly less efficient, but we need to do this only once.
Goal: CPU friendly, ASIC hard
Uses memory hardness to achieve this goal. It's the bottleneck of Ethereum system.
Uses a multi-level DAG construction to achieve this with light client friendliness.

ethecosys1

Fast block time

In general, Ethereum is faster in terms of block creation. Bitcoin has a 10 minutes’ block time where as Ethereum has 17 seconds’ block time. It is not reduced further because the problem with fast blocktimes, stale rates due to network latency.

If the blocktime is extremely long like 10 minutes, you can think of network latency have been negligent by comparison. You can think of it's being instant. But once you start pushing blocks time down, the problem of duplicate block arises. eg. someone created ‘Block (N+1)’; this block takes time to propagate through network. Meanwhile, someone else might also create ‘Block (N+1)’ before hearing about this block before. So, now we have two blocks, both on top of ‘Block N’ and both are competing. This is called a 'Fork'. The problem here is that one of the block should eventually win and the one which doesn't win gets discarded. The person who mined it doesn’t get reward.

This leads to centralization risks

Last block zero stale rate effect – Creator of last block is saved from this risk.
Network connectivity economics of scale – More powerful miner will get higher connectivity. Large miners end up being more effective then smaller miners.

Uncles

Solution to centralization risk problem is 'Uncles'. It says that allow stale blocks (the block which lost due to creation of fork) to be re-included and receive most of the reward. It cuts the centralization incentives by 85%. It allows the Ethereum blockchain to continue to be relatively safe under somewhat harsher circumstances both in terms of fast transaction time and high transactional load.

If you like the article, please follow us at

twitter @ether_world

facebook EtherWorld