Formal Definition for Classical Smart Contracts and Reference Implementation

Smart contracts are foundational to blockchain systems, enabling automated, trustless execution of agreements without intermediaries. Despite their widespread adoption across industries—from insurance to healthcare—there remains no universally accepted definition or standardized implementation. This lack of consensus creates confusion, hinders interoperability, and slows industry progress. This article presents a formal, mathematically grounded definition of classical smart contracts based on contractual commitments, introduces a platform-independent implementation framework, and demonstrates a working reference model on Hyperledger Fabric.

By bridging the gap between natural-language contracts and executable code, this work lays the groundwork for standardization, improved security, and broader accessibility in the smart contract ecosystem.

Understanding Classical Smart Contracts

At its core, a smart contract is a self-executing agreement with the terms directly written into code. First conceptualized by Nick Szabo in 1994, the idea remained theoretical until the emergence of blockchain technology provided a decentralized, tamper-proof environment for execution.

Unlike modern interpretations that treat any blockchain-based program as a smart contract, this article focuses on classical or contract-oriented smart contracts—those designed to digitally represent real-world legal or business agreements. These contracts must satisfy several essential properties:

Support complex business logic
Operate as a state machine
Execute autonomously
Produce verifiable and agreed-upon outcomes
Function without reliance on trusted third parties

This classical view contrasts with broader definitions where "smart contract" simply refers to any script running on a blockchain, regardless of whether it represents an actual agreement.

👉 Discover how blockchain enables trustless automation in modern financial systems.

The Need for a Formal Definition

Today’s smart contract implementations vary drastically across platforms:

Bitcoin uses a stack-based scripting language that is not Turing-complete, limiting functionality to simple transaction validations.
Ethereum supports full Turing-complete contracts via Solidity, allowing rich logic and persistent state.
Hyperledger Fabric runs chaincode (smart contracts) in Go, offering flexibility but lacking built-in state management.
EOS and BCOS support multiple programming languages and high-performance execution models.

These differences make it difficult to compare, verify, or port contracts across systems. Moreover, most descriptions rely on informal language, leading to ambiguity and vulnerabilities.

A formal definition addresses these challenges by:

Providing precise semantics for contract behavior
Enabling mathematical verification of correctness
Facilitating cross-platform compatibility
Supporting automated translation from human-readable terms

A Commitment-Based Model for Smart Contracts

To create a rigorous foundation, we define smart contracts using commitments—the fundamental building blocks of agreements. A commitment represents one party's obligation to another under certain conditions.

Definition: Commitment

A commitment $ C(x, y, p, r, tc) $ consists of five elements:

$ x $: Promisor (the one making the promise)
$ y $: Promisee (the recipient of the promise)
$ p $: Premise (a condition that must be met)
$ r $: Result (the action to be performed)
$ tc $: Time constraints (validity window)

Each commitment progresses through five possible states:

Active (act) – Awaiting premise fulfillment
Ready (bas) – Premise satisfied, awaiting result
Satisfied (sat) – Both premise and result fulfilled
Expired (exp) – Neither premise nor result achieved in time
Violated (vio) – Premise met but result not delivered on time

Time constraints are defined as a pair $ (pd_{act}, pd_{bas}) $:

$ pd_{act} $: Deadline for fulfilling the premise
$ pd_{bas} $: Deadline for completing the result after readiness

For example, in an airline delay insurance policy:

A passenger commits to buying a ticket within 24 hours
The insurer commits to depositing compensation funds if the flight is delayed over 4 hours
The system automates payouts based on verified flight data

These interdependent commitments form a network of obligations that collectively constitute a smart contract.

Smart Contract as a Finite State Machine

We formally define a smart contract as a finite state machine operating over a set of commitments.

Definition: Smart Contract

A smart contract $ SC = (CC, A, S, s_0, \delta, F) $ includes:

$ CC $: Finite set of commitments
$ A $: Set of actions (including timeouts)
$ S $: Finite set of states determined by commitment statuses
$ s_0 $: Initial state (all commitments active or ready)
$ \delta: S \times A \rightarrow S $: Transition function
$ F \subseteq S $: Set of terminal states

Each action (e.g., "deposit funds", "confirm flight delay") triggers a state transition. The entire contract evolves from initial to final state through valid transitions, ensuring all obligations are either fulfilled or properly resolved.

This model enables:

Clear visualization of contract workflows
Formal verification of correctness and termination
Detection of deadlocks or unreachable states
Automated compliance checking

General-Purpose Implementation Algorithm

To enable cross-platform deployment, we propose a generic algorithm for executing commitment-based smart contracts on any blockchain supporting programmable logic.

Core Execution Flow

invokeContract(contractID, invokerID, operation, sig):
  1. Load contract state from blockchain
  2. Verify digital signature of the caller
  3. Validate operation against current state and rules
  4. Execute state transition and update attributes
  5. Record operation and save new state to blockchain

Key features:

All operations require cryptographic authentication
Every state change follows predefined transition logic
Full audit trail preserved on-chain
External data (e.g., flight status) integrated via trusted oracles

Performance varies by platform:

Public blockchains (e.g., Ethereum): ~10-second finality
Consortium chains (e.g., Fabric): sub-second writes
Local test environments: hundreds of milliseconds per transaction

👉 See how developers are building next-generation dApps with secure smart contract frameworks.

Reference Implementation on Hyperledger Fabric

We implemented the airline delay insurance use case on Hyperledger Fabric, a permissioned blockchain widely used in enterprise settings.

Network Architecture

Our setup includes:

One channel with two organizations (insurer and platform operator)
Two peer nodes per organization
Three ordering nodes for consensus
Chaincode written in Go to manage contract logic

Fabric does not natively support contract state persistence across invocations. To overcome this limitation, we extended chaincode with explicit state management using key-value storage.

Smart Contract Program Structure

The implementation follows a modular design:

Initialization Module: Sets up contract instance and registers participants
Event Registration Module: Defines state transition rules
Event Response Module: Processes incoming events and updates state
Action Functions: Implement specific operations like buy_ticket, deposit, compensate

External data (flight delays) is submitted by authorized oracles. Multiple sources validate information before triggering payouts, enhancing trust and accuracy.

Once deployed, the system automatically executes compensation when qualifying conditions are met—eliminating disputes and reducing administrative overhead.

Security Considerations in Smart Contracts

Security remains critical. Historical incidents highlight risks:

The DAO attack (2017): Recursive call vulnerability drained $60M
BEC token exploit (2018): Integer overflow created trillions of fake tokens

Common vulnerabilities include:

Reentrancy attacks
Arithmetic overflows/underflows
Improper access control
Logic errors in state transitions

Best practices for mitigation:

Use formal verification tools
Conduct third-party audits
Implement circuit breakers and upgrade mechanisms
Limit gas usage and execution depth

Platforms like OKX provide advanced security tooling and monitoring to detect anomalies in real time.

👉 Learn how top platforms ensure smart contract safety before deployment.

Frequently Asked Questions (FAQ)

What is a classical smart contract?

A classical smart contract is a program that encodes real-world contractual agreements using formal logic. It emphasizes accurate representation of obligations, conditions, and outcomes—distinguishing it from general-purpose blockchain scripts.

How does this formal model improve security?

By modeling contracts as finite state machines with mathematically defined transitions, developers can verify correctness properties such as termination, absence of deadlocks, and compliance with business rules—reducing the risk of exploitable bugs.

Can this framework work on public blockchains like Ethereum?

Yes. While our reference implementation uses Hyperledger Fabric, the commitment-based model is platform-agnostic. It can be adapted to Ethereum, Solana, or other environments by mapping state transitions to native smart contract languages like Solidity or Rust.

How do external data sources (oracles) fit into this model?

Oracles provide verified real-world inputs—such as flight status or weather reports—that trigger state changes. In our model, oracle-provided data acts as events that drive transitions within the finite state machine.

Is user-friendly contract creation possible with this approach?

Yes. Future work includes developing visual modeling tools that allow non-programmers to define commitments using intuitive interfaces. These models can then be automatically compiled into executable code.

What are the next steps for standardization?

Standardization requires community adoption of common definitions, development of domain-specific languages for commitments, and integration with legal frameworks. This formal model provides a technical foundation for those efforts.

Conclusion and Future Work

This article presents a rigorous, commitment-based formal definition of classical smart contracts and demonstrates a practical implementation on Hyperledger Fabric. By treating contracts as finite state machines driven by verifiable actions and time-bound obligations, we enable greater clarity, security, and interoperability.

Future directions include:

Building visual modeling tools for non-developers
Creating compilers that translate commitment models into Solidity, Go, or Rust
Integrating legal ontologies to align digital contracts with regulatory requirements
Enhancing oracle networks for reliable off-chain data delivery

As smart contracts evolve from experimental tools to mission-critical infrastructure, formal methods will play an essential role in ensuring reliability, fairness, and trust in automated systems.

Core Keywords: smart contract, blockchain technology, formal definition, commitment model, state machine, Hyperledger Fabric, contract automation