Reference types behavior in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Reference types behavior

Create Object A

↓

Assign Ref1 = A

↓

Assign Ref2 = Ref1

↓

Modify via Ref2

↓

Check Ref1 shows change

↓

Reassign Ref2 to new Object B

↓

Ref1 still points to A

↓

End

This flow shows how reference types point to the same object, so changes via one reference affect the other, but reassigning a reference breaks the link.

Execution Sample

Blockchain / Solidity

objectA = {"value": 10}
ref1 = objectA
ref2 = ref1
ref2["value"] = 20
ref2 = {"value": 30}
print(ref1["value"])

This code shows two references to the same object, modifying it through one reference, then reassigning the second reference.

Execution Table

Step	Action	ref1	ref2	objectA	Output
1	Create objectA with value 10	null	null	{"value":10}
2	Assign ref1 = objectA	{"value":10}	null	{"value":10}
3	Assign ref2 = ref1	{"value":10}	{"value":10}	{"value":10}
4	Modify ref2["value"] = 20	{"value":20}	{"value":20}	{"value":20}
5	Reassign ref2 = {"value":30}	{"value":20}	{"value":30}	{"value":20}
6	Print ref1["value"]	{"value":20}	{"value":30}	{"value":20}	20

💡 Execution ends after printing ref1["value"] which is 20, showing ref1 still points to original object.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
objectA	null	{"value":10}	{"value":10}	{"value":20}	{"value":20}	{"value":20}
ref1	null	{"value":10}	{"value":10}	{"value":20}	{"value":20}	{"value":20}
ref2	null	null	{"value":10}	{"value":20}	{"value":30}	{"value":30}

Key Moments - 2 Insights

Why does changing ref2["value"] also change ref1["value"]?

Because ref1 and ref2 both point to the same object (objectA) at that time, so modifying via one reference affects the shared object, as shown in step 4 of the execution_table.

Why does ref1["value"] stay 20 after ref2 is reassigned?

Reassigning ref2 to a new object breaks its link to objectA, but ref1 still points to the original objectA, so ref1["value"] remains 20, as seen in step 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what is the value of ref1["value"]?

A 10

B 20

C 30

D null

💡 Hint

Check the 'ref1' column at step 4 in the execution_table.

At which step does ref2 stop pointing to the same object as ref1?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at when ref2 value changes independently in the execution_table.

If we changed ref2["value"] = 50 at step 4 instead of 20, what would ref1["value"] be at step 6?

A 20

B 30

C 50

D 10

💡 Hint

Since ref1 and ref2 share the same object before step 5, changes via ref2 affect ref1.

Concept Snapshot

Reference types store addresses to objects.
Multiple references can point to the same object.
Changing the object via one reference affects all references.
Reassigning a reference breaks the link to the original object.
Useful to understand shared state in blockchain data structures.

Full Transcript

This lesson shows how reference types behave in blockchain programming. We start by creating an object with a value. Then we assign two references to this same object. When we change the value through one reference, the other reference sees the change because they point to the same object. Later, when we assign a new object to one reference, it no longer points to the original object, but the other reference still does. This explains why changes through one reference affect others until reassignment breaks the link. Understanding this helps avoid bugs when working with shared data in blockchain code.

Practice

1. In blockchain programming, what happens when you assign one reference type variable to another?

easy

A. The variables become independent and unrelated.

B. A new copy of the data is created.

C. The original data is deleted.

D. Both variables point to the same data location.

Solution

1. Step 1: Understand reference assignment

   Assigning one reference type variable to another makes both point to the same data location in memory.

2. Step 2: Effect of changes through references

   Changes made through either variable affect the same original data because they share the reference.

3. Final Answer:

   Both variables point to the same data location. -> Option D

4. Quick Check:

   Reference assignment shares data location = A [OK]

Hint: Reference types share data location, not copy data [OK]

Common Mistakes:

• Thinking assignment copies data
• Assuming variables become independent
• Believing original data is deleted

2. Which of the following is the correct syntax to copy a reference type variable in Solidity (blockchain language)?

easy

A. uint[] memory newArray = oldArray;

B. uint[] newArray = oldArray.copy();

C. uint[] storage newArray = oldArray;

D. uint[] newArray = copy(oldArray);

Solution

1. Step 1: Understand storage vs memory in Solidity

   Storage variables hold data permanently on blockchain, memory variables are temporary copies.

2. Step 2: Correct way to copy reference

   Assigning a storage reference variable to another storage variable copies the reference, not the data.

3. Final Answer:

   uint[] storage newArray = oldArray; -> Option C

4. Quick Check:

   Storage assignment copies reference = B [OK]

Hint: Use 'storage' keyword to copy reference, not 'memory' [OK]

Common Mistakes:

• Using 'memory' copies data, not reference
• Assuming .copy() method exists
• Trying to use undefined copy functions

3. Consider this Solidity code snippet:

uint[] storage arr1 = someArray;
uint[] storage arr2 = arr1;
arr2.push(10);
uint length = arr1.length;

What is the value of length after execution?

medium

A. Length is unchanged from original someArray length.

B. Length increases by 1 due to push on arr2.

C. Length decreases by 1 due to push on arr2.

D. Code causes a compilation error.

Solution

1. Step 1: Understand reference assignment

   arr2 is assigned as a storage reference to arr1, so both point to the same array.

2. Step 2: Effect of push on arr2

   Pushing 10 to arr2 modifies the shared array, increasing its length by 1.

3. Final Answer:

   Length increases by 1 due to push on arr2. -> Option B

4. Quick Check:

   Shared reference means push affects both = C [OK]

Hint: Changes via one reference affect all references [OK]

Common Mistakes:

• Thinking arr1 length stays same
• Assuming arr2 is a copy
• Ignoring reference sharing behavior

4. Identify the error in this Solidity code snippet:

function updateArray(uint[] memory arr) public {
  uint[] storage ref = arr;
  ref.push(5);
}

medium

A. Cannot assign memory array to storage reference directly.

B. Cannot push to a storage array.

C. Function must be declared view.

D. No error; code runs fine.

Solution

1. Step 1: Check assignment between memory and storage

   In Solidity, you cannot assign a memory array directly to a storage reference variable.

2. Step 2: Understand push operation

   Push is allowed on storage arrays, but assignment error occurs before push.

3. Final Answer:

   Cannot assign memory array to storage reference directly. -> Option A

4. Quick Check:

   Memory to storage assignment invalid = A [OK]

Hint: Memory and storage types cannot be assigned directly [OK]

Common Mistakes:

• Assuming memory can be assigned to storage
• Thinking push is disallowed on storage
• Ignoring data location mismatch

5. You want to create a function in Solidity that returns a modified copy of a storage array without changing the original. Which approach correctly uses reference types to achieve this?

hard

A. Create a new memory array, copy elements from storage, modify it, then return.

B. Assign storage array to a storage reference, modify it, then return.

C. Return the storage array directly after modifying it.

D. Use a global variable to store the modified array.

Solution

1. Step 1: Understand data locations for copying

   To avoid changing original storage array, create a new memory array and copy elements.

2. Step 2: Modify and return the memory array

   Modify the memory array safely and return it without affecting storage data.

3. Final Answer:

   Create a new memory array, copy elements from storage, modify it, then return. -> Option A

4. Quick Check:

   Use memory copy to avoid changing storage = D [OK]

Hint: Copy to memory, modify, then return to keep original safe [OK]

Common Mistakes:

• Modifying storage reference directly
• Returning storage array after modification
• Using global variables unnecessarily