The Mystery Behind Ethereum’s Shine
Technical comparison between Bitcoin and Ethereum
Introduction: Why & How ?
In late 2017 when I started to learn about blockchain, I have noticed that there is a massive attention in Ethereum. I always hear that bitcoin is the first blockchain’s generation while Ethereum is the second blockchain’s generation, at that time I read a lot to understand the difference between bitcoin and Ethereum . I realized “ Why”; Bitcoin is a cryptocurrency that provides a decentralized payment system (using limited scripting language) but Ethereum is different, Ethereum is not just a cryptocurrency , Ethereum is a globally decentralized computing infrastructure that execute smart contracts ; computer code (written in rich programming language) that control digital values, where any developer can build his dapp on top of it. I was interested in developing dapps so I didn’t give much time for the yellow paper to understand “How”.
When I started to read the Ethereum yellow paper during Devcon v scholarship , I not only realized the reason, but also felt impressed with these great minds that brought these amazing ideas to life.
Let’s dig into the main important parts including :
- Data structure
- Block structure
- Transactions
- Gas in Ethereum & fees in Bitcoin
- State & Account types
Data structure
Bitcoin uses Merkel tree , binary trees containing cryptographic hashes, while Ethereum uses modified Merkel Patricia Tree. watch this video if you want to know more
please note that Medium doesn’t support subscript format , if you want to read the same article with some symbols mentioned in the yellow paper , check this document
BLOCK
Let’s see the Ethereum block structure
The Block Consists of :
Block Header :
Note that unlike bitcoin Ethereum doesn’t have one Merkel tree but 4 tries / trees (State Trie, Storage Trie, Transaction Trie & Receipts Trie) . Block header in ethereum consists of :
- parentHash : hash of the parent block’s header
- ommersHash : hash of the om-mers list portion of this block
- beneficiary : Miner Ethereum account where the fees of mining transferred.
- stateRoot : hash of the root node of the state trie, after a block and its transactions are finalized
- transactionsRoot : hash of the root node of the trie structure populated with each transaction from a Block’s transaction list
- receiptsRoot : hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list.Each transaction receipt, denoted BR[i] for the ith transaction, is placed in an index-keyed trie and the root recorded in the header. This is useful to form a zero-knowledge proof, or index and search. transaction receipt,R, is a tuple of four items comprising:
1. Ru : the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened
2. Rl :the set of logs created through execution of the transaction.
3. Rb :the Bloom filter composed from information in those logs.
4.The status code of the transaction. - logsBloom : where ethereum events stored , it’s an indexable filter of (logger address and log topics)
- difficulty : difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp.
- number : the number of the ancestor blocks , genesis block has number 0;
- gasLimit : quantity equal to the current maximum gas expenditure per block.
- gasUsed : quantity equal to the total gas used in transactions in this block
- timestamp : Unix’s time at this block’s inception.
- extraData : Arbitrary byte array where miner can add any data
- mixHash : hash that verifies that the block has been minded properly.
- nonce : hash that verifies that the block has been minded properly . (same as mixHash)
Body : body contains
- a list of ommer block headers : a list of ommer (uncle) block headers.
- Transaction Series : list of transactions included in this block
Holistic Validity: We can assert a block’s validity if and only if it satisfies several conditions: it must be internally consistent with the ommer and transaction block hashes and the given transactions
The process of finalizing a block involves four stages:
- Validate (or, if mining, determine) ommers:
- A block must specify a parent, and it must specify 0 or more uncles
- An uncle included in block B must have the following properties:
- It must be a direct child of the k-th generation ancestor of B, where 2 <= k <= 7.
- It cannot be an ancestor of B
- An uncle must be a valid block header, but does not need to be a previously verified or even valid block
- An uncle must be different from all uncles included in previous blocks and all other uncles included in the same block (non-double-inclusion)
- validate (or, if mining, determine) transactions: the total gas used in the block, must be equal to the accumulated gas used according to the final transaction
- apply rewards : by raising the account balance of the beneficiary and ommers if exist . Ommer blocks are useful to help reward miners for when duplicate block solutions are found. Ommer block receive a reward .stale block receives 87.5% of its base reward, and the nephew that includes the stale block receives the remaining 12.5%. Transaction fees, however, are not awarded to uncles
- verify (or, if mining, compute a valid) state and block nonce. By checking the final state ( after applying the reward & checking the transaction ) against stateRoot in block header .
While bitcoin’s block structure looks like
The Block Consists of :
Block Header : consists of :
- timestamp : Unix’s time at this block’s inception.
- nonce : A counter used for the Proof-of-Work algorithm .
- Version : A version number to track software/protocol upgrades
- Previous : Block Hash A reference to the hash of the previous (parent) block in the chain
- Merkel Root :A hash of the root of the merkel tree of this block’s transactions
- Difficulty: It is the difficulty necessary to mine the block. It adjusts during mining if solving it takes a long time.
Body : body contains
- Transaction Series : list of transactions included in this block.
Transactions
Ethereum Transactions T :
There are two types of transactions: message calls and contract creations. Each transaction applies the execution changes to the machine state μ (a temporary state which consists of all the required changes in computation that must be made before a block is finalized and added to the world state). Consists of the following fields:
- nonce : the Number of transactions sent by the sender
- gasPrice : The number of Wei to pay the network for unit of gas.
- gasLimit :The maximum amount of gas to be used in while executing a transaction
- to : Recipient of the message call.
- value : Amount of Wei transferred to the message recipient.
- v, r, s: Values related to signature.
- Init : (only in contract creation transactions ) Unlimited size byte array for EVM code
- data : An unlimited size byte array specifying the input data of the message call
Bitcoin Transactions:
- Header
- Bitcoin protocol version:
- Number of inputs:
- Number of output
- Block lock time (used if you don’t want to include this transaction in a block immediately )
- One or more input (UTXO)
* Hash pointer to a previous transaction ( this input was an output in the previous transaction)
* Index of the referenced output in the previous transaction.
* Unlocking script (called ‘scriptSig’) with an indication of its length to prove the ownership of this UTXO. - On or more output (UTXO)
* The amount of bitcoins to be transferred from the sender to the receiver.
* Locking script (called ‘scriptPubKey’) with an indication of its length. ‘scriptPubKey’ is a conditional pubkey script . Anyone who can satisfy the conditions of that pubkey script can spend up to the amount of satoshis paid to it.
Gas in Ethereum & fees in bitcoin
Ethereum Gas
Since Ethereum is Turing complete system , to avoid abuse all programmable computation in Ethereum is subject to fees. Computational means cost , the more compute power you need the more cost you have to pay.Ether used to purchase gas that is not refunded is delivered to the beneficiary address. The transaction is considered invalid if the account balance cannot support such a purchase.Gas does not exist outside of the execution of a transaction.
Every transaction has a specific amount of gas associated with i.t gasLimit & gasPrice are specified in the transaction
- gasLimit. Maximum amount of gas the sender willing to spend for executing that transaction. This help to auto abort if the transaction entered an infinite loop. If there is a remaining gas after executing the transaction , this gas is refunded to the transactor but if the transaction failed for any reason , no gas will be refunded.
- gasPrice, gasPrice is the answer of this question “How much would you like to pay for a unit of gas ?” Transactors are free to specify any gasPrice that they wish, however miners are free to ignore transactions as they choose.
Bitcoin fee:
is a small payment collected by miner , it’s not required in order for mining your transaction but to incentivize the miner to includes the transaction in the ledger as miners are free to ignore the transaction , this fee is collected from the difference between input output .
State & Account types
Bitcoin:
Bitcoin address is an ECDSA public key its balance is not maintained by bitcoin blockchain. If you are wondering how you can see you bitcoin balance , personal wallet app is scan the blockchain database and calculate the total UTXO related to a specific address .
Ethereum:
Ethereum has a world state σ which is the mapping between address and account states.
- There are types of account :
- Externally Owned Account (EOA) controlled by private key
- Contract Account control by contract .
- Account State σ [a] :
are stored outside the blockchain , in a modified Merkle Patricia Tree watch this video if you want to know more about MPT in a database backend named state database. Consists of four fields:
- nonce : number of transactions sent from this address including contract-creations.
- balance : number of Wei owned by this address.
- storageRoot : hash of the root node of a Merkel Patricia tree that encodes the storage contents of the account
- codeHash : (only for contract account ) hash of EVM (Ethereum Virtual machine) code stored in the state database . It’s immutable unlike all other fields .
Interested to read the yellow paper ?!
I’m sure you are interested in reading the yellow paper to know more and more , remember the point mentioned here are just the main differences in my opinion, but if you intend to take this journey , let me guide you as it’s not an easy task :D,
I remember when I told a friend of mine that I’m going to read & write about it , he told me literally :
“ Oh my gosh that sounds terrible :D . But very educational but it’s still awful”
He was right, my intention was to write a summary like I did with bitcoin white paper , but it’s too hard for my first time reading experience . I have to reread it more than 4 times :D at intervals to do so.
After my first time reading I can indicate that I only could grasp 50% -60% because of the encountered difficulties during reading and understanding the mathematical part “ it was awful as my friend told me :D “, but it helps me a lot to better understand Ethereum and some bugs that I’ve encountered before while developing dapps on top of Ethereum, so I’m satisfied with the result.
Here’s some important links that helped me :
- This is the best article I’ve ever read that explain the yellow paper.
- Special thanks to my colleague in devcon scholar program @shaqueilla.seale , she sent me this helpful Ethereum Yellow Paper Walkthrough series [ unfortunately they aren’t completed ]
- How data is stored in ethereum ethereum
- For me the most difficult parts in yellow paper are the
References:
Disclaimer: The views expressed by the author above do not necessarily represent the views of the Ethereum Foundation.
