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.

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.

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.

Variable Declaration and Initialization

Before we step into the topic of declarations, let’s make a brief note of the difference between declaration and initialization. I find making this distinction useful because I noticed the two being interchanged quite often, although they mean entirely different things.

Note:

Variable declaration means we’re just declaring there’s a variable of a certain type (hence the term), but we’re not necessarily saying anything about the variable value.

Variable initialization means we’re taking an existing variable and giving it some initial, also known as default value (hence the term). It’s quite common to do both at once, i.e., declare and initialize the variable.

Once a variable is only declared but not explicitly initialized, it will get an initial value.

This value varies from type to type, but the general underlying principle is the same: the initial value of any variable is the one whose byte representation is set to all zeros.

This means that if we take a variable and look at it at a very low level, where individual bytes are visible, we’d see only zeros. This is not necessarily the same if we look at the same variable at a higher level. This state of “all zeros” is sometimes also called the “zero-state” of a type.

Note: A variable initialization can be implicit or explicit.

An implicit initialization is made by the Solidity compiler, according to the underlying type of the variable.

An explicit initialization is made by the programmer, i.e., in the code, setting the variable to a desired initial value, again, according to the variable type.

Implicit Initializations of Variable Types

Let’s take a brief overview of the simple, primitive variables and their initial default values, starting with the simpler types and going to the more complex types.

A bool variable has a default value of false because it corresponds to its zero state. An integer value in a signed variant int or unsigned variant uint has a default value of 0.

Recommended Read: Understanding the Boolean Data Type in Solidity

Going over to the more complex types, statically-sized arrays and types bytes1 to bytes32, each of their elements will also be set to a zero-state, i.e., their equivalent of zero.

• For dynamically-sized arrays and types of bytes and strings, their default value is an empty array or an empty string, respectively.
• For even more complex, custom data types/structures, default values consist of (a set of) default values according to their underlying simpler types, since each complex type can be perceived as a set of simple(r) types.

The effects of the implicit approach are two-fold; they make our coding more safe and enjoyable but can also make it ambiguous. Let’s take a look at both of these cases.

Implicit Initialization and Value Ambiguity

In the first case, it prevents us from having uninitialized variables, which is a cause for many bugs in professional development.

For instance, in languages like Java, C, and C++, the default initialization value for some types of objects is null (we don’t have null or equivalent in Solidity).

Let’s see how implicit initialization aids us in our programming projects:

• In a simpler scenario, when a programmer just forgets to initialize his variables and objects to specific, non-null values but continues working with them as if he did initialize them. This type of bug is easy to notice and correct.
• Another, more complex scenario is where, due to the logic of the program, the initialization is left for a later stage of the code, possibly in a branch that is conditionally (un)reachable. If the source code is poorly organized and extensive, such bugs are hard to catch because they occur only occasionally.

Solidity takes care of both of these problems for us by not allowing a null value, therefore our programs will never experience bugs due to uninitialized variables.

However, there’s a catch in the second case, and let’s take a look at it more closely. Since Solidity implicitly initializes our variables if we don’t initialize them explicitly, the default value of a (primitive) variable is 0.

However, the result of our calculation may also be 0, and in that case, it’s impossible to differentiate whether the 0 came from implicit initialization without executing our calculation or is a result of our calculation.

A common approach to resolving such ambiguity is by introducing a variable, commonly called a flag, and conditionally setting it to some non-zero value during the calculation execution. That way, we can always tell if result 0 originated from the calculation, or the implicit initialization, just by looking at the flag.

Info: A flag is a common-purpose variable with a special (imaginary) role of tracking a certain program state. Flags are used to indicate a state of a calculation, function execution, readiness of a result, etc. We can think of a flag as a signaling light on a control panel. It’s entirely up to us to define a role for it and treat it that way.

Conclusion

In this article, we learned about the difference between variable declaration and initialization.

First, we learned about what variable declaration and initialization are. We also hinted there are two kinds of variable initializations: implicit and explicit.

Second, we went over implicit variable initializations for different variable types and also introduced the notion of zero-state value.

Third, we analyzed a very specific ambiguity regarding implicit initialization. This allowed us to introduce another interesting and very common tool in programming: a flag variable.

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 Declarations – A Helpful Guide with Video appeared first on Be on the Right Side of Change.

Therefore, the Ethereum TVL per Solidity developer is more than $104,000, and the Ethereum market cap per Solidity developer is more than $717,000. So for all practical purposes, you can assume that the total value locked per Solidity developer is at least $821,000.*

*I used very conservative assumptions; the real numbers will be much higher (see below). Also, I’m aware that not all Ethereum developers use Solidity, but most (see below). At the time of writing, we’re amid a bear market in 2023, with the TVL of both Ethereum and its Solidity smart contracts down roughly 70%. As the number of developers doesn’t grow proportionally to the price in a bull market, this number can be seen as a historic “worst-case” estimation.

How Many Monthly Active Solidity Developers Are There?

My basic assumption is that a monthly active Solidity developer checks the Solidity docs at least once per month. Currently, the Solidity docs have 580,000 visits per month and 2.15 pages per visit, so our estimate is 269,000 active Solidity developers per month.

Reasons there are more Solidity developers: Some active Solidity developers may not check out the docs during development. However, I think this won’t change the number by more than a factor of 2-3x.

Reasons there are fewer Solidity developers: On the other hand, this may be a significant overestimation of the number of Solidity devs because the number of sessions may be much larger than the number of active users. Many Solidity developers will check out the docs multiple times per month!

So, the 269,000 Solidity developers per month number is likely to be a significant overestimation and can be seen as an upper bound. Consequently, the TVL per Solidity developer will be much larger than our $821,000 number, even considering that not all ETH dApp developers use Solidity (only most).

If you’re interested in learning to create your own dApps and participate in this highly profitable growth market, check out our new Finxter Academy course:

The post $821,000 Ethereum Value per Solidity Developer appeared first on Be on the Right Side of Change.