A Deep Dive into Solidity Visibility Specifiers: Public, Private, Internal, and External

In this guide, we’ll explore the four primary visibility specifiers in Solidity: public, private, internal, and external. These specifiers determine how functions and state variables can be accessed and are crucial for writing secure, efficient, and maintainable smart contracts.

Table of Contents

Public Visibility

When you mark a function or state variable as public in Solidity, it’s like you’re opening your doors to the world. Anyone and everyone can access it—not just from within your contract but also from outside and even from other contracts that might derive from yours. It’s super inclusive but remember, it comes with a responsibility to ensure it’s used wisely because it’s accessible everywhere.

Example: Imagine a voting contract where everyone needs to see the total votes:

contract Voting { uint public totalVotes; function vote() public { totalVotes++; }
}

Private Visibility

Now, if public is like shouting from the rooftops, then private is your secret diary. Only the contract in which you declare something private can see or use it. It’s perfect for sensitive stuff that you don’t want the outside world or even child contracts messing with.

Example: Think of a bank contract that needs to keep its balance hidden:

contract BankAccount { uint private balance = 0; function updateBalance(uint _amount) private { balance += _amount; }
}

Internal Visibility

internal is a sweet spot between public and private. It’s like family privileges—only your contract and its kids (derived contracts) can access what’s marked internal. It’s great for when you want to protect functions from the outside world but still let your derived contracts get in on the action.

Example: Here’s a base contract that only lets derived ones increment a count:

contract BaseContract { uint internal itemCount; function incrementCount() internal { itemCount++; }
} contract ChildContract extends BaseContract { function incrementExternally() public { incrementCount(); }
}

External Visibility

And then we have external, which is specifically for those functions that should only be called from outside the contract. It’s like having a doorbell that only works when someone outside rings it. It’s more gas-efficient for these cases, but you can’t use it from inside the contract unless you do some special calling tricks.

Example: Think of a contract for a sale where buyers interact directly:

contract TokenSale { function buyTokens(address buyer) external payable { // Logic }
}

Comparing Internal and Private

Accessibility Within Contracts:

private: Functions and state variables are accessible only within the contract they are declared in. They cannot be accessed by derived (inheriting) contracts.

internal: Functions and state variables are accessible within the contract they are declared in and by any contract that inherits from this contract. This allows for broader use within contract families.

Inheritance Handling:

private: Completely hides the function or variable from any other contract, including those that inherit from the contract. Ideal for sensitive or critical functions that should not be exposed to inheriting contracts.

internal: Allows derived contracts to use or override the function or variable, facilitating reusable code and extension patterns in contract design.

Use Case Scenarios:

private: Best used for critical operations and sensitive data handling where access needs to be strictly controlled within the original contract.

internal: Suitable for creating base contracts that provide foundational functionality to derived contracts without exposing details to external contracts or accounts.

Comparing Public and External

External Access Efficiency:

public: Functions can be accessed internally within the contract, from derived contracts, and externally. However, when public functions are called externally, they are less gas-efficient compared to external functions.

external: Functions are specifically optimized for external calls, offering more gas efficiency when called from outside the contract but cannot be called directly from within the contract (requires using this.functionName()).

Flexibility vs. Specificity:

public: Provides the highest level of flexibility, allowing functions to be part of the internal contract logic and used externally, making them suitable for a wide range of interactions.

external: More specialized, designed strictly for interactions that occur from outside the contract, thus reducing flexibility but increasing gas efficiency for these specific interactions.

Typical Use Cases:

public: Ideal for functions that need to be readily accessible from any context, whether within the contract, from derived contracts, or externally. Often used for getter functions for state variables.

external: Best suited for functions that are intended to be part of the contract’s interface with the outside world, such as functions that interact with other contracts or are called by external users.

Understanding and appropriately applying public, private, internal, and external can significantly impact the security, efficiency, and functionality of your smart contracts. Always consider the specific needs and interactions of your contract when choosing visibility specifiers.