Sending transactions in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Sending transactions

Create transaction data

↓

Sign transaction with private key

↓

Broadcast transaction to network

↓

Network validates transaction

↓

Transaction added to block

↓

Transaction confirmed

This flow shows how a transaction is created, signed, sent to the network, validated, and finally confirmed.

Execution Sample

Blockchain / Solidity

tx = {"to": "0xABC123", "value": 10}
signed_tx = sign(tx, private_key)
broadcast(signed_tx)
// wait for confirmation

This code creates a transaction, signs it with a private key, and sends it to the blockchain network.

Execution Table

Step	Action	Data/Variable	Result/Output
1	Create transaction data	tx = {"to": "0xABC123", "value": 10}	Transaction object ready
2	Sign transaction	signed_tx = sign(tx, private_key)	signed_tx contains signature
3	Broadcast transaction	broadcast(signed_tx)	Transaction sent to network
4	Network validation	signed_tx	Transaction is valid
5	Add to block	signed_tx	Transaction included in block
6	Confirm transaction	block confirmation	Transaction confirmed on blockchain

💡 Transaction confirmed, process complete

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
tx	undefined	{"to": "0xABC123", "value": 10}	{"to": "0xABC123", "value": 10}	{"to": "0xABC123", "value": 10}	{"to": "0xABC123", "value": 10}	{"to": "0xABC123", "value": 10}	{"to": "0xABC123", "value": 10}
signed_tx	undefined	undefined	signed transaction object	signed transaction object	signed transaction object	signed transaction object	signed transaction object
confirmation	false	false	false	false	false	true	true

Key Moments - 3 Insights

Why do we need to sign the transaction before sending it?

Signing proves the transaction is from the owner of the private key. See step 2 in the execution_table where signing creates signed_tx.

What happens if the network finds the transaction invalid?

The transaction will not be added to a block or confirmed. In the execution_table, step 4 shows validation; if invalid, the process stops there.

Why do we wait for confirmation after broadcasting?

Confirmation means the transaction is securely recorded on the blockchain. Step 6 shows confirmation after inclusion in a block.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'signed_tx' after step 2?

A A transaction object with a signature

B An unsigned transaction object

C The private key

D The transaction confirmation status

💡 Hint

Check the 'Data/Variable' column at step 2 in the execution_table.

At which step does the network check if the transaction is valid?

A Step 1

B Step 4

C Step 3

D Step 6

💡 Hint

Look at the 'Action' column for validation in the execution_table.

If the transaction is not confirmed, which variable in variable_tracker remains false?

A tx

B signed_tx

C confirmation

D private_key

💡 Hint

Check the 'confirmation' variable values in variable_tracker.

Concept Snapshot

Sending transactions:
1. Create transaction data (recipient, amount).
2. Sign with private key to prove ownership.
3. Broadcast to blockchain network.
4. Network validates transaction.
5. Transaction added to block and confirmed.

Full Transcript

Sending a transaction on a blockchain involves creating the transaction data with recipient and amount, signing it with your private key to prove ownership, then broadcasting it to the network. The network checks if the transaction is valid, and if so, includes it in a block. Once the block is confirmed, the transaction is confirmed on the blockchain.

Practice

1.

What is the main purpose of sending a transaction on a blockchain?

easy

A. To create a new blockchain network

B. To mine new blocks

C. To move value or data from one account to another

D. To delete data from the blockchain

Solution

1. Step 1: Understand what a transaction does

   A transaction moves value or data between accounts on the blockchain.

2. Step 2: Compare options to the definition

   Only To move value or data from one account to another correctly describes sending a transaction.

3. Final Answer:

   To move value or data from one account to another -> Option C

4. Quick Check:

   Transaction purpose = move value/data [OK]

Hint: Transactions move value or data, not create or delete [OK]

Common Mistakes:

• Confusing transactions with mining
• Thinking transactions create blockchains
• Believing transactions delete blockchain data

2.

Which of the following is the correct way to sign a transaction before sending it?

transaction.sign(____)

easy

A. sender's public key

B. sender's private key

C. receiver's private key

D. network's public key

Solution

1. Step 1: Identify the key needed for signing

   Transactions must be signed with the sender's private key to prove ownership.

2. Step 2: Match the correct key to the method

   Only the sender's private key can sign the transaction securely.

3. Final Answer:

   sender's private key -> Option B

4. Quick Check:

   Sign with private key = sender's private key [OK]

Hint: Sign with sender's private key, never public key [OK]

Common Mistakes:

• Using public key to sign
• Using receiver's key instead of sender's
• Confusing private and public keys

3.

Consider this code snippet sending a transaction:

tx = {
  'to': '0xabc123',
  'value': 10,
  'nonce': 5,
  'gas': 21000
}
signed_tx = sign_transaction(tx, private_key)
result = send_transaction(signed_tx)
print(result)

What will print(result) most likely output if the nonce is incorrect?

medium

A. 'Nonce too low or too high error'

B. 'Transaction successful'

C. 'Gas limit exceeded error'

D. 'Invalid signature error'

Solution

1. Step 1: Understand nonce role in transactions

   Nonce must be correct and sequential to avoid replay or duplication errors.

2. Step 2: Identify error caused by wrong nonce

   An incorrect nonce causes a 'Nonce too low or too high' error during sending.

3. Final Answer:

   'Nonce too low or too high error' -> Option A

4. Quick Check:

   Wrong nonce = nonce error [OK]

Hint: Wrong nonce causes nonce error, not gas or signature errors [OK]

Common Mistakes:

• Confusing nonce error with gas error
• Assuming signature error for nonce issues
• Expecting success despite wrong nonce

4.

Given this code snippet, what is the main error preventing the transaction from sending?

tx = {
  'to': '0xdef456',
  'value': 5,
  'nonce': 3
}
signed_tx = sign_transaction(tx, private_key)
result = send_transaction(signed_tx)
print(result)

Options:

medium

A. Receiver address is invalid

B. Incorrect private key used for signing

C. Nonce value is too high

D. Missing gas field in the transaction

Solution

1. Step 1: Check required transaction fields

   Gas is required to pay for transaction processing; missing gas causes failure.

2. Step 2: Verify other fields and keys

   Nonce and receiver address look valid; no info about wrong private key.

3. Final Answer:

   Missing gas field in the transaction -> Option D

4. Quick Check:

   Missing gas = transaction fails [OK]

Hint: Always include gas field to avoid transaction failure [OK]

Common Mistakes:

• Ignoring gas field requirement
• Assuming nonce or address is wrong without evidence
• Not checking transaction structure

5.

You want to send multiple transactions quickly from the same account. Which approach ensures all transactions are accepted without nonce conflicts?

1. Use the same nonce for all transactions
2. Increment nonce by 1 for each transaction
3. Use random nonce values
4. Skip nonce and rely on network

hard

A. Increment nonce by 1 for each transaction

B. Skip nonce and rely on network

C. Use random nonce values

D. Use the same nonce for all transactions

Solution

1. Step 1: Understand nonce role in multiple transactions

   Nonce must be unique and sequential per account to avoid conflicts.

2. Step 2: Identify correct nonce handling method

   Incrementing nonce by 1 for each transaction ensures proper ordering and acceptance.

3. Final Answer:

   Increment nonce by 1 for each transaction -> Option A

4. Quick Check:

   Sequential nonce = no conflicts [OK]

Hint: Always increment nonce by 1 for each new transaction [OK]

Common Mistakes:

• Reusing same nonce causing rejection
• Using random nonce causing errors
• Assuming network assigns nonce automatically