The following article is based on Adam’s CharmingData channel and GitHub repository.

In this tutorial, we will create, test, and deploy a smart contract called SimpleStorage. This contract will allow your users to create their own sentence and store it on the blockchain. It will also allow users to retrieve the last sentence stored and display it on the page.

Consider the following Solidity contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

contract SimpleStorage {
    // Define a string called storeTheSentence. This is a state variable, which will be permanently stored in the blockchain.
    string storeTheSentence;

    constructor(string memory initialSentence) {
        // Assign the value of initialSentence to the storeTheSentence variable
        storeTheSentence = initialSentence;
    }

    // Declares a function called getSentence
    // Solidity funcions visibility: public, private, internal and external
    // Solidity view functions: https://www.geeksforgeeks.org/solidity-view-and-pure-functions/
    function getSentence() public view returns (string memory) {
        return storeTheSentence;
    }

    // Declare a function called setSentence
    // The function takes 1 input parameter, a string named newSentence, with the calldata data location in the Ethereum Virtual Machine
    function setSentence(string calldata newSentence) external {
        // Assign the value of newSentence to the storeTheSentence variable
        storeTheSentence = newSentence;
    }
}

This is a simple smart contract written in Solidity, the most popular programming language for implementing smart contracts on the Ethereum blockchain. The contract’s name is SimpleStorage, and it primarily focuses on storing and retrieving a string (a sequence of characters).

Here’s a brief breakdown of the contract:

1. State variable (storeTheSentence): This is a string variable that will store a sentence. This variable’s value is stored on the blockchain, making it a permanent, unerasable record.
2. Constructor function: When the contract is first deployed to the Ethereum blockchain, the constructor function is executed once. This function accepts one argument, a string (initialSentence), and assigns its value to the state variable storeTheSentence.
3. getSentence() function: This function is a public view function, which means anyone can call it to read the value of storeTheSentence without changing any data or state in the contract. It does not cost any gas to call this function because it doesn’t change the state of the blockchain.
4. setSentence() function: This function is declared as external, meaning it can only be called from outside the contract. It accepts one string argument (newSentence) and assigns its value to storeTheSentence, effectively updating the stored sentence. As this function modifies the state of the contract, it requires a transaction to be sent and will cost gas to execute.

In essence, this contract allows anyone to store a sentence on the Ethereum blockchain and retrieve it. Due to the permanent and public nature of blockchain storage, the stored sentence would be visible to anyone and cannot be erased or modified once set (except by calling the setSentence function again).

Let’s learn how to set it up in a step-by-step manner next.

Backend

1. Open the terminal (command line), create two new folders called simple-storage and backend. Go into the backend folder.

mkdir simple-storage
cd simple-storage
mkdir backend
cd backend

2. Set up a Hardhat project. Install the necessary libraries, by typing in the terminal:

npm init --yes
npm install --save-dev --save-exact hardhat@2.14.0
npm install dotenv

3. This library might be necessary to install as well, especially if you’re a Windows user:

npm install --save-dev @nomicfoundation/hardhat-toolbox@2

4. Make sure you are still in the backend directory. Now, create a sample contract project by typing in the terminal:

npx hardhat

• Select Create a Javascript Project. Don’t change anything in the Hardhat project root, just click enter. Yes, add a .gitignore.

5. Open the backend folder and remove any present contracts inside the contracts folder. Insert your SimpleStorage contract.
6. Now, inside the scripts folder, replace the contect of the deploy.js file with the deploy.js code from this project.
7. Create a .env file inside the backend folder. This will be used to store your wallet key and your Quicknode endpoint. A QuickNode API endpoint gives you quick access to a network of nodes.

• Add these two lines inside the .env file, and update the content inside the quotation marks:

QUICKNODE_HTTP_URL="your-quicknode-http-provider-goes-here-inside-the-quotation-marks"
PRIVATE_KEY="your-wallet-private-key-goes-here-inside-the-quotation-marks"

8. Open the hardhat.config.js file inside the backend folder and replace its content with the hardhat.config.js code from this project.
9. Compile your Contract by going back to your terminal (ensure you are in the backend directory). And type:

npx hardhat compile

• Every time you modify your contract (SimpleStorage), you will have to repeat the above compile step.

10. With your contract compiled, now we can deploy it to the sepolia testnet. In your terminal type:

npx hardhat run scripts/deploy.js --network sepolia

Save the contract address that was printed out. Go to https://sepolia.etherscan.io/ and insert the contract address into the Explorer input field. Take some time to explore the transaction details of your contract.

• Save this address somewhere. Don’t lose it!

Testing

Every Contract should be tested before deployment. In this case we deployed first becuause it’s freaking exciting to see our contract deployed. But we need tests to make sure our contract has no bugs and is secure.

1. Open the test folder and remove any present files inside of it. Create a new file called testing.js, and insert the testing.js code from this project.
2. Go back to the terminal, make sure you’re in the backend directory, and type:

npx hardhat test

Frontend

In this section of the tutorial we’ll create a dApp (decentralized app) that will connect to your contract and its functions, allowing you to interact with it. In other words, we’re building an interface for the contract.

1. Open the terminal (command line) and go into the simple-storage directory. Create a sample Next app by typing:

npx create-next-app@13 frontend

• Make sure to choose these settings.

2. Before running the sample app, you’ll need to remove the .git file that was automatically created inside the new frontend folder. To remove the file, type this command inside the terminal:

# Linux / macOS
cd frontend
rm -rf .git

# Windows
cd frontend
rm -r -fo .git

3. Install these packages using your terminal (you should still be in the frontend directory).

npm install web3modal
npm install ethers@5

4. Create a new folder called constants within the frontend directory. Inside the constants folder create a new file called index.js. Add the following code inside index.js.

export const MY_CONTRACT_ADDRESS = "MY_CONTRACT_ADDRESS";
export const abi = MY_ABI;

• Replace the MY_ABI with the abi array that can be found in the following file: backend/artifacts/contracts/SimpleStorage.json
• Replace the MY_CONTRACT_ADDRESS with the address of the contract that you deployed in the Backend section of this tutorial.

5. Finally, to build the interface of the contract, open the index.js file under the pages folder (in the frontend folder) and replace its content with the index.js code from this project.
6. Add the Charming Data images using the instructions below. Once you understand how to add images to your app, feel free to replace with your own images, in which case you would need to update the images’ names inside the pages/index.js file (lines 143 & 154)

• Add the logo-charmingdata-small.ico and logocharmingdata.png to the public folder inside the frontend directory. Do not change image names.

7. Go back to your terminal; make sure your in the frontend directory and type:

npm run dev

Sharing your dApp with others

We will use Vercel to deploy the frontend of our contract. Before starting with Vercel you will need to create a GitHub account if you don’t have one and push your code into a GitHub repository:

1. Once your repositoy has been created in Github, go to Vercel and create an account by connecting your GitHub account.
2. Once your GitHub account is connected, click the button to add a new project in Vercel.

• add your repository (you might have to import it as well)

3. Select Next.js as the Framework Preset. In the Root Directory click Edit to select frontend.
4. Click Deploy, and wait a few minutes. When done, click your domain link to see your dApp.

The previous text was originally written by Adam from CharmingData.

The post Smart Contract to Store a Sentence on ETH appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation. We’ll base this article on the original Solidity programming language content.

Conceptual Overview

A constructor is a Solidity language feature that makes it possible to attach a specific behavior, i.e., a function, to the beginning of the smart contract lifecycle. It is executed only once – when a contract’s instance is created. A constructor is the right place to define the contract initialization code.

The initialization cycle starts with the state variables: in case of an inline initialization, they are set to their explicitly specified values. Otherwise, the state variables are set to their type-determined default value when inline initialization is omitted. The next step of the initialization cycle is the execution of the constructor code.

After the constructor execution concludes, the final code of the contract is ready and deployed to the blockchain. This is a good place for us to discuss the cost of the contract deployment, which is proportional to the length of the code.

When we say “code”, we imply all the functions that make up the public interface, i.e., functions whose visibility modifiers are public or external.

Besides, all the functions can be reached via function calls through the public interface functions. In contrast, the contract cost does not include the constructor code or the functions only called from the constructor and whose visibility is set to internal.

Recommended: Solidity Function Calls – Internal and External

Default Constructor

As with most of our examples in previous articles, if we omit the constructor, the compiler will imply there’s a default constructor, which has no arguments and no body: constructor() {}, as showcased in this simple example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;

contract A {

    // A default constructor can be omitted.
    constructor() {}
}

The sole purpose of a default constructor is to initialize the state variables with their default, type-dependant values.

Note: Don’t forget to include the pragma directive before trying each of the following examples; I’m deliberately omitting it to avoid unnecessary code duplication.

Regular Constructor

First, we’ll take a look at a simplified example of a constructor that initializes the state variables to fixed values through a process called inline initialization:

contract A {
    uint public a;

    constructor() {
        a = 5;
    }
}

In this example, our state variable A is initialized to a fixed value of 5. Of course, this approach is excessive since we could have gotten exactly the same effect simply by doing the following:

contract A {
    uint public a = 6;
}

However, these two examples are hard-coded and don’t demonstrate the real usefulness of constructors, but I showed them for the sake of completeness and better understanding. The following example will start to unveil the true versatility and purpose behind using constructors:

contract A {
    uint public a;

    constructor(uint a_) {
        a = a_;
    }
}

contract B {
    A contract_A = new A(22);
    uint public a = contract_A.a();
}

Although more complex, this example shows how to declare a constructor that takes an argument via its parameter uint _a. This way, we can dynamically instantiate our contract, and that’s where the true power of parametrized constructors lies.

First, we declared contract A with a parametrized constructor. Then, we declared a new contract B in which we created an instance of contract A called contract_A by passing it argument 22. Finally, we assigned the value of the state variable contract_A.a to the state variable b by calling its getter function to confirm that contract_A is dynamically instantiated to the value of the given argument.

An even nicer, elegant example with the same effect can be achieved simply by deriving contract B from contract A by giving it an argument:

contract A {
    uint public a;

    constructor(uint a_) {
        a = a_;
    }
}

contract B is A(22) {
}

Conclusion

In this article, we learned about contract constructors.

First, we made a conceptual overview of a constructor in Solidity.

Second, we explained what a default constructor is.

Third, we showed how regular constructors can be declared and used through several illustrative, simple examples.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Function Constructors – A Helpful Simplified Guide with Video appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation. We’ll base this article on the original Solidity programming language content.

Overview

Function overloading is a feature that enables us to define more than one function with the same name but with different combinations of function parameters in terms of their number and type.

Roughly speaking, we’d usually go with the function overloading approach when we need:

• Different variants of the same base functionality or business logic, i.e. a function performing the addition of integers vs floating-point numbers;
• Specialized versions of one generalized base functionality, i.e., a function adding two integers instead of ten integers. In this case, a specialized version of the base functionality can be considered a function wrapper because it contains a call to the base function with some parameters commonly hardcoded to default values.

Note: In a sense, overloading can also be applied to inherited functions, but in that case, we refer to it as function overriding. When a function overrides an inherited function, it has the same signature as the overridden function, i.e., the same function name, parameter number, and parameter type. Effectively, the overriding function redefines the inherited (base) function behavior, but only on a sub-class level.

With that said, let’s just remember that function overloading produces more variants of the same-name function, while function overriding just redefines an inherited function.

Function overloading cannot be achieved by renaming the function parameters, i.e., function parameter names don’t affect the function signature and cannot produce an overloaded function.

Example – Function Overloading

The following example shows how function overloading works. As we always do, we’ll analyze it segment by segment.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

A regular contract defines two functions with the same name, but with a different number of parameters and parameter types.

contract A {

The first function f takes only one parameter, value, of type uint. The function behavior is extremely simple: it just returns the received parameter value by assigning it to the output parameter out.

    function f(uint value) public pure returns (uint out) {
        out = value;
    }

The second function f takes one more parameter, really, of type bool, but also keeps the same parameter from the first function f definition, value.

The function behavior is just a shade more complex: it conditionally returns the received parameter value by assigning it to the output parameter out, i.e., if the parameter really is set to true.

Otherwise, the parameter out returns the default value, determined from its variable type uint, which is 0.

    function f(uint value, bool really) public pure returns (uint out) {
        if (really)
            out = value;
    }
}

Example – Function Overloading in External Interface

Before we analyze another example of function overloading specific to external interfaces, let’s shortly discuss what’s so special about external interfaces.

Functions in external interfaces introduce two kinds of types: Solidity types and external (ABI) types. For instance, Solidity can have multiple address types, such as contract and address. However, from the ABI perspective, the mentioned types are regarded as the same type, which would cause an error during the compilation if used in an overloading attempt, as in our example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

A very simple example showing an attempted function overloading with different Solidity types, but the same (after compilation) ABI types.

contract A {

Input and output type B is contract type from the Solidity perspective, but it’s also address type from an ABI perspective.

    function f(B value) public pure returns (B out) {
        out = value;
    }

Input and output parameter types address are the same from the Solidity perspective and from the ABI perspective in both overloaded functions.

    function f(address value) public pure returns (address out) {
        out = value;
    }
}

Declares the placeholder contract B for parameter typing purposes.

contract B {
}

After compilation, both functions are declared as public (public =  external + internal), take the same overloaded form and therefore cause an error, since they both have input and output parameter types declared as address, hence causing improper overloading from ABI (compiler output) perspective:

TypeError: Function overload clash during conversion to external types for arguments.

Implementation

Now that we know what function overloading is, let’s see how it works.

A function call to an overloaded function is resolved by the function name and argument matching, meaning the right function in the current scope is selected depending on its name and the arguments in the function call.

Specifically, overloaded functions are selected as candidates if their arguments are implicitly convertible to the expected parameter types. Of course, if the function parameter conversion fails for only one parameter, the resolution fails and the function candidate is entirely dismissed.

Note: Function return parameters (types) are not part of the function resolution process.

To make the story of implicit conversion more clear, we’ll look at the example below:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;

contract A {
    function f(uint8 val) public pure returns (uint8 out) {
        out = val;
    }

    function f(uint256 val) public pure returns (uint256 out) {
        out = val;
    }
}

In this example, we have a function f overloaded in two instances: the first instance takes and returns a variable of uint8 type, while the other instance takes and returns a variable of uint256 type.

A call f(50) would return a type error because it’s ambiguous, i.e., it cannot precisely determine the right function instance since the argument 50 can be implicitly converted to match both functions. However, when we make a call f(256), a function f(uint256) is the only one that matches the result of the implicit conversion of argument 256, so this call proceeds without any errors.

Conclusion

This article taught us about function overloading and compared it with function overriding.

First, we made an overview to understand what we’re talking about.

Second, we went through an example showing how function overloading looks in its simplest form.

Third, we studied a bit more complex example of function overloading with regard to external interfaces.

Fourth, we went into just a bit more detail, showing how the overloaded function resolution works under the hood.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Function Overloading appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion, or a supplement to the official Solidity documentation.

Overview

The purpose behind a fallback function, as the name suggests, is to serve as a function that executes when:

• A contract receives a call but cannot match any other function by the function signature;
• When no data is supplied with the contract call and the contract doesn’t have the receive Ether function.

In a way, we can consider a fallback function as a default function that gets executed in the situations listed above.

Implementation

A fallback function must be declared with external visibility. One more important and potentially needed option is declaring a fallback function as virtual, meaning it can be overridden in an inheriting contract.

Declaring a fallback function as payable is possible, but not necessary; we’d declare it as payable only if the function must be able to receive Ether.

Recommended: What is “payable” in Solidity?

However, it’s a better practice to always define a receive() function, even if we do have a fallback() function. In such case, a fallback function would be used only for otherwise unmatched function calls. A fallback function can also use function modifiers.

A smart contract can have at most one fallback function declared in one of the two following forms, both omitting the keyword function which we’d usually use when defining an ordinary function:

fallback() external [payable]

or

fallback(bytes calldata input) external [payable] returns (bytes memory output)

If we use the second form of a fallback function declaration instead of a receive Ether function, input will contain the full data sent to the contract (equal to msg.data) and it will return msg.data in output (check the console log after calling the function). The returned data will not be ABI-encoded and will be returned in the original form (without padding).

Note: If a fallback function is activated when a contract is called from a .send() or .transfer() function, it will be limited to at most 2300 gas, which allows only basic logging. The same goes for the receive() function in the previous article.

Operations consuming more than 2300 gas are:

• writing to storage,
• creating a contract,
• calling an external function that consumes a large amount of gas, and
• sending Ether.

They can only execute if the fallback function is called by the low-level .call function.

In general, a fallback function can do anything, including some complex operations. The only condition is that enough gas is available to execute the operations.

Recommended: Introduction to Ethereum’s Gas in Solidity Development

Warning: A payable fallback function also enables our contract to receive Ether when a receive Ether function is missing. Regardless, it is recommended to implement a receive Ether function as it will specifically handle the Ether transfers. The fallback function will only be used for “interface confusion” cases, i.e., when a contract receives a function call to a non-existing function.

To decode the input data of a function, we can check the first four bytes which represent the function selector and are compared to available function signatures. Then, we can use abi.decode(...) function combined with the array slice syntax for decoding the ABI-encoded (Abstract Binary Interface) data:

(c, d) = abi.decode(input[4:], (uint256, uint256));

However, we shouldn’t be comfortable with this approach and use it only when no other is available. Instead, we should rather use available functions.

Example – The Source Code

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.2 <0.9.0;

contract Test {
    uint x;
    fallback() external { x = 1; }
}

contract TestPayable {
    uint x;
    uint y;
    fallback() external payable { x = 1; y = msg.value; }
    receive() external payable { x = 2; y = msg.value; }
}

contract Caller {
    function callTest(Test test) public returns (bool) {

        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);

        address payable testPayable = payable(address(test));

        return testPayable.send(2 ether);
    }

    function callTestPayable(TestPayable test) public returns (bool) {
        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);

        (success,) = address(test).call{value: 1}(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);

        (success,) = address(test).call{value: 2 ether}("");
        require(success);

        return true;
    }

    receive() external payable {}
}

Example – The Fallback Function

Let’s look at the contract example, showing what a fallback function looks like.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.2 <0.9.0;

contract Test {
    uint x;
    fallback() external { x = 1; }
}

The fallback function will execute every time since no other function is declared, i.e., no function signature would match a function call.

Also, if we try sending Ether to this contract, an exception will be thrown since the fallback function is not defined as payable and it cannot receive Ether.

This can be fixed in two steps:

1. Change the external keyword to external payable;
2. Remove x = 1; because this operation takes more than 2300 gas available.

We won’t make the change here, but in case you want to play with it, that’s how you can do it.

Example – Fallback Function + receive Ether Function

This time, let’s look at a contract example showing a fallback function and a receive Ether function, according to the recommendation on a good way to structure our smart contract projects.

contract TestPayable {
    uint x;
    uint y;

The fallback function is called for all unmatched function messages sent to this contract, except for plain Ether transfers (only when there’s a receive function).

fallback() external payable { x = 1; y = msg.value; }

Plain Ether transfers are calls with empty calldata and are processed by the receive function.

receive() external payable { x = 2; y = msg.value; }
}

In this example, we’ll build on both of the two previous examples and show how calls to the two examples differ.

contract Caller {
    function callTest(Test test) public returns (bool) {

The test parameter receives an argument, i.e., a destination contract address.

Then, a call to the non-existing function is deliberately made. A tuple is returned: the first part of the result is stored in the success variable, while the rest is discarded.

The fallback() function will execute, and the function call will complete with the success variable set to true.

    (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
    require(success);

Before we can call the send() function on the contract address received via parameter test, we must convert it from the address type to the address payable type.

This will allow us to call the send() function from the caller’s side, but the call itself will fail on the callee’s side because the fallback() function isn’t declared as payable, i.e., it cannot receive Ether.

    address payable testPayable = payable(address(test));
    return testPayable.send(2 ether);
}

In contrast to the previous callTest() function, the callTestPayable() function can successfully send Ether to the destination contract because the answering functions are both declared as payable.

function callTestPayable(TestPayable test) public returns (bool) {

The test parameter receives an argument, i.e., a destination contract address. Then, a call to the non-existing function is deliberately made.

We use different hard-coded values in all three calls to distinguish when a receive() function is executed (hard-coded value test.x = 2) instead of the fallback() function (hard-coded value test.x = 1).

Our receive() and fallback() functions both receive Ether and write to storage (x and y variables). As writing to storage requires more than 2300 gas, we wouldn’t be able to do both with send() function but instead had to use the low-level call() function.

The next function call is also with calldata, so a fallback() function is executed; test.x becomes = 1 (hard coded), and test.y becomes = 0 (a default value, since no value is sent).

A tuple is returned: the first part of the result is stored in the success variable, while the rest is discarded. The fallback() function will execute and the function call will complete with the success variable set to true.

        (bool success,) = address(test).call(abi.encodeWithSignature("nonExistingFunction()"));
        require(success);

The next function call is with calldata, but also with a value, so a fallback function is executed; test.x becomes = 1 (hardcoded assignment in the fallback function) and test.y becomes = 1 (parametrized assignment).

(success,) = address(test).call{value: 1} (abi.encodeWithSignature("nonExistingFunction()"));
require(success);

The next call is without calldata, so the receive function is executed; test.x becomes = 2 (hard-coded assignment in the receive function) and test.y becomes 2000000000000000000 (a parametrized assignment in the amount of Wei units equal to 2 Ether sent as a value).

        (success,) = address(test).call{value: 2 ether}("");
        require(success);
        // results in test.x becoming == 2 and test.y becoming 2 ether.

       return true;

    }
}

Conclusion

In this article, we learned about a fallback function, i.e., what it is, how, and when it’s used.

First, we made an overview of the fallback function.

Second, we learned about how a fallback function is implemented and what its limitations are.

Third, we listed the source code for easier navigation.

Fourth, we viewed a simple fallback function example.

Fifth, we examined a more thorough, complex example combining both a fallback and a receive function.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity’s Fallback Function – A Simple Guide appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion, or a supplement to the official Solidity documentation.

Overview

When our contract receives a transaction without a matching function, a special function called receive() is automatically executed.

Of course, we imply that our contract contains such a function. The contract can receive incoming Ether using this function and execute operations like putting the received amount in a balance or invoking other contract procedures.

We should differentiate the receive() function, which is a callback function, from a fallback function (a point for the upcoming section).

Implementation

A contract may have only one receive Ether function. The function is declared as:

receive() external payable { ... }

Note how we omitted the keyword function.

There are several peculiarities regarding the receive function: it cannot have any arguments, doesn’t return anything, and must have external visibility and payable state mutability.

Besides that, the receive function can be virtual, it can override its base function and also have modifiers.

Note:

A function (also called a base function) that allows an inheriting contract to override its behavior will be marked with a keyword virtual. (source)

A function that overrides that base function should be marked with the keyword override. (source)

Receive Function Properties

The receive function gets executed when a call with empty calldata arguments is made on a contract.

For instance, the receive function is executed on simple, plain Ether transfers, such as the ones made via .send() or .transfer() functions. However, if we didn’t introduce a receive function, but do have a payable fallback function (in more detail in the following article), the fallback function will be activated on a plain Ether transfer.

We can already notice that a fallback function is an alternative to having a receive function. A few paragraphs later, we’ll see if they’re almost equivalent and why. Finally, if we don’t have a receive function or a fallback function, our contract won’t be able to receive Ether via regular transactions and will throw an exception.

There’s a possible confusion between the terms fallback function and callback function, so let’s first get that out of the way:

• A fallback function is executed if (1) none of the other functions match the function identifier, or (2) no data (arguments) was provided with the function call. (source) A fallback function shouldn’t be confused with a callback function.
• A callback function is a function passed as an argument to a called function. After the called function is executed successfully, the callback function gets called. In practice, a callback function construct is commonly used for asynchronous behavior, where we want an activity to take place after the previous event completes. (source)

Operations consuming more than 2300 gas are:

• writing to storage,
• creating a contract,
• calling an external function that consumes a large amount of gas, and
• sending Ether.

They can only execute if the receive function is called by the low-level .call function.

Warnings

Although available, payable fallback methods aren’t recommended for receiving Ether. It’s much better to have a separate receive function for receiving Ether and a fallback function to cover all other cases. This approach will make our debugging easier and enable healthy separation of functionality.

There are two special cases where our contract will be able to receive Ether without a receive function.

It will do so as a recipient of a coinbase transaction, also known as a miner block reward, and as a destination of a keyword selfdestruct.

A contract is not able to react to Ether transfers of this kind and therefore cannot decline them. This is an inherent property stemming from the EVM design choice that Solidity cannot bypass.

The consequence of such implementation may be an unexpected value of address(this).balance, possibly higher than the amount accounted for by the contract logic.

Receive Function Example

In the following example, we’ll see what a contract’s receive function looks like in its simplest form.

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.0 <0.9.0;

contract Sink {

Here we define an event that will be emitted when the receive function is executed.

    event Received(address, uint);

This is the receive function declaration which usually contains more complex logic. In this example, it just emits the event (signal) letting us know that the receive function finished its execution.

    receive() external payable {
        emit Received(msg.sender, msg.value);
    }
}

Conclusion

In this article, we went through the details of receive function in Solidity. We also mentioned its alternative, the fallback function. We learned that the receive function allows us to receive the currency and is the first and the preferred one of the two possible choices for receiving currency.

First, we briefly overview the purpose behind the receive function in Solidity.

Second, we discussed the function implementation, i.e., what syntax we should use.

Third, we took a closer look at the function properties, learned how it works, and got familiar with a few use specifics in the form of warnings.

Fourth, we made a simple example showing how a receive function looks in action.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Receive Ether Function appeared first on Be on the Right Side of Change.

In this article, we will explore the different types of function visibility in Solidity and how the types are used. It’s part of our long-standing tradition to make this (and other) articles a faithful companion, or a supplement to the official Solidity docs for this article’s topic.

Overview

There are four types of function visibility in Solidity:

• public,
• external,
• internal, and
• private.

Public functions are the most permissive, as they can be called by anyone, including other contracts and external users. We declare them using the public keyword, which is the default visibility type if we leave out the visibility specifier keyword. We can imagine public functions as being internal and external at the same time.

External functions are similar to public functions, but they are intended to be called by other contracts rather than external users. They are declared using the external keyword and are useful for defining a contract’s interface, which is the set of functions that other contracts can use to interact with it.

Internal functions are similar to public functions, but they can only be called from within the contract in which they are defined and from the derived contracts. We declare them using the internal keyword and they are useful for separating out functionality only needed within the contract.

Warning: The default function visibility type is public and must not be confused with the default state variable visibility type, which is internal.

Private functions are the most restrictive, as they can only be called from within the contract in which they are defined. They are declared using the private keyword and are useful for hiding implementation details that are not relevant to external users. In contrast to internal functions, private functions cannot be called by the derived contracts, but only within the base contract.

One-Paragraph Summary: We should carefully consider function visibility when designing a contract, as it can significantly affect security and usability. Public functions can be called by anyone, so they should be used sparingly and only for functions that need to be exposed to both external and internal calls. External functions should be used to define the contract’s interface and make it easier for other contracts to interact with it. Internal and private functions can be used to hide implementation details and reduce the attack surface of the contract.

Public Functions

Public functions are part of the contract interface, which enables us to call these functions either internally, i.e. f() or via message calls, i.e., this.f().

We’d commonly declare a function as public to make it callable by other contracts or externally by users, such as us, when calling a function in e.g., Remix.

Recommended: Solidity Remix IDE Quickstart

A very simple example of a public function is given below:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

contract SimpleFunction {

   function addNumbers(uint a, uint b) 
   external 
   pure 
   returns (uint) {
       return a + b;
   }

   function callAddNumbers(uint a, uint b) 
   public
   pure
   returns (uint) {
      // This would work.
      return addNumbers(a, b);

      // This would work, but the mutability keyword must be 
      // at least 'view' because it calls the function addNumbers(...) 
      // from its environment.
      return this.addNumbers(a, b);
   }
}

Public functions provide us with the most freedom in terms of the simplest proof-of-concept approach for quickly testing new ideas, without concerning ourselves with potential design issues or security.

In such cases, however, we should remain aware that an “all-public” approach should be later replaced with stricter implementation, guided by best practices in terms of design and security.

External Functions

External functions are also part of the contract interface, which enables us to call them from other contracts and via transactions. However, there’s a restriction: we cannot call an external function f internally. That’s why an f() call does not work due to internal reference, however, this.f() does work because the keyword this refers to the contract externally.

Recommended: Solidity Function Calls – Internal and External

Let’s take a look at the following example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

contract SimpleFunction {

   function addNumbers(uint a, uint b) 
   external 
   pure 
   returns (uint) {
       return a + b;
   }

   function callAddNumbers(uint a, uint b) 
   public
   // Mutability keyword must be at least 'view', because it calls 
   // the function addNumbers(...) from its environment. 
   // It's not the case with internal function call.
   view
   returns (uint) {
       // This wouldn't work. An error would show up saying: 
       // "DeclarationError: Undeclared identifier. "addNumbers" is not 
       // (or not yet) visible at this point."
       return addNumbers(a, b);

       // This will work.
       return this.addNumbers(a, b);
   }
}

In the example above, we notice an error caused by trying to call the function callAddNumbers(...) declared as external. On the other hand, if we tried calling an external function via a message call by adding the keyword this, i.e., this.addNumbers(a, b), it would work just fine.

Note: A caller function calling another function via a message call should be declared at least as view (read-only), because it reads from its environment and pure is too restrictive.

The public visibility type can be considered external type and internal type simultaneously.

Internal Functions

We can access internal functions only from within the base (current) contract or contracts deriving (inheriting) from the base contract. This means internal functions are unavailable for external access because they are not exposed through the contract’s ABI. Because of that, internal functions can take parameters of internal types, like mappings or storage references.

Let’s revisit the modified example:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

contract SimpleFunction {

   function addNumbers(uint a, uint b) 
   internal
   pure 
   returns (uint) {
      return a + b;
   }

   function callAddNumbers(uint a, uint b) 
   public
   // Mutability keyword may be 'pure', since it calls 
   // the function addNumbers(...) internally.
   pure
   returns (uint) {

      // This will work.
      return addNumbers(a, b);

      // This wouldn't work. An error would show up saying: 
      // TypeError: Member "addNumbers" not found or not visible after
      // argument-dependent lookup in contract SimpleFunction.
      return this.addNumbers(a, b);
   }
}

The situation with internal functions is quite the opposite with regard to external functions: calling an internal function via a message call is not possible, i.e., this.addNumbers(a, b) won’t work. However, an internal call to an internal function will work just fine: addNumbers(a, b).

Private Functions

We’d declare a function as private function is used when the function is only intended to be called by functions within the same contract and is not accessible to external contracts or users.

The example below will show us how to make a function invisible to the outside world, but still an integral part of a contract.

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

contract SimpleFunction {

   function addNumbers(uint a, uint b) 
   private
   pure 
   returns (uint) {
      return a + b;
   }

   function callAddNumbers(uint a, uint b) 
   public
   // Mutability keyword may be 'pure', since it calls 
   // the function addNumbers(...) internally.
   pure
   returns (uint) {

      // This will work.
      return addNumbers(a, b);
   }
}

Conclusion

In this article, we learned about function visibility types in Solidity. Function visibility is an important concept in Solidity that determines who can call a function and access its variables. By carefully considering function visibility, we, as smart contract developers, can create secure, maintainable, and easy-to-use contracts.

Recommended: Blockchain Developers – Income and Opportunity

First, we introduced public functions and saw how they work and behave.

Second, we explained what external functions are and what their role is in the notion of public functions.

Third, we learned about internal functions and showed how they can be perceived as a second half of public functions.

Fourth, we rounded the story on function visibility with the introduction of private functions as the most restrictive form of function visibility type.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Function Visibility Made Easy appeared first on Be on the Right Side of Change.

These mechanisms will help us tremendously in achieving stable and secure smart contracts, so this is the right moment to introduce them and lay the ground for a more thorough analysis.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion, or a supplement to the official Solidity documentation.

assert()

We’d commonly use the assert(...) function to test if a certain expression evaluates to an expected value. The function takes a boolean expression as an argument, and if the expression evaluates to false, the transaction will throw an exception and revert all changes made in the transaction.

Note: We should refrain from using the assert(...) function in the production source code; it’s meant to be used mainly for testing and debugging.

Let’s take a look at a simple and familiar example of using the assert(...) function:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;

contract Divider {
    function divide(uint numerator, uint denominator) 
    public 
    pure
    returns (uint) {
        assert(denominator != 0);
        uint result = numerator / denominator;
        return result;
    }
}

In the example above, the assert(...) function is used to check that the denominator is not 0 before performing the division. If the denominator is 0, the transaction will throw an exception and revert any changes made by the transaction. This way, our smart contract is safe in terms of keeping the transaction in a consistent state.

require()

The require(...) function is similar to the assert(...) function, but contrary to the assert(...) function, it’s recommended for use in production code. Just like the assert(...) function, it takes a boolean expression as an argument and reverts the transaction if the expression evaluates to false.

Let’s take a look at an example of using require(...) function:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;

contract RequireExample {
    mapping(address => uint) balanceOf;
    
    function transfer(address _to, uint _value) public {
        // Ensures that the caller has sufficient funds.
        require(balanceOf[msg.sender] >= _value);
        // Transfers the funds.
        balanceOf[msg.sender] -= _value;
        balanceOf[_to] += _value;
    }
}

In this example, we use the require(...) function to ensure that the caller of the transfer(...) function has sufficient funds before transferring the specified amount. If the caller does not have sufficient funds, the transaction will throw an exception and revert any changes made by the transaction.

revert()

We’d use the revert(...) function to explicitly revert the changes made by a transaction and throw an exception. It is often used in conjunction with the require(...) function to revert the changes made by a transaction if a certain condition is not met.

Let’s take a look at an example of using revert(...):

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;
// This will report a warning
contract RevertExample{
   address private owner;

   function setOwner(address _newOwner) public {
       // Ensures that the caller is the current owner.
       require(msg.sender == owner);
       // Sets the new owner
       owner = _newOwner;
   }

Exceptions

Exceptions are a great mechanism available to us for error handling with external function calls and contract creation calls. They are similar to exceptions in other programming languages, but they work a bit differently in the context of a blockchain.

In Solidity, exceptions are thrown using the throw keyword, and they can be caught using the try/catch statements.

Recommended: Solidity Control Structures

Exceptions in many programming languages have the property of ‘bubbling up’ automatically until they are caught in a try/catch statement. The exceptions to this rule are the send(...) function and the low-level functions call(...), delegatecall(...) and staticcall(...). These functions just return false as their first return value in case of an exception, instead of ‘bubbling up’.

Warning: The low-level functions call(...), delegatecall(...) and staticcall(...) return true as their first return value if the account called is non-existent. We have discussed this behavior in earlier articles since it is a part of the design of the EVM. To circumvent it, we must check for the account’s existence before using the low-level functions.

Recommended: DelegateCall or Storage Collision Attack on Smart Contracts

Here is an example of using exceptions in a smart contract:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;

contract Divider {
    function divide(uint numerator, uint denominator) 
    public 
    pure
    returns (uint) {
        uint result = numerator / denominator;
        return result;
    }
}

contract Operation {

    Divider divider = new Divider();
    event Log(string message);

    function callOperation(uint numerator, uint denominator) 
    public 
    returns (uint result) {
        try divider.divide(numerator, denominator) returns (uint r) {
            return r;
        } catch {
            emit Log("External call threw an error.");
        }
    }
}

In this example, the divide(...) function throws an exception if the denominator is 0. The callOperation(...) function calls the divide(...) function and catches any exceptions that may be thrown. An exception is handled in the catch block by emitting the error message.

It is important to note that exceptions are expensive to use in Solidity because they require the use of gas to throw and catch the exception.

Recommended: Ethereum Gas – How It Works

With that in mind, we should use them sparingly and only when absolutely necessary.

Conclusion

In this article, we learned about four different mechanisms for handling errors in Solidity.

First, we got introduced to the assert(...) function and explained which are its use cases, as well as which are not.

Second, we went through the require(...) function and learned about its use cases.

Third, we got acquainted with the revert(...) function and showed how it can be used to handle errors.

Fourth, we got familiar with exception handling and learned how they’re used for error handling with external function calls and contract creation calls.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Error Handling with Assert, Require, and Revert Functions appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation for this article’s topic.

We should consider whether an expression should be checked or unchecked in the Solidity programming language. Checked expressions will throw an exception and halt the program if a certain condition is not met, while unchecked expressions do not have this behavior. We should be aware of this distinction because unchecked expressions can lead to performance increases at the cost of possible vulnerabilities in our smart contracts, while checked expressions assist us in ensuring the correctness and security of our code.

Checked Expressions

Checked expressions will throw an exception and halt the program if conditions of interest are unmet, or continue execution if they are satisfied.

For example, if we want to ensure that a certain variable contains a valid result before performing an operation, we can use a checked expression to throw an exception if the variable has an unwanted value.

require Function

There are several ways we can use checked expressions in Solidity. The most common way is to use the require(...) function, which will throw an exception if the condition passed to it is not met.

The following example shows how we can do it:

function divide(uint numerator, uint denominator) public {
    // Throws an exception if the denominator is zero.
    require(denominator != 0, "Division by zero");

    // Performs the division operation.
    uint result = numerator / denominator;
}

The require(...) function throws an exception if the denominator is zero. This helps us in ensuring that the division operation will not be performed if the denominator is zero, which would result in an error.

assert Function

Another way to use checked expressions is to use the assert(...) function, which is similar to require(...). The main difference between assert(...) and require(...) is that assert(...) is recommended for internal consistency checks, while require(...) is better suited for input validation.

In addition to the require(...) and assert(...) functions, there are several other ways we can take to check expressions in Solidity. For example, we can use the revert(...) function to throw an exception and revert the current transaction, or we can use the abort(...) function to throw an exception and halt the program completely.

We should remember that checked expressions are an important tool for ensuring the correctness and security of our Solidity source code. By using checked expressions, we can ensure that we’re meeting specific conditions before operations are performed, which aids in preventing errors and vulnerabilities in our smart contract.

Unchecked Expressions

On the other hand, unchecked expressions do not throw an exception or terminate the program if a specific condition is not met. This behavior can be useful in situations where we want to allow for a certain level of flexibility in our source code, but we should be aware it can also lead to vulnerabilities if not used carefully.

For example, if we have an unchecked expression that does not check the length of an array before performing an operation, it could potentially lead to an out-of-bounds exception.

Another way to use unchecked expressions is to use the call(...) function that allows us to call another contract function without checking for errors.

Reminder: The call(...) function is a low-level call function used for interaction with other contracts. It represents the recommended way for sending Ether via a call to the fallback function.

Warning: Although available, the call(...) function is not recommended for calling functions, because reverts are not forwarded up the call stack, type checks are bypassed, and function existence checks are omitted.

Let’s take a look at the following example of using the call(...) function:

function sendTransaction(address destContractAddress, uint amount) public {
    // Calls the 'receiveTransaction' function of the 
   // 'destContractAddress' contract without checking for errors
    (bool success, bytes memory data) = destContractAddress.call{value: amount}("receiveTransaction");
}

The .call(...) function is used for calling the receiveTransaction(...) function of the destContractAddress contract without checking for errors. This can be useful in situations where we want to allow some flexibility in our code, but it can also potentially lead to vulnerabilities if not used carefully.

Checked and Unchecked Arithmetic

Checked and unchecked expressions are a natural way of dealing with two distinct situations during arithmetic operations, overflow, and underflow. These two operations occur when an arithmetic operation is expected on an unrestricted integer, that falls outside the range of the resulting type.

Info: Before Solidity v0.8.0, arithmetic operations weren’t checked, so external libraries were needed to introduce additional checks. With Solidity v0.8.0, all arithmetic operations revert by default when overflow and underflow situations occur, introducing the needed behavior and eliminating the requirement for external libraries.

However, regardless of the checked behavior being the default one, we can still invoke the unchecked behavior by using an unchecked block, e.g.:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;
contract C {
    function f(uint a, uint b) pure public returns (uint) {
        // This subtraction will wrap on underflow.
        unchecked { return a - b; }
    }
    function g(uint a, uint b) pure public returns (uint) {
        // This subtraction will revert on underflow.
        return a - b;
    }
}

In this example, the f(...) function takes two uint arguments (only whole positive, unsigned numbers). By calling it as f(2, 3), the result will be 2**256-1, or in other words, the result will wrap around, starting on the left and coming on the far right side.

The same arithmetic operation, but with a checked variant, won’t make a wrap but instead cause a failing assertion.

We can use the unchecked block inside a block, but not as a standalone block or a replacement for a block.

Warning: An unchecked block cannot be nested. Also, the unchecked block effect applies only to the statements that are syntactically in the same block. Any function called from inside the block is not affected by the unchecked effect.

Recommended: Top 8 Scary Smart Contract Hacks They Use to Exploit Your DApp [+Video]

Checked and Unchecked Expressions in Solidity

To avoid ambiguity, we cannot use the _; symbol inside an unchecked block. _; is a special symbol that marks the insertion point in a modifier’s body. A modified function’s code will be inserted and executed at this specific point (docs).

These operators will cause a failing assertion on overflow or underflow situations; they will also wrap without an error if they’re used inside an unchecked block: ++, --, +, binary -, unary -, *, /, %, **, +=, -=, *=, /=, and %=.

Warning: We cannot disable the check for division by zero or modulo by zero using the unchecked block.

Integer division and multiplication operations by a power of 2 can be substituted by equivalent bitwise shift operators. However, bitwise shift operators do not check for overflow or underflow situations. Specifically, type(uint256).max << 3 does not revert even though type(uint256).max * 8 does.

Note: If we do an edge-of-the-interval operation, such as in int x = type(int).min; -x; it will result in an overflow because the negative range always holds one more value than the positive range, e.g. as in an imaginary range [-5, ..., 0, 4], where -5 cannot be converted to 5.

If we do an explicit type conversion, it will always truncate without a failing assertion, except when an integer is converted to an enum type.

Unchecked expressions can be useful in certain situations, but it’s important to use them carefully and consider the potential risks and vulnerabilities they may introduce. By using unchecked expressions wisely, we can achieve a balance between flexibility, performance, and security that is right for our particular use case.

Conclusion

In this article, we learned that checked and unchecked expressions are important concepts in Solidity programming. Checked expressions can enforce the correctness and security of our code, while unchecked expressions can improve the performance, but potentially lead to vulnerabilities if they’re used carelessly.

First, we got introduced to checked expressions in general. Then we learned about require(...) and assert(...) functions, and also mentioned the revert(...) and abort(...) functions.

Second, we explained the difference between the checked and unchecked expressions and showed how the call(...) function represents an unchecked expression.

Third, we went into detail on checked and unchecked arithmetic, explained when checked arithmetic became a default, and showed how to override the default behavior and perform the unchecked arithmetic.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Checked and Unchecked Expressions appeared first on Be on the Right Side of Change.

Zero-knowledge rollup, or ZK-Rollup, is a second-layer scaling solution that uses zero-knowledge proofs to bundle multiple transactions into a single proof that can be verified on the main Ethereum network. This technique significantly reduces the amount of data stored on the blockchain, thus improving its scalability and boosting transaction throughput.

A zkEVM Rollup is an attempt to build an Ethereum Virtual Machine (EVM)-compatible Rollup with zk-proofs while preserving the EVM codes and the knowledge derived from it. (source)

By leveraging zkEVM Rollups, Ethereum can benefit from increased transaction capacity, reduced gas fees, and improved security. As the Ethereum community and developers continue to explore and implement zkEVM Rollups, this technology has the potential to play a pivotal role in the broader adoption of blockchain and smart contracts.

Next, I’ll gradually build your knowledge of zkEVMs. Let’s start with the first profound question:

What is the Ethereum Virtual Machine (EVM)?

The Ethereum Virtual Machine (EVM) is like a giant computer brain that lives on the Ethereum blockchain. It’s responsible for keeping track of all the accounts and balances on the network, as well as executing smart contracts and other code. Think of it like a big, decentralized computer that processes all the transactions on the Ethereum blockchain .

But what’s really cool about the EVM is that it’s designed to be totally transparent and open to everyone. Anyone can write code that runs on the EVM, and the rules for how that code interacts with the rest of the blockchain are all publicly available. This means that developers can build all sorts of amazing decentralized applications (dApps) on top of Ethereum .

Of course, like any computer system, the EVM has to be secure and reliable, too. That’s why it’s designed to be totally decentralized and trustless. Instead of relying on a single central authority to keep everything running smoothly, the EVM is run by a network of nodes all around the world . These nodes work together to validate transactions and execute code, ensuring that everything is working as it should be.

So, in short, the Ethereum Virtual Machine is the heart and soul of the Ethereum blockchain . It’s what makes everything possible, from sending Ether (ETH) to building complex decentralized applications. And it’s all powered by a global network of nodes working together to keep the system running smoothly .

Recommended: What is the Ethereum Virtual Machine (EVM)?

What is a Rollup (L2) in Ethereum?

A rollup is a Layer 2 (L2) scaling solution in Ethereum that aggregates multiple transactions off-chain and submits them to the Ethereum blockchain as a single transaction, reducing congestion and increasing efficiency (source: Shrimpy, CoinDesk).

Rollups can be implemented as Zero-Knowledge rollups (ZK-rollups) or Optimistic rollups, and both types use smart contracts to ensure the integrity of the transactions (source: Ethereum.org).

Here’s a short story explaining rollups as a series of emoijs:

Ethereum Rollup =

Here’s my interpretation of the emojis:

– Rollups help Ethereum scale and process more transactions faster.

– Rollups aggregate multiple transactions off-chain and submit them to the Ethereum blockchain as a single transaction.

– Rollups use smart contracts to ensure the integrity of the transactions.

– Rollups store the aggregated transactions off-chain, reducing congestion on the Ethereum blockchain.

– Rollups can help reduce transaction fees and make Ethereum more accessible to everyone.

What Is a zkEVM Rollup?

A zkEVM rollup is a zero-knowledge Ethereum Virtual Machine, which aims to replicate the Ethereum environment as a rollup, allowing developers to build on it just like they would on Ethereum (source). The primary function of this innovative technology is to combine the advantages of EVM compatibility and zero-knowledge rollups, offering a scalable and seamless developer experience (source).

With zkEVM rollups, Ethereum layer 2 scaling solutions become more efficient by transferring computation and state storage off-chain while processing thousands of transactions in a batch and submitting only minimal summary data with zero-knowledge proofs to the Ethereum Mainnet (source).

This technique can potentially solve the scalability trilemma, making it a powerful tool for developers (source).

Explanation: The scalability trilemma is a concept in blockchain technology that posits that it is impossible to achieve all three of the following properties simultaneously: scalability, security, and decentralization. This means that a blockchain system can only optimize for two of these properties at the expense of the third. For example, if a blockchain system prioritizes scalability and security, it may sacrifice decentralization by relying on a smaller number of nodes to process transactions. Similarly, if a blockchain system prioritizes decentralization and security, it may sacrifice scalability by limiting the number of transactions that can be processed at any given time.

Due to their compatibility with Ethereum’s EVM, zkEVM rollups make it easy for developers to port existing Ethereum dApps and tokens to this new environment, maximizing the benefits of Layer-2 blockchains without losing the advantages of rollups (source).

So, in a nutshell, zkEVM rollups are the key to unlocking greater scalability, better throughput, and smooth developer experience on the Ethereum network. Ethereum scaling !

How zkEVM Rollups Work

In this section, we will explore the inner workings of zkEVM rollups, focusing on four key sub-sections: Zero-Knowledge Proofs, Batching Transactions, Data Availability, and Validation. Dive in and take a delightful journey through the world of zkEVM rollups.

Zero-Knowledge Proofs

At the heart of zkEVM rollups are zero-knowledge proofs (ZKP). These cryptographic techniques allow one party to prove the validity of a statement without revealing any information about the statement itself.

In other words, Zero Knowledge Proofs (ZKPs) are a way for someone to prove that they know something (like a password or a secret) without actually revealing what that thing is. It’s like a secret handshake , but with math!

ZKPs are really useful for privacy and security. They allow people to prove that they have access to sensitive information without actually revealing that information to anyone else. For example, you could use a ZKP to prove that you’re over 18 without revealing your exact age.

In the context of blockchain, ZKPs are used to keep transactions private and secure. They allow people to prove that they have the right to make a transaction without revealing any other information about themselves or the transaction. This can help protect against fraud and hacking, and keep the blockchain more secure.

In the context of zkEVMs, ZKP verifies the legitimacy of off-chain transaction batches while maintaining privacy and data security. For a deeper understanding of Zero-Knowledge Proofs, check out Alchemy.

Batching Transactions

Next up, batching transactions!

In zkEVM rollups, multiple transactions are grouped together into a single batch off-chain. This efficient process significantly reduces the amount of on-chain data, which in turn lowers gas fees and increases throughput.

To learn more about how batching transactions contribute to the scalability of Ethereum, refer to Chainstack Blog.

Data Availability

Ensuring data availability is a crucial aspect of zkEVM rollups. Although transaction data is computed off-chain, it is imperative to maintain the data’s availability to all network participants. In zkEVMs, this is achieved through data availability proofs, which guarantee that off-chain computed data can always be accessed and reconstructed if needed.

Validation

Last but not least, let’s talk about validation. To maintain Ethereum’s security and prevent double-spending attacks, all transactions need to be verified. With zkEVM rollups, off-chain computation is combined with on-chain data availability and ZKP. This enables the Ethereum network to validate transactions without performing the full computation itself. The result? A secure and efficient scaling solution. For a detailed look at zkEVM validation, check out ethereum.org.

zkEVMs in the Wild – Polygon, ZKSync, Scroll

As zkEVM rollups gain popularity, several projects have emerged that adopt this technology, such as Polygon, ZKSync, and Scroll. Let’s dive into these implementations and see how they are contributing to the wider Ethereum ecosystem.

Polygon zkEVM is a scaling solution designed to improve the throughput and reduce transaction costs on the Ethereum network. With its rollup-based architecture, it enables faster confirmations and enhanced security. Polygon’s vision is to create a mesh network of L2 solutions for Ethereum, and zkEVM plays a crucial role in realizing this ambition.

ZKSync is another project leveraging zkEVM technology to achieve a powerful layer-2 scaling solution. It guarantees the security of smart contracts by using zero-knowledge proofs and aims to process thousands of transactions per second. ZKSync promises to significantly improve the user experience for both developers and end-users, making decentralized applications more accessible to a broader audience.

Lastly, Scroll is an innovative project that combines zkEVM rollups with a privacy-focused approach. It seeks to provide scalable, trustless, and private computation using zero-knowledge proof technology. While not much information about Scroll is available at the moment, it is definitely a project worth keeping an eye on as privacy becomes increasingly important in the blockchain space.

zkEVM rollups like Polygon, ZKSync, and Scroll are paving the way for a more scalable, secure, and user-friendly Ethereum ecosystem. As these projects continue to develop and innovate, the potential for zkEVM technology to revolutionize the way we interact with decentralized applications becomes even more apparent.

Benefits of zkEVM Rollups

In this section, you’ll explore the advantages of using zkEVM rollups for off-chain computation and scaling while still maintaining compatibility with the Ethereum ecosystem. The primary benefits include improved scalability, security, and privacy.

Scalability

zkEVM rollups boost the throughput of the Ethereum network by aggregating multiple transactions into a single proof, known as a Layer 2 protocol. The power of this technique lies in the ability to “roll up” a large batch of transactions and then use a zero-knowledge proof to verify them before submitting them back to the mainnet. This process significantly reduces transaction costs and increases transaction capacity , making the Ethereum network more efficient and accommodating for users and developers.

Security

zkEVM rollups gain the advantage of the Ethereum network’s inherent security measures, making them an ideal solution for decentralized applications where trustless and secure environments are crucial . By executing transactions off-chain through a zero-knowledge proof mechanism, the security of the main Ethereum network remains uncompromised even as throughput increases.

Privacy

With zkEVM rollups, privacy is enhanced through the utilization of zero-knowledge proofs. This process enables obfuscation and selective disclosure of transaction data, minimizing the risk of sensitive information being exposed . This added layer of privacy makes zkEVM rollups an attractive option for applications where user anonymity and data protection are vital.

zkEVM rollups not only address the limitations of the Ethereum network, but also bring about essential improvements such as scalability, security, and privacy that cater to the dynamic demands of the burgeoning blockchain ecosystem . This makes them a fun yet powerful solution for a wide array of use cases and industries (see below).

Comparing zkEVM Rollups and Other Layer 2 Solutions

As Ethereum strives for better scalability and faster transaction speeds, several Layer 2 solutions have emerged as potential options. This section will compare zkEVM Rollups with Optimistic Rollups, Plasma, and State Channels.

Optimistic Rollups

Optimistic Rollups offer an alternative scaling solution that allows developers to build and deploy contracts on Layer 2 while maintaining compatibility with Ethereum. These rollups are “optimistic” because they assume transactions are valid, and any disputes are resolved on-chain. But they have a longer confirmation time and higher gas fees than zkEVM Rollups, which utilize zero-knowledge proofs for quick, secure transactions .(source)

Plasma

Plasma is a Layer 2 scaling solution that enables the creation of child chains off the main Ethereum blockchain. These child chains can process transactions independently and anchor their final states back to the Ethereum main chain. However, they are more suited to specific use cases, like token transfers and exchanges, than to general-purpose smart contracts. zkEVM Rollups aim to enable a broader range of applications by bringing the full Ethereum experience to Layer 2.(source)

State Channels

State Channels allow off-chain transactions between participants without compromising security. These channels can be opened, closed, or updated by participants, with only the final state of the channel being submitted to the Ethereum blockchain. State Channels offer faster transactions with negligible fees, but their applicability is limited to specific scenarios, such as micropayments, and they don’t generalize well to complex smart contracts. zkEVM Rollups have an edge in providing the familiar Ethereum-like environment while scaling the network . (source)

Recommended: Vitalik’s Incomplete Guide to Rollups

Use Cases and Applications

As one of the most promising layer 2 scaling solutions for Ethereum, zkEVM rollups have a broad range of use cases and applications. Let’s dive into a few examples that will put the capabilities of zkEVM rollups into perspective:

First, payments and swaps are natural fits for zkEVM rollups. By bundling many transactions into a single proof, zkEVM rollups can reduce gas fees and improve transaction throughput. Platforms like Loopring are already leveraging zkEVM technology to offer efficient payment processing and token exchanges.

Next, we have the booming world of Non-Fungible Tokens (NFTs) . Projects like Immutable are building on zkEVM rollups to facilitate minting and trading NFTs with reduced costs and increased speed. This makes it more accessible for artists and collectors to participate in the NFT marketplace, while also supporting gaming applications.

When it comes to decentralized finance (DeFi) , zkEVM rollups can provide enhanced scalability and privacy for lending, borrowing, and yield farming operations. DeFi platforms can leverage zkEVM rollups for optimized processing and cryptographic proofs, creating a more seamless experience for users.

These are just a few of the potential use cases for zkEVM rollups, and as the technology continues to mature, we can expect to see even more exciting and innovative applications across the Ethereum ecosystem. So, hold on to your hats, and let’s embrace the future of blockchain technology together!

“Rolling This Up”

In summary, a zkEVM (Zero-Knowledge Ethereum Virtual Machine) is a solution that aims to replicate the Ethereum environment using zero-knowledge proofs as rollups. This technology enhances Ethereum’s scalability and reduces costs while maintaining compatibility with its native programming environment.

Combining the power of zkRollups and the familiarity of the EVM, developers can utilize their existing knowledge and tools to build decentralized applications on layer 2 systems. The marriage of these concepts offers a more sustainable and efficient future for the Ethereum ecosystem.

As the blockchain space evolves and grows, we can expect further innovations fueled by the zkEVM concept . So, buckle up and get ready for an exciting ride in the world of decentralized applications!

Recommended: Join our free email academy on exponential technologies such as AI, Blockchain development, and programming.

The post What is a zkEVM Rollup? A Simplified Guide to Ethereum’s Most Promising Scaling Solution appeared first on Be on the Right Side of Change.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion, or a supplement to the official Solidity documentation.

Scopes Overview

Scope refers to the context in which we can access a defined variable or a function. There are three main types of scope specific to Solidity:

• global,
• contract, and
• function scope.

In the global scope, variables, and functions are defined at the global level, i.e., outside of any contract or function, and we can access them from any place in the source code.

In the contract scope, variables and functions are defined within a contract, but outside of any function, so we can access them from anywhere within the specific contract. However, these variables and functions are inaccessible from outside the contract scope.

In the function scope, variables and functions are defined within a function and we can access them exclusively from inside that function.

Note:

The concept of scopes in Solidity is similar and based on the concept of scopes in the C99 programming language. In both languages, a “scope” refers to the context in which a variable or function is defined and can be accessed.

In C99 (a C language standard from 1999), variables and functions can be defined at either the global level (i.e., outside of any function) or within a function. There is no “contract” scope in C99.

Global Scope

Let’s take a look at a simple example of the global scope:

pragma solidity ^0.6.12;

uint public globalCounter;

function incrementGlobalCounter() public {
    globalCounter++;
}

In this example, the globalCounter variable is defined at the global level and is, therefore, in the global scope. We can access it from anywhere in the code, including from within the incrementGlobalCounter(...) function.

Reminder: Global variables and functions can be accessed and modified by any contract or function that has access to them. We can find this behavior useful for sharing data across contracts or functions, but it can also present security risks if the global variables or functions are not properly protected.

Contract Scope

As explained above, variables and functions defined within a contract (but outside of any function) are in contract scope, and we can access them from anywhere within the contract.

Contract-level variables and functions are useful for storing and manipulating data that is specific to a particular contract and is not meant to be shared with other contracts or functions.

Let’s take a look at a simple example of the contract scope:

pragma solidity ^0.6.12;

contract Counter {
    uint public contractCounter;

    function incrementContractCounter() public {
        contractCounter++;
    }
}

In this example, the contractCounter variable is defined within the Counter contract and is, therefore, in contract scope. It is available for access from anywhere within the Counter contract, including from within the incrementContractCounter() function.

Warning: We should be aware that contract-level variables and functions are only accessible from within the contract in which they are defined. They cannot be accessed from other contracts or from external accounts.

Function Scope

Variables and functions that are defined within a function are in the function scope and can only be accessed from within that function.

Function-level variables and functions are useful for storing and manipulating data that is specific to a particular function and is not meant to be shared with other functions or with the contract as a whole.

Let’s take a look at the following example of the function scope:

pragma solidity ^0.6.12;

contract Counter {
    function incrementCounter(uint incrementAmount) public {
        uint functionCounter = 0;
        functionCounter += incrementAmount;
    }
}

In this example, the functionCounter variable is defined within the incrementCounter(...) function and is, therefore, in the function scope. It can only be accessed from within the incrementCounter function and is not accessible from other functions or from outside the contract.

C99 Scoping Rules

Now, let’s take a look at an interesting example showing minimal scoping by using curly braces:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;
contract C {
    function minimalScoping() pure public {
        {
            uint same;
            same = 1;
        }

        {
            uint same;
            same = 3;
        }
    }
}

Each of the curly braces pair forms a distinct scope, containing a declaration and initialization of the variable same.

This example will compile without warnings or errors because each of the variable’s lifecycles is contained in its own disjoint scope, and there is no overlap between the two scopes.

Shadowing

In some special cases, such as this one demonstrating C99 scoping rules below, we’d come across a phenomenon called shadowing.

Shadowing means that two or more variables share their name and have intersected scopes, with the first one as the outer scope and the second one as the inner scope.

Let’s take a closer look to get a better idea of what’s all about:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;
// This will report a warning
contract C {
    function f() pure public returns (uint) {
        uint x = 1;
        {
            x = 2; // this will assign to the outer variable
            uint x;
        }
        return x; // x has value 2
    }
}

There are two variables called x; the first one is in the outer scope, and the second one is in the inner scope.

The inner scope is contained in or surrounded by the outer scope.

Therefore, the first and the second assignment assign the value 1, and then value 2 to the outer variable x, and only then will the declaration of the second variable x take place.

In this specific case, we’d get a warning from the compiler, because the first (outer) variable x is being shadowed by the second variable x.

Warning: in versions prior to 0.5.0, Solidity used the same scoping rules as JavaScript: a variable declared at any location within the function would be visible through the entire function’s scope. That’s why the example below could’ve been compiled in Solidity versions before 0.5.0:

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.5.0 <0.9.0;
// This will not compile
contract C {
    function f() pure public returns (uint) {
        x = 2;
        uint x;
        return x;
    }
}

The code above couldn’t compile in today’s versions of Solidity because an assignment to variable x is attempted before the variable itself is declared. In other words, the inner variable x‘s scope starts with the line of its declaration.

Conclusion

In this article, we learned about variable and function scopes.

• First, we made a scope overview, introducing ourselves to three different scopes in Solidity.
• Second, we investigated the global scope by studying an appropriate example.
• Third, we looked at the contract scope through an appropriate example.
• Third, learned about the function scope on an appropriate example.
• Fourth, we glanced at C99 scoping rules based on C99 – a C language standard.
• Fifth, we also learned about shadowing and got an idea of why we should be careful about it.

What’s Next?

This tutorial is part of our extended Solidity documentation with videos and more accessible examples and explanations. You can navigate the series here (all links open in a new tab):

Prev Tutorial

Syllabus

Next Tutorial

The post Solidity Scoping – A Helpful Guide with Video appeared first on Be on the Right Side of Change.