What is the difference between a public, private, internal, and external function in Solidity?

Understanding Function Visibility in Solidity

Solidity, the primary programming language for Ethereum smart contracts, enforces strict access control through function visibility specifiers. These specifiers determine who can call a function—whether it’s from within the contract, derived contracts, or externally. The four types—public, private, internal, and external—define the scope of accessibility and play a crucial role in securing contract logic.

Public Functions

2. When a function is marked as public, Solidity automatically generates a getter function if it’s a state variable or allows direct invocation through the contract interface.

3. These functions become part of the contract’s ABI (Application Binary Interface), making them callable by wallets, dApps, and other smart contracts.

4. Gas costs may be higher for public functions due to external call overhead and data encoding requirements.

5. A common use case includes user-facing functions like token transfers or balance checks in ERC-20 contracts.

Private Functions

2. They are ideal for encapsulating sensitive logic that should not be exposed or overridden.

3. Since they are not part of the external interface, private functions do not appear in the ABI.

4. Developers often use them for internal validation, hashing, or cleanup routines that support public or internal operations.

5. Despite being private, their code is still visible on-chain; privacy refers only to execution access, not source concealment.

Internal Functions

2. They cannot be called directly by external accounts or unrelated contracts, even through address-based interactions.

3. Inheritance hierarchies rely heavily on internal functions to share reusable logic without exposing it publicly.

4. Like private functions, they do not contribute to the contract’s external ABI.

5. An example includes utility functions in OpenZeppelin’s SafeMath library or modifiers that enforce preconditions across multiple methods.

External Functions

2. Even the contract itself must use this.functionName() syntax to invoke its own external functions, which incurs a message call overhead.

3. This visibility is useful when you want to ensure a function is never executed internally, promoting modularity and reducing gas misuse.

4. External functions are included in the ABI and can be invoked via transaction or contract-to-contract calls.

5. They are commonly used for large data inputs, as calldata (used by external functions) avoids memory copying costs associated with internal calls.

Frequently Asked Questions

Can a private function be overridden in a derived contract?No, private functions cannot be accessed or overridden by derived contracts. Only internal and public functions can be overridden using the virtual and override keywords.

What happens if I don’t specify a visibility modifier?If no visibility is specified, Solidity defaults to public for functions. For state variables, the default is internal. Relying on defaults is discouraged for security and clarity reasons.

Is there a performance difference between internal and external function calls?Yes. Internal calls execute within the same contract context and use minimal gas. External calls, even when self-referenced, require a message call, increasing gas consumption due to stack isolation and ABI encoding.

Can an external function modify state variables?Yes, external functions can modify state variables unless restricted by other modifiers like view or pure. Their ability to alter storage depends on logic, not visibility.