Assertion patterns in Blockchain / Solidity

Introduction

Assertion patterns help check if something is true in your blockchain code. They stop the program if a mistake happens, keeping your data safe.

To make sure a transaction has enough funds before sending.

To check if a user is authorized before allowing access.

To verify that a smart contract's state is correct after an action.

To catch errors early during blockchain development.

To prevent invalid data from being saved on the blockchain.

Syntax

Blockchain / Solidity

assert condition, "error message"

The assert keyword checks if the condition is true.

If the condition is false, the program stops and shows the error message.

Examples

This checks if the balance is enough to cover the amount before sending money.

Blockchain / Solidity

assert balance >= amount, "Insufficient funds"

This ensures only the owner can perform certain actions.

Blockchain / Solidity

assert user == owner, "Unauthorized access"

This confirms the contract's state is as expected after an update.

Blockchain / Solidity

assert state == expected_state, "State mismatch"

Sample Program

This program checks if the balance is enough to send the amount. If not, it stops with an error.

Blockchain / Solidity

balance = 100
amount = 150
assert balance >= amount, "Insufficient funds"
print("Transaction approved")

Important Notes

Assertions are great for catching mistakes early but should not replace normal error handling.

In blockchain, stopping on errors helps protect funds and data integrity.

Summary

Assertions check if something is true and stop the program if not.

They help keep blockchain data safe by catching errors early.

Use clear error messages to understand what went wrong.

Practice

1.

What is the main purpose of an assertion in blockchain smart contract testing?

easy

A. To optimize the contract's gas usage

B. To log information without affecting execution

C. To deploy the contract to the blockchain

D. To check if a condition is true and stop execution if false

Solution

1. Step 1: Understand assertion role

   Assertions verify conditions during execution to ensure correctness.

2. Step 2: Identify assertion effect

   If the condition is false, assertions stop execution and revert changes to prevent errors.

3. Final Answer:

   To check if a condition is true and stop execution if false -> Option D

4. Quick Check:

   Assertions stop execution on false condition [OK]

Hint: Assertions stop code if condition fails, preventing errors [OK]

Common Mistakes:

• Thinking assertions only log info without stopping
• Confusing assertions with deployment steps
• Assuming assertions optimize gas usage

2.

Which of the following is the correct syntax for an assertion in Solidity?

?

easy

A. assert: balance >= amount;

B. assert(balance >= amount);

C. assert(balance < amount);

D. assert(balance = amount);

Solution

1. Step 1: Recall Solidity assertion syntax

   Assertions use the function-like syntax: assert(condition);

2. Step 2: Check condition correctness

   Condition should be a boolean expression, here balance >= amount is valid.

3. Final Answer:

   assert(balance >= amount); -> Option B

4. Quick Check:

   assert(condition) uses parentheses and semicolon [OK]

Hint: Assertions use assert(condition); with parentheses and semicolon [OK]

Common Mistakes:

• Using colon instead of parentheses
• Using assignment (=) instead of comparison (>=)
• Writing incorrect comparison operators

3.

Consider this Solidity code snippet:

uint balance = 100;
uint amount = 150;
assert(balance >= amount);

What will happen when this code runs?

medium

A. Execution continues normally

B. balance is updated to amount

C. Execution stops and reverts due to failed assertion

D. Compilation error due to invalid assertion

Solution

1. Step 1: Evaluate assertion condition

   balance is 100, amount is 150, so balance >= amount is false.

2. Step 2: Understand assertion behavior on false

   Assertion fails, so execution stops and reverts all changes.

3. Final Answer:

   Execution stops and reverts due to failed assertion -> Option C

4. Quick Check:

   False assertion stops execution [OK]

Hint: False assertion stops execution and reverts changes [OK]

Common Mistakes:

• Assuming code continues after failed assertion
• Thinking assertion causes compile error
• Believing balance changes automatically

4.

Identify the error in this Solidity assertion statement:

assert(balance = amount);

medium

A. Using assignment operator instead of comparison

B. Missing semicolon at the end

C. Incorrect function name, should be require()

D. balance and amount are undefined

Solution

1. Step 1: Analyze operator usage

   The single equals sign (=) assigns value, not compares values.

2. Step 2: Correct operator for assertion

   Assertions require comparison operators like == or >= to check conditions.

3. Final Answer:

   Using assignment operator instead of comparison -> Option A

4. Quick Check:

   Use '==' for comparison in assertions [OK]

Hint: Use '==' for comparison, not '=' assignment in assertions [OK]

Common Mistakes:

• Confusing '=' with '==' in conditions
• Thinking require() must replace assert() always
• Ignoring missing semicolon (which is present here)

5.

You want to assert that a user's balance is positive and provide a clear error message if not. Which assertion pattern is best?

?

hard

A. require(balance > 0, "Balance must be positive");

B. assert(balance > 0, "Balance must be positive");

C. assert(balance > 0);

D. if(balance <= 0) revert("Balance must be positive");

Solution

1. Step 1: Understand assertion vs require

   In Solidity, assert is for internal errors without messages; require allows error messages.

2. Step 2: Choose assertion with message

   require(condition, message) is best to check user input and show clear error.

3. Final Answer:

   require(balance > 0, "Balance must be positive"); -> Option A

4. Quick Check:

   Use require() for checks with error messages [OK]

Hint: Use require() to assert with clear error messages [OK]

Common Mistakes:

• Using assert() with message (not supported)
• Ignoring error messages in assertions
• Using if + revert instead of require() unnecessarily