Assertion patterns in Blockchain / Solidity - Time & Space Complexity

Time Complexity: Assertion patterns

O(n)

Understanding Time Complexity

When working with blockchain code, assertions help check if conditions are true during execution.

We want to see how these checks affect the time it takes for the program to run as input grows.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

function validateTransactions(transactions) {
  for (let i = 0; i < transactions.length; i++) {
    assert(transactions[i].amount > 0, "Amount must be positive");
  }
}

This code checks each transaction to make sure its amount is positive using an assertion.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through each transaction to run an assertion check.
• How many times: Once for every transaction in the list.

How Execution Grows With Input

As the number of transactions grows, the number of assertion checks grows the same way.

Input Size (n)	Approx. Operations
10	10 assertion checks
100	100 assertion checks
1000	1000 assertion checks

Pattern observation: The work grows directly with the number of transactions.

Final Time Complexity

Time Complexity: O(n)

This means the time to run grows in a straight line with the number of transactions.

Common Mistake

[X] Wrong: "Assertions run instantly and don’t add to time as input grows."

[OK] Correct: Each assertion runs once per item, so more items mean more checks and more time.

Interview Connect

Understanding how assertions affect time helps you write efficient blockchain code and explain your reasoning clearly.

Self-Check

"What if we added nested assertions inside another loop? How would the time complexity change?"

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