æternity Documentation Hub
AeternityGitHub
  • æternity Hub
  • Welcome to æternity documentation
  • Getting Started
    • What is æternity?
    • How to Use Aeternity
  • æternity core concepts
    • Introduction
    • æternity Protocol
      • æternity Coin
      • Fast Æternity Transaction Engine (FATE VM)
      • æternity Nodes
        • Node architecture
        • Node types
        • Node Roles
      • Transactions
        • Types of transactions
        • Transaction Lifecycle
        • Transaction Fees
        • Meta-transactions and Generalized Accounts
        • State Channel Transactions
      • Networks
      • Consensus Mechanisms
        • Next Generation Nakamoto Consensus (Bitcoin-NG)
        • Cuckoo Cycle Proof of Work
        • Hyperchains and Delegated Proof of Stake
        • Governance and Weighted Coin Voting
      • State Channels
      • Oracles
      • Aeternity Naming System (AENS)
    • Hyperchains
      • Hyperchains Whitepaper
    • Aeternity Governance
    • Aeternity Foundation
  • aeternity user tools and services
    • Introduction
    • Run an æternity node
    • Hyperchains web app
    • Hyperchains Bridge app
    • Mine aeternity coin
    • Superhero DEX
    • Superhero Wallet
    • ærc Bridge
    • Make an NFT
    • aepps: decentralized applications on æternity
    • æScan: æternity blockchain explorer
  • æternity Developer tools
    • Quick Start Guide
      • Development Environment Setup
      • Essential Tools Overview
      • Æternity Stack
      • First Steps in Development
    • Protocol
      • Core Protocol Components
        • æternity Consensus Protocol
        • Generalized Accounts
        • Smart Contracts
          • FATE VM
          • Smart contract languages
            • æternity Sophia Language
              • In-Depth Overview
              • Sophia Compiler
              • Sophia Visual Studio
              • Sophia http
              • æREPL
            • Solidity
          • Contract Transactions
        • State Channels
        • Oracles
      • Network Layer
        • Nodes
        • Sync
        • Gossip
        • Stratum
      • Utility Features
        • æternity Naming System (AENS)
        • Seralization Formats
    • æternity Sophia Language
      • In-Depth Overview
      • Sophia Compiler
      • Sophia Visual Studio
      • Sophia http
      • æREPL
    • Development Infrastructure
      • CLIs
      • SDKs and APIs
        • Javascript/Typescript SDK
        • Java SDK
        • Outdated SDKs
        • Node API reference
      • Middleware
      • Testing and Deployment
        • æproject
        • Testnets and Faucet
    • Token Standards
    • Aepps: Building apps on Aeternity
      • Boiler Plates
        • Angular Boiler Plate
        • React JS BoilerPlate
        • Vue BoilerPlate
    • Data and analytics
      • æScan
    • ÆRC Bridge
  • Hyperchains
    • Hyperchains Development Guide
    • Hyperchains Bridge
Powered by GitBook
On this page
  • What Makes Cuckoo Cycle Different
  • Technical Implementation
  • Difficulty Adjustment
  • Mining Process
  • Benefits for Network Security
  • Future Development

Was this helpful?

Export as PDF
  1. æternity core concepts
  2. æternity Protocol
  3. Consensus Mechanisms

Cuckoo Cycle Proof of Work

æternity uses Cuckoo Cycle as its proof-of-work algorithm, representing a significant departure from traditional proof-of-work systems. While many blockchain networks use computational puzzles that favor specialized hardware, Cuckoo Cycle is designed to be memory-bound rather than computation-bound, promoting more democratic participation in the mining process.

What Makes Cuckoo Cycle Different

Traditional proof-of-work algorithms like Bitcoin's SHA-256 are primarily limited by computational power, leading to an arms race in specialized mining hardware (ASICs). Cuckoo Cycle takes a different approach by making memory access speed the primary constraint. This choice has important implications for the network:

Memory latency doesn't improve as rapidly as computational power, reducing the advantage of specialized hardware over general-purpose computers. This characteristic helps maintain a more decentralized network by allowing broader participation in the mining process.

The algorithm requires miners to find cycles of a specific length in a large graph, making the mining process fundamentally different from traditional hash-based approaches. This graph-theoretic problem has proven to be both challenging to solve and easy to verify, making it an ideal candidate for proof of work.

Technical Implementation

In æternity's implementation, Cuckoo Cycle operates with specific parameters that balance security with efficiency:

The algorithm searches for cycles of length 42 in a graph defined by 30-bit edges. The ratio between the number of edges and nodes (set to 1/2 by default) helps control the difficulty of the problem. This configuration has been carefully chosen to provide the right balance between security and mining accessibility.

The final step of the mining process involves hashing the solution and comparing it to a difficulty target. This additional step allows for fine-grained control over block creation timing, ensuring consistent block production even as network conditions change.

Difficulty Adjustment

æternity implements an adaptive difficulty mechanism that helps maintain consistent block times:

The difficulty target is adjusted based on the timestamps of the last 17 blocks. While timestamps in a decentralized system can't be perfectly reliable, the protocol ensures that block timestamps cannot precede those of previous blocks.

Miners must meet the target difficulty specified in the previous block. Any block submitted with an incorrect difficulty target or failing to meet the required difficulty is rejected by honest nodes. This system ensures that the network can adapt to changes in total mining power while maintaining predictable block generation times.

Mining Process

The mining process in æternity follows these steps:

  1. A miner attempts to find a valid cycle in the graph defined by the Cuckoo Cycle parameters

  2. Upon finding a cycle, the solution is hashed

  3. The hash is compared against the current difficulty target

  4. If the hash meets the target requirement, the solution is valid and can be included in a key block

This process occurs only for key blocks in the Bitcoin-NG protocol, while micro blocks are generated without mining, allowing for rapid transaction processing between key blocks.

Benefits for Network Security

Cuckoo Cycle's memory-bound nature provides several security benefits:

Memory bottlenecks help prevent the centralization of mining power that has occurred in many other blockchain networks. The algorithm's requirements make it more practical for a diverse set of participants to contribute to network security.

The verification process is extremely efficient, reducing the overhead for nodes validating new blocks. This efficiency is particularly important in æternity's Bitcoin-NG implementation, where rapid block verification is essential for maintaining high transaction throughput.

Future Development

The Cuckoo Cycle implementation continues to evolve with the æternity platform. Ongoing research and development focus on optimizing the algorithm parameters and exploring potential improvements to further enhance decentralization and efficiency.

For developers and miners interested in participating in the network, understanding Cuckoo Cycle is essential as it fundamentally influences how new blocks are created and validated. The algorithm's unique properties contribute to æternity's goals of maintaining a secure, decentralized, and accessible blockchain platform.

PreviousNext Generation Nakamoto Consensus (Bitcoin-NG)NextHyperchains and Delegated Proof of Stake

Last updated 7 months ago

Was this helpful?