Skip to main content

Smart Contract Patterns

Adopt best practice patterns.

See example Audit Report from DeFi Safety

Read best practices in solidity

  1. Memorise the most common code patterns that lead to hacks
  2. Use established standards from established best practice auditors as much as possible

Common Patterns​

Sources for standardised patterns that are proven to be secure?

Behavioral Patterns​

  • Guard Check: Ensure that the behavior of a smart contract and its input parameters are as expected.
  • State Machine: Enable a contract to go through different stages with different corresponding functionality exposed.
  • Oracle: Gain access to data stored outside of the blockchain.
  • Randomness: Generate a random number of a predefined interval in the deterministic environment of a blockchain.

Security Patterns​

  • Access Restriction: Restrict the access to contract functionality according to suitable criteria.
  • Checks Effects Interactions: Reduce the attack surface for malicious contracts trying to hijack control flow after an external call.
  • Secure Ether Transfer: Secure transfer of ether from a contract to another address.
  • Pull over Push: Shift the risk associated with transferring ether to the user.
  • Emergency Stop: Add an option to disable critical contract functionality in case of an emergency.

Upgradeability Patterns​

  • Proxy Delegate: Introduce the possibility to upgrade smart contracts without breaking any dependencies.
  • Eternal Storage: Keep contract storage after a smart contract upgrade.

Economic Patterns​

  • String Equality Comparison: Check for the equality of two provided strings in a way that minimizes average gas consumption for a large number of different inputs.
  • Tight Variable Packing: Optimize gas consumption when storing or loading statically-sized variables.
  • Memory Array Building: Aggregate and retrieve data from contract storage in a gas efficient way.

Characteristics​

Smart Contract Characteristics

  • Verifiable
  • Trustless
  • Self-governing
  • Permissionless
  • Distributed and robust
  • Stateful
  • Native built-in payments

Development Flow​

Smart Contracts must be very throughly tested and audited before deployment to mainnet.

Re-use standard contracts that have passed the test of time.

  1. Checks Effects and Interactions
  2. Do checks to revert first to save gas.

Approach

  1. Use Scaffold Eth to experiment with proof of concept ideas quickly
  2. Polish and test Smart Contract business rules with Foundry
  3. Use Nextjs for Product UI/UX interface to Smart Contract ABIs

A Smart Contract's ABI is the product of compiling Solidity code (in the case of Ethereum).

Process​

Basic steps in Ethereum development:

  1. Write a Contract's business logic in Solidity
  2. Compile Solidity to produce the ABI
  3. Load the ABI in a frontend application
  4. Use libaries to interact with the ABI

Execute Functions​

To execute functions on a smart contract, you need to have:

  • Address
  • Contract ABI (Interaction Blueprint)
  • Function (to be called)
  • node connection (metamask)

Rules​

Contracts exist on a single network, but EVM code can be copied and pasted

Deploying a contract is a one way decision. You can't change the contract after it's deployed. Therefore Security/Trust is vitally important in the blockchain programming.

The best way to pick up good security habits is to read code of Established Ventures that have withstood the test of time and routinely review common hacks.

Transactions​

  • Cost (Ether Gas) money
  • Take time to execute - UX Implications
  • Returns a transaction hash

Structure​

Anatomy of a Smart Contract:

StackDescription
BalanceAmount of ether this account owns
StorageData stored on the contract
CodeMachine Code logic for how to process transactions that change the balance

Context​