## **Developer's Guide**

**Ergo Platform Overview**

Ergo is a next-generation Proof-of-Work (PoW) blockchain platform designed for secure, efficient, and decentralized smart contract execution. It lays the foundation for a new wave of blockchain-based applications, focusing on scalability, security, and privacy. Ergo leverages advanced technologies like the powerful scripting language ErgoScript, flexible Zero-Knowledge Proofs, and the eUTXO model, an evolution of Bitcoin's UTXO model.

Get a concise overview of Ergo, its standout features, and the technology and decisions that power it on the Why Ergo? page.
Find answers to the most common questions about Ergo in our FAQ.

**Key Features**

**ErgoScript**: A simple high-level language that enables clear descriptions of contractual logic. ErgoScript supports the creation of flexible crypto-contracts based on Σ-protocols (a class of Zero-Knowledge Proofs), allowing for privacy-preserving transactions and complex smart contract functionality.

**Extended UTXO Model (eUTXO)**: The eUTXO model allows each UTXO to carry arbitrary data and be protected by an arbitrary predicate or spending condition. This flexibility enables the representation of various assets, tokens, and smart contract states within the blockchain.

**Mining with Autolykos**: Ergo utilizes Autolykos, an efficient, ASIC-resistant Proof-of-Work algorithm designed for a fair launch.

Learn about Ergo's Emission schedule.

**NiPoPoWs**: Short for Non-Interactive Proofs of Proof-of-Work, these are compact data structures that validate blockchain events without needing full network connectivity or downloading all block headers. They enable efficient light clients, log-space mining, and trustless sidechains.

**Storage Rent**: Also known as demurrage, this mechanism mitigates blockchain bloat and turns it into a profitable venture by charging for on-chain storage.

**Turing-Complete Smart Contracts**: Ergo supports Turing-complete smart contracts, enabling complex on-chain computations.


[📚 DeCo EU Layman Class - Basics of eUTxO: ](https://www.youtube.com/watch?v=SAWeW6wajEw) A great introductory course aimed at the layman from Decentralised Collaboration.

[🧾 Learning Ergo 101: eUTXO](https://dav009.medium.com/learning-ergo-101-blockchain-paradigm-eutxo-c90b0274cf5e)

[📹 Learning Blockchains like Cardano and Ergo 
](https://www.youtube.com/watch?v=HDn49bToTMI): Discusses the process of learning blockchain concepts, emphasizing the importance of understanding theoretical aspects and practical interaction through playgrounds and nodes.

**Transactional Model**

Ergo adopts a transactional approach similar to Bitcoin's UTXO model. In this model, transactions utilize and produce single-use entities known as 'boxes'. Every transaction in Ergo represents an atomic state transition, consuming boxes from the state and creating new ones in their place. The eUTXO model allows each UTXO to carry arbitrary data and be protected by an arbitrary predicate (or spending condition). The data can represent various tokens or smart contract states.

![](https://docs.ergoplatform.com/assets/ergo-model.png)


This image illustrates the structure and process flow of a blockchain transaction on the Ergo platform using its extended UTXO model (eUTXO).

**Boxes & Their Components**

[Registers within Boxes](https://docs.ergoplatform.com/dev/data-model/box/registers/): Boxes come equipped with multiple registers capable of holding various assets and complex ErgoScript types.

[**Assets in Ergo**](https://docs.ergoplatform.com/dev/data-model/box/tokens/): Dive deeper into the different assets that can be held within these boxes.

Ergo also supports advanced data structures like AVL+ Trees which can be used to store and authenticate large amounts of data on-chain.

**Transactional Basics**

**Tutorials & Guides**

[Ergo Platform Basic Starter Tutorial](https://docs.ergoplatform.com/dev/stack/basics/)

[Create & Send a Transaction](https://www.youtube.com/watch?v=Md5s-XV6-Hs): A video tutorial on creating and sending a transaction using AppKit.

[Sign a Transaction](https://docs.ergoplatform.com/tutorials/sign-tx/): Learn how to sign a transaction with Sigma Rust.

[Sending a Chained Transaction](https://docs.ergoplatform.com/tutorials/chained-tx/): A guide on sending a chained transaction using Ergpy.

[Getting Started with Fleet SDK:](https://fleet-sdk.github.io/docs/getting-started) A beginner's guide to the Fleet SDK.

**Tokens & NFTs**

[**Issuing a Token:**](https://docs.ergoplatform.com/dev/data-model/box/tokens/) A step-by-step guide on how to issue a token on Ergo.

[**Burning a Token:**](https://docs.ergoplatform.com/dev/tokens/burn/) Learn how to burn a token, effectively removing it from circulation.

[**Minting an NFT:**](https://docs.ergoplatform.com/dev/tokens/nfts/create/) A comprehensive guide on creating a Non-Fungible Token (NFT) on Ergo.

[**Minting an On-Chain NFT:**](https://docs.ergoplatform.com/dev/tokens/nfts/on-chain/) Don't want to rely on third-party storage? You can squeeze an NFT directly into the registers!

**ErgoScript**

ErgoScript is a super-simple subset of Scala, enabling clear descriptions of contractual logic that can be Turing-complete. It is flexible enough to allow for ring signatures, multi-signatures, multiple currencies, atomic swaps, self-replicating scripts, and long-term computation.

The Account model of Ethereum is imperative, meaning that sending coins from Alice to Bob requires changing balances in storage through a series of operations. In contrast, Ergo's UTXO-based programming model is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain, not changes to be made in the storage state as a result of the contract execution.

**Introduction**

[Quick Primer](https://docs.ergoplatform.com/dev/scs/ergoscript-primer/)

[Core Concepts of ErgoScript](https://docs.ergoplatform.com/dev/scs/ergoscript/ergoscript-key-concepts/)

[Sigma Language](https://docs.ergoplatform.com/dev/scs/sigma-lang/)

[Creating a Simple Pay-to-Script App](https://docs.ergoplatform.com/dev/scs/p2s/)


**Experimenting**

[escript.online](https://escript.online/)


[PlutoMonkey:](https://docs.ergoplatform.com/dev/stack/utilities/plutomonkey/) Compile any ErgoScript contract into a P2S. Check out these simple examples.

[Scastie:](https://docs.ergoplatform.com/dev/scs/ergoscript/scastie/) An online compiler tailored for Scala, perfect for developers eager to experiment, share, or learn Scala.

[Kiosk](https://docs.ergoplatform.com/dev/stack/kiosk): A web-based UI to explore ErgoScript.

[Ergo-Puppet](https://docs.ergoplatform.com/dev/scs/puppet/): An advanced tool built on the Ergo Playground, designed for off-chain experimentation and unit testing of Ergo contracts.

**Tooling**

[Ergo Development Generics Elements
](https://github.com/Ergo-Lend/edge)

[VSCode ErgoScript Language Support
](https://github.com/GuapSwap/vscode-ergoscript-language-support)

[ErgoScala](https://docs.ergoplatform.com/dev/stack/ergoscala/): A compiler for Ergo smart contracts written in ErgoScala (a subset of Scala).

[CLI Compiler](https://docs.ergoplatform.com/dev/stack/compiler/): A Command Line Interface tool to compile ErgoScript code into an Ergo address.

[FlowCards](https://docs.ergoplatform.com/dev/scs/flowcards/): A declarative framework for developing Ergo dApps.

[ergo-playgrounds](https://github.com/ergoplatform/ergo-playgrounds): Run contracts and off-chain code in the browser.

[ergo-script-re](https://github.com/ross-weir/ergo-script-re/tree/main): Libraries for Ergo Script reverse engineering and analysis.


**Courses**

If you're interested in deepening your understanding of ErgoScript and the Ergo ecosystem, consider taking one of the following courses:

DeCo Education: Into the Woods: This course provides a comprehensive introduction to the Ergo ecosystem.

ErgoScript 101 Crash Course (Slides): A crash course covering the basics of ErgoScript, perfect for beginners.

Learn ErgoScript By Example Via The Ergo Playground with Robert Kornacki (Video): This video tutorial offers practical examples of how to use ErgoScript in the Ergo Playground.

DeCo-Education/ErgoScript-Developer-Course: A more advanced course for developers looking to build on their ErgoScript knowledge.

**Tutorials**

ErgoScript by Example Repository

Testing Ergo Contracts Off-chain

Debugging ErgoScript

ergo-playground: A collection of miscellaneous scenarios implemented on the Ergo blockchain.

**Boilerplate**

scala-play-next-ergo

ergo-scala-skeleton-app

The Ergo Web Template: An introductory guide for individuals new to Ergo, offering a hands-on experience with essential Ergo functionalities.

Ergo-play-boilerplate

**Advanced Tutorials**

ErgoScript Tutorial

Advanced ErgoScript Tutorial

**Interpreters**

ErgoScript has two compiler and ErgoTree interpreter implementations for the Sigma Language:

Sigmastate-interpreter: For JVM languages, utilized by AppKit.

Sigma-Rust: A simpler alternative for the ErgoTree interpreter and transaction tools.

**Cryptography**

Ergo has generic support for ring and threshold signatures, as well as a variety of cryptographic protocols via composable sigma-protocols built into the core.

Sigma Protocols (Σ-Protocols) are the foundation of Ergo’s smart contracts. Their advantage is that they are composable using simple AND/OR logic. When combined with a blockchain, these composable proofs enable very powerful use cases, allowing for the implementation of sophisticated tasks that would otherwise be impossible, risky, or expensive on other platforms.

Crypto Primitives#
Hash Functions:

Sha256: Secure Hash Algorithm 256-bit.
Blake2b256: A cryptographic hash function faster than MD5 and SHA-256, providing security similar to the strongest hash functions available.
Encoding:

Base58: A binary-to-text encoding scheme used for encoding Bitcoin addresses and other text-based data.
Signing Algorithms:

ECDSA (secp256k1): Elliptic Curve Digital Signature Algorithm over the secp256k1 curve, widely used in Bitcoin and other cryptocurrencies.
Schnorr: A digital signature scheme that is simple, provably secure in the random oracle model, and allows for the aggregation of multiple signatures into a single signature, enhancing efficiency and privacy.
Primitive Secrets:

Schnorr Signature: A proof of knowledge of a discrete logarithm with respect to a fixed group generator.
Diffie-Hellman Tuple: A proof of equality of discrete logarithms, enabling secure exchange of cryptographic keys over a public channel.
Non-Interactive Proofs:

The proofs of sigma-statements are made non-interactive with the Fiat-Shamir transformation, which converts an interactive proof of knowledge into a non-interactive one by using a cryptographic hash function.
Additional Cryptographic Standards:

EIP-0003: Deterministic Wallet Standard: A standard defining the structure and operation of deterministic wallets in the Ergo platform.
See this page for a description of the global cryptographic functions available in ErgoScript.

**Tutorials**

Creating a 3-out-of-5 Threshold Signature

Message Signing and User Authentication

Verifying Schnorr Signatures in ErgoScript

Updateable Multisig Pattern

Making and Implementing a Signature, Elliptic Curves, and Extended Keys: Ergo with C#

**Tools**

Scrypto: A comprehensive open-source cryptographic toolkit, specifically engineered to simplify and safeguard the process of integrating cryptography into your applications. Supports AVL+ Trees and Batch Merkle Proof Serialization and Deserialization.

**Advanced Concepts**

**Merkle Trees**

Merkle Trees are a fundamental data structure in the Ergo blockchain, ensuring the integrity and authenticity of data. They play a crucial role in various blockchain operations, from verifying transactions within blocks to securing additional metadata in the Extension Block. Ergo extends the concept of Merkle Trees by combining transactions and their corresponding spending proofs into a single Merkle Tree.

Developers should familiarize themselves with Merkle Trees and their associated code implementations to effectively leverage them in their Ergo projects.

**AVL Trees (Plasma)**

AVL trees are highly efficient authenticated data structures natively supported in Ergo. These trees offer several benefits, including the ability to authenticate data properties without accessing the entire dataset. Developers can seamlessly integrate AVL trees into their Ergo applications using one of the Plasma libraries.

**Multi-Stage Protocols**

Multi-Stage Contracts is a technique where, using transaction trees, we can emulate persistent storage in UTXO-based systems by linking several UTXOs containing small pieces of code to form a large multi-stage protocol. This enables on-chain computations, making it possible to process parallelized actions on top of smart contracts and construct Turing-complete applications.

**App Development**

Developers have a plethora of tools, libraries, SDKs, frameworks, and utilities at their disposal to seamlessly interact with the blockchain, craft applications, and present them to users. Navigate through the Developer Section to use grid buttons that help refine your technical stack requirements and pinpoint the ideal tooling.

If you're aiming to develop a comprehensive decentralized application on Ergo, consider the following SDKs and frameworks tailored to your specific needs:

As a spreadsheet!

Most repositories are also categories on Grist. This is a great place to start if you're looking for a specific repository or want to see what's currently being worked on.

**Primary SDKs**

AppKit: The go-to SDK for JVM developers, supporting Java, Scala, Kotlin, and Mobile platforms.

General Example
Using AppKit with Python
AppKit by Example
Fleet SDK: A pure JS library designed for effortless Ergo transaction creation.

Getting Started with Fleet SDK
The Ergo Web Template: An introductory guide for individuals new to Ergo, offering a hands-on experience with essential Ergo functionalities.
SigmaRust: An ErgoTree interpreter with transaction tools and bindings for JS/TS/Swift/Java/C/Ruby.

Address Generation Demo
Create Transaction Demo
**Alternative SDKs**

Ergpy: A Python-JVM wrapper facilitating interactions with the Ergo blockchain.

Mosaik: A dedicated UI system crafted for Ergo dApps.

JSON dApp Environment

Headless dApp Framework: A Rust-based framework for creating Ergo Headless dApps, marking the debut of a portable UTXO-centric headless dApp development framework on any blockchain.

RustKit (In Development): An upcoming toolkit aiming to align the Rust development experience with the JVM.

**Payments**

ErgoPay: Ergo's dApp connector for non-web wallets.

dApp Connector: For connecting dApps to web-based wallets like Nautilus and SAFEW.

Proxy Contracts: A smart contract design used in blockchain ecosystems to enable secure and controlled interaction between users and decentralized applications.

**Libraries**

ergo-lib-go: Go wrapper around C bindings for ErgoLib from sigma-rust.

ergo-lib-wasm: Ergo-lib bindings for JS/TS.

ergo_client: Rust library containing HTTP clients for various Ergo applications.

sigma-builders: Easy-to-use library for creating protocol abstractions interacting with the Ergo blockchain.

**Templates**

[📕 Side Tooling for Building dApps on Ergo](https://dav009.medium.com/ergo-101-side-tooling-for-building-dapps-on-ergo-c71889d60826): Building functional dApps on Ergo requires more than just smart contracts and transactions.

[📕 DeCo Education: DApp Components - Backend](https://deco-education.github.io/deco-docs/docs/into-the-woods/trail2-ergo-coding/dapp-components)

[📕 DeCo Intro Lessons: Build a Mobile App on](https://www.youtube.com/watch?v=qR0_k7VH6KI&list=PLopsKGshj0B4BpMoSMh5hQk8gVfWk-si6)


**Ergo Infrastructure**

**Ergo Node & Network**

Ergo Node: The Ergo Node forms the core of Ergo's P2P network, maintaining and synchronizing the entire blockchain.
Bootstrap from UTXO Snapshot: Expedite the setup of a pruned full node on the testnet by bootstrapping from a UTXO snapshot.
Fork Your Own Chain: Learn how to customize and create your own chain with specific parameters.
API & Programmatic Access#
Node API: Gain a comprehensive overview of the Ergo node API functionalities.
Public APIs: If you prefer not to run your own node, you can utilize these public APIs for a variety of functionalities.

**Explorers**

Public Explorers can be accessed at explorer.ergoplatform.com and testnet.ergoplatform.com.

Delve deeper into blockchain data with GraphQL.

Explorer & Node Bundles: Install both locally for a comprehensive blockchain experience.

uExplorer: A lightweight Ergo explorer backed by CassandraDB.
Blockchain Explorer with Raspberry Pi: Learn how to set up an explorer using Raspberry Pi.

**Toolkits**

danaides: A high-performance blockchain toolkit.
Off-chain#
Bootstrap an Oracle Pool on Testnet

Running Off-chain Bots

**Documentation & Reports**

Foundational Papers: Explore the academic and technical papers that laid the groundwork for Ergo.

EF Transparency Report: Gain insights into the Ergo Foundation's operations and transparency initiatives.

Ergo's Social Contract: Delve into the principles and commitments that guide Ergo's community and development.

Howey Test Analysis: Understand how Ergo measures up against the Howey Test for securities.


[📚 DeCo Intro Lessons](https://www.youtube.com/watch?v=qR0_k7VH6KI&list=PLopsKGshj0B4BpMoSMh5hQk8gVfWk-si6): Programming basics for the layman from Decentralised Collaboration (DeCo).

[📚 DeCo Education Docs
](https://deco-education.github.io/deco-docs/docs/category/into-the-woods): 
DeCo steps you through eUTXO & NFTs, dApp Development, and Multi-Stage Transactions & Smart Contracts.

[📹 Ergo Blockchain Crash Course](https://www.youtube.com/playlist?list=PL8-KVrs6vXLTVXGwmYXjOBRx3VymB4Vm2)

Ergo crash course presented by developer Luca (lgd), covering the eUTXO model, anatomy of Ergo, and more.

Ergo Community Resources#
Analytics & Insights#
Ergo Watch: Dive into on-chain analytics and data.
Community Knowledge Base#
Ergonaut Space: Discover Ergo's community-driven wiki, filled with insights and information.
Explore the Ecosystem!#
Sigmaverse.io: Explore a diverse range of dApps built on Ergo.

ErgCube: Another platform to discover and interact with Ergo dApps.

The Ecosystem section on this site acts as a directory for projects building on Ergo and potential future ideas.

Ergo Platform

Developer's Guide

## **Students**

If you're a student interested in learning about the Ergo blockchain and its ecosystem, this guide is designed to provide you with a comprehensive introduction and valuable resources to kickstart your journey.

**Intersections with Computer Science**

As a student, you have the opportunity to leverage your academic knowledge in computer science and apply it to the innovative field of blockchain development, particularly with the Ergo platform. This section explores the intersections between various computer science disciplines and the tasks involved in building and maintaining blockchain systems, enabling you to bridge the gap between theory and practice.

**Databases**: Utilize your skills in relational and non-relational database systems to build blockchain indexers and manage transactional data on the Ergo platform. The UTXO model in Ergo provides a unique perspective on data management and state representation.
Programming Languages: Develop smart contracts using ErgoScript, a powerful language designed for the Ergo blockchain. Leverage your knowledge of functional programming, domain-specific languages, and language design principles to contribute to the evolution of ErgoScript and its compilers.

**Networks:** Engage with the peer-to-peer (P2P) layer of Ergo, drawing upon your expertise in distributed systems and network architecture. Understanding Ergo's consensus mechanism and network protocols will enhance your ability to optimize and secure the network.

**Systems Programming:** Explore the low-level operations of the Ergo platform, focusing on how ErgoTree scripts are executed and how the sigmastate-interpreter functions. This will deepen your understanding of blockchain systems programming.

**Compiler Design:** Apply principles of language design and compiler development to create or enhance smart contract tooling for ErgoScript. This involves understanding the compilation process from high-level ErgoScript to low-level ErgoTree.

**Backend Systems:** Develop API endpoints for Ergo nodes, utilizing your skills in server-side programming and database integration. This will support the interaction between decentralized applications and the Ergo blockchain.

**Operating Systems:** Contribute to the infrastructure and performance optimization of Ergo nodes by addressing challenges related to concurrency, resource management, and low-level system interactions. The unique storage rent feature in Ergo offers an interesting case study in resource management.

**DevOps:** Deploy and maintain decentralized application infrastructure on the Ergo platform by leveraging skills in automation, containerization, and cloud services. This ensures robust and scalable blockchain solutions.

**Cryptography:** Design secure transactions and privacy-preserving features on Ergo by implementing advanced cryptographic algorithms and protocols. Ergo's use of Sigma protocols and other cryptographic techniques provides a rich area for exploration.

**Security:** Implement privacy-enhancing protocols on the Ergo platform by employing cryptographic techniques such as Sigma protocols and zero-knowledge proofs. These are integral to ensuring the security and privacy of transactions on Ergo.

**Getting Started**

Before diving into the technical aspects, it's essential to understand the fundamental concepts and principles behind Ergo. Here are some recommended resources to help you get started:

**Why Ergo?:** Get a concise overview of Ergo, its standout features, and the technology and decisions that power it.

**Ergo Platform Overview**: Explore the key features of Ergo, including ErgoScript, the eUTXO model, Autolykos, NiPoPoWs, and more.
FAQ: Find answers to the most common questions about Ergo.

**Introductory Resources**: Check out the recommended introductory videos, courses, and resources to gain a solid foundation in blockchain technology and Ergo.

**Chatbots**: Chatbots can provide quick information access but have limitations. The Ergo chatbots are trained on documentation and may hallucinate or err on topics outside their training data. For general Ergo or ErgoScript questions, try the General Ergo Chatbot or ErgoScript Chatbot. For complex or in-depth queries, refer to official documentation, engage with the community, or seek guidance from experienced developers.
Engaging with the Ergo community and collaborating with other students and developers can greatly enhance your learning experience. Here are some ways to get involved:

**Connect with the Community**: Join the Ergo community on Discord, participate in hackathons, and explore contribution opportunities.

**Ergonaut Space**: Explore the community-driven wiki filled with insights and information about Ergo.

**Ergo Forum**: Participate in discussions, ask questions, and share your knowledge on the Ergo Forum.

**GitHub Repositories:** Explore the official Ergo repositories on GitHub and contribute to open-source projects.
Remember, learning is a continuous journey, and the Ergo ecosystem is constantly evolving. Stay curious, engage with the community, and don't hesitate to ask questions or seek guidance from experienced developers and contributors.

**Learning ErgoScript**

ErgoScript is a powerful scripting language that enables the creation of flexible crypto-contracts based on Sigma Protocols, a class of Zero-Knowledge Proofs. Learning ErgoScript is crucial for understanding and developing on the Ergo blockchain. Here are some resources to help you get started:

**ErgoScript Primer**: A quick introduction to ErgoScript and its core concepts.

**Sigma Language**: Learn about the Sigma Language, the foundation of ErgoScript.

**Creating a Simple Pay-to-Script App**: A hands-on tutorial for creating a simple pay-to-script application.

**Experimenting with ErgoScript**: Explore various tools and platforms for experimenting with ErgoScript, such as escript.online, PlutoMonkey, Scastie, Kiosk, and Ergo-Puppet.

**ErgoScript Tooling:** Discover various tools and libraries for working with ErgoScript, including compilers, language support, and frameworks.

**ErgoScript Courses**: Consider taking one of the recommended courses to deepen your understanding of ErgoScript and the Ergo ecosystem.




Students

## **The Ergo Data Model**

This document provides a comprehensive and in-depth exploration of Ergo's unique data model, based on the UTXO (Unspent Transaction Output) model, enhanced with powerful smart contract capabilities (eUTXO).

**1. Theoretical Foundations & Core Concepts** 

**1.1 Computational Model Evolution & UTXO vs. Account Model**

Ergo represents a significant advancement in blockchain computational models, extending the traditional Unspent Transaction Output (UTXO) paradigm through its enhanced eUTXO (Extended UTXO) model. Unlike conventional blockchain architectures, Ergo's model introduces:

Programmable State Transitions: Enabling complex computational logic within transaction outputs. This contrasts with the account-based model used in other blockchains (like Ethereum), where state is globally mutable. See UTXO Model Explained for a comparison of Ergo's model in terms of parallelism, privacy, and scalability.

**Stateless Verification**: Allowing efficient validation without maintaining complete blockchain state.
Deterministic Execution: Ensuring predictable and verifiable transaction outcomes.

**1.2 Fundamental Design Principles**

Computational Completeness: Supporting Turing-complete smart contract execution within strict cryptographic constraints.
Cryptographic Composability: Enabling complex cryptographic protocols through Sigma Protocols.
Scalable State Management: Designing a model that supports parallel transaction processing and efficient state verification.

**2. Blockchain Structure: Components and Function**

A solid understanding of the blockchain structure lays the groundwork for exploring Ergo’s data model. Ergo blocks contain critical metadata, transactions, and proofs.

**2.1 Block Components**

Block Overview: Comprehensive introduction to block structure in Ergo, detailing how blocks aggregate transactions, references, and proofs.
Block Header: Detailed examination of block header components, which include references to previous blocks, difficulty, and other crucial metadata.
Block Transactions: Understanding how transactions are organized within a block to form the ledger state.
AD Proofs: Authenticated Data Proofs enable efficient stateless client verification by providing cryptographic proofs of state transitions.

**Extension Section**: An exploration of Ergo’s flexible data storage section that can hold additional metadata and information beyond basic transactions.

**3. Boxes: Foundational State Units**

At the core of Ergo's data model is the "Box," which is Ergo's implementation and extension of the UTXO (Unspent Transaction Output) concept. While traditional UTXOs simply track unspent coins, Ergo's Boxes enhance this model with additional programmable capabilities.

**3.1 The Box Concept**

A Box is essentially a "smart UTXO" - it serves the same role as a UTXO in tracking unspent value, but extends this with sophisticated computational features. Like a UTXO, a Box is created when value is sent in a transaction and is consumed (spent) when that value is transferred elsewhere. However, Boxes add the following capabilities that go beyond basic UTXOs:

Immutable State: Each box represents an atomic, immutable state unit that cannot be modified after creation. See Box Lifecycle for details on creation, spending, and destruction.

Typed Registers: Boxes contain 10 registers (R0-R9) with specific purposes and rich computational potential:

**R0:** Monetary Value (in nanoERGs)

**R1:** Protection Script (Smart Contract)

**R2**: Assets/Tokens

**R3**: Creation Details

**R4-R9**: Flexible, Typed Custom Data Storage
Supports multiple data types: Int, Long, BigInt, GroupElement, Coll[Byte]
Can store complex structures and collections
Densely packed with type-safe access
Programmable Spending Conditions: Each box specifies precise conditions under which it can be spent, enabling complex logic through ErgoScript. See Box Modeling and Box Overview for detailed exploration.

By transforming UTXOs from simple value trackers to programmable state containers, Ergo enables more expressive and flexible blockchain interactions while maintaining cryptographic integrity and computational efficiency.

**4. Transactions: Engines of State Change**

Transactions define how boxes are created, transformed, and consumed, and are central to Ergo’s dynamic state evolution.

**4.1 Transaction Foundations**

Transaction Overview: Fundamental principles of how transactions work in Ergo.
Transaction Composition: Detailed guide to constructing complex transactions off-chain before submitting them on-chain.
Transaction Format: Technical specification of transaction structure, ensuring interoperability and standardization.

**4.2 Advanced Transaction Mechanisms**

Chained Transactions: Explore how sequentially dependent transactions can be composed.
Merkle Tree in Transactions: Understanding how Merkle trees provide data integrity and facilitate efficient proofs.
Transaction Signing and Backend Signing: Cryptographic principles and implementations for authenticating transactions.
Transaction Validation: Comprehensive overview of on-chain verification processes that ensure correctness and adherence to protocol rules.

**4.3 Specialized Transaction Features**

Data Inputs (Read-Only Inputs): Access additional data in transactions without spending boxes.
Transaction Fees: Understanding fee structures, ensuring that miners are incentivized.
Babel Fees and Babel Fees Plugin: Innovative mechanisms allowing fees to be paid in alternative tokens.

**5. Assets and Tokens: Powering a Diverse Economy**

Ergo supports a rich ecosystem of assets, from fungible tokens to NFTs, enabling complex economic models.

**5.1 Fungible Tokens**

Token Basics: Introduction to tokens within the Ergo ecosystem and their fundamental characteristics.
Asset Standard (EIP-4): Standard for creating and managing tokens in Ergo.
Token Verification (EIP-21): Ensuring token authenticity and integrity.

**5.2 Non-Fungible Tokens (NFTs)**

NFT Overview: Comprehensive introduction to NFTs on Ergo.
NFT Creation: Guide to minting NFTs.
NFT Versions (V1 vs V2): Comparison of different NFT implementation standards.
On-Chain NFTs: Storing NFT data directly on the blockchain.
NFT Royalties: Mechanisms for continuous compensation to creators.

**5.3 Special Token Concepts**

Perpetual Tokens: Tokens designed to exist indefinitely.
**Token Burning**: Permanently removing tokens from circulation.

**Singletons:** Unique tokens with special properties.

**Auction Contract (EIP-22):** Standard auction contract implementation details.

**Artwork Contract (EIP-24):** Specialized standard for managing digital artwork tokens.

**6. Addressing and Identity**

Ergo uses an address system that ensures security, privacy, and flexibility.

Address Basics: Fundamental concepts of Ergo addresses, including encoding, format, and usage
Address Types: Detailed overview of Pay-to-Public-Key (P2PK), Pay-to-Script-Hash (P2SH), and Pay-to-Script (P2S) address types
Address Validation: Methods and best practices for validating Ergo addresses, including checksum verification and format validation

**7. Payment Standards and Protocols**

Ergo defines protocols to streamline user interactions with wallets and applications.

ErgoPay Protocol (EIP-20): Interaction protocol for mobile wallets and dApps.
Payment Request URI (EIP-25): Standard format for payment requests.
Proxy Contracts (EIP-17): Mechanisms to manage funds and logic via intermediary contracts.

**8. Cryptographic Foundations**

Ergo’s cryptographic design ensures robust security, privacy, and flexibility.

**8.1 Sigma Protocols**

Non-interactive Zero-Knowledge Proofs: Private transaction verification without revealing sensitive data.
Flexible Signature Schemes: Supporting multiple signature types.
Privacy-Preserving Mechanisms: Advanced features to protect user privacy.

**8.2 Cryptographic Primitives**

Discrete Logarithm Proofs: Foundational to signature verification.
Ring Signatures: Enhanced privacy through signer ambiguity.
Threshold Signatures: Enabling multi-party computational scenarios.

**9. Verification, Consensus, and Sustainability**

**9.1 Transaction Validation and Script Execution**

Ergo employs a robust, stateless transaction validation approach:

Transaction Construction & Signing: See Transaction Composition, Transaction Format, and Signing.
On-Chain Verification: Transaction Validation and Merkle Proofs.
Script Validation: Detailed in Script Validation and ErgoScript Language Specification.
Execution Environment: Access blockchain state via Context Variables, ensure deterministic evaluation, and apply cost constraints.

**9.2 Consensus Algorithm & Storage Rent**

Difficulty Adjustment: A dynamic mechanism that adjusts mining difficulty every block to maintain a target block time of approximately 2 minutes, ensuring network stability and predictable block creation despite fluctuations in mining power. See this page for technical details.
Storage Rent Mechanism: A novel approach that prevents blockchain bloat and ensures long-term sustainability by requiring users to pay rent for storing data on-chain. See this page for details on implementation, fees, and economic incentives.

**10. Data Structures and Performance**

General Data Structures
Proof of Proof-of-Work (PoPow): Consensus mechanism enhancement for light clients.

**10.1 Authenticated Data Structures**

Merkle Trees for efficient state commitment.
Merkle Batch Proof
Merkle Extension
Merkle Light Proof
AVL+ Trees for authenticated key-value storage.
Interlink Vectors: Lightweight blockchain verification.
AD Proofs: Supporting stateless clients.

**10.2 Scalability and Efficiency**

Parallel transaction validation inherent in the eUTXO model.
Stateless validation reduces computational and storage overhead.
Just-in-time costing ensures resource use is always checked.
For more information see the scaling section.

11.**Advanced Concepts: Mastering Ergo's Capabilities**

**11.1 Multi-Stage Transactions**

Multi-Stage Transactions: Understanding how to design and implement complex, multi-step transaction flows.

The Ergo Data Model

## **The Ergo 'Box' model**

Ergo uses a transactional model similar to Bitcoin's Unspent Transaction Output (UTxO) model. In this model, transactions create and consume single-use entities called 'boxes'.

In ErgoScript, a 'box' is a versatile version of a UTXO. It represents not only the amount of cryptocurrency owned by an address, but also contains 'registers' for additional data. This data can range from simple values to complex structures, which can be used in transactions and smart contract execution.

This makes Ergo's box different from a traditional UTXO, which only represents an amount of unspent cryptocurrency associated with a certain address. In UTXO-based cryptocurrencies, each transaction consumes one or more UTXOs as inputs and creates one or more UTXOs as outputs, with the 'unspent' outputs being the 'coins' that can be spent in future transactions.

The term 'box' in Ergo's context captures the idea that these entities are like containers holding various types of information (value, tokens, custom data, etc.), beyond just the unspent transaction output balance. This makes the boxes in Ergo significantly more flexible and functional, enabling more complex operations, such as running scripts or smart contracts, directly on the blockchain.

**Key Points**

A box is an immutable unit, which can be created or removed, but never altered.
The box is not just a simple coin; it houses data, code, and registers, with all of its contents exclusively stored in the registers.
Four pre-defined registers contain the box's monetary value, its protection script, and the ID of the transaction that created the box.
Each box has a unique ID, derived from the unique contents of the box, including the data of the transaction that created it.
Boxes are integral to the Ergo protocol. The active box set is authenticated through a hash-based data structure, facilitating the development of lightweight full nodes, as detailed in this paper.
A box can hold up to six additional registers with typed data, accessible by the script.
Transactions consist of both input and output boxes.

**An example box**

Consider the 'proof-of-no-premine' from the Ergo genesis state. This box contains the last block IDs from Bitcoin and Ethereum at the launch time, as well as the latest news headlines:

`     {
    "boxId": "b8ce8cfe331e5eadfb0783bdc375c94413433f65e1e45857d71550d42e4d83bd",
    "value": 1000000000,
    "ergoTree": "10010100d17300",
    "assets": [],
    "creationHeight": 0,
    "additionalRegisters": {
      "R5": "0e42307864303761393732393334363864393133326335613261646162326535326132333030396536373938363038653437623064323632336337653365393233343633",
      "R6": "0e464272657869743a20626f746820546f727920736964657320706c617920646f776e207269736b206f66206e6f2d6465616c20616674657220627573696e65737320616c61726d",
      "R8": "0e45d094d0b8d0b2d0b8d0b4d0b5d0bdd0b4d18b20d0a7d0a2d09fd09720d0b2d18bd180d0b0d181d182d183d18220d0bdd0b02033332520d0bdd0b020d0b0d0bad186d0b8d18e",
      "R7": "0e54e8bfb0e8af84efbc9ae5b9b3e8a1a1e38081e68c81e7bbade38081e58c85e5aeb9e28094e28094e696b0e697b6e4bba3e5ba94e5afb9e585a8e79083e58c96e68c91e68898e79a84e4b8ade59bbde4b98be98193",
      "R4": "0e403030303030303030303030303030303

0303031346332653265376533336435316165376536366636636362363934326333343337313237623336633333373437"
    }
  }
`

**Additional Box Functions**

Besides the registers, each box features a unique identification hash that can be referenced using the id function. Box ids are computed by applying the blake2b256 hash function to the box's content, expressed as a Coll[Byte]. You can directly access the un-hashed byte collection representing a box using the bytes function. Note that each box’s content and id are cryptographically unique, meaning that no two boxes within the blockchain can share the same id or content bytes. This uniqueness is guaranteed by the inclusion of creationInfo in each box, as transaction ids and associated output indexes must be unique to a given UTXO. The bytesWithoutRef function can be used to retrieve a Coll[Byte] that excludes such information.

**Example**

`{
    // Retrieve the value and token multipliers from the registers of the current box
    val valueMultiplier = SELF.R4[Int].get
    val tokenMultiplier = INPUTS(1).R4[Int].get

    // Check if the current box is the same as the first input box
    if(SELF.id == INPUTS(0).id){
        // If it is, check if the output box has the correct value and token amounts
        val outputValue = OUTPUTS(0).value == SELF.value * valueMultiplier 
        val outputTokens = OUTPUTS(0).tokens(0)._2 == SELF.value * tokenMultiplier 
        // Return a Sigma proposition that is true only if both outputValue and outputTokens are true
        sigmaProp(outputValue && outputTokens)
    }else{
        // If the current box is not the same as the first input box, check if the output goes to a specified address
        val outputGoesToCheese = {
            // Create a public key that corresponds to a specific address
            PK("9etXmP7D3ZkWssDopWcWkCPpjn22RVuEyXoFSbVPWAvvzDbcDXE").propBytes
                == OUTPUTS(0).propositionBytes
        }
        // Return a Sigma proposition that is true only if outputGoesToCheese is true
        sigmaProp(outputGoesToCheese)
    }
}
`



The Ergo 'Box' model

## **Ergo Box Registers**

In Ergo's blockchain model, a box is a versatile entity that not only holds the value of cryptocurrency but also contains additional data in the form of registers. This makes it a more functional and flexible version of the Unspent Transaction Output (UTXO) found in Bitcoin and many other cryptocurrencies.

Each box contains at least four essential pieces of information:

The value in NanoErgs (1 Erg = 1000000000 NanoErgs).
The protection script (similar to Bitcoin's scriptPubKey) or "smart contract", which secures the box's expenditure.
Any additional assets or tokens contained within the box.
Details about the box's creation, including the txId, which is the ID of the transaction that created the box, and an output index. This information also includes a maxCreation height parameter set by the box creator (note: this is not the actual creation height; it aids in the creation of "payment channels").

These pieces of information are stored in the first four registers of the box. The remaining registers, from R4 to R9, can be used to store custom data for use in smart contracts. Scripts can access their own registers and the registers of input and output boxes of the spending transaction.

![](https://media.discordapp.net/attachments/980490396356476938/1331615487033081908/image.png?ex=67924310&is=6790f190&hm=b3ada06d9d413a14da04f12ce86827eb1380ddb1a1cd229472cdada9edbc9a80&=&format=webp&quality=lossless&width=567&height=455)

**Register R0**

Register R0 holds the monetary value of the box in nanoERGs. Use the Box.value command to access this register, where Box could signify SELF or any box in the INPUTS or OUTPUTS collections.

**Register R1**

Register R1 stores the proposition bytes of the guarding ErgoScript contract associated with the box. Use Box.propositionBytes to access this register.

**Register R2**

Register R2 contains a collection of tokens stored in the box. Each token is identified by two elements: a unique token id and the quantity of the specific token. Use Box.tokens to access this collection.

**Register R3**

Register R3 holds information about the box’s creation, such as the originating transaction id, the box's output index (i.e., the index used in OUTPUTS), and the block height at the creation time of the transaction from which the box originates. Use Box.creationInfo to access this register. The creation height is part of Ergo's unique storage rent feature, where boxes can be spent after four years, allowing miners to charge a small fee and recycle ERGs back into the blockchain.

**Registers R4 - R9 (Optional)**

These registers can contain any data defined when the box first originates from a transaction. The data could be of any common type found in ErgoScript, along with more complex types built from Pairs and Collections. These registers may also contain complex types such as Box, SigmaProp, GroupElement, and AVLTree.

The optional registers can hold any of the following data types:

Int, Long with standard Scala semantics.
BigInt - a 256-bit integer (all computations are modulo 2^256).
GroupElement - a point on the Secp256k1 curve represented in compressed format.
Coll[Byte] - a byte collection, conceptually similar to Scala's Array[Byte].
Collection of the above (i.e., Coll[Int], Coll[GroupElement], Coll[Coll[Byte]], and so forth).
A boxId is calculated based on the contents of all the registers, uniquely defining a box. This can be compared to Bitcoin's (txId, vOut) pairs.

**Typed Registers**

Both ErgoScript and ErgoTree are typed, meaning that when a script accesses a register, it expects a specific type which is denoted in brackets.

For instance,

`// Assign the value of the R4 register of the current box to the variable x
val x = SELF.R4[Int]
`

In the above example, the register is expected to have an Int type. Therefore, the expression SELF.R4[Int] should return a valid Option[Int] type value.

When you try to retrieve the value of the register SELF.R4[Int], there are three potential scenarios:

The register does not exist, hence SELF.R4[Int].isDefined will return false.
The register has an Int type value, thus SELF.R4[Int].get will fetch that value, and SELF.R4[Int].isDefined will be true.
The register carries a value of a different type, in which case SELF.R4[Int] will fail, and it will not produce a valid Option[Int] type value.
In some use cases, a register may contain values of various types. An additional register can be employed as a tag to facilitate the access of such a register.


`val tagOpt = SELF.R5[Int] // Retrieve the value of the register R5 of type Int and assign it to the variable `tagOpt`
val res = if (tagOpt.isDefined) { // Check if `tagOpt` is not empty
  val tag = tagOpt.get // Obtain the value of `tagOpt` and assign it to the variable `tag`
  if (tag == 1) { // Check if `tag` equals 1
    val x = SELF.R4[Int].get // Retrieve the value of the register R4 of type Int and assign it to the variable `x`
    // Compute `res` using the value `x` of type Int
  } else if (tag == 2) { // Check if `tag` equals 2
    val x = SELF.R4[GroupElement].get // Retrieve the value of the register R4 of type GroupElement and assign it to the variable `x`
    // Compute `res` using the value `x` of type GroupElement
  } else if (tag == 3) { // Check if `tag` equals 3
    val x = SELF.R4[ Array[Byte] ].get // Retrieve the value of the register R4 of type Array[Byte] and assign it to the variable `x`
    // Compute `res` using the value `x` of type Array[Byte]
  } else {
    // Compute `res` when `tag` is neither 1, 2, nor 3
  }
} else {
  // Compute `res` when the register is not present
}
`




Ergo Box Registers

## **Tokens on Ergo**

Ergo's native tokens are incredibly versatile and can represent a wide range of assets, including shares, complementary currency units, and various tangible or intangible items. The infrastructure of Ergo is designed to seamlessly handle the representation and transfer of these diverse assets, integrating them into the blockchain as first-class citizens.

There is no central database where tokens are registered currently, your best bet is to use community resources like supported tokens in the ergotipper bot and spectrum-finance/ergo-token-list.

**Token Storage**

Tokens are stored in a special register R2 of a box in the form of (tokenId -> amount) pairs.
A single box can hold up to 255 secondary tokens.

**Register Usage**

The Ergo reference implementation wallet uses specific registers in a unique way, although the protocol doesn't enforce this:

R4 - verbose name
R5 - description
R6 - number of decimal places
Additional registers (R7, R8, R9) can store asset-specific information

**Limitations**

There are certain indirect limitations to consider:

The size of a box should not exceed 4 kilobytes.
The presence of tokens increases the computational cost of the transaction.

**Asset Creation**

An exception to the rule of weak preservation (the total amount in inputs should be no less than the total amount in outputs) is that a transaction can generate tokens from thin air in its outputs if the asset identifier matches the identifier of the transaction's first input box. Given that the box identifier is cryptographically unique, it's impossible to have a second asset with the same identifier, assuming the hash function used is collision-resistant (which it indeed is). This rule also implies that only one new asset can be created per transaction.

**Examples**

How to mint a token with Fleet SDK
Creating a perpetual token (designed to exist indefinitely, unless it is removed by garbage collection.)

Tokens on Ergo

## **Perpetual Tokens**

ErgoScript allows the creation of a 'perpetual token', a token that is designed to exist indefinitely, unless it is removed by garbage collection.

`    {
      val isPerpetual = {(b: Box) =>
        b.propositionBytes == SELF.propositionBytes && b.tokens == SELF.tokens
      }

      sigmaProp(OUTPUTS.exists(isPerpetual))
    }
`

This code snippet ensures the persistence of a collection of perpetual tokens, even if the collection's size is zero. If you protect a single token using this script, it guarantees that the token will only be removed by garbage collection.
For a comprehensive discussion, refer to this thread.

**Multi-Stage Protocols**

Multi-stage protocols are beneficial in situations where multiple scripts need to interact. In these protocols, a script can reference the script of a subsequent stage.

For instance, consider the following example:

In script1, we have the statement:


hash(OUTPUTS(0).propositionBytes) == script2Hash
Here, script1 verifies if the hash of the first output's propositionBytes matches the hash of script2.

But, if we want script2 to refer back to script1, as shown below:


hash(OUTPUTS(0).propositionBytes) == script1Hash
We face a cyclic reference problem, as both scripts are referencing each other.

To overcome this, we can store script1Hash in a register of the box that contains script2. We also need to modify script1 to ensure that the corresponding register of any box containing script2 equals hash(SELF.propositionBytes).

While the "vanilla" perpetual token is intriguing, the "max-once-per-block-use" perpetual token offers more flexibility and power, and should be considered as a distinct design pattern.

Perpetual Tokens

## **Burning a token**

There are sometimes occasions when you want to delete a token from your wallet.

Your address was airdropped a token you no longer want
You created an NFT but something about it is not right.
A project sent you voting or other tokens that you no longer need
To get rid of those tokens, you have a few options.

**Mobile Wallet**: [TokenJay](https://www.tokenjay.app/app/#burntoken) (This requires an Ergopay compatible wallet like Ergo Mobile Wallet)

**Nautilus**: Ergo Token Minter / Burner
[SAFEW](V) supports token burning natively.

Send to 4MQyMKvMbnCJG3aJ, a [P2S (Pay-to-Script)](https://docs.ergoplatform.com/dev/scs/p2s/) representation of a “false” condition, i.e. the box is unspendable.
**Programmatically**

To burn tokens programmatically, simply spend an Unspent Transaction Output (UTXO) containing the tokens you wish to eliminate. Ensure not to include these tokens in the output of the transaction.

**Using AppKit**

If you're working with AppKit, the transaction builder conveniently offers a burntoken method tailored for this purpose.

**Ergo Token Minter Integration**

The burn token functionality integrated by ThierryM1212 can be observed here. The crucial steps involved are as follows:

Identify and select the input boxes holding the tokens to be burnt, along with a small ERG amount.
Construct the output boxes, excluding consideration of the tokens. The transaction builder automatically appends an additional output change box encompassing all tokens.
Retrieve the transaction JSON representation.
Edit the output change box details to eliminate the tokens intended for burning.
Dispatch the modified transaction (JSON) to the network.
This streamlined approach simplifies the process of burning tokens while maintaining transaction integrity.There are sometimes occasions when you want to delete a token from your wallet.

Your address was airdropped a token you no longer want
You created an NFT but something about it is not right.
A project sent you voting or other tokens that you no longer need
To get rid of those tokens, you have a few options.

Mobile Wallet: TokenJay (This requires an Ergopay compatible wallet like Ergo Mobile Wallet)
Nautilus: Ergo Token Minter / Burner
SAFEW supports token burning natively.
Send to 4MQyMKvMbnCJG3aJ, a P2S (Pay-to-Script) representation of a “false” condition, i.e. the box is unspendable.

**Programmatically**

To burn tokens programmatically, simply spend an Unspent Transaction Output (UTXO) containing the tokens you wish to eliminate. Ensure not to include these tokens in the output of the transaction.

**Using AppKit**

If you're working with AppKit, the transaction builder conveniently offers a burntoken method tailored for this purpose.

**Ergo Token Minter Integration**

The burn token functionality integrated by ThierryM1212 can be observed here. The crucial steps involved are as follows:

Identify and select the input boxes holding the tokens to be burnt, along with a small ERG amount.
Construct the output boxes, excluding consideration of the tokens. The transaction builder automatically appends an additional output change box encompassing all tokens.
Retrieve the transaction JSON representation.
Edit the output change box details to eliminate the tokens intended for burning.
Dispatch the modified transaction (JSON) to the network.
This streamlined approach simplifies the process of burning tokens while maintaining transaction integrity.

Burning a token

**Overview**

Non-Fungible Tokens (NFTs) are unique and indivisible blockchain tokens. They can be used to represent and prove ownership of digital products such as works of art, in-game items or characters, virtual trading cards and much, much more.

**Use cases**

**Unforgeable identity**

Let’s say you create a phenomenally successful exchange dApp, which pays a small percentage of trading fees to the owner – designated by ownership of that NFT. That token, and future revenues, can now be transferred and sold. The token can also be managed by a secondary smart contract, which could divide revenues among 100 tokens representing shareholders. The NFT could be used to update the dApp, or shut it down, if necessary – whatever conditions were coded into it. The point is that the NFT provides guaranteed, unforgeable proof of identity.

**UTXO NFTs**

One interesting feature is that Ergo can be used to create [PoW-backed NFTs](https://docs.ergoplatform.com/uses/PoW_tokens/). For most NFTs, a user simply generates a UTXO with the token contract attached. But it’s also possible for miners to create special NFTs, where the id of the newly minted token is the id of a coinbase transaction. This has all kinds of potential use cases, but the core idea is that a miner has the opportunity to create a special NFT when they mine a block. While any number of NFTs can be created via a regular smart contract, a finite number of these PoW-backed NFTs can exist.

There are other applications of NFTs that use the extended UTXO model, including facilitating a new generation of complex dApps. For example, a dApp creator can generate an NFT associated with an address and smart contract. While anyone can use that contract, and even create a transaction using the private key of that address, the NFT owner can still maintain administrative rights or other privileges.

Non-Fungible Tokens on Ergo

## **Creating an NFT**

**Creating an NFT programmatically**

See this [page](https://docs.ergoplatform.com/dev/tokens/nfts/nft-examples/) for some simple examples that demonstrate how to programmatically mint a NFT on the Ergo Blockchain.

**Standard**

The standard for artwork issuance on Ergo is[ EIP-0024: Artwork Contract.](https://docs.ergoplatform.com/dev/tokens/standards/eip24/) This standard outlines the process of issuing NFTs, including the two different design versions, V1 and V2, and the importance of artist identity. V2 offers more flexibility and features, such as handling multiple royalty recipients, detailed artwork traits, and additional information.

**Resources**

**Minting your NFT online**

[ergoauctions.org](https://ergoauctions.org/#/auction/active?type=all) Allows NFT minting. ([HowTo](https://ergoplatform.org/en/blog/2022-03-08-how-to-minting-a-non-fungible-token-nft-on-the-ergo-blockchain/))

[Lilium](https://docs.ergoplatform.com/eco/lilium/) is a tool for artists to mint and sell their collections.

**Developer Resources**

[ergpy](https://github.com/mgpai22/ergpy) has bulk-minting (with royalties!)

[ergo-nft-bulk-minter](https://github.com/mgpai22/ergo-nft-bulk-minter

[ergonfts.org](https://ergonfts.org/)



Creating an NFT

## **Design Choices: V1 vs V2**

EIP-0024 offers two design versions for artwork issuance: V1 and V2. Both designs involve two important boxes in the issuance process: the issuance box and the issuer box. The main difference between V1 and V2 lies in the issuer box.

**V1 Design**

In V1, the issuer box has the following attributes:

R4 is an Int representing 1000 times the royalty percentage of the artwork. For example, if the royalty percentage is 2%, the value in R4 would be 20.
The proposition bytes of the issuer box represent the contract to which the royalty percentage will be sent. This design choice was made with the assumption of AOT (Ahead-of-Time) costing, which was replaced with JIT (Just-in-Time) costing in 2022.
V1 mainly focuses on handling royalties for the artist or proxy contract.

**V2 Design**

V2 addresses some of the shortcomings in V1 and extends the proposal to include collections. The V2 issuer box has the following attributes:

R4 contains the artwork standard version.

R5 holds royalty recipients and their respective percentages.

R6 contains three types of traits: Properties, Levels, and Stats.

R7 contains the token ID of the collection.

R8 specifies additional information about the artwork, such as explicit content.

V2 offers more flexibility and features, such as handling multiple royalty recipients, detailed artwork traits, and additional information.

**Artist Identity**

Establishing the artist's identity is crucial for auction houses to prevent NFT scams and unauthorized copies. The artist's identity cannot be solely determined by the issuance box, as it may be impersonated. Instead, the artist's identity and address are established by the first P2PK input in the transaction chain leading to the artwork issuance. This means that if a proxy contract is used, the first input of the transaction that sends funds to the proxy contract will determine the artist's identity.

Design Choices: V1 vs V2

## **NFT Examples**

**Using Scala**

minting-for-dummies is a basic tool for NFT minting quickly in Scala.

You can see the mint() logic here

**Using Ergo Python Appkit**

To mint an NFT using the Ergo Python Appkit, you can utilize the mintToken method provided by the ErgoAppKit class. First, you need to initialize the ErgoAppKit instance with the appropriate parameters such as nodeUrl, networkType, explorerUrl, and nodeApiKey. Then, you can call the mintToken method with the required parameters, including the value, tokenId, tokenName, tokenDesc, mintAmount, decimals, and contract.

Here's an example of how to mint an NFT using the ergo-python-appkit:


`from ergo_python_appkit import ErgoAppKit
from org.ergoplatform.appkit import ErgoContract

# Initialize ErgoAppKit instance
appKit = ErgoAppKit(nodeUrl="https://ergo-node-url", networkType="mainnet", explorerUrl="https://ergo-explorer-url", nodeApiKey="your-node-api-key")

# Define the NFT parameters
value = 1000000
tokenId = "your-token-id"
tokenName = "Your Token Name"
tokenDesc = "Your Token Description"
mintAmount = 1
decimals = 0

# Compile the contract
contract = ErgoContract.compile("sigmaProp(true)")

# Mint the NFT
appKit.mintToken(value, tokenId, tokenName, tokenDesc, mintAmount, decimals, contract)
`

After minting the NFT, you can use other methods provided by the ErgoAppKit class to interact with the NFT, such as transferring it to another address or querying its properties.

Reference links:

[ErgoBox](https://github.com/ergo-pad/ergo-python-appkit/ergo_python_appkit/ErgoBox.py)

[ErgoAppKit](https://github.com/ergo-pad/ergo-python-appkit/ergo_python_appkit/appkit.py)

[ErgoTransaction](https://github.com/ergo-pad/ergo-python-appkit/ergo_python_appkit/ErgoTransaction.py)

[ergo-python-appkit module
](https://github.com/ergo-pad/ergo-python-appkit/ergo_python_appkit/__init__.py)

[Building transaction and minting a token using AppKit from Python.
](https://docs.ergoplatform.com/dev/stack/appkit/appkit-node/)

**More Examples**

[Bulk Mint with Royalties using v1 design in Python
](https://github.com/mgpai22/ergpy/blob/main/examples/example_5_bulk_mint_with_royalty.py)

[On-Chain NFTs](https://docs.ergoplatform.com/dev/tokens/nfts/on-chain/)

**References**

[Eip4TokenBuilder on GitHub
](https://github.com/ergoplatform/ergo-appkit/lib-impl/src/main/java/org/ergoplatform/appkit/impl/Eip4TokenBuilder.java)

[Eip4Token on GitHub](https://github.com/ergoplatform/ergo-appkit/common/src/main/java/org/ergoplatform/appkit/Eip4Token.java)


NFT Examples

## **On-chain NFTs**

**On-chain NFTs: Technical Aspects**

On-chain NFTs on Ergo differ from regular NFTs as they store images directly on the blockchain, specifically in the R9 register of the NFT box. This eliminates the need for third-party storage. However, this comes with a size constraint. The maximum size for on-chain NFTs on Ergo is approximately 3.5 Kb, considering space for the NFT name, description, and other data within the total 4 Kb limit. This constraint challenges artists to create captivating pieces within a limited space.

**Steps to create an on-chain SVG**:

Draw a relatively simple image in SVG vector format and manually optimize your art: smooth lines, remove minor details, reduce the number of colors, etc. Further optimize using svg-optimizers.

Convert your *.svg file to Data URI format (there are many online/offline converters available).

Check if your data fits within the 4 kb box limit (<3.5 Kb). If not, return to the first step.

Place this data in the R9 register.

Most challenging part: Mint the NFT using a tool that allows you to manipulate the R9 register.


**Examples of On-chain Collections**

**Vector Minimalism** collection:

[Landscape #06. View from the train window
](https://ergotokens.org/#/?token=62e9e8fc25e148a35e4bb99d70b810a897e78a7fd26adda0e8335a2ad17ef58c)

[Landscape #08. Flight over the desert
](https://ergotokens.org/#/?token=cf3f157c32c22749742fb0acc85aa07e6640b61290b26a89efd9e40f5070a938)

[Monument #11. Moai](https://ergotokens.org/#/?token=1d7430bacd2a0b1d83366cfad766a8dfb221c2de80ee95ab271a29bfdf7fc0a0)

[Monument #02. Spring Temple Buddha](https://ergotokens.org/#/?token=d935e4fa226bbd89dfc37e45f5a6bbcdee259f1368210aca61f1b6183e01c408)

![](https://github.com/ergoplatform/ergodocs/assets/99899807/10efaf86-a7ba-46ec-a620-db9a4f59a29a)

Tokenart collection uses SVG as a container for ASСII art:

[Tokenart Cat #2](https://ergotokens.org/#/?token=14435234f5fdf1bfc0f98c2186512db292266bf4ac8d0c74f6ad056dcfaf36d1)


[Tokenart Shark #2](https://ergotokens.org/#/?token=723f7eb846895bd0294619300488eb1974e6827e27d1624289019b42ec7252a3)

The SVG contains pure text:

![](https://github.com/ergoplatform/ergodocs/assets/99899807/02b1142b-a25d-4cc4-8092-c6026baa046c)

**A Brief History**

During the spring and summer of 2021, there were several on-chain projects on Cardano. For instance, the on-chain interactive NFT stored an entire HTML page with JS in its metadata. However, if we delve deeper into history, we find that the pioneers were the team from Larva Labs with their autoglyphs project, which was an ETH smart contract dated April 2019.

The NFT hype in the fall of 2021 led to the emergence of guides like this on on-chain NFT mining.

The first Ergo on-chain NFT was minted on 18/8/2021. You can find the related discussion here. This was achieved by transforming the data into a Data URI and encoding it into the R9 register.

The Technical Aspects of Regular Ergo NFTs#
What should we know about Ergo NFTs?

Let's consider an NFT with the ID

47394b9319353dee45621c5a8d1ffb00cc21c946913f148df5fa4f721fefa8d0, also known as AH v.1 link.

Here's how the NFT's name, description, and URL are stored on each Ergo node, among the 40 GB+ of all blockchain data.

NFT minting transaction on Ergo explorer: Tx

NFT name stored in register R4:

![](https://github.com/ergoplatform/ergodocs/assets/99899807/ad99a442-6569-4f66-b3e2-3c0279bc28ec)

NFT description stored in register R5:

![](https://github.com/ergoplatform/ergodocs/assets/99899807/59e3428b-2ed5-45dc-aca3-29c77dbd3a05)


NFT image URL stored in register R9: 

![](https://github.com/ergoplatform/ergodocs/assets/99899807/5f5838ca-ae99-43eb-aab4-d2d774c3ff83)

This is the underlying structure of the majority of NFTs on all blockchains (Ergo, Cardano, Ethereum, etc). In essence, only the name, description, and image link are stored on the blockchain (other technical parameters depending on the blockchain/NFT standard have been omitted for simplicity). The image itself is stored on a third-party storage service (like ipfs, imgbb.com, etc).

On-chain NFTs

## **Royalties**

Ergo's royalty system is integrated into the minting metadata and can be accessed via smart contracts. This integration allows marketplaces to include royalties in their sale contracts, a feature utilized by both Sky Harbor and Auction House. Consequently, any listings on a marketplace that respects royalties will have the royalties embedded in their smart contract, preventing them from being bypassed.

The upcoming AuctionHouse V3 will introduce the ability to support multiple recipients for royalties. This feature will facilitate collaborations among artists.

Royalties

## **Singletons**

In the UTXO model, a token issued with a quantity of exactly one unit is referred to as a singleton token. Singleton tokens can be used to emulate long-lived accounts similar to those found in Waves, Ethereum Classic, etc. A transaction that spends an old box with the singleton token and creates a new one can be controlled by the script of the old box, requiring the new box to have certain characteristics (such as a specific script or amount). This allows a smart account, marked with the token, to exist and alter its state as dictated by the smart account contract through a chain of transactions.

One specific example of a singular token is an oracle. For instance, a token can be created to act as an ERG/EUR exchange rates oracle. A box that contains this token would encode the exchange rate in a specific register. Since the oracle is a long-lived account, contracts can know the oracle token identifier beforehand and refer to it.



Singletons

## **EIP-0004: Asset Standard**

This standard provides a uniform way to issue Ergo tokens.

A standard interface allows any tokens on Ergo to be re-used by other applications: from wallets to decentralized exchanges.

**Ergo tokens background**

Ergo supports custom tokens as first-class citizens.

Namely, a special register (R2) of a box contains (tokenId -> amount) pairs.
A box can contain at most 255 secondary tokens.
There are also indirect limits:

A box can be no larger than 4 kilobytes
Tokens add to the computational cost of the transaction.
A transaction can create out-of-thin-air tokens in its outputs if the token identifier is equal to the identifier of the first input box of the transaction.

As the box identifier is cryptographically unique, there is no chance of having the second token with the same identifier while the hash function is collision-resistant.

This rule also means that only one new token per transaction can be created.

Unlike ergs, other tokens can be burnt: the total amount for a token in transaction inputs should be no less than the amount of the outputs.

Storage rent component allows a miner to collect (or burn) all the tokens inside a box if it is expired, and there are not enough Ergs in the box to pay the storage rent fee.

**Ergo tokens standard**

Though this is not required by the protocol, we propose the following structure for the box that issues a token:

![](https://media.discordapp.net/attachments/980490396356476938/1331630514133536860/image.png?ex=6792510f&is=6790ff8f&hm=1866eb6aebb742fb058007512ac295abfc99fe45ad368332dba1349e61e87d5e&=&format=webp&quality=lossless&width=1245&height=605)

Note, that additional registers (R4-R6) are encoded as Coll[Byte] type of ErgoScript and their encoded representation is received as '\x0e' + intToVlq(byteArray.length) + byteArray where byteArray is UTF-8 representation of the original string. The example above issues one thousand tokens called "USD" with two decimals each. The transaction that issues such a token was included in block 98288 and may be found in block explorer)

**Ergo asset types**

This standard is an extension of token standard:

In the asset type standard, R7 is a required two-byte value encoded as Coll[Byte]. The first byte represents the asset category, for example, NFT or Share Tokens. The second byte specifies the exact subcategory, for example, Picture Artwork NFT or ErgoMixer's Share Tokens. The second byte can be omited so that the issuance only specifies the catagory and not the subcatagory, for example, Share Tokens. Also, the remaining R8 and R9 registers can be used by each individual asset types based on their needs.

The standardization of various asset types can be found below:

![](https://media.discordapp.net/attachments/980490396356476938/1331631054368411668/image.png?ex=6792518f&is=6791000f&hm=e9531603b495af2587d3b1d24f442e4067db6c4e82a7cb497d856708a208338a&=&format=webp&quality=lossless&width=1168&height=726)

The above registers (R7-R9) are also encoded as Coll[Byte] type unless stated otherwise.



EIP-0004: Asset Standard

## **EIP-0021: Genuine Token Verification**

**Description**

This EIP lists the common tokens of value with their unique identifier, so users as well as wallet and explorer applications can verify if a token is genuine. The EIP is meant to be updated regularly when new tokens of value are added.

**Motivation**

Ergo tokens can hold a certain value, best-known examples are the SigUSD and SigRSV tokens in use by the SigmaUSD stablecoin protocol. Tokens can be minted by every user, with a name and description free to choose. This means everyone can mint new tokens named "SigUSD", which bears a problem for end-users to decide if a token they received is genuine or not.

**Ergo tokens background**

See EIP-4: Ergo supports custom tokens as first-class citizens. A transaction can create out-of-thin-air tokens in its outputs if the token identifier is equal to the identifier of the first input box of the transaction. As the box identifier is cryptographically unique, there's no chance to have the second token with the same identifier while the hash function being used is collision-resistant.

In order to verify the authenticity of a token, the unique identifier of a token is needed to check.

**Process to add tokens to this list**

As outlined before, this list should only hold tokens of value. This means that mainly tokens of financial value can be added. Before opening a PR to add your token to this list, ask yourself if your token is interesting for scammers. When the answer is no, the token should probably not added to this list. On rare occasions, tokens of a certain intrinsic value to the community could be added as well when there was a community vote with significant community participation.

**Recommended approach for applications showing tokens to end-users**

**Verified tokens**

Applications should add a verification sign next to a token which is listed in the following genuine tokens list.

Proposed verification sign: Material icons verified

**Suspicious tokens**

In order to protect end-users for confusion, it is decided for some tokens in the genuine tokens list that the verbose name should be unique and should not be used by other tokens. This is not enforced by Ergo protocol, so applications should check if a token uses a unique name from the list and add a warning sign when needed.

Proposed warning sign: Material icons report

**Blocked tokens**

Applications should show a warning sign next to tokens identified to be harmful or impersonating other tokens.

Proposed warning sign: Material icons dangerous

**Token lists**

**Genuine tokens**

Verbose name	Token id	Unique name	Issuer
SigUSD	03faf2cb329f2e90d6d23b58d91bbb6c046aa143261cc21f52fbe2824bfcbf04	yes	sigmausd.io
SigRSV	003bd19d0187117f130b62e1bcab0939929ff5c7709f843c5c4dd158949285d0	yes	sigmausd.io


**Blocked tokens**

Token id


EIP-0021: Genuine Token Verification

## **EIP-0022: Auction Contract**

**Motivation**

Decentralized auctioning of any kind of tokens (artwork, share tokens, etc.) is an important part of any blockchain. This EIP is proposing the auction contract with various features listed in the Design section

**Design**

This proposed contract allows any kind of tokens to be auctioned while supporting the following features:

Any token as the auction's currency alongside ERG
"Buy it now" which allows a buyer to instantly buy the auctioned token by paying the predefined amount in the auction's currency
Auction duration as timestamp which is much more precise than block height and is independent of the network difficulty
Auto extending the duration near the end of the auction based on a global config
Minimum bid step - each bidder has to increase the previous bid at least by this amount
Royalty - The original owner (whomever issued the token) gets a share of the auction every time his/her token is auctioned using a global config

**The contract**

`{
  // R4: The seller's ergo tree
  // R5: Current bidder's ergo tree
  // R6: (Minimum bid, minimum step)
  // R7: The auction's end time in timestamp
  // R8: The auction's "Buy it now" amount. -1 if it is not enabled.
  // R9: Auction info that is needed for UI/UX purposes - stringfied json encoded as Coll[Byte]:
  //     - initialBid: The auction's initial bid
  //     - startTime: The auction's start time
  //     - description: The auction's description
  //     - Any other info needed in the future
  //
  // tokens(0): auctioned token
  // tokens(1): current bid for non-ERG auctions - doesn't exist otherwise
  //
  // dataInputs(0): Auction house configuration - contains configs like UI fee and artist fee
  //     - R4: UI fee in thousand, e.g. 10 for 1% or 5 for 0.5%
  //     - R5: UI implementor's ergo tree
  //     - R6: Maximum miner fee for withdrawal
  //     - R7: Extend configuration as a Coll[Long] with two values (extendThreshold, extendNum)
  //             e.g., (30 * 60 * 1000L, 40 * 60 * 1000L) to extend the duration for 40min if 30min is left when the bid is placed

  // originalIssuanceBox: Spent box with ID equal to the NFT ID
  //     - R4: Royalty percentage - 0 if empty
  //     - R5: Artist address

  val seller = SELF.R4[Coll[Byte]].get
  val currBidder = SELF.R5[Coll[Byte]].get
  val minBid = SELF.R6[Coll[Long]].get(0)
  val minStep = SELF.R6[Coll[Long]].get(1)
  val endTime = SELF.R7[Long].get
  val buyItNowAmount = SELF.R8[Long].get

  // auction currency can be any token like SigUSD
  val auctionCurrency = if (SELF.tokens.size > 1) SELF.tokens(1)._1
                        else Coll[Byte]()
  val isCurrencyERG = auctionCurrency.size == 0
  val getBoxVal = {(b: Box) => {
     if (isCurrencyERG) b.value
     else {
       if (b.tokens.size == 1 && b.tokens(0)._1 == auctionCurrency) b.tokens(0)._2
       else if (b.tokens.size == 2 && b.tokens(1)._1 == auctionCurrency) b.tokens(1)._2
       else 0L
     }
  }}

  val currBid = getBoxVal(SELF)

  val auctionConfig = CONTEXT.dataInputs(0)

  // auction is not finished, a bid is being placed
  val isNextBid = {
     val extendConfig = auctionConfig.R7[Coll[Long]]
     val extendThreshold = extendConfig.get(0)
     val extendNum = extendConfig.get(1)
     // we extend the auction end time by extendNum if the bid is placed near the very end (extendThreshold)
     val newEndTime = if (endTime - CONTEXT.preHeader.timestamp <= extendThreshold) endTime + extendNum
                      else endTime


     val newSelf = OUTPUTS(0) // new auction box
     val oldBidRefundBox = OUTPUTS(1) // refund box

     val isUsingBuyItNow = buyItNowAmount != -1 && getBoxVal(newSelf) >= buyItNowAmount

     // as a general check, ERG value can not be less than the current
     newSelf.value >= SELF.value &&
     // auction is not finished
     CONTEXT.preHeader.timestamp < endTime &&
     // preserve auctioned tokens
     newSelf.tokens(0) == SELF.tokens(0) &&
     // correct value and contract for the new box
     (getBoxVal(newSelf) >= getBoxVal(SELF) + minStep || getBoxVal(SELF) < minBid || isUsingBuyItNow) &&
     getBoxVal(newSelf) >= minBid &&
     newSelf.propositionBytes == SELF.propositionBytes &&
     // shouldn't be able to add tokens - will change the currency from ERG to a worthless token
     SELF.tokens.size == newSelf.tokens.size &&
     // currency must be the same
     // refund the previous bidder
     oldBidRefundBox.propositionBytes == currBidder &&
     getBoxVal(oldBidRefundBox) >= currBid &&
     // preserve the auction config
     newSelf.R4[Coll[Byte]].get == seller &&
     // just making sure that the new R5's type is Coll[Byte]
     newSelf.R5[Coll[Byte]].get.size > 0 &&
     newSelf.R6[Coll[Long]].get.size == 2 &&
     newSelf.R6[Coll[Long]].get(0) == minBid &&
     newSelf.R6[Coll[Long]].get(1) == minStep &&
     newSelf.R7[Long].get == newEndTime &&
     newSelf.R8[Long].get == buyItNowAmount &&
     newSelf.R9[Coll[Byte]] == SELF.R9[Coll[Byte]]

  }

  // either auction has ended due to time or "Buy it now" is being used
  val isFinishedWithBid = {
     val winnerBox = OUTPUTS(0)
     val auctionFeeBox = OUTPUTS(1)
     val sellerBox = if (OUTPUTS.size < 3) SELF
                         else OUTPUTS(2)
     val artistRoyalty = if (OUTPUTS.size < 4) SELF
                         else OUTPUTS(3)
     val originalIssuanceBox = if (auctionFeeBox.R4[Box].isDefined) auctionFeeBox.R4[Box].get
                               else OUTPUTS(OUTPUTS.size - 1)

     val auctionFee = (currBid * auctionConfig.R4[Int].get) / 1000
     val auctionFeeTo = auctionConfig.R5[Coll[Byte]].get // ui implementor's ergo tree

     val artistSharePerc = if (originalIssuanceBox.R4[Int].isDefined) max(originalIssuanceBox.R4[Int].get, 0)
                           else 0
     val artistShare = (currBid * artistSharePerc) / 1000

     val maxFee = auctionConfig.R6[Long].get
     // if currency is not ERG, then nothing has to be deducted from it for miner fee. Otherwise, 2 * maxFee will be deducted
     val minerFeeInCurrency = if (isCurrencyERG) maxFee * 2 // one maxFee for the miner fee and one for the seller box
                              else 0L

     val artistGetsHisShare = {
       artistShare == 0L || {
         blake2b256(originalIssuanceBox.bytes) == SELF.tokens(0)._1 && // the same ID as the NFT - the integrity of the box is also ensured with this line
         getBoxVal(artistRoyalty) >= artistShare && // gets at least the percentage defined in the auction config box
         artistRoyalty.propositionBytes == originalIssuanceBox.propositionBytes // goes to the artist
       }
     }

     val buyItNow = (currBid >= buyItNowAmount && buyItNowAmount != -1)

     val outSize = if (artistShare == 0L) 4
                   else 5

     // either auction is finished or "Buy it now" is used
     (CONTEXT.preHeader.timestamp >= endTime || buyItNow) &&
     getBoxVal(auctionFeeBox) >= auctionFee &&
     auctionFeeBox.propositionBytes == auctionFeeTo &&
     winnerBox.tokens(0) == SELF.tokens(0) &&
     winnerBox.propositionBytes == currBidder &&
     getBoxVal(sellerBox) >= currBid - auctionFee - artistShare - minerFeeInCurrency &&
     sellerBox.propositionBytes == seller &&
     artistGetsHisShare &&
     OUTPUTS.size == outSize
  }

  // in this case, there is no winner and the seller doesn't need to pay any fee to the auction house or the artist
  val isFinishedWithoutBid = {
     val maxFee = auctionConfig.R6[Long].get
     val minerFeeInCurrency = if (isCurrencyERG) maxFee
                              else 0L
     currBid < minBid &&
     CONTEXT.preHeader.timestamp >= endTime &&
     OUTPUTS.size == 2 &&
     OUTPUTS(0).tokens(0) == SELF.tokens(0) &&
     OUTPUTS(0).propositionBytes == seller &&
     getBoxVal(OUTPUTS(0)) >= currBid - minerFeeInCurrency
  }

  val validConfig = auctionConfig.tokens(0)._1 == AUCTION_CONFIG_TOKEN_ID
  sigmaProp((isNextBid || isFinishedWithBid || isFinishedWithoutBid) && validConfig)
}
`




EIP-0022: Auction Contract

## **EIP-0024: Artwork Contract**

**Motivation**

With the discovery that we can easily use spent boxes in contracts (see here), some new features are introduced for artworks and can be extended further in the future. This EIP is an extension of Asset standard and tends to standardize artwork issuance in particular.

**Design V1**

There are two important boxes in the issuance process of an artwork.

The issuance box, which follows Asset standard depending on the type of artwork.
The issuer box, which is the first input of the transaction that is issuing the artwork. In particular, the box with the same ID as the artwork's token ID.
Now we will discuss why the issuer box is important and define a standard for it.

The issuer box is important because it has the same ID as the artwork's token ID and we can include it (although it is spent) in our transactions either in registers or as context data. This means that we can prove/verify certain features that an artwork may have using this box. The following is the v1 standard for this box - which may be extended in the future (refer to Design V2 part).

R4 of this box is an Int, showing 1000 * royalty percentage of the artwork. e.g, 20 for 2% royalty. If R4 of the issuer box of an artowrk is empty or non-positive, then royalty is considered to be 0%.
In the current design of the Auction contranct, proposition bytes of this box is the contract that the royalty percentage will be sent to. This is a suboptimal design because of AOT costing mechanism which is supposed to be replaced with JIT costing with a soft-fork that will happen with v5.0 of ergo node.
As mentioned, royalty amount will go to the propositiona bytes of the issuer box. In the case of a simple proxy contract (proposition bytes of the issuer box), this means that the artist will receive the royalty share. However, the proxy contract may enforce the royalty to go to any other complex contract - e.g., 20% to the artist, and 80% to some charity.

**Design V2**

Version 2 of this proposal is created to both extend this proposal to include collections and fix some poor design choices that were caused by the AOT costing issues. The following is the v2 standard for the issuer box.

R4 is an integer showing the artwork standard version. If This register is empty, the type is something other than Int, or the number is greater or equal to 100 then it should be considered as part of V1 design. Otherwise, this register shows the version number for the standard, i.e., 2 for Design V2.
R5 is of type Coll[(Coll[Byte], Int)] that encodes information about royalty recipients and percentages. In particular, a list of royalty recipients and their respective percentage. The Coll[Byte] part is the ergo tree of one of the royalty recipients and the Int part shows 1000 * royalty percentage of this recipient (e.g. 50 if the receipient receives 5% of the sale). The total royalty percentage of the artwork is the sum of percentages of this list. If the list is empty, the artwork's royalty is 0%. Royalty amount must go to royalty recipients based on the explained share of recipients. An important note here is that it is the responsibility of the auction contract to follow the appropriate version of this standard and consequently send the royalty amount to appropriate recipient(s).

R6 contains three types of traits:

**Properties**: These are textual traits such as specifying sex as male.

**Levels**: These are numerical traits that encode some sort of level-like information such as specifying speed as 60 out of 100.

**Stats**: These are numerical traits that encode any numerical information about the NFT such as specifying age as 25 out of 50.

Although the structure of levels and stats are similar, they can be considered different in marketplaces both for UI/UX purposes and also for filtering purposes.

The following specifies the structure for traits.

`( // properties
  Coll[(  
    Coll[Byte],  // key
    Coll[Byte]   // value
  )],
  ( // levels
    Coll[(
      Coll[Byte],  // key
      (Int, Int)   // value, max
    )],
    // stats
    Coll[(
      Coll[Byte],  // key
      (Int, Int)   // value, max
    )]
  )
)
`

If a list is empty(e.g., there is no levels) then the corresponding Coll should be empty. Keys are case-insensitive which means for example, marketplaces should treat "KeY" the same as "key". Moreover, keys should be consistent across different artworks of a specific collection. For example, if "key1" is a property trait, it should always be used as a property trait in all artworks of a specific collection. All Coll[Byte] types in the above structure are UTF-8 text encoded as Coll[Byte].
R7 of this box contains token ID of the collection as Coll[Byte] otherwise it is an empty Coll[Byte]. This is needed for two cases:
if the issuer box contains more than one collection token, this will specify which one is the collection that the artist intended to put the artwork in.
if the issue box contains some collection tokens but the artist does not intend to put the artwork in any collections. In this case, this register must be an empty Coll[Byte].
R8 of this box is Coll[(Coll[Byte], Coll[Byte])] specifying other additional information about the artwork. the following pieces of information currently is intended to be in this register.
Whether the artwork is explicit content or not. The key is "explicit" and the value is 0x00 if it is not explicit and 0x01 if it is. If this key is not present the artwork is assumed to not be explicit content.
The order of these information should not be important as it is intended to represent a json with the following format:

`{
  "key1": "value1",
  "key2": "value2",
  "...": "..."
}
`

This field can be extended in the future based on the needs of Auction Houses around.

**Artist Identity??

Artist identity is very important for any auction house to eliminate NFT copies and scams for the end-users.

The identity of the artist can not necessarily be determined with the issuance box (unless it is a P2PK box) since its correctness can not be verified, e.g., one can impersonate an artist.

Hence, the artist's identity and address are determined with the first P2PK input in the chain of transactions leading to the artwork issuance. This means that in the case of using proxy contracts, the first input of the transaction that is sending the funds to the proxy contract is going to determine the artist's identity.

EIP-0024: Artwork Contract

## **Ergo Box Design: A Comprehensive Guide**

The UTXO (Unspent Transaction Output) system is the backbone of many blockchain networks, and at its core are boxes. These boxes are not just containers for the value of a currency within a blockchain; they are also equipped with registers that are protected by a contract, enhancing their functionality on the Ergo blockchain.

Registers are essentially storage units for data and information at specific addresses in the blockchain. To visualize this, think of these boxes as advanced storage units or containers. For instance, consider a cup:

A Cup:

Holds liquid primarily
Can contain a certain quantity of liquid
Now, let's translate this into a blockchain context:

A Cup Box:

Stores only Ergs or a specific token
Has a storage limit enforced by a guard script
A guard script or contract sets restrictions on the box. Without it, a box is just a storage unit for information or a certain amount of currency. The introduction of guard scripts, which establish specific rules for the boxes, adds a level of control and functionality to the boxes, much like a remote control. The focus here is not on the internal workings of a remote control (guard script) or the data it transmits (registers and storage), but on its functionality - pressing a button changes the TV channel.

**Understanding Box Modeling**

Box modeling is a framework that aids developers or box designers in creating a box to perform specific tasks. This structure promotes a clear and systematic understanding of a box's roles and operational mechanics.

**Key Principles in Box Design**

A blockchain serves as a financial canvas, allowing developers, engineers, and designers to build financial systems on top of it. However, design flaws can lead to security vulnerabilities, unscalable designs, and inefficient processes. Therefore, it's crucial to prioritize security, scalability, and efficiency in design.

The three pillars of box design are:

**Security**

The box should be designed to prevent exploitation by unauthorized users.

**Scalability**

The system should be designed to handle multiple concurrent requests smoothly.

**Efficiency**

A straightforward design makes it easier for engineers to understand and improve the design.

**Box Modeling: A Step-by-Step Guide**

Before diving into the principles mentioned above, it's essential to understand the basics of box modeling.

When modeling a box, consider the following:

**What is the box's purpose?**

For instance, a lending box is designed to simplify the loan process.

**What data should the box store?**

The box's function determines the data stored in it. A lending box, for example, would store lending-related information in its registers.

**How will the box perform its function?**

This step involves thinking about the overall transaction, not just the box. It requires scripting the guard script (or smart contract) to perform its intended function using the data stored in the registers.

**Register Data Types**

Registers can store data in various formats, which can be single or multiple entries.

**Single data entries include:**

Long

Coll[Byte] (also known as String)

Bool

**Multiple data entries include:**

Coll[Long]
Coll[Coll[Byte]]
Coll[Bool]
Resources#
This guide is based on the article by Keith Lim
For more technical details on the format of a box, please see this page

Ergo Box Design: A Comprehensive Guide

## **Addresses**

Addresses in Ergo are short strings that correspond to specific scripts and serve as a means to protect a box.
Unlike Bitcoin (BTC), where addresses store a single amount, in Ergo's eUTxO model, a box contains registers that can store various values, including its native tokens.
So, each box has an ERG amount and may or may not have a bunch of {tokenid, token amount} pairs, all in the UTXO model.
Unlike account-based models like eth, ergo tokens are native and are not smart contracts.
Address Types#
Learn about the different types of addresses used in Ergo and their corresponding address types by visiting the Address Types page.

**Address Validation**

Learn how to validate Ergo addresses by visiting the Address Validation page, which provides essential insights and methods for verifying P2S, P2SH, and P2PK addresses.

**Resources**

Ergo Vision | A wallet visualization tool to be used for investigating transactions and addresses

## ##Address Types**

Possible network types are:

Mainnet - 0x00
Testnet - 0x10
Address types are (semantics described below):

0x01 - Pay-to-PublicKey(P2PK) address
0x02 - Pay-to-Script-Hash(P2SH)
0x03 - Pay-to-Script(P2S)
For an address type, we form content bytes as follows:

P2PK - serialized (compressed) public key
P2SH - first 192 bits of the Blake2b256 hash of serialized script bytes
P2S - serialized script (this is where mining rewards go!)
For example,

Sending 10 ERG to a P2PK address usually means that a corresponding transaction will contain a box in which 10 Ergs are locked by a public key encoded in the P2PK Address.
Similarly, in the case of a P2S address, the box will be locked by a script encoded in the Address.
In the most complicated case of a P2SH script, the box will be protected by a special predefined script that takes the first 192 bits of Blake2b256 hash value for a script shown by an input spending the box.
Here are some examples of the various types of addresses you'll see on the testnet:

P2PK (3WvsT2Gm4EpsM9Pg18PdY6XyhNNMqXDsvJTbbf6ihLvAmSb7u5RN)
P2SH (rbcrmKEYduUvADj9Ts3dSVSG27h54pgrq5fPuwB)
P2S (Ms7smJwLGbUAjuWQ)
And here is how what they look like on the mainnet:

P2PK (9fRAWhdxEsTcdb8PhGNrZfwqa65zfkuYHAMmkQLcic1gdLSV5vA)
P2SH (8UApt8czfFVuTgQmMwtsRBZ4nfWquNiSwCWUjMg)
P2S (4MQyML64GnzMxZgm, BxKBaHkvrTvLZrDcZjcsxsF7aSsrN73ijeFZXtbj4CXZHHcvBtqSxQ)
Note: P2S can start with any number, D, M, or any other of base58. 9 is always a P2PK address on the mainnet.

**Summary**

Prefix byte = network type + address type
(for example, P2S script on the testnet starts with 0x13 before Base58)
checksum = leftmost_4_bytes (blake2b256 (prefix byte || content bytes))
address = prefix byte || content bytes || checksum

**P2S vs P2SH**

Typically most people use P2S because it is a lot easier to use. P2SH means you have to keep the contract ready off-chain to be submitted when you create the transaction, and if you lose it, then your funds are stuck forever. This also makes it harder for other people to use your dApp as they need the contract themselves, rather than just the address. P2SH is technically cheaper since you store less data on-chain, but likely we won't see anyone using P2SH until we start to get heavy load on-chain.

P2SH is a good candidate for a pre-defined contract template (in terms of EIP-5) From this perspective context var id can be a template parameter. So fixing concrete id is not necessary. The template hex can be created once and then used across dApps. Sigma already support ContractTemplate, and the corresponding code can be made available in Fleet via Sigma-js.


## **Address validation**

ergo-simple-addresses contains few zero-dependencies Java-friendly utils for working with addresses. The Integration Guide for Exchanges may also be relevant. There is also a simple method in Fleet.

P2S has no limit since it is the serialized script.
P2SH is 192 bits since it is the "first 192 bits of the Blake2b256 hash of serialized script bytes."
P2PK length is fixed. You can use the linked class to validate an address (it gives a runtime exception when created from an invalid string).
In P2S, everyone can see the script; in P2SH, the script will be known when it will be spent.

P2SH has 0x12 at the beginning, and P2S has 0x13 on testnet and 0x02 and 0x03 on mainnet accordingly (note that in hex, you can see that, but in base58, it can change to anything).

As you can see

88dhgzEuTXaRxf1rbqBRZ6Zbw9iigdB4PCdjyFKLrk22gnmjKcxZBe53vqJVetRa4tTNF9oowQWPp2c6

equals

03 10 02 04 a0 0b 08 cd 02 a1 f5 67 16 cb 8d f4 fe b9 37 14 37 90 4b 91 25 b8 2d b9 39 23 8c d7 d9 48 78 6d b3 3d e3 13 9f ea 02 d1 92 a3 9a 8c c7 a7 01 73 00 73 01 8c 23 55 af

Addresses

## **Transactions**

Each Ergo transaction is an atomic state transition operation, which means that it destroys a box from the state and creates new ones.

**Anatomy**

Each transaction executed on Ergo consists of these three things.

One or more Input boxes
This is the source of your funds for the transaction.
These boxes must already exist and will be destroyed by the transaction.
The guard script in each box will be evaluated and must return true for the transaction to be considered valid.
One or more Output boxes
This is your destination of funds.
These boxes will be created.
Zero or more Data-Input boxes
These are additional boxes whose data can be referenced and used by smart contracts of the inputs.
The guard script in these boxes will not be evaluated.

**Data Inputs**

[Data inputs](https://docs.ergoplatform.com/dev/protocol/tx/read-only-inputs) are a unique concept created by Ergo, which were added to Cardano with the Vasil Hardfork. These allow multiple transactions to share a data-input box, storing only a single reference to the box in the block.

**Overview**

If the transaction is spending boxes protected by a non-trivial script, its inputs should also contain proof of spending correctness - context extension (user-defined key-value map) and data inputs (links to existing boxes in the state) that you may use during script reduction to crypto, signatures that satisfies the remaining cryptographic protection of the script.
Transactions are not encrypted, meaning you can publicly view transactions included in blocks.

**Tools**

[Transaction builder ](https://thierrym1212.github.io/txbuilder/)| The application allows you to manipulate Ergo JSON transactions with a UI and to sign them with a wallet or to prepare the JSON for the Swagger API. It can also load the JSON of an unsigned transaction to edit it. | GitHub | [Video](https://youtu.be/0VhfY7osT2k)


## **Composing Transactions**


Each Ergo transaction represents an atomic state transition operation. This operation destroys an existing box from the state and generates new ones.

**Anatomy of a Transaction**

Every transaction executed on Ergo comprises three main components:

One or more Input boxes: These are the sources of your funds for the transaction. These boxes, which must already exist, will be destroyed by the transaction. The guard script in each box is evaluated and must return true for the transaction to be deemed valid.
One or more Output boxes: These are the destinations of your funds. These boxes will be created by the transaction.
Zero or more Data-Input boxes: These are supplementary boxes whose data can be referenced and utilized by the smart contracts of the inputs. The guard script in these boxes is not evaluated.

**Data Inputs**

Data inputs are a unique feature introduced by Ergo and later adopted by Cardano with the Vasil Hardfork. This concept allows multiple transactions to share a data-input box, storing only a single reference to the box in the block.

In traditional UTXO-based blockchains, transactions typically require spending and destroying all inputs. However, Ergo introduces the concept of data inputs to allow transactions to reference existing UTXOs and read their data without consuming them. This innovation solves the limitations normally associated with eUTXO.

Data inputs enable multiple transactions within a block or slot to read the data from the same UTXO concurrently, as none of them actually spend or destroy the data. This parallel processing of data inputs reduces transaction fees, as smart contract execution is not required, and there is no need to create extra outputs. Additionally, data inputs address various other challenges, making them a valuable design choice for all UTXO-based blockchains.

**Overview**

If the transaction is spending boxes protected by a non-trivial script, its inputs should also contain proof of spending correctness - context extension (user-defined key-value map) and data inputs (links to existing boxes in the state) that can be used during script reduction to crypto, signatures that satisfy the remaining cryptographic protection of the script.
Transactions are not encrypted, which means that transactions included in blocks can be viewed publicly.

**Tools for Composing Transactions**

Transaction builder: This application enables you to manipulate Ergo JSON transactions with a UI and to sign them with a wallet or to prepare the JSON for the Swagger API. It can also load the JSON of an unsigned transaction for editing. GitHub | Video
Refer to this basic tutorial for sending a transaction for an introduction.
Ergo also supports 'Chained transactions' (spending outputs of off-chain transactions).


## **Executing a Chained Transaction**


Chained transactions allow for the sequential use of outputs from off-chain transactions. This guide will walk you through the process of submitting a chained transaction on Ergo. The basic method demonstrated here is based on the ergpy examples. For managing extensive interlinked transactions, you can refer to the Transaction Group framework provided by GetBlok.

**Establish a Blockchain Connection**

Start by defining the URL of the node to connect to the Ergo blockchain. This could be either a MainNet or TestNet node URL. The connection is then established using the ErgoAppKit.


`# Assign the node URL
node_url: str = "http://213.239.193.208:9052/"

# Establish the connection
ergo = appkit.ErgoAppKit(node_url=node_url)
`

**Set Up Wallet Mnemonic**

Next, prepare your wallet mnemonic. This is a sentence-like password that will be used to access your wallet. This example includes receiver addresses and the amount to be sent in each transaction. Furthermore, it sets a sleep time, which is the delay between transaction submissions. The required amount for the genesis outbox, which is the first transaction in the chain, is also calculated.

`# Define the wallet mnemonic
wallet_mnemonic = "decline reward asthma enter three clean borrow repeat identify wisdom horn pull entire adapt neglect."

# Specify receiver addresses
receiver_addresses = [
    "3WwdXmYP39DLmDWJ6grH9ArXbWuCt2uGAh46VTfeGPrHKJJY6cSJ",
    "3WwuG9amNVDwkJdgT5Ce7aJCfeoafVmd9tag9AEiAZwgPi7pYX3w",
    "3Wxk5oofZ3Laq2CpFW4Fi9YQiaep9bZr6QFg4s4xpzz4bi9tZq2U"
]

# Define the amount for each transaction
amount = [0.22, 0.33, 0.11]

# Set the number of consecutive transactions
consecutive_transactions = 3

# Define the time gap between submissions of transactions
sleep_time = 0.5 

# Calculate the total amount for the genesis outbox
genesis_amount = [consecutive_transactions * (0.22 + 0.33 + 0.11) + (consecutive_transactions + 1) * 0.001]

# Wallet of the sender
genesis_receiver = [""]  
`

**Generate an Output Box**

To create an output box from the signed transaction, we use the simple_send method from the helper_functions module. The function returns a signed transaction, which we then use to obtain the genesis outbox.

`# Generate a signed transaction
genesis_tx = helper_functions.simple_send(ergo=ergo, amount=genesis_amount, wallet_mnemonic=wallet_mnemonic,
                                          receiver_addresses=genesis_receiver, return_signed=True)
# Get the genesis outbox
genesis_outbox = appkit.get_outputs_to_spend(genesis_tx, 0)      
`

**Submit the Transactions**

Finally, we submit the transactions to the node. For each transaction in the chain, we use the output box from the previous transaction as the input box for the current transaction. The first transaction retrieves the input box from the genesis outbox. The last transaction is not chained, i.e., its output box

will not be used as an input box in any subsequent transaction. The ID of the genesis transaction and the last transaction are printed to the console. After the final transaction is submitted, the process ends.

`# Print the transaction ID of the genesis transaction
print(ergo.txId(genesis_tx))  

outBox_list = []

# Process all the transactions in the chain
for x in range(consecutive_transactions):
    # If it's the first transaction
    if x == 0: 
        tx_1 = helper_functions.simple_send(ergo=ergo, amount=amount, wallet_mnemonic=wallet_mnemonic,
                                            receiver_addresses=receiver_addresses, input_box=genesis_outbox,
                                            return_signed=True, chained=True)
    # If it's the last transaction
    elif x == consecutive_transactions - 1: 
        tx_1 = helper_functions.simple_send(ergo=ergo, amount=amount, wallet_mnemonic=wallet_mnemonic,
                                            receiver_addresses=receiver_addresses, input_box=outBox_list[x - 1],
                                            return_signed=True)
    # If it's neither the first nor the last transaction
    else: 
        tx_1 = helper_functions.simple_send(ergo=ergo, amount=amount, wallet_mnemonic=wallet_mnemonic,
                                            receiver_addresses=receiver_addresses, input_box=outBox_list[x - 1],
                                            return_signed=True, chained=True)
    # Get the outbox from the current transaction
    tx_1_outbox = appkit.get_outputs_to_spend(tx_1, 0)
    outBox_list.append(tx_1_outbox)

    # Pause before processing the next transaction
    time.sleep(sleep_time)

# Print the transaction ID of the last transaction
print(ergo.txId(tx_1)) 

# Pause before ending the program
time.sleep(sleep_time)

# End the program
helper_functions.exit()
`



Transactions

Box Format

## **ErgoScript Tooling**

ErgoScript is a powerful and flexible language for creating smart contracts on the Ergo blockchain. As with any programming language, having the right tools can greatly enhance the development experience and productivity. This page provides an overview of various tools, resources, and examples to help you get started with ErgoScript development.

**Introduction**

ErgoScript is a domain-specific language designed specifically for the Ergo blockchain. It is inspired by Scala and allows developers to create secure and efficient smart contracts. While ErgoScript is not Turing-complete, it can be used to build Turing-complete applications by leveraging the extended UTXO model of the Ergo blockchain.

The ErgoScript ecosystem offers a wide range of tools and resources to help developers at all levels, from beginners to experienced professionals. These tools include playgrounds, tutorials, courses, explanations, references, and examples.

**Playgrounds**

[escript.online
](https://escript.online/)

Compile ErgoScript directly in your browser with [ErgoScript Playground](https://wallet.plutomonkey.com/p2s/)

There is also [Scastie](https://scastie.scala-lang.org/greenhat/T2jSEv11QcWpXX1XrcHUdw/31)

[Kiosk ](https://docs.ergoplatform.com/dev/stack/kiosk)lets anyone play with ErgoScript using a basic web-based UI

[ergoscript-compiler](https://github.com/ergoplatform/ergoscript-compiler)

**Courses**

[ErgoScript 101 Crash Course (Slides)
](https://docs.google.com/presentation/d/10gYO82z_7qloRrFOcCxTFuzpP40IImPyIKMV2ZFd9M4/edit#slide=id.p)

[Learn ErgoScript By Example Via The Ergo Playground with Robert Kornacki (Video)](https://www.youtube.com/watch?v=8l2v1asHgyA)

[The ErgoScript Developer Course from DeCo Education
](https://github.com/DeCo-Education/ErgoScript-Developer-Course)

[Deco Education: 2022 Script Class
](https://www.youtube.com/watch?v=qR0_k7VH6KI&list=PLopsKGshj0B4DfFnS-pvriZhba050eaXu)

**Tutorials**

[ErgoScript by Example Repository](https://github.com/ergoplatform/ergoscript-by-example)

[Testing Ergo Contracts Off-chain
](https://github.com/anon-real/contract-testing)

**Advanced Tutorials**

[Advanced ErgoScript Tutorial](https://ergoplatform.org/docs/AdvancedErgoScriptTutorial.pdf)

[ErgoScript tutorial](https://ergoplatform.org/docs/ErgoScript.pdf)

**Explanations**

[ErgoScript Design patterns](https://www.ergoforum.org/t/ergoscript-design-patterns/222)

[SigmaState Protocols](https://storage.googleapis.com/ergo-cms-media/docs/sigmastate_protocols.pdf)

**References**

[ErgoScript Language Spec](https://github.com/ScorexFoundation/sigmastate-interpreter/blob/develop/docs/LangSpec.md)

[ErgoScript](https://ergoplatform.org/docs/ErgoScript.pdf)


[ErgoTree](https://ergoplatform.org/docs/ErgoTree.pdf)

[High-Level Design Patterns In Extended UTXO Systems](https://github.com/Emurgo/Emurgo-Research/blob/master/smart-contracts/High%20Level%20Design%20Patterns%20In%20Extended%20UTXO%20Systems.md)


**Examples**

[ErgoPad Plasma Staking Contracts](https://github.com/paideiadao/paideia-contracts/blob/main/paideia_contracts/contracts/plasma_staking/ergoscript/latest/plasmaStaking.es)

[GetBlok.io Smart Pools](https://github.com/GetBlok-io/ergo-smartpooling-contracts)

**Visual**

[FlowCards](https://docs.ergoplatform.com/dev/scs/flowcards/)
 is A Declarative Framework for Development of Ergo dApps
[flowcardLib: Ergo FlowCard library for diagrams.net](https://github.com/lucagdangelo/flowcardLib)

[ergo-castanet](https://github.com/iandebeer/ergo-castanet)

**Box**

Here is a box to experiment with

This address will create an output at this box.

ErgoScript Tooling

## **ErgoTree: Reference Manual**

ErgoTree forms the backbone of Ergo's smart contracts. It is the typed abstract syntax of the ErgoTree language used for defining logical propositions that protect boxes (coin abstractions) in Ergo. While ErgoTree is fundamental, most users interact with it indirectly, primarily developing contracts using a higher-level language called ErgoScript, which later compiles into ErgoTree.

**Understanding ErgoTree**

ErgoTree serves as a specialized language, encapsulating the universal language of the Ergo blockchain. It directly interacts with key components such as Boxes, Tokens, and Zero-Knowledge Sigma-Propositions. ErgoTree is optimized for efficient storage and rapid execution.

A language intended for writing blockchain contracts must be deterministic to ensure spam-resistance. It also needs to be simple yet expressive enough to function as a solid platform for contractual money. ErgoTree meets these requirements, making it an essential tool for creating, securing, and managing boxes on the Ergo blockchain.

Complementing ErgoTree is a frontend language named ErgoScript. Drawing inspiration from Scala/Kotlin, ErgoScript shares common subsets with Java and C#, making it user-friendly for programmers acquainted with these languages. ErgoScript is designed to attract a broad spectrum of programmers with its intuitive approach.

Structure, Authentication, and Application#
ErgoTree, distinct from low-level languages like stack-based EVM assembly, is structured as a typed abstract syntax tree. In this regards ErgoTree is a kind of authentication language aka “smart signature used to validate transactions or actions by verifying specific conditions.

ErgoTree achieves this by combining:

Secret Data Predicates: Conditions verifying confidential information such as digital signatures or secret keys.
Blockchain Context Predicates: Conditions dependent on the transaction's specific context within the blockchain.
By evaluating these predicates, ErgoTree authenticates transactions, ensuring their legitimacy and adherence to set rules. Its ability to validate and secure transactions while adapting to the transaction context makes ErgoTree a versatile tool, extending its applicability to various digital platforms, including other cryptocurrencies and Central Bank Digital Currencies (CBDCs), or even non-monetary digital objects where smart access could be needed.

Additional parties can be authorized
Parties can delegate authorization
AND/OR expressions
Conditions can be more than who signed.

**Key ErgoTree Concepts**

ErgoTree is written into UTXO boxes and is subsequently evaluated by the transaction verifier.
The propositions are stored in the blockchain in the ErgoTree serialization format. This format optimizes for compact storage, swift script execution, and efficient transaction validation.
The reference implementation of ErgoTree is in Scala, but alternative implementations can utilize other languages.
ErgoTree's binary format intentionally omits metadata, which might be necessary for various Ergo applications.

**Additional Resources**

ErgoTree serialization section available here.
Constant-less lambdas.
ErgoTree as an Authentication Language.
Human representation for ergo tree #812.
ErgoTree pseudo-code: Generates pseudo code for compiled ergo trees on a best effort basis.


## **ErgoTree Introduction**

This section describes a typed abstract syntax of the ErgoTree language, which is used to define logical propositions protecting boxes in the Ergo blockchain.

Serialized ErgoTree expressions are written into UTXO boxes and then evaluated by the transaction verifier.

Most Ergo users do not use ErgoTree directly since they are developing contracts in a higher-level language, such as ErgoScript, which is then compiled into ErgoTree.

The reference implementation of ErgoTree uses Scala; however, alternative implementations can use other languages. This documentation provides a language-neutral specification of ErgoTree for developers of alternative ErgoTree implementations.

The design space of programming languages is very broad, ranging from general-purpose languages like C, Java, and Python to specialized languages like SQL, HTML, CSS, etc.

The language for writing contracts on the blockchain must have several properties to serve as a robust platform for contractual money.

First, the language and the contract execution environment should be deterministic. Once created and stored in the blockchain, a smart contract should always behave predictably and deterministically; it should only depend on well-defined data context and nothing else.
As long as the data context does not change, any execution of the contract should return the same value any time it is executed on any execution platform using any compliant language implementation. No general-purpose programming language is deterministic because they provide non-deterministic operations, and ErgoTree does not have non-deterministic operations.
Second, the language should facilitate spam-resistance, i.e. defending against attacks when malicious contracts can overload the network nodes and bring the blockchain down (Ler17).
To fulfil this goal transaction model of ErgoTree supports predictable cost estimation and the fast calculation of contract execution costs to ensure the evaluation cost of the given transaction is always within acceptable bounds. In a general (Turing-complete) case, such cost prediction is not possible and requires special mechanisms such as Gas (Woo14). Gas limits on transactions indeed protect the network from spam attacks. Still, at the expense of the users, who need to be careful to specify the gas limit large enough for the transaction to complete; otherwise, the gas used for the failed transaction will be kept by the miners for their work, and the user will not get it back.
Third, the contract's language should be simple yet expressive enough to implement a wide range of practical applications efficiently.
For example, ErgoTree is not turing-complete, but it is co-designed with the capabilities of the Ergo blockchain platform itself, making the whole system Turing-complete as demonstrated in (CKM18). The simplicity of the language enables spam resistance.
Forth, simplicity and expressivity are often the characteristics of domain-specific languages (Fow10, Hud96).
From this perspective, ErgoTree is an intermediate representation of a DSL for writing smart contracts. The language directly captures the ubiquitous language of the Ergo blockchain directly manipulating with Boxes, Tokens, Zero-Knowledge Sigma-Propostions etc.
These are the novel first-class features of Ergo platform, which it provides for user applications.

It has a complementary frontend language called ErgoScript, whose syntax is inspired by Scala/Kotlin and shares a common subset with Java and C#; thus, if you are proficient in any of these languages, you will be right at home using ErgoScript as well.
ErgoScript aims to address the large audience of programmers with minimum surprise and WTF ratio.
And last but not least, ErgoTree, as a core language of Ergo platform, should be optimized for compact storage and fast execution.




ErgoTree: Reference Manual

Tooling

## **Data Inputs in ErgoScript**

ErgoScript's data inputs are a novel feature that enhances the traditional UTXO-based blockchain's functionality. This section delves into the concept of data inputs, their advantages, and their application within Ergo transactions.

**Understanding Data Inputs**

Traditional UTXO-based blockchains involve the consumption and subsequent destruction of inputs during transactions. Ergo innovates on this model with data inputs, which permit transactions to reference and read from existing UTXOs without the need to consume them. This breakthrough overcomes several limitations of the classic UTXO model, adding a layer of flexibility and efficiency to Ergo's extended UTXO (eUTXO) model.

**Key Features of Data Inputs**

Non-Destructive Access: Data inputs grant transactions the ability to tap into UTXO contents without the need to spend or consume them, preserving the UTXOs for future transactions.
Concurrent Data Access: Data inputs allow for the simultaneous referencing and reading of a UTXO's data by multiple transactions within a single block, without any of them spending the UTXO. This feature facilitates parallel processing and alleviates transaction execution bottlenecks.

**Benefits of Data Inputs**

The integration of data inputs into ErgoScript offers several notable benefits:

**Reduced Transaction Fees**: Since data inputs do not necessitate script execution or the generation of new outputs, they contribute to lower transaction fees, making them an economical choice for intricate transactions.

**Enhanced DeFi Applications***: Data inputs prove invaluable for decentralized finance (DeFi) applications, such as decentralized exchanges (DEXs) or order-book systems. They enable contracts to reference external data, like oracle data or order book states, without the need to consume the data boxes, facilitating concurrent interactions with the same state by multiple parties.

**Improved Scalability and Efficiency**: Data inputs contribute to network scalability and efficiency by allowing several transactions to concurrently read from the same data input, reducing the necessity for extra outputs and lessening the likelihood of transaction conflicts.

**Working with Data Inputs**

Ergo's data inputs are a distinctive feature not found in other eUTXO-based systems. When employing data inputs in ErgoScript, it's crucial to grasp their operation and how to leverage them effectively in smart contracts.

**Usage in Transactions**

In ErgoScript, data inputs are "read-only" boxes that supply vital information for contract validation without being spent in the transaction. For instance, a DeFi contract might utilize a data input to verify an asset's current price from an oracle box, ensuring the transaction complies with specific conditions without modifying the oracle box.

**Example Use Case**

Imagine a transaction that references a box with the ID d2b9b6536287b242f436436ce5a1e4a117d7b4843a13ce3abe3168bff99924a1 as both an input and a data input. This illustrates the versatility of data inputs, enabling a transaction to read and potentially update a box's state in one operation, assuming the box pre-existed the transaction.

In ErgoScript, you can refer to other boxes in the transaction using constructs like:


INPUTS(0).value > 10000 && OUTPUTS(1).value > 20000
This script enforces conditions based on the values of the first input and the second output boxes, showcasing how data inputs can be used to influence the logic of a transaction without consuming the referenced boxes.

**Comparison with Traditional Models**

Data inputs in ErgoScript provide a significant advancement over traditional UTXO models, particularly in how they facilitate more complex and interactive smart contracts. For a more detailed comparison between eUTXO and account-based models, refer to the Off Chain Logic & eUTXO article.

**Best Practices and Considerations**

**Selective Use**: Only include data inputs that are necessary for your contract logic to minimize transaction size and fees.

**Reliable Sources**: Ensure that the data accessed through data inputs is reliable and comes from trusted sources, especially when using oracles or external data providers.

**Validation Checks**: Always validate the data within data inputs to ensure it is in the expected format and state, reducing the risk of transaction failures.

**Additional Resources**

For further reading and deeper understanding of the UTXO model and its implementation in Ergo, consider the following resources:

[Unlocking The Potential Of The UTXO Model](https://github.com/Emurgo/Emurgo-Research/blob/master/smart-contracts/Unlocking%20The%20Potential%20Of%20The%20UTXO%20Model.md)


[Building A Portable And Reusable (PaR) UTXO dApp Standard](https://www.ergoforum.org/t/building-a-portable-and-reusable-par-utxo-dapp-standard/441)

[Data Inputs Semantics
](https://www.ergoforum.org/t/data-inputs-semantics/654)

[Model Transaction Example](https://docs.ergoplatform.com/dev/protocol/tx/model-tx/)

**Conclusion**

Data inputs are a powerful feature in ErgoScript that significantly enhance the flexibility, efficiency, and scalability of smart contracts. By allowing read-only access to UTXOs, data inputs enable more sophisticated interactions within the Ergo blockchain, making them an essential tool for developers building complex dApps and DeFi solutions.




Data Inputs in ErgoScript

## **Multi-Stage Protocols**

Unspent Transaction Outputs (UTXOs) are known for their scalability and reduced error rates. However, Ethereum's account model provides the advantages of persistent storage and a shared global context. Multi-Stage Contracts utilize a technique involving transaction trees to mimic persistent storage in UTXO-based systems. This is achieved by interlinking multiple UTXOs, each containing snippets of code, to create an extensive multi-stage protocol. This approach introduces on-chain computations and enables the execution of parallel actions within smart contracts.

This method offers a functionality akin to Ethereum's accounts but without the associated overhead.

For additional insights, refer to the Multi-Stage Contracts in the UTXO Model (Paper) and (Video Presentation).

**Examples**

The concept is illustrated through various examples, including contracts for A Rock Paper [Scissors game with provable fairness](https://docs.ergoplatform.com/dev/scs/tx/rock-paper-scissor/),[ Reversible Address with anti-theft features](https://docs.ergoplatform.com/dev/scs/tx/reversible-address/), and [A comprehensive ICO.](https://docs.ergoplatform.com/dev/scs/tx/ico/)

**Tutorials & Guides**

Explore the following resources for a deeper understanding of Multi-Stage Protocols:

[Ensuring Secure User Entry and Bootstrap Funneling in Multi-Stage Protocols](https://www.ergoforum.org/t/secure-user-entry-bootstrap-funneling-in-multi-stage-protocols/228)

[Workflow for Multi-Stage Protocol Development: Off-Chain and On-Chain](https://www.ergoforum.org/t/multi-stage-protocol-off-chain-on-chain-development-workflow/269)
(Note: The third link is a duplicate and has been omitted to improve the page's clarity and usefulness.)


## **Transaction Chains**

In a multi-stage protocol, a transaction chain is a sequence of transactions that are executed in a specific order to achieve a particular outcome or goal. Each transaction in the chain depends on the successful execution of the previous transaction, and the overall success of the protocol depends on the successful execution of the entire transaction chain.

For example, a transaction chain in a decentralised exchange protocol might involve several steps to execute a trade between two parties. The transaction chain might include steps such as:

Approving the exchange to spend the required tokens from the user's wallet.

Depositing the tokens to be traded into the exchange's smart contract.

Placing an order to buy or sell tokens at a specific price

Matching the order with a corresponding buy or sell order

Executing the trade by transferring the tokens and corresponding payment between the parties

Withdrawing the traded tokens and payment from the exchange's smart contract back to the respective parties' wallets

In this example, each transaction in the chain depends on the successful execution of the previous transaction, and the overall success of the trade depends on the successful execution of the entire transaction chain. If any transactions fail or encounter an error, the entire chain may fail, and the trade will not be executed.

Overall, transaction chains are an important aspect of multi-stage protocols. They provide a structured approach to achieving specific goals or outcomes while ensuring that the various transactions are executed in a specific order and with appropriate dependencies on each other.

**Process**

A transaction chain is used for creating a multi-stage protocol whose code does not contain loops or if statements.

A transaction chain is created as follows:

**1: Represent as N#**
Represent an Ethereum-like contract’s execution using n sequential steps, where each step represents a transaction that modifies its state. The states before and after a transaction are a directed graph's start and end nodes, with the transaction as the edge joining them. As an example, a 3-stage contract, such as the ICO example of Section 4.3, is represented as:

![](https://docs.ergoplatform.com/assets/img/scs/tx-chain.png)

The states contain data and the code that was executed in the transaction.

2: **State**
. 
Hardwire state n’s code and data inside state n − 1’s code. Then require the code of state n − 1 to output a box containing state n’s code and data. An example is given in the following pseudocode:

`// Ensure the output box has the same ErgoScript code as the state box and the same R4 data
// This is used to propagate data from the state box to the output box
out.propositionBytes == state_n_code &&
out.R4[Int].get == SELF.R4[Int].get
`

The above code uses the field propositionBytes of a box, which contains the binary representation of its guard script as a collection of bytes.

3: **Repeat**

Repeat Step 2 by replacing (n, n − 1) by (n − 1, n − 2) while n > 2

To avoid code size increase at each iteration, we ideally work with hashes, as in hash(out.propositionBytes) == state n code hash. However, for clarity of presentation, we will skip this optimization.

Next, we will look at Transaction Trees


## **Transaction Tree**

A transaction tree is a structure that represents a sequence of related transactions in a hierarchical manner, with each transaction in the tree having one or more child transactions that are dependent on its successful execution.

A transaction tree can be thought of as a more complex version of a transaction chain, in which each transaction in the chain may have multiple child transactions, each of which may in turn have their own child transactions. This creates a branching structure that resembles a tree, with the original transaction at the root and subsequent transactions branching off from it.

Transaction trees can be useful for representing more complex transaction sequences and dependencies, particularly in the context of smart contracts and other advanced blockchain applications. They can help to ensure that transactions are executed in the correct order and with appropriate dependencies, while also providing a more detailed and flexible view of the overall transaction sequence.

**Process**

A transaction tree is an extension of transaction chains where the code can contain if statements and simple loops, i.e., where some start and end nodes are the same. The following figure illustrates a transaction tree.

![](https://docs.ergoplatform.com/assets/img/scs/tx-tree.png)

An if statement is handled using the following pseudocode.

`if (condition) {
    out.propositionBytes == state_3_code // if true, set proposition to state_3_code
} else {
    out.propositionBytes == state_4_code // if false, set proposition to state_4_code
}
`

A simple loop is a special case of the if statement:

`if (condition) {
    out.propositionBytes == state_2_code // if true, set proposition to state_2_code
} else {
    out.propositionBytes == SELF.propositionBytes // if false, set proposition to SELF.propositionBytes
}
`

Most useful contracts can be represented using branches and simple loops but no cycles (as shown by examples in the paper). Ergo can be used to create such contracts using UTXOs.

Next, we will look at Transaction Graphs


## **Transaction Graphs**

A transaction graph is a structure that represents a set of related transactions in a more flexible and dynamic manner than a transaction tree. While a transaction tree is a hierarchical structure representing a sequence of transactions with specific dependencies between them, a transaction graph is a more general representation of the relationships between transactions with more complex and flexible dependencies.

In a transaction graph, each transaction is represented as a node, with edges connecting the nodes to represent dependencies between transactions. Unlike a transaction tree, which has a defined hierarchy and fixed relationships between transactions, a transaction graph allows for more complex and flexible relationships between transactions, including multiple dependencies and more complex branching.

Transaction graphs can be useful for representing complex transactions and dependencies, particularly in the context of smart contracts and other advanced blockchain applications. They allow for a more flexible and nuanced view of the transaction sequence, with the ability to represent more complex relationships and dependencies between transactions.

Transaction graphs are a powerful tool for representing complex blockchain transactions. They can help to improve the efficiency, scalability, and security of blockchain-based systems and applications, particularly in the context of advanced smart contracts and other decentralised applications.

As shown below, Ergo supports a more advanced technique called transaction graphs, where cycles are allowed in contract references.

![](https://docs.ergoplatform.com/assets/img/scs/tx-graph.png)

Please see the [Advanced ErgoScript Tutorial](https://storage.googleapis.com/ergo-cms-media/docs/AdvancedErgoScriptTutorial.pdf) Section 3.3.3.

## **Context Enrichment**

In Bitcoin and other existing UTXO systems, the context is just the UTXO being processed.

In order for a UTXO-based system to support transaction trees, the context must be rich enough to contain at least the entire spending transaction.

More formally, for any UTXO based blockchain, we can define the following levels of context, each extending the previous:

Level 1: current UTXO, height and timestamp
Level 2: current transaction (inputs and outputs)
Level 3: current block header and block solution
Level 4: current block (other sibling transactions)
Any platform at Level 2 and above is suitable for transaction trees. In this regard, Bitcoin operates at Level 1 and Ergo at Level 3.

Note that in Level 4 we cannot check validity of transactions independently of other transactions in the block. Hence it is more complex to implement Level 4.

In this work we show via examples how to create efficient Ethereum-like contracts in the UTXO model using transaction trees. The examples include a Rock-Paper-Scissors game, an Initial Coin Offering (ICO) campaign and a new primitive called reversible addresses for securely storing funds.

Enriched Context Levels#
Script code can have predicates on objects in context.
Example OUTPUT(0).value >= 1000
It is known that Level 2 can emulate Turing complete (hence Ethereum) However, the proof uses Rule 110 cellular automation. Reduction is not efficient
We need something more efficient than Rule 110. This is our contribution.
How to ensure that each stage follows protocol?#
Code in context Level 2 and higher allows multistage protocols

Spending transactions must create another UTXO with the required properties.


out.propositionBytes == state_n_code && 
out.R4[Int].get == SELF.R4[Int].get // ensure data is propagated
This code is checking two conditions:

Whether the propositionBytes of the out box is equal to state_n_code.
Whether the R4 register of the out box is equal to the R4 register of the current SELF box.
The first condition checks if the script of the output box matches the expected script (as represented by state_n_code). If this condition is not satisfied, the script will reject the transaction.

The second condition ensures that a certain data value stored in the R4 register is propagated from the current box to the output box. If this condition is not satisfied, the script will reject the transaction.




Multi-Stage Protocols

## **Cryptographic**

This document provides an in-depth look at the cryptographic schemes, protocols, and data structures used in the Ergo blockchain. Ergo’s security model relies heavily on advanced cryptographic protocols that ensure the integrity of transactions, protect user privacy, and enforce complex spending conditions within smart contracts. This document outlines the internal workings of these cryptographic schemes, focusing on their implementation within Ergo, particularly through the sigmastate-interpreter, sigma-rust, and Scrypto repositories.

**Overview**

Ergo’s cryptographic toolkit is built around composable Sigma protocols, which allow for flexible, secure, and efficient proofs of knowledge and cryptographic operations within its smart contract framework. These Sigma protocols are the foundation of Ergo’s cryptographic security, and they enable privacy-preserving applications like multi-signature wallets, ring signatures, and threshold signatures.

**Cryptographic Toolkit**

**Hash Functions**: SHA-256 & Blake2b are used for generating secure cryptographic digests and ensuring data integrity.
Encoding: Base58 encoding is used to represent binary data, such as public keys or hashes, in a more human-readable format.

**Signing Algorithms**: Ergo supports both ECDSA (secp256k1) and Schnorr signatures for secure transaction signing.

**Primitive Secrets:** Schnorr signatures and Diffie-Hellman tuples are primitive secrets used in creating proofs of knowledge.
Non-Interactive Proofs: Ergo makes cryptographic proofs non-interactive using the Fiat-Shamir transformation, making them suitable for blockchain environments.
For more details on cryptographic functions in ErgoScript, see ErgoScript Cryptographic Functions.

**Sigma Protocols**

Sigma protocols (Σ-protocols) are a subclass of cryptographic proof systems that allow a prover to convince a verifier of knowledge of a secret without revealing the secret itself. They are integral to the privacy and security features in Ergo, enabling advanced cryptographic applications such as zero-knowledge proofs, ring signatures, and threshold signatures.

**How Sigma Protocols Work**

At their core, Sigma protocols provide a secure way to prove the following properties:

**Proof of Knowledge of Discrete Logarithm:** Prove knowledge of the discrete logarithm of a given public key without revealing the secret key.

**Proof of Equality of Discrete Logarithms (Diffie-Hellman Tuple)**: Prove that two discrete logarithms (e.g., over different bases) are equal without revealing the logarithms.

These basic Sigma protocols can be combined using logical operators, such as AND, OR, and THRESHOLD (k-out-of-n), to form complex proofs.

**Composability of Sigma Protocols**

One of the key advantages of Sigma protocols is their composability. They can be combined in flexible ways to create sophisticated cryptographic contracts:

**OR Proofs**: Prove knowledge of one secret from a set of secrets (e.g., ring signatures).
AND Proofs: Prove knowledge of all secrets in a statement (e.g., multi-signature).

**Threshold Proofs**: Prove knowledge of at least k out of n secrets. This is essential for threshold signatures, where a subset of participants must cooperate to authorize a transaction.
These constructs enable the creation of powerful, privacy-preserving applications on Ergo.

Example: 3-out-of-5 Threshold Signature#
Consider a 3-out-of-5 threshold signature that allows any three participants to sign a transaction. This ErgoScript implements such a scheme:


`val ringScript = s"""
{
  atLeast(
    3, 
    Coll(
      PK("9f8ZQt1Sue6W5ACdMSPRzsHj3jjiZkbYy3CEtB4BisxEyk4RsNk"), 
      PK("9hFWPyhCJcw4KQyCGu4yAGfC1ieRAKyFg24FKjLJK2uDgA873uq"), 
      PK("9fdVP2jca1e5nCTT6q9ijZLssGj6v4juY8gEAxUhp7YTuSsLspS"), 
      PK("9gAKeRu1W4Dh6adWXnnYmfqjCTnxnSMtym2LPPMPErCkusCd6F3"),
      PK("9gmNsqrqdSppLUBqg2UzREmmivgqh1r3jmNcLAc53hk3YCvAGWE")
    )
  )
}
`

This script enables three participants from a group of five to cooperatively sign and authorize a transaction. It leverages the THRESHOLD (k-out-of-n) logic, which is native to Sigma protocols, ensuring that only a subset of participants is required to perform cryptographic operations.

**Schnorr Signatures**

Schnorr signatures are a key part of Ergo’s cryptographic foundation, providing an efficient, simple, and secure way to verify the authenticity of transactions. The Schnorr signature scheme is based on the hardness of the discrete logarithm problem and is favored for its performance and security properties over ECDSA.

**How Schnorr Signatures Work**

The signing process in Schnorr signatures follows these steps:

Key Generation: Generate a private key 
 and compute the corresponding public key 
, where 
 is the generator of the elliptic curve (SecP256K1).

Signing: To sign a message 
, the user:

Picks a random nonce 
 and computes 
,
Computes 
,
Computes the signature as 
.

Verification: The verifier checks the signature by computing 
 and verifying: [ e = H(R' || P || m) ]

Schnorr signatures are widely used in Ergo for multi-signature schemes, privacy-enhancing protocols, and adaptor signatures.

**Use Cases of Schnorr Signatures**

Multi-Signature Wallets: Schnorr signatures enable efficient and secure multi-signature wallets, where multiple participants must sign a transaction collaboratively.
Adaptor Signatures: Adaptor signatures allow for conditional private swaps, such as atomic swaps between different cryptocurrencies, without revealing sensitive information.
For detailed examples and implementation, see Verifying Schnorr Signatures in ErgoScript.

**Diffie-Hellman Protocol**

The Diffie-Hellman (DH) protocol is widely used in cryptography for secure key exchange. In Ergo, the Diffie-Hellman Tuple (DHT) protocol allows provers to demonstrate shared knowledge of a secret without revealing it, enabling privacy-preserving cryptographic proofs.

**Diffie-Hellman Tuple (DHT)**

In a Diffie-Hellman Tuple, a prover proves knowledge of a shared secret 
 such that:

This protocol can be combined with Sigma protocols to create privacy-preserving smart contracts, such as stealth addresses and mixers. For instance, ErgoMix relies on the security of the Diffie-Hellman protocol to ensure transaction fungibility and user privacy.

**Use Cases of Diffie-Hellman**

Stealth Addresses: Ensure that each transaction generates a unique address, making it difficult to link transactions to the original public address, protecting user privacy.
ZeroJoin Mixers: Enable on-chain privacy-preserving mixing of tokens, ensuring that transactions remain fungible and private without reliance on trusted third parties.
For a deep dive into Diffie-Hellman Tuples, refer to Diffie.

**Data Structures in Ergo**

Ergo employs specialized cryptographic data structures to ensure secure and efficient state management within its blockchain:

**AVL+ Trees**

Ergo uses AVL+ trees as part of its Authenticated Dynamic Dictionary (ADD) to track UTXO state changes. These trees provide cryptographic proofs of state changes while maintaining logarithmic complexity for inserts, lookups, and deletions. AVL+ trees are essential for the UTXO model’s scalability and efficiency, enabling fast and secure updates across the network.

Implementation: Learn more about AVL+ trees in BatchAVLProver.scala and BatchAVLVerifier.scala.

**Merkle Trees**

Merkle trees are used in Ergo to ensure the integrity of large datasets, such as blocks of transactions, without requiring the entire dataset to be transmitted or verified. By storing only the root hash of a Merkle tree, nodes can quickly verify that individual transactions are part of the block, reducing the overhead of verification.

Learn more about Merkle trees here.

**Security Considerations**

The cryptographic schemes in Ergo rely on the hardness of the discrete logarithm problem and other well-established cryptographic assumptions. It is critical that developers design smart contracts carefully to avoid vulnerabilities, such as weak randomness or improper use of cryptographic primitives. Ergo provides extensive test coverage for its cryptographic implementations, such as the SigningSpecification.

**Conclusion**

Ergo’s cryptographic framework, built on Sigma protocols, Schnorr signatures, and Diffie-Hellman key exchanges, provides robust tools for secure and privacy-preserving decentralized applications. Its composable cryptographic proofs enable developers to create complex spending conditions, privacy-enhancing features, and flexible multi-signature schemes, all while maintaining a high standard of security.

For more information, visit the sigmastate-interpreter repository, sigma-rust repository, and Scrypto repository.


Cryptographic

## **Sigma Protocols**

**Introduction**
Sigma protocols (Σ-protocols) are a class of cryptographic proof systems that play a central role in the Ergo blockchain. These protocols allow a prover to convince a verifier that they know a value, such as a secret key, without revealing the value itself. Σ-protocols are the foundation for many privacy-preserving and multi-signature functionalities in Ergo.

In ErgoScript, proving and verifying cryptographic statements are first-class primitives, giving developers access to powerful Σ-protocols. Scripts protecting transaction outputs can contain Σ-statements, which must be proven (by generating Σ-proofs) before the outputs can be spent.

Conceptually, Σ-proofs are generalizations of digital signatures. The Schnorr signature scheme is the canonical example of a Σ-proof: it allows the recipient to prove knowledge of a secret (discrete logarithm) without revealing it. Σ-proofs in Ergo extend this concept, allowing the creation of more complex cryptographic protocols like multi-signature, ring signatures, and threshold signatures.

**Elementary Σ-Protocols in ErgoScript**

ErgoScript offers two elementary Σ-protocols over a group of prime order, such as an elliptic curve group:

**Proof of Knowledge of Discrete Logarithm (Schnorr Signature):** This protocol proves knowledge of the discrete logarithm of a given public key with respect to a fixed generator. Essentially, this is the Schnorr signature scheme.

**Proof of Equality of Discrete Logarithms (Diffie-Hellman Tuple):** This protocol proves that two values share the same discrete logarithm across two different generators.
These basic protocols can be composed to create more advanced proofs using logical connectives like AND, OR, and THRESHOLD. This composability is what enables the creation of sophisticated smart contracts and multi-signature schemes.

For a detailed introduction to Σ-protocols, refer to the paper On Σ-protocols.

**Composability of Σ-Protocols**

A powerful feature of Σ-protocols in Ergo is their composability. You can create logical combinations of cryptographic statements using basic AND/OR logic.

Examples include:

**Ring Signatures:** A ring signature is a proof of knowledge of one of multiple secrets. For example:

Prove knowledge of either secret A or secret B.

**Threshold Signatures**: A threshold signature is a proof that a certain number of secrets are known. For example:

Prove knowledge of at least two of three secrets.

These constructions allow for flexible and privacy-preserving proofs. The THRESHOLD construct (also known as k-out-of-n) is particularly useful for multi-party agreements, ensuring that a subset of participants can authorize a transaction without requiring everyone’s involvement.

Example: 3-out-of-5 Threshold Signature

`val ringScript = s"""
{
  atLeast(
    3, 
    Coll(
      PK("9f8ZQt1Sue6W5ACdMSPRzsHj3jjiZkbYy3CEtB4BisxEyk4RsNk"), 
      PK("9hFWPyhCJcw4KQyCGu4yAGfC1ieRAKyFg24FKjLJK2uDgA873uq"), 
      PK("9fdVP2jca1e5nCTT6q9ijZLssGj6v4juY8gEAxUhp7YTuSsLspS"), 
      PK("9gAKeRu1W4Dh6adWXnnYmfqjCTnxnSMtym2LPPMPErCkusCd6F3"),
      PK("9gmNsqrqdSppLUBqg2UzREmmivgqh1r3jmNcLAc53hk3YCvAGWE")
    )
  )
}
"""
`

This contract is an example of a 3-out-of-5 threshold signature scheme. It can be compiled to a Pay-to-Script (P2S) address, where any three of the five public keys can authorize a transaction.


**Use Cases of Σ-Protocols**

1.**Multi-Signature Wallets**

Multi-signature wallets are a natural use case for Σ-protocols, where multiple parties are required to authorize a transaction. Σ-protocols allow you to set up flexible conditions such as requiring two out of three signatures, or even more complex schemes involving multiple participants.

**2. Ring Signatures for Privacy**

Ring signatures provide privacy by allowing a user to sign a transaction on behalf of a group without revealing which group member signed it. This is particularly useful for creating anonymous transactions and decentralized mixers, such as ErgoMixer. The privacy of ring signatures makes them ideal for applications where anonymity is crucial, such as anonymous donations or private payments.

**3. Threshold Signatures**

Threshold signatures are critical for decentralized control. For example, a corporate wallet could be protected by a 3-out-of-5 signature scheme, ensuring that no single party can unilaterally control the funds.

**4. Time-Locked Conditions**

Σ-protocols can be combined with time-locked conditions. For instance, you can construct a contract that allows a transaction to be spent if either a ring signature is provided by a set of participants before a certain block height, or the funds can be refunded by a single party after the block height has passed.

**5. Decentralized Mixers**

ErgoMixer is an advanced, non-custodial token mixer based on Σ-protocols. It leverages ring signatures and zero-knowledge proofs to provide enhanced privacy while ensuring that no third party is needed to manage or approve the mixing process. SigmaJoin, an off-chain implementation of ErgoMixer, further extends the concept of trustless and decentralized privacy mechanisms.

**Prover and Verifier Workflow**

In Ergo, transaction processing using Σ-protocols involves two main actors: the Prover and the Verifier.

Prover:

The Prover uses the ErgoTree interpreter to reduce a high-level spending condition into a SigmaBoolean (the cryptographic proposition that needs to be proven). The SigmaBoolean is then converted into a cryptographic proof using the Fiat-Shamir transformation, ensuring that the transaction can only be authorized by parties who possess the necessary secrets (such as private keys).
Verifier:

The Verifier also uses the ErgoTree interpreter to reduce the spending condition into a SigmaBoolean. It then checks the cryptographic proof against this proposition, ensuring that the transaction is valid and all required conditions are met.

**Fiat-Shamir Transformation**

The Fiat-Shamir transformation is a cryptographic technique that makes interactive proof systems non-interactive, suitable for use in blockchain environments. This is crucial for Sigma protocols, as it allows Σ-proofs to be created and verified without requiring real-time interaction between the prover and the verifier.

In Ergo, Σ-protocols rely on the Fiat-Shamir transformation to generate challenges (hash values) from the commitments and messages involved in the proof. This ensures that the proofs are non-interactive and can be verified deterministically on-chain.

**Applications and Resources**

**Applications**

**ErgoMixer:** A state-of-the-art, non-custodial token mixer using Σ-protocols for privacy and anonymity.

**SigmaJoin**: An off-chain implementation of ErgoMixer for decentralized privacy-preserving transactions.
Ergo Threshold Signature Contracts: Use Σ-protocols to create custom multi-signature wallets and contracts.

**DarkFund0**

DarkFund0: A ZK fund for privacy applications, sponsoring developments in privacy-focused decentralized finance (DeFi) on Ergo.

**Tutorials**

Verifying Schnorr Signatures in ErgoScript
Updateable Multisig Pattern

**Presentations**

Sigma Protocols
On Σ-protocols

**Conclusion**

Sigma protocols form the backbone of Ergo’s smart contracts and cryptographic proofs, enabling flexible and privacy-preserving transactions. Whether it's for simple multi-signature wallets, complex threshold signatures, or advanced privacy-preserving ring signatures, Σ-protocols provide the necessary cryptographic tools for building secure and decentralized applications on the Ergo blockchain.

With their composability and integration into ErgoScript, Σ-protocols make Ergo a versatile platform for privacy-focused cryptographic applications.




Sigma Protocols

## **Schnorr Signature**

In the simplest case, a signature in an Ergo transaction is a Schnorr signature. In more complex cases, it corresponds to a subset of Generalized Schnorr Proofs, which are used in privacy-preserving applications and advanced cryptographic protocols.

The Schnorr signature is a core cryptographic primitive in Ergo, used both in basic transaction validation and as part of more complex proof systems. It is simple, efficient, and secure, making it an ideal choice for the wide range of cryptographic functionalities in Ergo.

**Overview**

Ergo’s Schnorr signatures are implemented using the SecP256K1 elliptic curve, the same curve used in Bitcoin. The flexibility of Schnorr signatures enables Ergo to support a range of applications, from simple transactions to more advanced multi-signature schemes and privacy-enhancing protocols.

**Key Properties:**

Elliptic Curve: Ergo uses SecP256K1, ensuring compatibility with Bitcoin-based systems.
Generalized Proofs: In Ergo, Schnorr signatures can be generalized into complex Sigma protocol proofs that allow for privacy-preserving multi-party computations and other advanced cryptographic applications.
Standards Compliance: Ergo’s implementation closely follows established cryptographic standards (RFCs), allowing for interoperability with protocols like MuSig.
How Schnorr Signatures Work#
The Schnorr signature process consists of key generation, signing, and verification.

**Key Generation**

A user generates a private key 
 and computes the corresponding public key 
, where 
 is the generator point on the elliptic curve.

**Signing**

To sign a message 
, the following steps are performed:

Generate a random nonce 
 and compute 
.
Hash the values 
, 
, and the message 
 to generate a challenge 
: [ e = H(R \parallel P \parallel m) ]
Compute the signature 
 as: [ s = k + ex ]
Verification#
To verify a signature 
, the verifier computes: [ R' = sG - eP ] and checks if: [ e = H(R' \parallel P \parallel m) ] If the condition holds, the signature is valid, demonstrating that the signer knows the private key corresponding to the public key 
.

**Generalized Schnorr Proofs**

In more complex cases, Ergo extends Schnorr signatures into Generalized Schnorr Proofs as part of the Sigma protocol framework. These generalized proofs enable advanced cryptographic functionalities such as:

Multi-Signature Protocols: Implementations like MuSig, which allows multiple participants to collectively sign a transaction. This reduces the overall transaction size and preserves privacy by aggregating public keys and signatures.
Ring Signatures: Where one can prove they belong to a group of signers without revealing which specific individual signed the message.
Threshold Signatures: Schemes like k-out-of-n signatures, where a subset of signers must collaborate to authorize a transaction.

**Use Cases of Schnorr Signatures**

**1. MuSig (Multi-Signature Protocols)**

The MuSig protocol allows multiple participants to collaboratively generate a Schnorr signature. This enhances privacy and efficiency, as the final signature is indistinguishable from a regular Schnorr signature, and the transaction size is reduced.

**Use Case:** Multi-signature wallets, where multiple parties must sign off on a transaction.
Privacy: The individual signers are indistinguishable from each other.

**2. Adaptor Signatures for Atomic Swaps**

Adaptor signatures are an extension of Schnorr signatures that facilitate atomic swaps and cross-chain exchanges. These signatures enable conditional transactions, allowing a swap to be completed only when a specific secret is revealed.

**3. Privacy-Preserving Transactions**

Ergo uses Schnorr signatures in combination with Sigma protocols to enable privacy-preserving applications, such as:

**Mixers**: Anonymous transaction systems like ZeroJoin rely on Schnorr-based ring signatures.
Stealth Addresses: Ensure recipient privacy by generating one-time addresses for each transaction.
Sigma Protocols and Schnorr Signatures#
Schnorr signatures are a foundational part of Ergo’s Sigma protocol framework. Sigma protocols generalize Schnorr signatures, allowing them to be composed into complex cryptographic proofs. For example:

**Ring signatures**: Prove that a signer belongs to a group without revealing which individual actually signed.
Threshold signatures: Require collaboration between multiple parties to authorize a transaction.
Non-Interactive Proofs: Sigma proofs can be transformed into non-interactive proofs via the Fiat-Shamir transformation, which allows them to be used in blockchain environments without interactive verification.
Resources for Developers#
To dive deeper into Schnorr signatures and how they are implemented in Ergo, refer to the following resources:

Schnorr-based signing function: Sign function based on Schnorr protocol.
Generalized Schnorr proofs: Learn how SigmaBoolean is used to create advanced cryptographic conditions on the Ergo blockchain in the SigmaBoolean Documentation.

**Conclusion**

Schnorr signatures are central to Ergo’s cryptographic framework, both as simple transaction signatures and as the basis for Generalized Schnorr Proofs. By leveraging Sigma protocols, Ergo extends Schnorr signatures into powerful cryptographic tools for privacy-preserving applications, multi-signature schemes, and complex cryptographic contracts.

For developers, these tools enable the creation of advanced decentralized applications (dApps) that prioritize both privacy and security. As part of the broader cryptographic infrastructure, Schnorr signatures ensure that Ergo remains at the forefront of privacy-focused blockchain technology.

For further reading, explore:

[MuSig paper
](https://eprint.iacr.org/2018/068)

[Adaptor Signatures](https://eprint.iacr.org/2018/123.pdf)

[SigmaBoolean Documentation](https://docs.ergoplatform.com/dev/scs/types/sigmaboolean/)

Schnorr Signature

## **Data Structures in Ergo**

In Ergo, several key data structures are employed to support its blockchain and smart contract functionality. These data structures are designed to ensure efficient and secure access to data, guaranteeing optimal performance and data integrity.

Here's a list of the main data structures used within the Ergo ecosystem:

**1. AVL Trees (Authenticated Dynamic Dictionaries)**

**Purpose**: AVL Trees in Ergo are a specialized type of self-balancing binary search tree, used to store and authenticate dynamic sets of data in a compact and efficient manner. They ensure efficient and secure access to your data, guaranteeing optimal performance and data integrity.

**Usage:**
In the storage of UTXO states, where efficient verification of state changes is required.
In applications like off-chain code and distributed systems managing the Plasma infrastructure, where privacy-preserving transactions need to verify inclusion or exclusion of certain elements without revealing all details.

**Documentation Reference:** AVL Trees in Ergo, Plasma

**2. Merkle Trees**

**Purpose**: Merkle Trees are a fundamental data structure in the Ergo blockchain, ensuring the integrity and authenticity of data. They play a crucial role in various blockchain operations, from verifying transactions within blocks to securing additional metadata in the Extension Block.

**Usage:**
In the construction of the Transaction Merkle Tree, combining all transactions and their corresponding spending proofs into a single Merkle Tree.
In the Extension Block Merkle Tree, securing key-value data like miner votes and protocol parameters.
In creating Merkle Batch Proofs, allowing efficient validation of the integrity and authenticity of data transactions. It supports the serialization and deserialization of Merkle proofs in batches, significantly improving the speed and efficiency of data verification processes.
In generating compact proofs of state transitions, enabling lightweight clients to securely participate in the network. An example of how a lite client can check a Merkle-tree-based membership proof is detailed in the Lite Client Checking Merkle Proof documentation.

**Documentation Reference:** Merkle Trees in Ergo
**3. Sigma Trees (ErgoTree)**

**Purpose:** Sigma Trees, also known as ErgoTrees, are specialized data structures that represent logical propositions and cryptographic conditions in the Ergo blockchain. These trees are used in the execution of smart contracts and scripts, encapsulating complex logic and cryptographic proofs.

**Usage:**
In representing the logic and conditions of ErgoScript smart contracts.
In evaluating conditions for spending boxes (UTXOs) by verifying the cryptographic proofs and logic encoded in the ErgoTree.
Potential future integration with Merkle Trees (MT) or Sparse Merkle Trees (SMT) to enable working with Ergo transactions and the extension block database directly from ErgoScript.

**Documentation Reference**: ErgoTree

**4. Context Data Structures**

**Purpose:** These structures represent the contextual information that is available during the execution of ErgoScripts. Contexts include details such as the current block height, the transaction being processed, and any additional data inputs.

**Usage:**

In providing necessary environmental details for smart contract execution.
In enabling the contextual flexibility of ErgoScripts.
**Documentation Reference:** Context Data Structures

**5. Proof of Proof-of-Work (PoPow) Data Structures

**Purpose**: These are specialized data structures used to implement PoPow, which allows lightweight nodes to verify the longest chain without downloading the entire blockchain.
Usage:
In creating and verifying interlink vectors, which are crucial for PoPow security.
In enabling lightweight clients to participate in the network with minimal data requirements.
Documentation Reference: PoPow Data Structures
6. Box Data Structures#
Purpose: Boxes are the fundamental data structures representing UTXOs in Ergo. Each box contains value, associated tokens, and an ErgoScript that defines spending conditions.
Usage:
In the creation and management of UTXOs.
In defining conditions for transaction execution within the blockchain.
Documentation Reference: Box Format
7. Transaction Data Structures#
Purpose: These structures represent the transactions within the Ergo blockchain. They include inputs, outputs, data inputs, and other necessary information for executing transactions.
Usage:
In organizing and executing financial transfers, contract calls, and state changes.
In ensuring the integrity and validity of transactions through the blockchain.
Documentation Reference: Transaction Format
8. Interlink Vectors#
Purpose: Used in conjunction with Merkle Trees for PoPow proofs, interlink vectors allow efficient verification of the chain of blocks in the blockchain.
Usage:
In the implementation of PoPow protocols for verifying blockchain headers.
Documentation Reference: Interlink Vectors
Potential Additional Data Structures#
As the Ergo ecosystem continues to evolve, additional data structures may be introduced, particularly in areas such as privacy-preserving protocols, advanced smart contract functionalities, or optimization of blockchain operations.

Hash-Based Accumulators#
For UTXO-based systems, simpler and well-studied hash-based accumulators are effective. Sparse Merkle Trees are sufficient for UTXO settings, though not the most efficient solution. More efficient alternatives include UTREEXO or the approaches described in this paper.

UTREEXO#
UTREEXO is a more efficient alternative for representing the UTXO set compared to traditional Merkle Trees. It allows for partially stateless clients, which can be practical in many scenarios. However, fully stateless clients still require archival nodes to store and update client proofs.

Partially Stateless Clients#
Ergo currently employs an approach outlined in this paper to support partially stateless clients. This approach balances security and efficiency, as fully stateless clients still depend on archival nodes for storing and updating client proofs.

Resources#
Comparison of AVL Trees and Merkle Trees in Ergo#
In Ergo, both AVL trees and Merkle trees play critical roles in ensuring the integrity, security, and efficiency of the blockchain. While they are both binary trees, their specific structures, purposes, and use cases differ significantly, making each suitable for different aspects of the Ergo ecosystem.

AVL Trees (Authenticated Dynamic Dictionaries)#
Overview: AVL trees in Ergo, particularly the AVL+ variant, are self-balancing binary search trees used to store and authenticate dynamic data sets. The main characteristic of AVL trees is their ability to maintain balance, which ensures that the height of the tree remains logarithmic in relation to the number of nodes. This property guarantees that operations such as search, insertion, and deletion can be performed efficiently, even as the data set grows.

Use Case in Ergo:

UTXO Set Management: AVL+ trees are employed to manage the UTXO (Unspent Transaction Output) set in the Ergo blockchain. Since UTXOs are frequently created and spent, the dynamic nature of AVL trees makes them ideal for this application. They support efficient updates while providing compact proofs for verification, which is crucial for maintaining the blockchain's performance.
Key Advantages:

Efficient Handling of Dynamic Data: AVL trees are optimized for scenarios where data changes frequently, such as the UTXO set, where coins are constantly being spent and created.
Compact Proofs: AVL+ trees generate compact proofs for the inclusion or exclusion of elements, aiding in efficient state verification.
Merkle Trees#
Overview:

Merkle trees are hash-based binary trees where each node contains a cryptographic hash. They are primarily used to ensure the integrity and authenticity of data. In a Merkle tree, leaf nodes represent individual data elements, and each non-leaf node is a hash of its child nodes. The Merkle root, derived from the tree, serves as a cryptographic commitment to the entire data set, allowing for efficient verification of data integrity through Merkle proofs.

Use Case in Ergo:

Transaction Verification: Merkle trees are used in Ergo to commit all transactions in a block into a single tree structure. The resulting Merkle root is included in the block header, enabling the network to verify the inclusion of any transaction within the block quickly.
Extension Block Security: Merkle trees are also utilized in the Extension Block to secure additional metadata, such as miner votes and protocol parameters. This ensures that the data has not been tampered with after the block is created.
Key Advantages:

Efficient Verification of Static Data: Merkle trees are particularly well-suited for static or infrequently changing datasets. They allow for quick verification of data integrity without the need to access the entire data set.
Compact Proofs: Merkle proofs are compact and efficient, making them ideal for verifying individual elements within a large dataset, such as transactions within a block.
Why Use AVL Trees or Merkle Trees?#
When to Use AVL Trees:

Dynamic Data Management: AVL trees are the preferred choice for dynamic data sets that require frequent updates, such as the UTXO set in Ergo.
Real-Time Applications: Their ability to maintain balance and support efficient insertions and deletions makes AVL trees ideal for real-time blockchain applications.
When to Use Merkle Trees:

Data Integrity and Authentication: Merkle trees excel in scenarios where data integrity needs to be proven without frequent modifications. They are perfect for static datasets where the structure remains relatively unchanged, such as in block headers or extension blocks.
Efficient Data Verification: For use cases requiring efficient verification of specific data elements within a large dataset, Merkle trees provide the necessary cryptographic proofs with minimal overhead.
Conclusion#
Both AVL and Merkle trees are indispensable in the Ergo blockchain, each serving distinct but complementary purposes. AVL trees are optimized for dynamic data management and are essential for handling the UTXO set, where data changes frequently. In contrast, Merkle trees are used to ensure the integrity and authenticity of static datasets, such as transactions within a block or data in the Extension Block, through efficient cryptographic proofs. Understanding these differences is crucial for developers working within the Ergo ecosystem to leverage the right data structure for their specific use case.



Data Structures in Ergo

## **Proof of Proof-of-Work (PoPow) Data Structures in Ergo**


**Overview**

Proof of Proof-of-Work (PoPow) is an advanced protocol that enables lightweight clients to securely and efficiently verify that a blockchain follows the longest chain rule without downloading the entire blockchain. This is particularly important for resource-constrained devices, such as mobile phones or IoT devices, where downloading and storing the entire blockchain is impractical.

The PoPow protocol is built on top of several key data structures that facilitate this efficient verification process. This documentation page provides an in-depth look at these data structures, how they interact, and their roles within the PoPow protocol.

**Key Data Structures in PoPow**

The PoPow protocol relies on a combination of interlink vectors, NiPoPoW proofs, and Merkle trees to achieve its goals. Each of these data structures plays a specific role in enabling efficient verification of the blockchain's integrity.

**Interlink Vectors:**

**Purpose**: Interlink vectors store references to previous block headers at different difficulty levels. They allow lightweight clients to verify the blockchain's integrity by checking only a subset of blocks, rather than the entire chain.

**Structure**: An interlink vector is an array where each element points to a previous block header. The level of each element is determined by the number of leading zeros in the block's hash, corresponding to the difficulty level of that block.

**Usage:** Interlink vectors are updated as new blocks are added to the blockchain, ensuring that the latest blocks are always accessible for verification. They are particularly useful in scenarios where quick and efficient chain validation is needed.

**Code Reference**: InterlinkVector.scala
NiPoPoW (Non-Interactive Proof of Proof-of-Work) Proofs:

**Purpose**: NiPoPoW proofs allow a lightweight client to verify that a given chain is the correct one (i.e., the chain with the most cumulative work) without interacting with the blockchain network.

**Structure:** A NiPoPoW proof consists of a sequence of block headers from the blockchain, including interlink references and proof chains. The proof chain includes blocks that represent a certain amount of work, with a gap between them that ensures the inclusion of the most important blocks.

**Usage**: NiPoPoW proofs are used by clients to verify that a blockchain adheres to the longest chain rule by checking the work done on the chain. They reduce the amount of data that needs to be processed while maintaining a high level of security.

**Code Reference**: NipopowProof.scala

**Merkle Trees**:

**Purpose**: Merkle trees are used to efficiently verify the inclusion of specific data elements (such as transactions or block headers) in a larger dataset. In the context of PoPow, Merkle trees help verify that the interlink vectors and other components of the PoPow proof are correctly formed.

**Structure**: A Merkle tree is a binary tree where each leaf node is a hash of a block of data, and each non-leaf node is a hash of its child nodes. The root of the tree, known as the Merkle root, serves as a cryptographic commitment to the entire dataset.

**Usage**: In PoPow, Merkle trees are used to generate Merkle proofs that verify the inclusion of specific blocks or headers in the chain. These proofs are then included in the NiPoPoW proof to provide lightweight clients with the necessary evidence to trust the blockchain's integrity.
Code Reference: Extension.scala

**Interaction Between Data Structures**

The PoPow protocol leverages the interaction between interlink vectors, NiPoPoW proofs, and Merkle trees to provide a comprehensive solution for lightweight blockchain verification. Here's how these data structures work together:

Interlink vectors are generated and updated as new blocks are mined. These vectors provide references to important block headers at different difficulty levels, allowing clients to quickly identify and verify the most relevant parts of the blockchain.

NiPoPoW proofs are constructed using the interlink vectors and the chain of block headers. These proofs include a carefully selected subset of block headers that represent the chain's cumulative work, along with the interlink references needed to verify the chain's integrity.

Merkle trees are used to create cryptographic proofs that verify the inclusion of specific data elements, such as block headers or interlink references, in the PoPow proof. These Merkle proofs are included in the NiPoPoW proof, providing clients with a compact and secure way to verify the blockchain.

The combination of these data structures ensures that the PoPow protocol is both secure and efficient, enabling lightweight clients to participate in the blockchain network without requiring extensive resources.

Example: Constructing a NiPoPoW Proof#
Here is a step-by-step overview of how a NiPoPoW proof is constructed using the PoPow data structures:

Collect Block Headers:

A set of block headers is selected from the blockchain, representing different points in the chain with varying difficulty levels. These headers are chosen based on the work they represent and their relevance to the chain's integrity.
Build the Interlink Vector:

The interlink vector is constructed by referencing the selected block headers. Each element in the vector points to a block header with a specific difficulty level, ensuring that the proof covers the entire chain.
Generate Merkle Proofs:

Merkle proofs are generated for the selected block headers and interlink references. These proofs ensure that the data elements included in the proof are valid and can be verified by the client.
Assemble the NiPoPoW Proof:

The block headers, interlink vector, and Merkle proofs are assembled into a NiPoPoW proof. This proof is then sent to the client, who can use it to verify the blockchain's integrity.
Verification by the Client:

The client verifies the NiPoPoW proof by checking the Merkle proofs and ensuring that the interlink vector correctly references the block headers. If the proof is valid, the client can trust that the blockchain follows the longest chain rule.
Conclusion#
The PoPow protocol is a powerful tool for enabling secure and efficient blockchain verification by lightweight clients. By leveraging interlink vectors, NiPoPoW proofs, and Merkle trees, PoPow provides a scalable solution for verifying the integrity of the blockchain without requiring extensive resources.

Developers working with the Ergo blockchain should familiarize themselves with these data structures and their interactions to effectively implement and utilize PoPow in their applications. As the Ergo ecosystem continues to grow, PoPow and its associated data structures will play a crucial role in maintaining the security and scalability of the network.

Proof of Proof-of-Work (PoPow) Data Structures in Ergo

Welcome to the comprehensive Ergo Developer's Guide! Whether you're a seasoned blockchain developer or just starting out, this guide is designed to provide you with an in-depth understanding of the Ergo platform and the resources available to you. Explore the unique features of Ergo, learn how to develop on our platform, and connect with our vibrant community.

xplore the unique features of Ergo, learn how to develop on our platform, and connect with our vibrant community.

Developing on Ergo

Course Details

Level

Ratings

Modules

Lessons

Holder $WORK Price

Contact Us

Documentation

Navigation