A Byte of Blockchain - Week 38 Ethereum Transaction Basics..Cont'd

Recap

Last week we introduced Ethereum as

1. Decentralized
2. Open source
3. Run by consensus protocols &
4. Implemented by nodes scattered across the globe.

Then we delved into Bitcoin blockchain transactions which are restricted in a way that a transaction data structure mainly contains :

1. The transaction value
2. The transaction reference
3. The script to lock the UTXO (for transaction outputs) &
4. Script to unlock the UTXO (for transaction inputs)

So the only transaction that is efficiently possible in a Bitcoin blockchain is funds transfer.

      Debit A for 500 BTC

                  Credit B for 500 BTC

The scripting language of Bitcoin blockchain is intentionally set in a simple manner to facilitate this transfer of funds efficiently. Any other complications like looping conditions will only cause issues like infinite loops which in turn could result in resource wastage & Denial of Service attacks (DOS)

Let us revisit our visualization from last week as below :

We then incorporated an additional condition for transferring funds from A to B & asked a few questions :

1. How will this "additional condition" be accommodated in the transaction ?
2. Where will this condition be incorporated in the transaction data structure ?
3. Who will validate whether this condition has actually been satisfied ?
4. What will be the trigger to activate this condition in the system?

Ethereum Transaction Data Structure

Among other things (which we will get into shortly!), Ethereum transaction messages include :

1. Sender Address - who initiated the transfer
2. Recipient Address - the beneficiary of the transfer
3. Transaction Value - Amount sent to recipient
4. Data Field

Now, 1 to 3 are pretty straightforward, it is the fourth field which sets Ethereum apart from Bitcoin Blockchain. What is so special about this field and why does it matter?

Let's dive in....

Photo by Edneil Jocusol: pexels.com/photo/boy-in-a-pool-2326887

A Simple Transaction

Let us assume for simplicity sake,

1. A will transfer 500 ETH to B (Assume it is TRANSACTION A) only if B transfers 100 ETH to C (Assume it is TRANSACTION B) &
2. TRANSACTION A is due on 1st January and TRANSACTION B is due one day before i.e., 31st December &
3. TRANSACTION A will go through only if TRANSACTION B has gone through

How will TRANSACTION A know whether TRANSACTION B has gone through or not?

Let us remind ourselves of the two critical fields above :

1. Transaction Value
2. Data

We will get into smart contracts at a later stage but for now let us just imagine there is a code in Ethereum Blockchain to transfer 100 ETH from B to C as below: (We will discuss this in pseudo-code which is like code logic written in normal English & not in programming syntax)

Pseudo-code to Transfer 100 ETH from B to C

# Transfer 100 ETH from B to C 

Get Address of B
Get Address of C
Check if B has balance > 100 ETH
if B has balance > 100 ETH:
          transfer 100 ETH to C        
          return TRUE       
else:
          return FALSE

(The else condition is triggered when the balance is less than 100 ETH)

So, the output of the above code is TRUE or FALSE.

1. TRUE if B has transferred 100 ETH to C (In other words, "Condition satisfied")
2. FALSE if B has NOT transferred 100 ETH to C (In other words, "Condition NOT satisfied")

We can visualize the above code as below :

The output from this code (TRUE or FALSE) gets "called" into TRANSACTION A data field where the transfer of 500 ETH from A to B will happen depending on the output from TRANSACTION B. (This, in programming parlance is a function call which we will discuss in detail at a later stage)

1. If the output is TRUE, the data field in Transaction A gets populated with "TRUE" & 500 ETH moves from A to B.

2. If the output is FALSE, the data field in Transaction A gets populated with "FALSE" & no funds transfer happens between A & B.

The below visualizations make it clear :

With this understanding of the importance of the "DATA" field in an Ethereum transaction, let us move to the concepts that we introduced in Week 36 which are

1. Virtual Machine
2. State Transition
3. Turing Completeness