Introduction to Solidity Contracts
In Solidity, contracts serve as the fundamental building blocks, analogous to classes in object-oriented programming languages. They encapsulate state variables for persistent data storage and functions that can modify these variables. When a function from another contract instance is called, it triggers an Ethereum Virtual Machine (EVM) function call, switching the execution context and making the previous contract's state variables inaccessible.
Creating Contracts
Contracts can be created externally via Ethereum transactions or internally from within another Solidity contract. Integrated development environments (IDEs) like Remix streamline this process through user-friendly interfaces. For programmatic contract creation on Ethereum, the JavaScript API web3.js is commonly used, with the web3.eth.Contract method simplifying deployment.
During creation, a constructor function (bearing the same name as the contract) executes once. Constructors are optional, and only one is permitted, meaning overloading is not supported. Constructor arguments are ABI-encoded after the contract code internally. If using web3.js, this encoding is handled automatically.
A contract creating another must know the source (and binary) code of the contract being created, preventing circular dependencies.
pragma solidity ^0.4.16;
contract OwnedToken {
TokenCreator creator;
address owner;
bytes32 name;
function OwnedToken(bytes32 _name) public {
owner = msg.sender;
creator = TokenCreator(msg.sender);
name = _name;
}
function changeName(bytes32 newName) public {
if (msg.sender == address(creator))
name = newName;
}
function transfer(address newOwner) public {
if (msg.sender != owner) return;
if (creator.isTokenTransferOK(owner, newOwner))
owner = newOwner;
}
}
contract TokenCreator {
function createToken(bytes32 name) public returns (OwnedToken tokenAddress) {
return new OwnedToken(name);
}
function changeName(OwnedToken tokenAddress, bytes32 name) public {
tokenAddress.changeName(name);
}
function isTokenTransferOK(address currentOwner, address newOwner) public view returns (bool ok) {
address tokenAddress = msg.sender;
return (keccak256(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff);
}
}Visibility and Getter Functions
Solidity defines four visibility types for functions and state variables due to its two function call types: internal (no EVM call) and external (EVM call). Functions can be external, public, internal, or private, with public as the default. State variables cannot be external and default to internal.
external: Part of the contract interface, callable from other contracts and transactions. Inefficient for internal calls.public: Part of the contract interface, callable internally or via messages. Automatic getter functions are generated for public state variables.internal: Accessible only within the current contract or derived contracts.private: Accessible only within the defining contract, not available in derived contracts.
Note: Everything in a contract is visible externally. private only restricts other contracts from accessing or modifying the information.
Visibility specifiers are placed after the type for state variables and between the parameter list and return keyword for functions.
pragma solidity ^0.4.16;
contract C {
function f(uint a) private pure returns (uint b) { return a + 1; }
function setData(uint a) internal { data = a; }
uint public data;
}Getter Functions
The compiler automatically generates getter functions for all public state variables. These functions have external visibility. When accessed internally, they are treated as state variables; externally, they are functions.
pragma solidity ^0.4.0;
contract C {
uint public data = 42;
}
contract Caller {
C c = new C();
function f() public {
uint local = c.data();
}
}For complex types like structs and mappings, getter functions return individual members, omitting mappings due to key specification challenges.
Function Modifiers
Modifiers alter function behavior, enabling automatic condition checks before execution. They are inheritable and can be overridden by derived contracts. Multiple modifiers are checked in order, separated by spaces.
pragma solidity ^0.4.11;
contract owned {
address owner;
function owned() public { owner = msg.sender; }
modifier onlyOwner {
require(msg.sender == owner);
_;
}
}
contract mortal is owned {
function close() public onlyOwner {
selfdestruct(owner);
}
}Modifiers can accept arguments, and super calls forward requests through the inheritance hierarchy.
Constant State Variables
State variables declared constant must be assigned compile-time constant expressions. Accessing storage, blockchain data, or executing external calls is disallowed. Allowed functions include keccak256, sha256, ripemd160, ecrecover, addmod, and mulmod. The compiler replaces constant variables with their values, reserving no storage.
pragma solidity ^0.4.0;
contract C {
uint constant x = 32**22 + 8;
string constant text = "abc";
bytes32 constant myHash = keccak256("abc");
}Functions
View Functions
Functions declared view promise not to modify state. State modifications include writing to variables, emitting events, creating contracts, selfdestructing, sending ether, calling non-view/pure functions, low-level calls, and specific assembly opcodes.
pragma solidity ^0.4.16;
contract C {
function f(uint a, uint b) public view returns (uint) {
return a * (b + 42) + now;
}
}Pure Functions
pure functions promise not to read or modify state. Reading state includes accessing state variables, balance, block, tx, msg members (except msg.sig and msg.data), calling non-pure functions, and certain assembly opcodes.
pragma solidity ^0.4.16;
contract C {
function f(uint a, uint b) public pure returns (uint) {
return a * (b + 42);
}
}Fallback Functions
Contracts can have a single, unnamed, parameterless, and return-less fallback function. It executes when no other function matches the call or when ether is sent with no data. To receive ether, it must be payable. Fallback functions have a limited gas budget (2300 gas), making cost efficiency critical.
pragma solidity ^0.4.0;
contract Test {
function() public { x = 1; }
uint x;
}
contract Sink {
function() public payable { }
}Function Overloading
Contracts can overload functions with different parameters. Overload resolution matches arguments to the best candidate through implicit conversions. External functions must differ by external types, not just Solidity types.
pragma solidity ^0.4.16;
contract A {
function f(uint8 _in) public pure returns (uint8 out) { out = _in; }
function f(uint256 _in) public pure returns (uint256 out) { out = _in; }
}Events
Events leverage EVM logging, allowing dapp user interfaces to react through JavaScript callbacks. Logs are address-associated and stored on the blockchain. Up to three parameters can be indexed, making them searchable. Non-indexed parameters are stored in log data.
pragma solidity ^0.4.0;
contract ClientReceipt {
event Deposit(address indexed _from, bytes32 indexed _id, uint _value);
function deposit(bytes32 _id) public payable {
Deposit(msg.sender, _id, msg.value);
}
}Low-level logging functions log0 to log4 provide direct log access.
Inheritance
Solidity supports multiple inheritance through code copying, including polymorphism. Functions are virtual, with the most derived version called. Inheritance linearization follows Python’s C3 linearization, requiring base classes ordered from "most base-like" to "most derived."
pragma solidity ^0.4.16;
contract owned {
function owned() public { owner = msg.sender; }
address owner;
}
contract mortal is owned {
function kill() public {
if (msg.sender == owner) selfdestruct(owner);
}
}
contract named is owned, mortal {
function named(bytes32 name) {
// Registration logic
}
function kill() public {
// Custom logic
super.kill();
}
}Base constructor arguments can be provided in the inheritance list or modifier-style in the derived constructor.
Abstract Contracts and Interfaces
Abstract contracts contain unimplemented functions (terminated with ;). They cannot be compiled directly but serve as base contracts. Interfaces are similar but stricter: no function implementations, inheritance, constructors, variables, structs, or enums.
pragma solidity ^0.4.11;
interface Token {
function transfer(address recipient, uint amount) public;
}Libraries
Libraries are deployed once and reused via DELEGATECALL, executing in the caller’s context. They cannot have state variables, inherit, be inherited, or receive ether. Library functions are attached to types using using A for B.
pragma solidity ^0.4.16;
library Set {
struct Data { mapping(uint => bool) flags; }
function insert(Data storage self, uint value) public returns (bool) {
if (self.flags[value]) return false;
self.flags[value] = true;
return true;
}
}
contract C {
using Set for Set.Data;
Set.Data knownValues;
function register(uint value) public {
require(knownValues.insert(value));
}
}Library calls are actual EVM calls, copying memory and value types. Storage references avoid copies.
Frequently Asked Questions
What is the primary purpose of a Solidity contract?
Solidity contracts act as self-contained entities storing data and functions on the blockchain. They enable decentralized applications by enforcing logic through code, facilitating trustless interactions between parties without intermediaries.
How do function modifiers enhance security?
Modifiers automate precondition checks, such as verifying sender identity or input validity, before function execution. This reduces code duplication and minimizes errors, ensuring critical conditions are consistently enforced across multiple functions.
Can libraries have state variables?
No, libraries are stateless by design. They cannot define state variables, inherit from other contracts, or receive ether. This ensures code reusability without compromising contract isolation or introducing unintended storage conflicts.
What happens if a fallback function is not payable?
Contracts without a payable fallback function reject direct ether transfers via send or transfer, throwing an exception. However, they can still receive ether through coinbase transactions or selfdestruct operations, which cannot be intercepted.
How does multiple inheritance resolve function conflicts?
Solidity uses C3 linearization to order base contracts, ensuring a deterministic method resolution order. The most derived function is called, and super forwards calls to the next base in the hierarchy, preventing ambiguity and diamond problem issues.
Why use interfaces over abstract contracts?
Interfaces provide a stricter abstraction, guaranteeing no implementation details exist. They are ideal for defining pure interfaces for external interactions, ensuring compliance with expected signatures without any underlying logic or state.