Solidity Patterns: Guard Checks and State Machines Explained

Guard checks ensure Solidity contracts handle user inputs safely, preventing unexpected behaviors and securing transactions.

### Understanding Solidity Patterns: Guard Checks and State Machines
* 🛡 In this series, the focus is on **Solidity patterns that enhance the robustness and reliability of smart contracts**, crucial for blockchain technology.
* 📜 The tutorial references an article by Frevol and will cover various sections, explaining each **pattern** and providing **code examples**.
* 💻 Viewers are encouraged to practice coding alongside the tutorial using **Remix**, an online Solidity compiler that facilitates **writing and testing smart contracts**.
* 🔒 The first pattern discussed is guard checks, which are **essential for validating user input and ensuring that functions execute as intended** to prevent unpredictable behavior in smart contracts.
* 🍔 An example involving a burger shop smart contract illustrates the implementation of **guard checks**, demonstrating how to **prevent unauthorized transactions** such as purchasing burgers **without payment** or refunding **incorrect amounts**.
* ✅ The tutorial explains the use of `require`, `revert`, and `assert` statements to enforce checks within the contract, ensuring that **conditions are met before proceeding with transactions**.
* 🔄 Additionally, the concept of **state machines** is introduced, showing how to manage different stages of a contract's lifecycle, such as **ordering**, **making**, and **delivering burgers**, through the use of **enums and modifiers**.
* ⚙ Overall, the session emphasizes the **importance of implementing these patterns** to create **secure and efficient smart contracts** in Solidity.

### Implementing a Burger Shop Smart Contract with State Management and Oracles
* 🍔 The burger shop contract allows for a state machine implementation to manage the burger-making process, transitioning through stages such as **"ready to order," "making burger,"** and **"deliver burger."**
* 👨 A function called `makeBurger` updates the state to **"deliver burger"** when the employee completes the burger, while a `pickupBurger` function lets the client pick up the burger, returning the state to **"ready to order."**
* 🔒 Access control is implemented to ensure that **only the employee can call `makeBurger`** when the state is **"making burger,"** and **only the client can call `pickupBurger`** when the state is **"deliver burger."**
* ⚙ The contract includes error handling to prevent functions from being executed at incorrect stages, providing feedback such as **"not at correct stage"** when appropriate.
* 🌐 An oracle pattern is introduced to access external data, allowing the burger shop to **pull activities from an API**, demonstrating the interaction between the **smart contract and off-chain data**.
* 🔑 The contract also implements basic access restrictions, ensuring that **only the contract owner can execute certain functions**, enhancing **security and control** over the contract's operations.
* 🧪 Testing the contract in a virtual machine shows the various states and functionalities in action, highlighting how the **state machine effectively manages the burger shop's operations**.
* 🔄 The tutorial emphasizes that while the implementation serves educational purposes, real-world applications would require **more robust logic and careful consideration of security risks**, especially when using **oracles**.

### Implementing Smart Contract Patterns for Security and Efficiency
* 🔍 The discussion begins with exploring the stages of a smart contract's execution, emphasizing the **importance of understanding the order of operations**.
* 🍔 A transaction to buy a burger is initiated, showing the '**pending**' status and the necessity of '**confirming successful execution**' through function calls.
* ⚙ The concept of **access control** is introduced, highlighting the need for **owner-based and time-based controls** to prevent being **locked out of contract features**.
* 🔒 The checks-effects-interactions pattern is explained, stressing the **importance of validating conditions before changing state variables** to avoid **re-entrancy vulnerabilities**.
* 💰 Different methods for transferring Ether are compared, with a strong recommendation for using the '**call**' method due to its **flexibility in gas handling and error checking**.
* 📜 The pull-over-push pattern is introduced as a **safer alternative for refunds**, allowing users to **claim their funds** rather than having them automatically sent, **reducing risks**.
* 🚨 An emergency stop mechanism is discussed as a **crucial safety feature**, allowing the contract owner to **pause interactions in case of issues**, with practical implementation in the **burger shop example**.
* 📈 Finally, various economic patterns are covered, such as string equality checks and tight variable packing, aimed at **optimizing gas usage in smart contracts** while ensuring **efficient data handling**.

Solidity best practices

HashLips Academy

Introduction to Solidity Patterns and Series Overview

The series will cover Solidity patterns to improve code robustness and reliability.

The series will reference an article by Frevol, going through each section with explanations and code examples.

Introduction of the presenter, Daniel (Hashlifts), and invitation to join the Discord or Telegram channels for assistance.

Recommendation to practice by following along with code examples on remix.ethereum.org.

Explanation of Remix as an online Solidity compiler for compiling human-readable code into bytecode.

Solidity patterns were originally coded in version 0.4.2, but examples will use 0.8.0.

Focus on concepts like guard checks, state machines, oracles, and randomness, adapting implementations to the current Solidity version.

Guard checks ensure expected function execution and prevent unpredictable behavior in smart contracts.

Without guard checks, immutability of blockchain can lead to disastrous consequences.

Reference to a 'Learn Solidity Basics' course for those unfamiliar with Solidity fundamentals.

Coding Example: Burger Shop Smart Contract

Creation of a new workspace in Remix called 'Solidity Patterns'.

Creation of a new file 'GuardCheck.sol' and copying pragma and license from 'Ballot' contract.

Fictional example of a burger shop smart contract with buyBurger and refund functions.

Defining the 'burgerShop' contract with variables for burger cost (0.2 ether).

Testing the initial burger shop contract reveals vulnerabilities in buyBurger and refund functions.

Guard checks validate user input and contract behavior, reverting state changes on failure.

Implementation of guard checks using `require` statements, `assert`, and `revert`.

Using `require` statements in the `buyBurger` function to ensure sufficient payment.

Creating and using modifiers to abstract reusable logic for guard checks.

Explanation of state machines and their application in smart contracts for state updates.

Using enums to define different stages (ready, make, deliver) in the burger shop example.

Creating a modifier `isAtStage` to control function execution based on the current stage.

Creating an `updateStage` function to transition between stages.

Testing the state machine implementation in Remix, observing stage transitions.

The oracle pattern addresses accessing off-chain data, emphasizing the importance of trusted sources.

Three main parts of the oracle pattern: main contract, oracle contract, and external data source.

Example: Using an API to get activities for lucky packets in the burger shop.

Using the provable API for interaction with the external world.

Implementing `getActivity` and `callback` functions in the oracle contract.

Challenges in achieving true randomness on the blockchain due to predictability and miner influence.

Initial approach using `keccak256` hash and modulus operator, demonstrating its vulnerability to miner manipulation.

A more secure approach using a staged method with a trusted party, sealed seed, and block number verification.

Explanation of the staged approach: bet placement, seed setting by a trusted party, and result reveal.

Emphasis on the importance of the trusted party's role in verifying the randomness.

Access Restriction Pattern: Security Patterns

Implementing access control to restrict function calls based on roles or time.

Assigning an owner to the contract using a constructor function.

Creating an `onlyOwner` modifier to restrict function calls to the owner.

Implementing time-based access control using a `startDate` variable and a `shopOpened` modifier.

Discussion on extending access control to include employee roles.

Checks-Effects-Interactions Pattern: Security Patterns

Explanation of the checks-effects-interactions pattern to prevent re-entrancy vulnerabilities.

Example demonstrating the importance of ordering checks, state updates (effects), and external interactions.

Improper ordering can lead to re-entrancy attacks.

Correct ordering: checks, then effects, then interactions.

Secure Ether Transfers: Security Patterns

Comparison of `transfer`, `send`, and `call` methods for sending Ether, recommending `call` for its flexibility in handling gas.

The `transfer` function is no longer recommended due to its potential for failure and contract reverts.

The `call` method forwards all available gas, allowing for more flexibility and handling potential gas increases.

Pull over Push Pattern: Security Patterns

The pull over push pattern shifts the responsibility of Ether transfer from the contract to the user.

Implementing a mapping `userRefunds` to track refunds owed to users.

Creating a `claimRefund` function for users to withdraw their refunds.

Refactoring the `refund` function to use the `userRefunds` mapping and clear the entry after claim.

Emergency Stop Pattern: Security Patterns

Implementing an emergency stop mechanism to pause contract functionality in case of errors.

Using a boolean variable `paused` to control the pausing mechanism.

Creating a `pause` function callable by the owner to toggle the `paused` state.

Creating a `notPaused` modifier to prevent function execution when paused.

Testing the emergency stop mechanism in Remix.

Merging `buyBurger` and `buyDeluxeBurger` functions into a single function with a `price` parameter.

Modifying the `shouldPay` modifier to check against either `normalCost` or `deluxeCost`.

Further refactoring to improve code clarity and reusability of modifiers.

Proxy Delegate Pattern: Upgradeability Patterns

Explanation of the proxy delegate pattern for delegating function execution to another contract while updating the main contract's storage.

Example illustrating the use of `delegatecall` to execute functions in a separate contract.

Benefits of using the delegate pattern for upgradability and maintaining storage consistency.

Example demonstrating how to upgrade a contract by updating the delegate address.

Eternal Storage Pattern: Upgradeability Patterns

The eternal storage pattern addresses preserving data across smart contract upgrades.

Example of a separate eternal storage contract for persistent data storage.

Getter and setter methods for managing data in the eternal storage contract.

Benefits of using eternal storage for maintaining data across contract upgrades.

String equality comparison: optimizing gas usage by checking string lengths before hashing.

Tight variable packing: organizing variables by data type to improve compiler efficiency.

Memory array building: aggregating data using getter functions to reduce gas costs when retrieving data from the contract.