Functions and Interaction

Solidity & DeFi journey

Token world

Solidity basics

0/22

Meeting

Hello, Blockchain!

Smart contract structure

Smart contract state variables

Functions and Interaction

Data Operations — Basics

Numeric and Boolean Data Types

Strings, Bytes and Addresses

Local Variables and State Variables

Constants and Immutable Variables

Functions with Multiple Return Values

Variable Visibility Modifiers

Function Visibility and Behavior Modifiers

Advanced Operations and Security

Remix IDE — Platform Introduction

Remix IDE — Advanced Features

Basic Error Handling

Advanced Error Handling

Custom Modifiers

Arrays - Basics of Ordered Data

Mappings - Associative Data Structures

Structs and Enums - Data Grouping

Blockchain basics

0/0

Basic cryptography

0/0

Скидки на «Starter» и «Pro» до

Выбрать тариф

Functions — Contract ActionsNext, Alex moves on to functions:
— "Variables are the passive part. Functions are the active part. They're like buttons. You press them — and something happens."
Functions
﻿
TermsFunction — a block of code that performs a specific task. Can accept input parameters and return a result. Functions allow users to interact with the contract and change its state. A function can be called in a transaction on the blockchain.
Function parameters — input data that a function receives to work with. Each parameter has a type and name. They allow passing information to the function for processing.
Return value — data that a function gives as the result of its work. Specified using the returns keyword and data type.
Pure function — a function that doesn't read or modify the contract's state. Performs only calculations with passed parameters. Marked with the pure modifier.
View function — a function that can read the contract's state but cannot modify it. Used to retrieve data without creating transactions. Marked with the view modifier.
Payable function — a function that can receive cryptocurrency payments along with the call. Marked with the payable modifier. Received funds are added to the contract's balance.
What is a Function?Alex thinks about the concept of a function:
— "A function is like a 'black box'. You give it input data, some manipulations happen inside, and you get a result at the output. I don't need to know how exactly it works inside — the main thing is to understand what task it solves and what result it returns."
Function as black box
﻿
For example, when Alex calls the function multiply(5, 3), he knows he will get 15, but he doesn't necessarily need to know how exactly the multiplication happens inside the function.
Solidity
// Input: two numbers → Black box (function) → Output: product of numbers
function multiply(uint256 a, uint256 b) public pure returns (uint256) {
    return a * b;  // Internal logic is hidden from the user
}
Function DeclarationFunction declaration begins with the keyword function. Then the function name and parameters in parentheses. Then visibility modifiers, followed by the return type.
Let's break down the function piece by piece:
Solidity
function setTokenPrice(uint256 newPrice) public returns (bool) {
    //     ↑             ↑                      ↑         ↑
    //   name        parameters             modifiers   what it returns
﻿
    // function body - what it does.
    // Here – assigns a new value to a state variable
    tokenPrice = newPrice;
﻿
    // return value
    return true;
}
Function Structure in SolidityAlex studies the anatomy of a Solidity function:
Solidity
function function_name(parameter_type parameter_name) modifiers returns (return_type) {
    // function body
﻿
    // return value
    return value;
}
1. Function Name— "The name should clearly describe what the function does. calculateArea is better than just calc."
2. Parameters (Input Data)— "This is data that the function receives to work with. Each parameter has a type and name."
Solidity
function transferTokens(address to, uint256 amount, string memory reason) public {
    //                    ↑        ↑               ↑
    //                  address  amount      transfer reason
}
3. Visibility and Behavior Modifiers— "They define who can call the function and its behavior type. If not specified, default modifiers will be used."
4. Return Type— "This is the data type that the function returns as the result of its work."
Solidity
function getBalance(address user) public view returns (uint256) {
    //                                               ↑
    //                                         returns a number
    return balances[user];
}
5. Function Body— "Here the logic is described — what exactly is executed when the function is called."
Why Do We Need Functions?Alex understands that functions solve several important tasks:
1. Code Organization— "When code is broken down into functions, each performing one small task, it's much easier to understand and maintain."
Solidity
contract TokenContract {
    // Instead of one huge function — many small and understandable ones
    function validateTransfer(address from, address to, uint256 amount) internal pure returns (bool) {
        // Transfer validation
    }
﻿
    function updateBalances(address from, address to, uint256 amount) internal {
        // Balance updating
    }
﻿
    function transfer(address to, uint256 amount) public {
        require(validateTransfer(msg.sender, to, amount), "Invalid transfer");
        updateBalances(msg.sender, to, amount);
    }
}
2. Simplified Understanding— "I don't need to know how a function works inside. The main thing is understanding what it does. It's like using a calculator: it doesn't matter how it's built, what matters is that it calculates correctly."
3. Reuse— "If I need to do the same actions in different parts of the program, I can write one function and use it many times."
Solidity
contract GameContract {
    function calculateDamage(uint256 baseDamage, uint256 multiplier) public pure returns (uint256) {
        return baseDamage * multiplier / 100;
    }
﻿
    function swordAttack(uint256 strength) public pure returns (uint256) {
        return calculateDamage(strength, 120);  // Reusing the function
    }
﻿
    function magicAttack(uint256 intelligence) public pure returns (uint256) {
        return calculateDamage(intelligence, 150);  // And reusing again
    }
}
Function Features in BlockchainAlex asks an important question:
— "How do functions in blockchain differ from regular functions in other programming languages?"
After studying the documentation, he understands the key differences:
1. Connection with TransactionsIn blockchain, each function call that changes the contract state creates a transaction:
State-changing functions (without view/pure) → create a transaction, cost gas, changes are written to blockchain forever
View/Pure functions → executed locally, free, don't create transactions
Solidity
contract Example {
    uint256 public counter;
﻿
    // Creates a transaction! Costs gas, written to blockchain
    function increment() public {
        counter += 1;
    }
﻿
    // Does NOT create a transaction! Free, executed locally
    function getCounter() public view returns (uint256) {
        return counter;
    }
}
2. Execution Cost— "In regular programs, a function executes for free. In blockchain, you need to pay gas for changing data!"
3. Irreversibility— "In a regular program, you can roll back changes or restart. In blockchain, every change is recorded forever!"
4. Publicity— "Any blockchain participant can look at the function code and call public functions. In regular programs, code is often hidden."
The memory Keyword — Where to Store Data?Alex notices something strange in the code:
— "Why does string always have string memory written, but uint256 doesn't? What is this memory?"
He studies the documentation and understands: in Solidity there are different "places" for storing data, like different shelves in a store.
Data Storage Locations:storage — permanent storage (like a database field) — data is saved in the blockchain forever
memory — temporary storage (like RAM in a computer) — data exists only during function execution, you can read and write temporary information
calldata — read-only (like a computer disk without write capability) — data is passed to the function, cannot be changed and is not saved after function execution
Which Types Require memory?The memory keyword needs to be specified only for complex data types:
✅ Require memory:
string — strings
bytes — byte arrays
arrays (uint256[], address[], etc.)
structures (struct)
❌ Do NOT require memory:
uint256, int256 — numbers
bool — boolean values
address — addresses
Why Does This Happen?Alex understands the logic:
— "Simple data types (numbers, addresses) have a fixed size — they always take the same amount of space. The compiler knows where to put them."
— "Complex data types (strings, arrays) have variable size — a string can be 5 characters or 500. Therefore, you need to explicitly specify where to store them."
Examples of Correct Usage:Solidity
// ✅ Correct - string requires memory specification
function setMessage(string memory newMessage) public {
    message = newMessage;
}
﻿
// ✅ Correct - string requires memory when returning
function getMessage() public view returns (string memory) {
    return message;
}
﻿
// ✅ Correct - simple types do NOT require memory
function incrementCounter() public {
    counter = counter + 1;  // uint256 doesn't require memory
}
﻿
// ❌ Error - without memory the compiler won't understand where to store the string
function setMessage(string newMessage) public {  // ERROR!
    message = newMessage;
}
Visibility and Behavior ModifiersIn function declaration there's an important part — modifiers:
— "Modifiers are like 'access settings' for functions. They define two important things: who can call the function (visibility) and how it interacts with blockchain data (behavior)."
He studies two categories of modifiers:
Visibility modifiers (public, private, internal, external) — define where the function can be called from
Behavior modifiers (view, pure, payable) — define how the function works with contract state
— "Understanding modifiers is critical. Wrong visibility can open security vulnerabilities, and wrong behavior can lead to unexpected gas costs."
Visibility ModifiersAlex studies who can call functions:
public - everyone can callFunctions are accessible to everyone: users, other contracts, and inside the contract itself.
Examples of functions usually made public:
Solidity
// Basic balance operations, they may be needed both inside and outside the smart contract
function getBalance() public view returns (uint256) {
    return balance;
}
﻿
// Fund transfer
function transfer(address to, uint256 amount) public {
    // transfer logic
}
﻿
// Account deposit
function deposit() public payable {
    balance += msg.value;
}
﻿
// Getting contract information
function getContractInfo() public view returns (string memory) {
    return "My Smart Contract";
}
private - only functions in the same contract can callAccessible only inside this contract. Even inheriting contracts don't have access.
Examples of functions usually made private:
Solidity
// Internal calculations
function _calculateFee(uint256 amount) private pure returns (uint256) {
    return amount * 3 / 100; // 3% fee
}
﻿
// Checking internal conditions
function _isValidUser(address user) private view returns (bool) {
    return userBalances[user] > 0;
}
﻿
// Resetting internal data
function _resetCounters() private {
    dailyTransactions = 0;
    weeklyLimit = 1000;
}
internal - functions in the same contract and inheriting contracts can callAccessible inside the contract and in inheriting contracts. Not accessible from outside.
Examples of functions usually made internal:
Solidity
// Basic transfer logic that can be extended by inheritors
function _transfer(address from, address to, uint256 amount) internal {
    balances[from] -= amount;
    balances[to] += amount;
}
﻿
// Common checks, can be reused by child contracts
function _validateAmount(uint256 amount) internal pure returns (bool) {
    return amount > 0 && amount < 1000000;
}
﻿
// Initialization for inherited contracts
function _initialize(address owner) internal {
    contractOwner = owner;
    isInitialized = true;
}
external - can only be called from functions in other contractsAccessible only from outside the contract. Cannot be called from inside the contract itself. More economical than public for large data.
Examples of functions usually made external:
Solidity
// Administrative functions
function emergencyStop() external {
    require(msg.sender == admin, "Only admin");
    paused = true;
}
﻿
// Callback functions
function onTokenReceived(address from, uint256 amount, bytes calldata data) external {
    // Called by other contracts
}
﻿
// API for external calls with large data
function processLargeData(uint256[] calldata numbers) external {
    // more economical for large arrays
}
Important Difference: Visibility Modifiers for Variables vs FunctionsAlex notices an important feature:
— "Wait! The public modifier for functions doesn't work the same as for variables!"
He studies the documentation and understands the key difference:
For variables public = automatic getter, allowing reading the variable from outside the contract
Solidity
contract Example {
    uint256 public counter = 10;  // Automatically creates:
﻿
    // function counter() public view returns (uint256) {
    //     return counter;
    // }
}
For functions public = ability to call the function from outside the contract, by users or other contracts
Solidity
contract Example {
    function incrementCounter() public {  // Can be called from outside AND inside
        // function logic
    }
﻿
    function internalHelper() internal {  // Only from inside the contract
        incrementCounter();  // This works
    }
}
Important conclusion: The visibility modifier of a function has significantly greater importance for contract security than the visibility modifier of a variable. Wrong function visibility can open critical vulnerabilities — for example, if a private administrative function is accidentally declared as public, attackers will be able to call it. While wrong variable visibility most often leads only to unwanted data disclosure, but not to loss of contract control.
Behavior ModifiersBehavior modifiers define how a function interacts with contract data and blockchain:
— "It's like different operating modes. Some functions can do everything — read, write, receive money. Others — only read. And third ones — don't access anything at all, only calculate."
view - read-only dataFunctions can read data from the blockchain but cannot change it. Free when called directly, not from another function.
Examples of view functions:
Solidity
// Getting user balance
function getBalance(address user) public view returns (uint256) {
    return balances[user];
}
﻿
// Checking permissions
function isOwner(address user) public view returns (bool) {
    return user == owner;
}
﻿
// Getting blockchain information
function getCurrentTime() public view returns (uint256) {
    return block.timestamp;
}
﻿
// Calculations based on current data
function calculateInterest(address user) public view returns (uint256) {
    return balances[user] * interestRate / 100;
}
pure - no state accessFunctions don't read or change contract data. Work only with passed parameters.
Examples of pure functions:
Solidity
// Mathematical calculations
function add(uint256 a, uint256 b) public pure returns (uint256) {
    return a + b;
}
﻿
// Interest calculation
function calculateInterest(uint256 amount, uint256 rate) public pure returns (uint256) {
    return amount * rate / 100;
}
﻿
// String operations
function concatenate(string memory a, string memory b) public pure returns (string memory) {
    return string(abi.encodePacked(a, " ", b));
}
﻿
// Data validation
function isValidEmail(string memory email) public pure returns (bool) {
    bytes memory emailBytes = bytes(email);
    return emailBytes.length > 5; // Simplified check
}
payable - can receive paymentsFunctions can receive ETH — blockchain currency along with the call. Without payable, sending ETH will result in an error.
Examples of payable functions:
Solidity
// Account deposit
function deposit() public payable {
    balances[msg.sender] += msg.value; // msg.value - sent ETH amount
}
﻿
// Item purchase
function buyItem(uint256 itemId) public payable {
    require(msg.value >= itemPrices[itemId], "Insufficient payment");
    // Purchase logic
}
﻿
// Donations with message
function donate(string memory message) public payable {
    require(msg.value > 0, "Donation must be greater than 0");
    totalDonations += msg.value;
}
﻿
// Constructor can be payable
constructor() public payable {
    owner = msg.sender;
    // Can send ETH during deployment
}
Comparing Behavior ModifiersAlex creates a table for better understanding:
Modifier
Read State
Change State
Receive ETH
Gas Cost
Creates Transaction
view
✅ Yes
❌ No
❌ No
0 (free)
❌ No
pure
❌ No
❌ No
❌ No
0 (free)
❌ No
payable
✅ Yes
✅ Yes
✅ Yes
Has cost
✅ Yes
Regular
✅ Yes
✅ Yes
❌ No
Has cost
✅ Yes
Practical Example: Token Sale ContractAlex decides to create a complete example that will show all studied modifiers in action. He develops a contract for token sales:
— "Great idea! I'll make a contract where users will be credited with internal balance for deposited ETH. All modifiers will be useful here: pure for calculations, view for checking balances, payable for receiving payments!"
Solidity
contract TokenSaleVault {
    uint256 public tokenPrice = 0.001 ether;
    uint256 public userTokenBalance;
﻿
    // Pure: we don't read state variables
    function calculateTokens(uint256 ethAmount) public pure returns (uint256) {
        return ethAmount / 0.001 ether;
    }
﻿
    // View: only reading state variable – balances[user]
    function getBalance(address user) public view returns (uint256) {
        return userTokenBalance;
    }
﻿
    // Payable: receiving payment and changing state
    function buyTokens() public payable {
        require(msg.value > 0, "Send ETH to buy tokens");
        uint256 tokens = calculateTokens(msg.value);
        userTokenBalance += tokens;
    }
﻿
    // ...
}
Combining ModifiersAlex understands that modifiers can be combined:
Solidity
contract Example {
    uint256 private data = 42;
﻿
    // Combination: external + view. Doesn't change state and can only be called from outside
    function getData() external view returns (uint256) {
        return data;
    }
﻿
    // Combination: public + payable. Can be called inside and outside, and function can accept ETH
    function deposit() public payable {
        // Function is accessible to everyone AND can receive payments
    }
﻿
    // Combination: internal + pure. Call only from inside, doesn't read or change state
    function helper(uint256 x) internal pure returns (uint256) {
        return x * 2;
    }
}
Examples of Different Function TypesAlex tries to create different types of functions:
Pure Functions (Pure Calculations)Solidity
function cube(uint256 input) public pure returns (uint256) {
    // Only calculate value based on arguments. Don't read or change contract state variables.
    uint256 output = input * input * input;
    return output;
}
View Functions (Data Reading)Solidity
contract Calculator {
    uint256 public lastResult;
﻿
    function getLastResult() public view returns (uint256) {
        return lastResult;  // Only read, don't change
    }
}
State-Changing FunctionsSolidity
contract Counter {
    uint256 public count;
﻿
    function increment() public {
        count = count + 1;  // Change contract state
    }
}
Payable Functions (Receiving Payments)Solidity
contract Donation {
    uint256 public totalDonations;
﻿
    function donate() public payable {
        totalDonations += msg.value;  // Receive and account for payment
    }
}
He writes the first example:
Solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
﻿
contract HelloWorld {
    string public message = "Hello, World!";
﻿
    // Function to change the message
    function setMessage(string memory newMessage) public {
        message = newMessage;
    }
﻿
    // Function to get the message
    function getMessage() public view returns (string memory) {
        return message;
    }
}
Now any user can call the setMessage function and change the message in the contract. The contract can not only store the message, but also change it, and also return the current value.
A Contract You Can Interact WithAlex gets inspired and decides to try adding interaction. He wants anyone to be able to change something in the contract. For example, increment a counter:
Solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
﻿
contract Counter {
    uint256 public counter = 0;  // Variable stored in the blockchain
﻿
    function incrementCounter() public {
        counter = counter + 1;  // Users can increment the counter
    }
}
— "Now my contract works like a visitor counter. Any user can call the incrementCounter() function and report that they visited the site!"
He smiles:
— "Without functions, a contract is like a museum. You can look, but you can't touch anything. With them, it becomes a real tool."
Alex decides to try deploying the contract to the blockchain to see how it works. The contract was deployed at address 0xcF62FF514e60f05eA36c3e7D27AB51932a61599A. Alex went to look at etherscan to see what it looks like – https://sepolia.etherscan.io/address/0xcF62FF514e60f05eA36c3e7D27AB51932a61599A#code.
On the page he saw a lot of interesting things. There was the contract code described and lots of different information. But the most interesting was in the Read Contract and Write Contract tabs.
In Read Contract he saw the counter variable and its value, which was equal to 0.
Counter variable visualization
﻿
In Write Contract he saw the incrementCounter function and a button to call it.
incrementCounter function visualization
﻿
By clicking the Write button, a transaction to the contract will be created to execute the incrementCounter function and the counter variable value will increase by 1.
Practical AssignmentNow Alex wanted to combine everything he learned:
— "I want to implement a contract that will store a value — a counter. Anyone can add one to it. Or subtract. Or reset it."
Alex sat down to write code intensively. After several hours he finally finished. Overjoyed, he jumped up from his chair and knocked over coffee on his laptop. Part of the code was lost. What a horror!
Help Alex fix the broken counter. Your task is to fix the contract with a counter variable and functions.
Практические задания
Загрузка...
Additional MaterialsOfficial Documentation﻿Solidity by example - Functions﻿
﻿Solidity Documentation - Functions — complete guide to functions in Solidity
﻿Solidity Documentation - Data Location — explanation of storage, memory and calldata

Modifier	Read State	Change State	Receive ETH	Gas Cost	Creates Transaction
`view`	✅ Yes	❌ No	❌ No	0 (free)	❌ No
`pure`	❌ No	❌ No	❌ No	0 (free)	❌ No
`payable`	✅ Yes	✅ Yes	✅ Yes	Has cost	✅ Yes
Regular	✅ Yes	✅ Yes	❌ No	Has cost	✅ Yes

Скидки на «Starter» и «Pro» до

Выбрать тариф

Functions — Contract ActionsNext, Alex moves on to functions:
— "Variables are the passive part. Functions are the active part. They're like buttons. You press them — and something happens."
Functions
﻿
TermsFunction — a block of code that performs a specific task. Can accept input parameters and return a result. Functions allow users to interact with the contract and change its state. A function can be called in a transaction on the blockchain.
Function parameters — input data that a function receives to work with. Each parameter has a type and name. They allow passing information to the function for processing.
Return value — data that a function gives as the result of its work. Specified using the returns keyword and data type.
Pure function — a function that doesn't read or modify the contract's state. Performs only calculations with passed parameters. Marked with the pure modifier.
View function — a function that can read the contract's state but cannot modify it. Used to retrieve data without creating transactions. Marked with the view modifier.
Payable function — a function that can receive cryptocurrency payments along with the call. Marked with the payable modifier. Received funds are added to the contract's balance.
What is a Function?Alex thinks about the concept of a function:
— "A function is like a 'black box'. You give it input data, some manipulations happen inside, and you get a result at the output. I don't need to know how exactly it works inside — the main thing is to understand what task it solves and what result it returns."
Function as black box
﻿
For example, when Alex calls the function multiply(5, 3), he knows he will get 15, but he doesn't necessarily need to know how exactly the multiplication happens inside the function.
Solidity
// Input: two numbers → Black box (function) → Output: product of numbers
function multiply(uint256 a, uint256 b) public pure returns (uint256) {
    return a * b;  // Internal logic is hidden from the user
}
Function DeclarationFunction declaration begins with the keyword function. Then the function name and parameters in parentheses. Then visibility modifiers, followed by the return type.
Let's break down the function piece by piece:
Solidity
function setTokenPrice(uint256 newPrice) public returns (bool) {
    //     ↑             ↑                      ↑         ↑
    //   name        parameters             modifiers   what it returns
﻿
    // function body - what it does.
    // Here – assigns a new value to a state variable
    tokenPrice = newPrice;
﻿
    // return value
    return true;
}
Function Structure in SolidityAlex studies the anatomy of a Solidity function:
Solidity
function function_name(parameter_type parameter_name) modifiers returns (return_type) {
    // function body
﻿
    // return value
    return value;
}
1. Function Name— "The name should clearly describe what the function does. calculateArea is better than just calc."
2. Parameters (Input Data)— "This is data that the function receives to work with. Each parameter has a type and name."
Solidity
function transferTokens(address to, uint256 amount, string memory reason) public {
    //                    ↑        ↑               ↑
    //                  address  amount      transfer reason
}
3. Visibility and Behavior Modifiers— "They define who can call the function and its behavior type. If not specified, default modifiers will be used."
4. Return Type— "This is the data type that the function returns as the result of its work."
Solidity
function getBalance(address user) public view returns (uint256) {
    //                                               ↑
    //                                         returns a number
    return balances[user];
}
5. Function Body— "Here the logic is described — what exactly is executed when the function is called."
Why Do We Need Functions?Alex understands that functions solve several important tasks:
1. Code Organization— "When code is broken down into functions, each performing one small task, it's much easier to understand and maintain."
Solidity
contract TokenContract {
    // Instead of one huge function — many small and understandable ones
    function validateTransfer(address from, address to, uint256 amount) internal pure returns (bool) {
        // Transfer validation
    }
﻿
    function updateBalances(address from, address to, uint256 amount) internal {
        // Balance updating
    }
﻿
    function transfer(address to, uint256 amount) public {
        require(validateTransfer(msg.sender, to, amount), "Invalid transfer");
        updateBalances(msg.sender, to, amount);
    }
}
2. Simplified Understanding— "I don't need to know how a function works inside. The main thing is understanding what it does. It's like using a calculator: it doesn't matter how it's built, what matters is that it calculates correctly."
3. Reuse— "If I need to do the same actions in different parts of the program, I can write one function and use it many times."
Solidity
contract GameContract {
    function calculateDamage(uint256 baseDamage, uint256 multiplier) public pure returns (uint256) {
        return baseDamage * multiplier / 100;
    }
﻿
    function swordAttack(uint256 strength) public pure returns (uint256) {
        return calculateDamage(strength, 120);  // Reusing the function
    }
﻿
    function magicAttack(uint256 intelligence) public pure returns (uint256) {
        return calculateDamage(intelligence, 150);  // And reusing again
    }
}
Function Features in BlockchainAlex asks an important question:
— "How do functions in blockchain differ from regular functions in other programming languages?"
After studying the documentation, he understands the key differences:
1. Connection with TransactionsIn blockchain, each function call that changes the contract state creates a transaction:
State-changing functions (without view/pure) → create a transaction, cost gas, changes are written to blockchain forever
View/Pure functions → executed locally, free, don't create transactions
Solidity
contract Example {
    uint256 public counter;
﻿
    // Creates a transaction! Costs gas, written to blockchain
    function increment() public {
        counter += 1;
    }
﻿
    // Does NOT create a transaction! Free, executed locally
    function getCounter() public view returns (uint256) {
        return counter;
    }
}
2. Execution Cost— "In regular programs, a function executes for free. In blockchain, you need to pay gas for changing data!"
3. Irreversibility— "In a regular program, you can roll back changes or restart. In blockchain, every change is recorded forever!"
4. Publicity— "Any blockchain participant can look at the function code and call public functions. In regular programs, code is often hidden."
The memory Keyword — Where to Store Data?Alex notices something strange in the code:
— "Why does string always have string memory written, but uint256 doesn't? What is this memory?"
He studies the documentation and understands: in Solidity there are different "places" for storing data, like different shelves in a store.
Data Storage Locations:storage — permanent storage (like a database field) — data is saved in the blockchain forever
memory — temporary storage (like RAM in a computer) — data exists only during function execution, you can read and write temporary information
calldata — read-only (like a computer disk without write capability) — data is passed to the function, cannot be changed and is not saved after function execution
Which Types Require memory?The memory keyword needs to be specified only for complex data types:
✅ Require memory:
string — strings
bytes — byte arrays
arrays (uint256[], address[], etc.)
structures (struct)
❌ Do NOT require memory:
uint256, int256 — numbers
bool — boolean values
address — addresses
Why Does This Happen?Alex understands the logic:
— "Simple data types (numbers, addresses) have a fixed size — they always take the same amount of space. The compiler knows where to put them."
— "Complex data types (strings, arrays) have variable size — a string can be 5 characters or 500. Therefore, you need to explicitly specify where to store them."
Examples of Correct Usage:Solidity
// ✅ Correct - string requires memory specification
function setMessage(string memory newMessage) public {
    message = newMessage;
}
﻿
// ✅ Correct - string requires memory when returning
function getMessage() public view returns (string memory) {
    return message;
}
﻿
// ✅ Correct - simple types do NOT require memory
function incrementCounter() public {
    counter = counter + 1;  // uint256 doesn't require memory
}
﻿
// ❌ Error - without memory the compiler won't understand where to store the string
function setMessage(string newMessage) public {  // ERROR!
    message = newMessage;
}
Visibility and Behavior ModifiersIn function declaration there's an important part — modifiers:
— "Modifiers are like 'access settings' for functions. They define two important things: who can call the function (visibility) and how it interacts with blockchain data (behavior)."
He studies two categories of modifiers:
Visibility modifiers (public, private, internal, external) — define where the function can be called from
Behavior modifiers (view, pure, payable) — define how the function works with contract state
— "Understanding modifiers is critical. Wrong visibility can open security vulnerabilities, and wrong behavior can lead to unexpected gas costs."
Visibility ModifiersAlex studies who can call functions:
public - everyone can callFunctions are accessible to everyone: users, other contracts, and inside the contract itself.
Examples of functions usually made public:
Solidity
// Basic balance operations, they may be needed both inside and outside the smart contract
function getBalance() public view returns (uint256) {
    return balance;
}
﻿
// Fund transfer
function transfer(address to, uint256 amount) public {
    // transfer logic
}
﻿
// Account deposit
function deposit() public payable {
    balance += msg.value;
}
﻿
// Getting contract information
function getContractInfo() public view returns (string memory) {
    return "My Smart Contract";
}
private - only functions in the same contract can callAccessible only inside this contract. Even inheriting contracts don't have access.
Examples of functions usually made private:
Solidity
// Internal calculations
function _calculateFee(uint256 amount) private pure returns (uint256) {
    return amount * 3 / 100; // 3% fee
}
﻿
// Checking internal conditions
function _isValidUser(address user) private view returns (bool) {
    return userBalances[user] > 0;
}
﻿
// Resetting internal data
function _resetCounters() private {
    dailyTransactions = 0;
    weeklyLimit = 1000;
}
internal - functions in the same contract and inheriting contracts can callAccessible inside the contract and in inheriting contracts. Not accessible from outside.
Examples of functions usually made internal:
Solidity
// Basic transfer logic that can be extended by inheritors
function _transfer(address from, address to, uint256 amount) internal {
    balances[from] -= amount;
    balances[to] += amount;
}
﻿
// Common checks, can be reused by child contracts
function _validateAmount(uint256 amount) internal pure returns (bool) {
    return amount > 0 && amount < 1000000;
}
﻿
// Initialization for inherited contracts
function _initialize(address owner) internal {
    contractOwner = owner;
    isInitialized = true;
}
external - can only be called from functions in other contractsAccessible only from outside the contract. Cannot be called from inside the contract itself. More economical than public for large data.
Examples of functions usually made external:
Solidity
// Administrative functions
function emergencyStop() external {
    require(msg.sender == admin, "Only admin");
    paused = true;
}
﻿
// Callback functions
function onTokenReceived(address from, uint256 amount, bytes calldata data) external {
    // Called by other contracts
}
﻿
// API for external calls with large data
function processLargeData(uint256[] calldata numbers) external {
    // more economical for large arrays
}
Important Difference: Visibility Modifiers for Variables vs FunctionsAlex notices an important feature:
— "Wait! The public modifier for functions doesn't work the same as for variables!"
He studies the documentation and understands the key difference:
For variables public = automatic getter, allowing reading the variable from outside the contract
Solidity
contract Example {
    uint256 public counter = 10;  // Automatically creates:
﻿
    // function counter() public view returns (uint256) {
    //     return counter;
    // }
}
For functions public = ability to call the function from outside the contract, by users or other contracts
Solidity
contract Example {
    function incrementCounter() public {  // Can be called from outside AND inside
        // function logic
    }
﻿
    function internalHelper() internal {  // Only from inside the contract
        incrementCounter();  // This works
    }
}
Important conclusion: The visibility modifier of a function has significantly greater importance for contract security than the visibility modifier of a variable. Wrong function visibility can open critical vulnerabilities — for example, if a private administrative function is accidentally declared as public, attackers will be able to call it. While wrong variable visibility most often leads only to unwanted data disclosure, but not to loss of contract control.
Behavior ModifiersBehavior modifiers define how a function interacts with contract data and blockchain:
— "It's like different operating modes. Some functions can do everything — read, write, receive money. Others — only read. And third ones — don't access anything at all, only calculate."
view - read-only dataFunctions can read data from the blockchain but cannot change it. Free when called directly, not from another function.
Examples of view functions:
Solidity
// Getting user balance
function getBalance(address user) public view returns (uint256) {
    return balances[user];
}
﻿
// Checking permissions
function isOwner(address user) public view returns (bool) {
    return user == owner;
}
﻿
// Getting blockchain information
function getCurrentTime() public view returns (uint256) {
    return block.timestamp;
}
﻿
// Calculations based on current data
function calculateInterest(address user) public view returns (uint256) {
    return balances[user] * interestRate / 100;
}
pure - no state accessFunctions don't read or change contract data. Work only with passed parameters.
Examples of pure functions:
Solidity
// Mathematical calculations
function add(uint256 a, uint256 b) public pure returns (uint256) {
    return a + b;
}
﻿
// Interest calculation
function calculateInterest(uint256 amount, uint256 rate) public pure returns (uint256) {
    return amount * rate / 100;
}
﻿
// String operations
function concatenate(string memory a, string memory b) public pure returns (string memory) {
    return string(abi.encodePacked(a, " ", b));
}
﻿
// Data validation
function isValidEmail(string memory email) public pure returns (bool) {
    bytes memory emailBytes = bytes(email);
    return emailBytes.length > 5; // Simplified check
}
payable - can receive paymentsFunctions can receive ETH — blockchain currency along with the call. Without payable, sending ETH will result in an error.
Examples of payable functions:
Solidity
// Account deposit
function deposit() public payable {
    balances[msg.sender] += msg.value; // msg.value - sent ETH amount
}
﻿
// Item purchase
function buyItem(uint256 itemId) public payable {
    require(msg.value >= itemPrices[itemId], "Insufficient payment");
    // Purchase logic
}
﻿
// Donations with message
function donate(string memory message) public payable {
    require(msg.value > 0, "Donation must be greater than 0");
    totalDonations += msg.value;
}
﻿
// Constructor can be payable
constructor() public payable {
    owner = msg.sender;
    // Can send ETH during deployment
}
Comparing Behavior ModifiersAlex creates a table for better understanding:
Modifier
Read State
Change State
Receive ETH
Gas Cost
Creates Transaction
view
✅ Yes
❌ No
❌ No
0 (free)
❌ No
pure
❌ No
❌ No
❌ No
0 (free)
❌ No
payable
✅ Yes
✅ Yes
✅ Yes
Has cost
✅ Yes
Regular
✅ Yes
✅ Yes
❌ No
Has cost
✅ Yes
Practical Example: Token Sale ContractAlex decides to create a complete example that will show all studied modifiers in action. He develops a contract for token sales:
— "Great idea! I'll make a contract where users will be credited with internal balance for deposited ETH. All modifiers will be useful here: pure for calculations, view for checking balances, payable for receiving payments!"
Solidity
contract TokenSaleVault {
    uint256 public tokenPrice = 0.001 ether;
    uint256 public userTokenBalance;
﻿
    // Pure: we don't read state variables
    function calculateTokens(uint256 ethAmount) public pure returns (uint256) {
        return ethAmount / 0.001 ether;
    }
﻿
    // View: only reading state variable – balances[user]
    function getBalance(address user) public view returns (uint256) {
        return userTokenBalance;
    }
﻿
    // Payable: receiving payment and changing state
    function buyTokens() public payable {
        require(msg.value > 0, "Send ETH to buy tokens");
        uint256 tokens = calculateTokens(msg.value);
        userTokenBalance += tokens;
    }
﻿
    // ...
}
Combining ModifiersAlex understands that modifiers can be combined:
Solidity
contract Example {
    uint256 private data = 42;
﻿
    // Combination: external + view. Doesn't change state and can only be called from outside
    function getData() external view returns (uint256) {
        return data;
    }
﻿
    // Combination: public + payable. Can be called inside and outside, and function can accept ETH
    function deposit() public payable {
        // Function is accessible to everyone AND can receive payments
    }
﻿
    // Combination: internal + pure. Call only from inside, doesn't read or change state
    function helper(uint256 x) internal pure returns (uint256) {
        return x * 2;
    }
}
Examples of Different Function TypesAlex tries to create different types of functions:
Pure Functions (Pure Calculations)Solidity
function cube(uint256 input) public pure returns (uint256) {
    // Only calculate value based on arguments. Don't read or change contract state variables.
    uint256 output = input * input * input;
    return output;
}
View Functions (Data Reading)Solidity
contract Calculator {
    uint256 public lastResult;
﻿
    function getLastResult() public view returns (uint256) {
        return lastResult;  // Only read, don't change
    }
}
State-Changing FunctionsSolidity
contract Counter {
    uint256 public count;
﻿
    function increment() public {
        count = count + 1;  // Change contract state
    }
}
Payable Functions (Receiving Payments)Solidity
contract Donation {
    uint256 public totalDonations;
﻿
    function donate() public payable {
        totalDonations += msg.value;  // Receive and account for payment
    }
}
He writes the first example:
Solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
﻿
contract HelloWorld {
    string public message = "Hello, World!";
﻿
    // Function to change the message
    function setMessage(string memory newMessage) public {
        message = newMessage;
    }
﻿
    // Function to get the message
    function getMessage() public view returns (string memory) {
        return message;
    }
}
Now any user can call the setMessage function and change the message in the contract. The contract can not only store the message, but also change it, and also return the current value.
A Contract You Can Interact WithAlex gets inspired and decides to try adding interaction. He wants anyone to be able to change something in the contract. For example, increment a counter:
Solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
﻿
contract Counter {
    uint256 public counter = 0;  // Variable stored in the blockchain
﻿
    function incrementCounter() public {
        counter = counter + 1;  // Users can increment the counter
    }
}
— "Now my contract works like a visitor counter. Any user can call the incrementCounter() function and report that they visited the site!"
He smiles:
— "Without functions, a contract is like a museum. You can look, but you can't touch anything. With them, it becomes a real tool."
Alex decides to try deploying the contract to the blockchain to see how it works. The contract was deployed at address 0xcF62FF514e60f05eA36c3e7D27AB51932a61599A. Alex went to look at etherscan to see what it looks like – https://sepolia.etherscan.io/address/0xcF62FF514e60f05eA36c3e7D27AB51932a61599A#code.
On the page he saw a lot of interesting things. There was the contract code described and lots of different information. But the most interesting was in the Read Contract and Write Contract tabs.
In Read Contract he saw the counter variable and its value, which was equal to 0.
Counter variable visualization
﻿
In Write Contract he saw the incrementCounter function and a button to call it.
incrementCounter function visualization
﻿
By clicking the Write button, a transaction to the contract will be created to execute the incrementCounter function and the counter variable value will increase by 1.
Practical AssignmentNow Alex wanted to combine everything he learned:
— "I want to implement a contract that will store a value — a counter. Anyone can add one to it. Or subtract. Or reset it."
Alex sat down to write code intensively. After several hours he finally finished. Overjoyed, he jumped up from his chair and knocked over coffee on his laptop. Part of the code was lost. What a horror!
Help Alex fix the broken counter. Your task is to fix the contract with a counter variable and functions.
Практические задания
Загрузка...
Additional MaterialsOfficial Documentation﻿Solidity by example - Functions﻿
﻿Solidity Documentation - Functions — complete guide to functions in Solidity
﻿Solidity Documentation - Data Location — explanation of storage, memory and calldata