Visibility in Solidity Functions

Introduction

Today, we'll shift our focus from the data itself to the functions that operate on it. This lesson addresses the learning outcome: Write functions with appropriate visibility specifiers (public, external, internal, private).

These four keywords are the gatekeepers of your contract. They define who can call your functions and from where. This is not just a high-level concept of access control; it has profound, low-level implications for how your contract is compiled, how the EVM routes function calls, and ultimately, how much gas your users will pay. Given your interest in EVM internals and optimization, we will explore these connections in detail.

The Four Levels of Visibility

Solidity provides four visibility specifiers to control how and where your functions can be called. Getting them right is essential for both security and proper contract design.

To begin, let's get a clear and complete overview of what each specifier does.

As the video explained, the access rules can be summarized as follows:

The key takeaways from this initial overview are:

• private is the most restrictive.
• internal is like private but allows access for child contracts (inheritance).
• public is the most permissive.
• external is specifically for calls coming from outside the contract.

Under the Hood: Visibility and the EVM

Now, let's dig deeper into why these rules work the way they do at the EVM level. Your interest in low-level mechanics will be well-served here. The visibility of a function is not just an abstract rule; it's physically reflected in the contract's compiled bytecode.

When you make a transaction to a contract, the transaction's calldata contains information about which function you want to execute and with which arguments. The EVM needs a way to parse this data and jump to the correct piece of code. This is done using function selectors.

Here's the critical connection to understand:

1. public and external functions are exposed in the ABI: The Solidity compiler generates a unique 4-byte function selector for every public and external function. This selector is derived from the function's signature (its name and argument types). The contract's bytecode includes a dispatch mechanism that compares the first four bytes of the incoming calldata against its list of known selectors to find a match and execute the corresponding function.

2. internal and private functions have no selectors: The compiler does not generate function selectors for these functions. They are not part of the contract's public-facing Application Binary Interface (ABI). Therefore, there is no way for an external transaction to call them; the EVM's dispatch mechanism simply wouldn't find a matching selector. They are resolved at compile time as simple jumps (JUMP opcodes) within the contract's own code.

This is the fundamental reason why visibility works: it's not a suggestion, but a hard-coded aspect of the contract's entry points.

Practical Implications: public vs. external and Gas Optimization

Since both public and external functions can be called from outside the contract, a common point of confusion is when to use one over the other. The answer often comes down to gas efficiency, a topic of primary importance in DeFi.

The common wisdom is "external is cheaper than public," but this is an oversimplification. The truth is more nuanced and relates to how function arguments are handled by the EVM.

Let's summarize the key performance difference for external calls:

• external functions: Arguments are read directly from calldata. calldata is a read-only data location where transaction data is stored. Accessing it is very cheap.
• public functions: When called externally, arguments are first copied from calldata into memory. memory is a more expensive, volatile data location. This copying step adds gas costs, especially for large arguments like arrays or strings.

Therefore, the rule of thumb is:

If a function is only ever meant to be called externally from outside the contract, prefer external. You'll save gas, particularly if the function accepts large arrays or other complex data types as arguments.

The trade-off is that an external function cannot be called directly from within the same contract. You would have to use the this.myExternalFunction() syntax, which forces an actual external call to your own contract, incurring higher gas costs than a simple internal call.

Synthesis and Design Principles

We can now combine these concepts into a clear set of design principles for choosing the right visibility.

Here is a summary of best practices for choosing a visibility specifier:

Conclusion

In this lesson, you've moved beyond a surface-level understanding of function visibility to see how it's enforced at the EVM level and how it impacts gas optimization.

Key Takeaways:

• Visibility specifiers (public, external, internal, private) are fundamental for defining a contract's API and enforcing access control.
• Only public and external functions are exposed in the contract's ABI via function selectors, making them callable from outside. internal and private functions are resolved at compile time and are not externally accessible.
• For functions intended only for external calls, external is generally more gas-efficient than public because it reads arguments directly from calldata, whereas public copies them to memory.
• Choosing the most restrictive visibility specifier that meets your needs is a core principle of secure and efficient smart contract development.

Now that you can define variables and control access to functions, you have the structural components of a contract in place. In our next lesson, we will start building the logic within those functions by exploring control flow constructs like if/else, for, and while loops.