Recap
Last week, we introduced certain concepts to understand Ethereum as below :
- Virtualization
- State Transition
- Turing completeness
Virtualization is where we can create through hypervisors multiple systems within the same physical device irrespective of the operating system. E.g., you can operate a windows system within a Macbook Pro.
State Transition denotes changes in the state of an entity or a platform due to transactions performed on the platform. E.g., changes in balances due to transactions.
Turing Completeness denotes the extent to which a programming language or device is able to solve computational problems which can be denoted in code.
Ethereum - Genesis
As i mentioned in Week 35, to understand Ethereum, we will revisit some concepts of Bitcoin Blockchain as they both use the same foundational concepts. Revisiting the concepts again will help us internalize and understand them better.
Ethereum is
- Decentralized,open source
- Run by consensus protocols
- Implemented by nodes scattered across the globe
Transactions in Ethereum are
- Initiated through wallets and smart contracts (this is in Ethereum only!!)
- Propagated to all the nodes
- Validated by all the nodes
- Added to blocks (Blocks contain transactions stored in a data structure)
Blocks in Ethereum are
- Mined by miner nodes using Proof of Work (as of now!!)
- Validated & confirmed by all the nodes
- Added to the previous block to extend the chain
What is so special about Ethereum ? What does it have that Bitcoin blockchain doesn't have?
Transaction Basics
Let us rewind back to weeks 18 to 21 where we explained transactions in Bitcoin Blockchain. There are two types of transactions :
- Transaction Inputs
- Transaction Outputs
For more details, you can refer to Weeks 18 to 21. For now, we will focus on the data fields in a Bitcoin transaction. A transaction output contains :
- The transaction value
- The locking script which needs to be unlocked to spend the UTXO (Unspent Transaction Output)
A transaction input contains
- The transaction value
- The unlocking script to spend the UTXO
- Reference to the UTXO
- Sequence no.
If you have noticed, there are only fields for
- Amount &
- References or scripts
Even in normal funds transfers that we do now, the entries contain
- Amount and
- Sender & Beneficiary account details
There could be additional fields for narration which is an optional field more for information purpose only.
The below visualization makes it more clear:
So, the primary objective of the Bitcoin blockchain is purely for transferring bitcoin only & is not optimized for anything else. Now, what do we mean by "anything else" ?
Let us assume our parties A & B in Bitcoin blockchain, the funds transfer from A to B is pretty straightforward as shown above with all the required conditions satisfied as per the underlying protocol.
Now, let us add an additional condition that A will transfer funds to B only if B satisfies certain conditions. Now,
- How will this "additional condition" be accommodated in the transaction ?
- Where will this condition be incorporated in the transaction data structure ?
- Who will validate whether this condition has actually been satisfied ?
- What will be the trigger to activate this condition in the system?
