Formal Definition and Implementation of Classical Smart Contracts

Abstract

Smart contracts are a core component of blockchain systems, with widespread real-world applications. However, there is currently no unified definition of smart contracts, and implementations vary significantly across different blockchain platforms. This lack of standardization hinders public understanding and industry growth.

This study traces the evolution of smart contracts, analyzes their conceptual shifts, and summarizes their essence. We compare existing implementations and propose a formal definition of classical smart contracts, laying the groundwork for standardization. Additionally, we introduce a platform-agnostic implementation method, demonstrated on Hyperledger Fabric. Finally, we outline future research directions.

Introduction

Smart contracts, first proposed by Szabo in 1994 [[1]](#references), were initially defined as self-executing programs that enforce contractual terms without trusted third parties. Blockchain technology later provided the ideal decentralized environment for their execution.

Despite their adoption in fields like agricultural insurance (automating payouts for crop disasters) [[2]](#references) and healthcare data sharing (managing rights between patients, hospitals, and analysts) [[3]](#references), smart contracts lack precise definitions. Descriptions often rely on ambiguous natural language or equate them to "blockchain-based programs," diverging from their contractual roots.

This paper focuses on classical smart contracts—programmatically defined agreements. We address two key challenges:

1. How to formalize contractual logic for accurate representation.
2. How to bridge the gap between legal experts and developers.

Smart Contract Overview

1.1 Definitions

• Classical (Narrow) Definition: Programs that digitally enforce contractual obligations without intermediaries [[1, 5]](#references).

  • Example: A flight delay insurance contract automating payouts if delays exceed 4 hours.

• Broad Definition: Any program running on a blockchain [[7–12]](#references).

  • Example: Ethereum’s decentralized applications (dApps).

1.2 Implementations

| Platform | Language | Turing-Complete? | State Support | Use Case |
|------------------|----------------|-------------------|---------------|----------------------------|
| Bitcoin | Script | No | Limited | Basic transaction logic |
| Ethereum | Solidity | Yes | Yes | Complex dApps |
| Hyperledger Fabric | Go | Yes | No* | Enterprise solutions |
| EOS | C++, Rust | Yes | Yes | High-performance contracts |

*Fabric lacks native state support but can be extended (see Section 4).

1.3 Security Concerns

• Vulnerabilities like TheDAO hack (2016) [[15]](#references) and BEC token exploit (2018) [[16]](#references) highlight risks.
• Solutions include formal verification tools (e.g., ChainSafe) and audits.

Formal Definition

2.1 Commitments

A commitment is a quintuple C(x, y, p, r, tc):

• x: Promisor (e.g., insurer).
• y: Promisee (e.g., policyholder).
• p: Premise (e.g., flight delay >4h).
• r: Result (e.g., payout).
• tc: Time constraints (e.g., "payout within 24h").

States:

1. Activated (p = false, r = false).
2. Ready (p = true, r = false).
3. Fulfilled (p = true, r = true).
4. Expired (timeout without p).
5. Violated (timeout after p but no r).

👉 Explore real-world smart contract examples

2.2 Finite-State Machine Model

A smart contract is a state machine SC = (CC, A, S, s₀, δ, F):

• CC: Set of commitments.
• A: Actions (e.g., depositFunds).
• S: States (e.g., "Policy Active").
• s₀: Initial state.
• δ: Transition function.
• F: Terminal states.

Example: Flight insurance contract transitions:

1. s₀: Policy purchased (C₃: bas).
2. s₂: Premium paid (C₄: bas).
3. s₄: Payout triggered (C₇: sat).

Implementation

3.1 Algorithm

Input: Contract ID, caller ID, operation, signature.
Output: Success/failure.

1. Verify signature (verifySig).
2. Check operation validity (verifyOperation).
3. Update state (executeContract).
4. Commit to blockchain (saveContract).

3.2 Challenges

• External Data: Oracles (e.g., Oraclize) fetch trusted off-chain data (e.g., flight status).
• Performance: Fabric achieves sub-second latency in test environments.

Reference Implementation on Hyperledger Fabric

4.1 Architecture

• Chaincode: Go-based logic for blockchain interactions.
• State Machine: Custom layer tracking contract states.

4.2 Workflow

1. User submits a transaction (e.g., claimPayout).
2. Peer nodes simulate and endorse the transaction.
3. Orderers batch transactions into blocks.
4. Validated blocks are added to the ledger.

👉 Learn more about Hyperledger Fabric

Conclusion and Future Work

This paper formalizes classical smart contracts and provides a platform-agnostic implementation. Future work includes:

• Visual modeling tools for non-technical users.
• Automated translation from contract language to code (e.g., Solidity).

FAQs

Q1: What distinguishes classical smart contracts from broad definitions?

A: Classical contracts enforce specific agreements (e.g., insurance terms), while broad definitions include any blockchain program.

Q2: How do smart contracts handle real-world data?

A: They rely on oracles (trusted data feeds) for external information (e.g., weather APIs).

Q3: Can smart contracts be modified after deployment?

A: No—they’re immutable by design. Fixes require redeploying a new version.

Q4: What industries benefit most from smart contracts?

A: Insurance, supply chain, and healthcare due to their need for automated, tamper-proof agreements.

Q5: Are smart contracts legally binding?

A: Currently, they lack universal legal recognition, but frameworks like Ethereum’s ERC-20 are gaining traction.

References

1. Szabo, N. (1994). Smart Contracts.
2. Agricultural Insurance Case Study (2018).
3. Healthcare Data Sharing Model (2019).
   ... (Full references available in the original text.)