State Machine Design Pattern in Solidity

The design patterns in programming are proven solutions to common problems, and the state machine is one such design pattern, particularly beneficial in developing Ethereum smart contracts using Solidity. It enables a contract to be in one of a finite number of states and transition from one state to another, following predefined rules.

Understanding the State Machine Pattern

The state machine pattern in Solidity can be visualized as a contract moving through distinct stages or ‘states’ in its life cycle. Each state represents a specific condition of the contract. At any given time, only one state is active, and the transition from one state to another is governed by functions or ‘transitions.’

These transitions often require specific conditions, ensuring secure and predictable behaviour. The state machine pattern is ideal for situations where a process follows a particular order or has distinct stages.

Implementing State Machine in Solidity: A Basic Example

To illustrate the state machine pattern, consider a simplified auction contract. This auction will have three states: Started, In Progress, and Ended.

pragma solidity ^0.8.4; 
 
contract Auction { 
    enum State { Started, InProgress, Ended } 
 
    State public state; 
 
    constructor() { 
        state = State.Started; 
    } 
 
    function startAuction() public { 
        require(state == State.Started, "Can't start the auction again."); 
        state = State.InProgress; 
    } 
 
    function endAuction() public { 
        require(state == State.InProgress, "Can't end the auction before it starts or after it has ended."); 
        state = State.Ended; 
    } 
}

In this contract, we have an enum State representing different states of the auction. The state variable is of State type, and it starts in the Started state. The startAuction function transitions the state from Started to InProgress, and endAuction transitions from InProgress to Ended.

Use Cases

A state machine is an excellent fit for contract design in scenarios where a system progresses through a sequence of states, each with different applicable rules and actions. Below are some use cases:

1. Crowdfunding campaigns: These campaigns typically have stages like Funding, Expired, and Successful. Each of these stages can correspond to states in a state machine, controlling actions like donating, withdrawing funds, and calculating payouts.
2. Auctions: As shown in the example above, auctions can progress through states such as Started, InProgress, and Ended, each with different rules for bidding and winning.
3. Supply Chain Contracts: A supply chain involves stages like Ordered, In Transit, Delivered, and Received, making it an ideal fit for a state machine pattern.

State Machine and Contract Upgradability

A crucial aspect of smart contract development is contract upgradability, particularly when utilizing the state machine design pattern. As contracts move through different states, the rules and logic governing these states might need to evolve, necessitating contract upgrades. It’s essential to design your contracts to allow for future improvements without losing the current state of the contract. Proxy patterns and upgradeability libraries like OpenZeppelin’s can come in handy.

Extending the State Machine Pattern

While the state machine pattern provides a robust foundation, it must often be extended or integrated with other design patterns for more complex contracts. For instance, you should incorporate the Access Control pattern to restrict who can trigger state transitions or the Reentrancy Guard pattern to secure your contracts against recursive attacks.

Let’s extend our auction contract only to allow the owner to end the auction.

pragma solidity ^0.8.4; 
 
contract Auction { 
    enum State { Started, InProgress, Ended } 
 
    State public state; 
    address public owner; 
 
    constructor() { 
        owner = msg.sender; 
        state = State.Started; 
    } 
 
    function startAuction() public { 
        require(state == State.Started, "Can't start the auction again."); 
        state = State.InProgress; 
    } 
 
    function endAuction() public { 
        require(msg.sender == owner, "Only the owner can end the auction."); 
        require(state == State.InProgress, "Can't end the auction before it starts or after it has ended."); 
        state = State.Ended; 
    } 
}

We added a owner variable to track who deployed the contract in this extended version. The endAuction function now includes an additional requirement only to end the auction.

Wrapping Up

The State Machine pattern in Solidity offers a strategic way to handle the different phases in the lifecycle of a smart contract. It fosters transparency and ensures that the transitions occur predictably and securely.

The state machine design pattern significantly reduces the complexity of smart contracts by clearly defining state transitions. However, the challenge lies in designing the transitions accurately and maintaining strict access control, as faulty design can potentially lead to compromised contract states.

As a developer, it’s crucial to carefully assess the system you’re designing and ensure the state machine pattern aligns with your needs. Remember, while patterns are tools to solve common problems, they are not a one-size-fits-all solution and should be used judiciously.

Stay tuned, and happy coding!

Visit my Blog for more articles, news, and software engineering stuff!

Follow me on Medium, LinkedIn, and Twitter.

Check out my most recent book — Application Security: A Quick Reference to the Building Blocks of Secure Software.

All the best,

Luis Soares

CTO | Head of Engineering | Blockchain Engineer | Web3 | Cyber Security | Solidity | Smart Contracts

#blockchain #solidity #ethereum #smartcontracts #designpatterns #datastructures #communication #protocol #data #smartcontracts #web3 #security #privacy #confidentiality #cryptography #softwareengineering #softwaredevelopment #coding #software