diff --git a/Basics/README.md b/Basics/README.md index a155d9b79..6b065b830 100644 --- a/Basics/README.md +++ b/Basics/README.md @@ -1,3 +1,3 @@ ## Loading, Compiling, Deploying -This beginner level tutorial introduces Remix's interface and concepts used in Ethereum. \ No newline at end of file +This beginner level tutorial introduces Remix's interface and concepts used in Ethereum. diff --git a/Intro-to-blockchain-and-ethereum/README.md b/Intro-to-blockchain-and-ethereum/README.md new file mode 100644 index 000000000..bc7fc9c69 --- /dev/null +++ b/Intro-to-blockchain-and-ethereum/README.md @@ -0,0 +1 @@ +This section is a primer of Web3 concepts you will encounter. It covers what a blockchain is, a primer on the EVM, Ethereum accounts, transactions, gas, etc. \ No newline at end of file diff --git a/Intro-to-blockchain-and-ethereum/config.yml b/Intro-to-blockchain-and-ethereum/config.yml new file mode 100644 index 000000000..253bf89ad --- /dev/null +++ b/Intro-to-blockchain-and-ethereum/config.yml @@ -0,0 +1,12 @@ +--- +id: intro-blockchain +name: An introduction to the Blockchain and Ethereum +summary: Understand the blockchain and how it works from the Ethereum perspective +level: 1 +tags: + - Blockchain +steps: + - name: Introduction to the Blockchain (for Developers) + path: intro-to-blockchain + - name: Introduction to the Ethereum Virtual Machine (EVM) + path: intro-to-evm diff --git a/Intro-to-blockchain-and-ethereum/intro-to-blockchain/README.md b/Intro-to-blockchain-and-ethereum/intro-to-blockchain/README.md new file mode 100644 index 000000000..7fce8ac1c --- /dev/null +++ b/Intro-to-blockchain-and-ethereum/intro-to-blockchain/README.md @@ -0,0 +1,31 @@ +A blockchain is an append-only ledger shared across many computers (nodes). Unlike a traditional database, you never edit or delete past entries; you can only add new entries that, together, define the latest state. + +On public blockchains (some blockchains are private), identical copies of this ledger are widely replicated, and nodes accept new data only if it satisfies the network’s consensus rules. + +## How blockchains work + +At a high level, three parts cooperate: an execution layer that deterministically turns transactions into state changes, a consensus mechanism that orders blocks and decides what becomes canonical, and data availability/state so everyone can fetch and verify the data. When these are aligned, immutability is the practical outcome and rewriting history becomes economically prohibitive. + +### Consensus mechanism + +A consensus mechanism is how the network agrees on the next valid block. For example, **proof-of-stake**, where validators bond capital and can be slashed, and or **proof-of-work**, where miners prove computational effort. + +### Execution Layer + +The execution layer defines how transactions are interpreted and applied to state, step by step, the same way on every node. For example, on EVM chains (Ethereum and many L2s), contracts compile to EVM bytecode. + +Note: Execution is separate from consensus; a network can change how it reaches agreement without changing how code runs, and vice versa. + +### State changes + +Users submit signed transactions that describe intended changes (transfer value, call a contract). Nodes execute these deterministically and, if valid, include them in blocks that extend the chain. + +### Immutability + +Immutability isn’t “forbidden by code”; it’s economically enforced. On Ethereum, blocks become finalized when ≈ two-thirds of staked validators attest to the relevant checkpoints. Reverting a finalized block would require creating conflicting finality—an act that implies slashing at least one-third of the total staked ETH. With roughly ~35–36 million ETH staked today, that’s on the order of ≥11–12 million ETH at risk, which makes rewriting finalized history prohibitively costly. + +## Further reading + +- [Web2 vs. Web3](https://ethereum.org/developers/docs/web2-vs-web3/). +- [An introduction to blockchain and Ethereum](https://ethereum.org/developers/docs/intro-to-ethereum/). +- [Consensus algorithms in blockchains](https://www.geeksforgeeks.org/compiler-design/consensus-algorithms-in-blockchain/). diff --git a/Intro-to-blockchain-and-ethereum/intro-to-evm/README.md b/Intro-to-blockchain-and-ethereum/intro-to-evm/README.md new file mode 100644 index 000000000..7a1c0f434 --- /dev/null +++ b/Intro-to-blockchain-and-ethereum/intro-to-evm/README.md @@ -0,0 +1,75 @@ +The **Ethereum Virtual Machine (EVM)** is the engine that all EVM-compatible smart contracts run on. It’s not one server. It’s a set of rules (a specification). + +Every node follows the same rules so that, with the same inputs, they all get the same result. The EVM defines what a smart contract can do, how data is stored, what operations exist, and how much those operations cost. + +## From Solidity to Bytecode + +When you write a smart contract, you're working in a high-level language like Solidity. But the EVM doesn't understand Solidity directly. It only understands **bytecode**, which is a sequence of low-level instructions called opcodes. Think of opcodes as the assembly language of Ethereum: simple commands like "add two numbers," "store this value," or "jump to another instruction." + +The Solidity compiler takes your human-readable code and translates it into this bytecode. You can see this compilation output in Remix under the Solidity Compiler tab, where you'll find compilation details including the ABI, storage layouts, function hashes, and two types of bytecode that serve different purposes. + +![Solidity compile details](https://raw.githubusercontent.com/ethereum/remix-workshops/master/intro-to-blockchain-and-ethereum/intro-to-evm/images/compile-details.png) + +## Deploying a Smart Contract on the EVM + +Let's deploy a simple ETH vault to understand how this works: + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.8.24; + +contract Vault { + mapping(address => uint256) public balanceOf; + + event Deposited(address indexed from, uint256 amount); + event Withdrawn(address indexed to, uint256 amount); + + function deposit() external payable { + balanceOf[msg.sender] += msg.value; + emit Deposited(msg.sender, msg.value); + } + + function withdraw(uint256 amount) external { + require(balanceOf[msg.sender] >= amount, "insufficient"); + // effects + balanceOf[msg.sender] -= amount; + // interaction + (bool ok, ) = msg.sender.call{value: amount}(""); + require(ok, "send failed"); + emit Withdrawn(msg.sender, amount); + } +} +``` + +When you compile this contract, the compiler produces two distinct programs. The **creation bytecode** (labeled "bytecode" in Remix) runs once during deployment: it sets up your contract's initial state and returns the **runtime bytecode**, which is what gets permanently stored at your contract's address. Every future interaction with your contract executes this runtime bytecode. + +The EVM itself operates as a simple stack machine. It has a stack where it pushes and pops values during computation, temporary memory that gets wiped after each transaction, and permanent storage where your state variables, like the `balanceOf` mapping live on the blockchain. Even though your Solidity code has mappings, events, and named functions, the EVM just sees a sequence of opcodes manipulating these memory spaces. + +## Calling the Contract: ABI, Selectors, and Dispatch + +Once your contract is deployed, how does the EVM know which function to execute when someone interacts with it? This is where **calldata** comes in. Calldata is the data you send along with a transaction: it contains the instructions for what you want the contract to do. + +Wallets and tools follow the **Ethereum ABI** (Application Binary Interface) to format this calldata correctly. For our `deposit()` function, the calldata structure is straightforward. The first 4 bytes contain the **function selector**, which uniquely identifies which function you're calling. This selector is computed by taking the keccak256 hash of the function signature (like `"deposit()"`) and keeping only the first 4 bytes. After the selector comes any encoded arguments, though `deposit()` has none. + +When your runtime bytecode executes, it begins by reading those first 4 bytes from the calldata. It then uses conditional jumps to route execution to the appropriate function logic (a process called dispatching). If the selector doesn't match any known function, Solidity routes to your `fallback` or `receive` handlers if they exist, or the transaction reverts. + +In Remix's Deployed Contracts panel, you'll see your contract's address and all its callable methods. When you click these buttons, Remix is constructing the proper calldata with the correct function selector and sending it to your contract. + +![Contract Callable Methods](https://raw.githubusercontent.com/ethereum/remix-workshops/master/intro-to-blockchain-and-ethereum/intro-to-evm/images/deployed-contract.png) + +## Events and Logs + +When you emit events in your code, the EVM uses special `LOG` opcodes to write **logs** into the transaction receipt. These logs don't modify storage; they're not part of your contract's state. Instead, they're designed for off-chain consumers like UIs and indexers to track what happened during execution. + +Each log contains the contract's address, up to four indexed **topics** (like the `from` parameter marked `indexed` in our `Deposited` event), and additional unindexed data. The first topic is typically the hash of the event signature, which helps tools identify what kind of event occurred. + +## Gas + +Every opcode in the EVM has a gas cost. When you send a transaction, you specify a gas **limit**: the maximum amount of gas you're willing to spend. As your transaction executes, each operation debits from this limit. Reading from storage costs gas. Writing to storage costs more gas. Simple arithmetic costs less than both. + +If your transaction runs out of gas before completing, the current **execution frame** reverts; all state changes are undone, though you still pay for the gas consumed up to that point. This mechanism prevents infinite loops and ensures that network resources aren't abused. It also means that writing efficient code isn't just good practice; it directly reduces costs for your users. + +## Further Reading + +- [The Ethereum virtual machine](https://ethereum.org/developers/docs/evm/). +- [The Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf). diff --git a/Intro-to-blockchain-and-ethereum/intro-to-evm/images/compile-details.png b/Intro-to-blockchain-and-ethereum/intro-to-evm/images/compile-details.png new file mode 100644 index 000000000..149e7f300 Binary files /dev/null and b/Intro-to-blockchain-and-ethereum/intro-to-evm/images/compile-details.png differ diff --git a/Intro-to-blockchain-and-ethereum/intro-to-evm/images/deployed-contract.png b/Intro-to-blockchain-and-ethereum/intro-to-evm/images/deployed-contract.png new file mode 100644 index 000000000..39f1bb4fe Binary files /dev/null and b/Intro-to-blockchain-and-ethereum/intro-to-evm/images/deployed-contract.png differ