> For the complete documentation index, see [llms.txt](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blockchain-journal-hope-mabuza.gitbook.io/blockchain-journal-hope-mabuza-docs/smart-contracts/week-3-solidity-deep-dive-data-types-memory-vs-storage-mappings-..md).

# Week 3 : Solidity Deep Dive (Data Types, Memory vs Storage, Mappings).

#### Day 15 <a href="#day-15" id="day-15"></a>

**Solidity Syntax and Conditionals**

* Today I went deeper into Solidity syntax. I have written some Solidity before and used it in last week's assessment, but today things started making more sense rather than just following patterns I didn't fully understand. The thing that stood out most was how conditionals work differently to what I was used to.
* `require` is a conditional that must be true for the function to continue. If the condition is not met, all changes are reverted, and the program stops at that point. You would use `require` when something must be true before any logic runs, like checking that a user has enough balance before a withdrawal.
* `if-else` is more flexible. If the `if` condition fails, the program moves to the `else` block and keeps running unless you explicitly use a `revert`. You would use `if-else` when you want the contract to handle different outcomes rather than just stopping entirely.

***

#### Day 16 <a href="#day-16" id="day-16"></a>

**Memory vs Storage and Why It Matters**

* Today I wrote a contract where you can add products and retrieve a specific product based on its ID. In the function where we add the product, we marked the product name parameter as `memory`, and in the `getProduct` function we also saved the product variable as `memory`.
* The compiler forces us to add the `memory` keyword because `string` is a reference type in Solidity. Reference types must always specify a data location, either `memory`, `storage`, or `calldata`. Without it, the compiler doesn't know where the data should live.
* `memory` variables only exist during the execution of the function and are not stored permanently on the blockchain. This helps save storage space and reduces gas costs. `storage` on the other hand is permanent and costs more because it writes to the blockchain. Knowing when to use each one is something I can see becoming really important as contracts get more complex.

***

#### Day 17 <a href="#day-17" id="day-17"></a>

**Loops, Gas Costs and Why Unbounded Arrays Are Dangerous**

* Lets talk loops. In Java, an infinite loop can cause an app to crash. In Solidity, the problem is different, looping over a large array means the user has to pay gas for every iteration. The bigger the array, the more expensive the function becomes, and at some point it can hit the block gas limit and become completely unusable.
* I ran into this problem in my own contract. I had logic inside a loop that was doing too much work per iteration. The fix was to reduce what was happening inside the loop and move some of the logic outside of it where possible. It was a good practical lesson rather than just a theory warning.
* Lesson of the day: avoid iterating over an unbounded array. It increases gas fees, risks hitting the block gas limit, and makes your contract unreliable for users.

***

#### Day 18 <a href="#day-18" id="day-18"></a>

**Workshop Day, Contracts, the Trilemma, and More**

* Today was our first workshop with Karabo and it covered a lot of ground. We started with the basics and built up from there, which was a good reminder that most advanced smart contracts are just combinations of simple concepts done correctly.

**Simple Banking Contract**

* Below is a simple Bank contract we worked through:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract SimpleBank {
    
    mapping(address => uint256) public balances;
    event MoneyDeposited(address indexed sender, uint256 amount);
    
    function deposit() public payable {
        balances[msg.sender] += msg.value;
        emit MoneyDeposited(msg.sender, msg.value);
    }
}
```

It has a mapping that connects every address to a balance. The mapping works like a dictionary, the key is the address and the value is the amount of ETH that address has deposited.

There is an event that gets emitted after every deposit. Events are like logs on the blockchain, when we emit them we are recording that something happened.

The `deposit()` function is marked as `payable`, which means the contract can receive ETH. `msg.value` is the amount of ETH being sent and `msg.sender` is the person calling the function.

So every time someone deposits ETH, their balance increases and the contract emits an event logging the deposit.

**The Blockchain Trilemma**

* We were introduced to the Blockchain Trilemma. Every blockchain struggles to fully optimise all three of these at the same time:

1. Security
2. Decentralization
3. Scalability

Improving one usually comes at the cost of another. Ethereum is actively working on improving scalability while trying to hold onto its strong security and decentralization.

**Zero-Knowledge Proofs**

* ZK technology is one of the ways Ethereum is tackling the scalability problem, especially through Layer 2 solutions like zk-rollups. ZK proofs allow transactions to be processed off-chain and then verified on-chain with a cryptographic proof. Think of it as doing all the heavy work off the blockchain and only submitting the final verified result. This reduces congestion and gas costs while keeping the network secure.

**Nodes**

* Nodes are what keep the blockchain running and in order. They store a copy of the blockchain, validate transactions, and enforce the protocol rules. In Proof of Stake, validators are rewarded for participating honestly. Some full nodes are also run voluntarily by people who just want to support decentralization, which says a lot about the ethos of the ecosystem.

**MEV**

* We also touched on MEV, which stands for Maximal Extractable Value. It refers to the extra profit validators can make by reordering, including, or excluding certain transactions before a block is finalised. It affects transaction fees and fairness in the network and is one of those topics that sounds technical but has very real consequences for everyday users.

***

#### Day 19 <a href="#day-19" id="day-19"></a>

**How Solidity Forces You to Think Differently About Data**

* The biggest difference I notice between Web Development and Solidity is how you have to think about data structures. In Web Development there is garbage collection, memory is managed automatically and you rarely think about the cost of storing a variable. Even if your data structure is messy, the system handles cleanup behind the scenes.
* In Solidity, every state variable costs gas because it is stored permanently on the blockchain. Users pay for every transaction, so a poorly designed data structure does not just slow things down, it makes your contract expensive and frustrating to use. This forces you to be intentional about what actually needs to live on-chain and what can be handled off-chain or in memory. It is a different mindset entirely and one I am still getting used to.

***

#### Day 20 (ABC) <a href="#day-20-abc" id="day-20-abc"></a>

**AI Tools and Understanding ABIs**

* Today had two very different but interesting parts. We started with a look at AI tools, Karabo walked us through how he uses OpenClaw AI and talked about how to get the most out of AI while staying aware of its limitations and security risks. We also watched a video generated using Seedance which was a fun way to see how far generative AI has come.
* The second part was about ABIs in Solidity, which was the more technical and useful lesson for me. An ABI, which stands for Application Binary Interface, acts as a translator between a frontend and a smart contract. It is like a guide that tells an external application how to interact with the contract, what functions exist, what inputs they expect, what they return, and whether they cost gas or not. Without the ABI, the frontend would have no idea how to call functions or make sense of the responses. We were tasked with analysing the ABI of the VendingMachine contract from the ABC GitBook and understanding how the frontend talks to the contract through it.

***