Ergo Blockchain Crash Course:

Quick And Dirty (NSFW)

Luca D’Angelo

Purpose

• Learn the basic concepts of eUTXO and the Ergo blockchain.
• Learn the basics of the ErgoScript language.
• Learn about design considerations and ethics.
• You are a laymen interested in blockchain.
• You are a developer interested in developing on Ergo but don’t know where to start.
• You are a miner interested in gaining a deeper understanding of the blockchain you have invested so much time and money into.
• Learn about a breadth of different topics without going too deep within each one, but a good foundation to jump into other areas you may be more interested in.

Course Outline

• eUTXO Model Review
• Anatomy of Ergo Blockchain
• ErgoScript Development Fundamentals
• Examples

ErgoPad

• Website: https://ergopad.io
• Discord: https://discord.com/invite/E8cHp6ThuZ
• Telegram: https://discord.com/invite/E8cHp6ThuZ

FIN

Ergo Blockchain Crash Course:

eUTXO Model Review

Outline

• eUTXO Model Review
• Answer some basic questions

eUTXO Model Review: What is eUTXO?

eUTXO ≔ Extended Unspent Transaction Output

Resulting Questions

1. What is a transaction?
2. What is an output?
3. What does unspent mean?
4. What makes it extended?

eUTXO Model Review: What is a transaction?

• Conceptual Model: Directed Acyclic Graph (DAG) with a flow on it.
• Directed: Edges have explicit direction (like the Arrow of Time)
• Acyclic: No cycles or loops, you can’t get back to the past (like Samurai Jack)
• Graph: Name given to the object which consists of nodes connected together by edges.
• Flow: The information “flowing” through each edge, in and out of each node.
• Transaction: A node in the DAG with input and output edges.
• A state transition operation on the input eUTXOs to the output eUTXOs.

eUTXO Model Review: What is an output?

• Conceptual Model: All nodes in the graph contain input edges and output edges. The outgoing edges are the eUTXOs (i.e. the outputs).

eUTXO Model Review: What does unspent mean?

• Conceptual Model: All input edges into a node (i.e. transaction) are in the process of being spent. The inputs were once outputs of a previous transaction node. Before the inputs were spent they were unspent outputs.

eUTXO Model Review: What makes it extended?

• Conceptual Model: Each edge is associated with a data object, instead of just one single value (i.e. the base currency of the blockchain).
• For each input within a transaction, computation can occur with the data.

eUTXO Model Review: Informal Definition

• Output can be defined as a tuple with three parameters: (𝜈, value, 𝛿)
• 𝜈: validator function
• value: amount of the currency
• 𝛿: datum (the singular of data) representing arbitrary data

​

• Unspent output can be spent (used) as an input if: 𝜈(value, 𝛿, 𝜌, tx) = true
• tx: transaction information
• 𝜌: redeemer, cryptographic hash of the tx signed with the spender’s private key

eUTXO Model Review: Description Within Ergo

eUTXO ≔ a box

Implications

• A box can contain arbitrary data ⇒ 𝛿
• A box contains a script/contract ⇒ 𝜈
• A box must contain a minimum amount of the base currency ⇒ value
• Within a script/contract one has access to the transaction context ⇒ 𝜈(tx)
• In order for the inputs to be spent, the transaction must be signed ⇒ 𝜌
• Think of the box as the edges in the graph.

​

ErgoPad

• Website: https://ergopad.io
• Discord: https://discord.com/invite/E8cHp6ThuZ
• Telegram: https://discord.com/invite/E8cHp6ThuZ

FIN

Ergo Blockchain Crash Course:

Anatomy of Ergo Blockchain

Outline

• Anatomy of Ergo Blockchain
• Anatomy of a Box
• Anatomy of a Transaction
• Anatomy of an Address
• Anatomy of a Token
• Anatomy of a Block
• Anatomy of a Wallet

Anatomy of a Box: Registers

• R0 - R3: predefined registers
• Value: ERG amount in box
• Script: the guarding contract
• Based on Sigma Protocols
• Tokens: native assets
• Coll[Byte]: token id
• Long: token amount
• Creation Info:
• Int: transaction block height
• Coll[Byte]: transaction id | output index

Anatomy of a Box: Size Limits

• All ERG is represented in nanoERG (i.e. signed Long type)
• All unspent boxes MUST have a minimum amount of ERG to exist:
• Minimum ERG for existence: 1E6 nanoERG
• Box size: sum of data size in each register of the box
• Maximum box size limit: 4 KB = 4096 B
• Once a box is spent, it can no longer be used as an input into a transaction.

Anatomy of a Box: Box Types

• Data Inputs
• Read-only (i.e. not spent) boxes that can be referenced in different transactions within the same block.
• Inputs
• Are spent within a transaction.
• Outputs
• Outputs boxes from the transaction, unspent and waiting to be spent in another transaction, either in the same block, some other subsequent block, or never

Anatomy of a Transaction

Anatomy of a Transaction

• Data Inputs
• Read-only inputs.
• Inputs
• Spent in the transaction.
• Context Extension Variables
• Variable values inserted at the time of the transaction and not at contract compilation time.
• Outputs
• The new eUTXOs
• Conservation of ERG
• ERG In = ERG Out
• Miner Fee
• Minimum miner fee: 10E6 nanoERG
• Miners can vote to increase/decrease this value.

Anatomy of a Transaction: Transaction Cost

• Different “types” of transaction cost
• Literal: Miner Fee
• Design Limit: Computational cost limit
• Deterministic
• You have no free will, it doesn’t exist.
• Everything is calculated before the transaction is ever submitted to the blockchain
• You can calculate all the miner fees the user will have to pay beforehand
• The computational cost limit of the transaction will prevent you from submitting a transaction to the blockchain, thus you can modify your design and ensure it will execute correctly once below the limit
• Transaction will only fail if it is not submitted into a block by a miner:
• In this scenario, it is as if the transaction never occurred
• (i.e. the wave function never collapsed)
• User’s funds will not be spent.
• Try submitting to the blockchain again

Anatomy of a Transaction: Conservation of ERG

What is the flow?

• Conceptual model for transactions was a directed-acyclic graph with a flow network.
• ERG into the transaction MUST equal the ERG out of the transaction.
• Does NOT apply to tokens.

Storage Rent:

• Every 4 years, if the ERG value within any eUTXO is too low to pay the transaction fee, all ERG and tokens within it will be recycled by the network (i.e. sent to miner instead).

​

Anatomy of a Transaction: Fun Physics Analogies

• Energy cannot be created or destroyed ≅ ERG cannot be created or destroyed
• Can ERG be destroyed?
• Bitcoin:
• If someone loses their keys, that BTC is lost to the network ⇒ is “destroyed”
• Ergo:
• With storage rent ERG in a eUTXO will be recycled ⇒ not “destroyed”
• Ergo blockchain is therefore a CLOSED system, unlike the current FIAT economic system

Consequences:

• No need to “print” more money or adopt any inflationary policy in which more coins come into existence due to fear that there will not be “enough for everyone” in the future.
• “100E6 ERG is all there is, or ever was, or every will be.”

Anatomy of a Transaction: Mempool

Mempool ≔ Memory Pool

What is the mempool?

• A “pool” of memory within the computer in which the node resides and has access too, where transactions go before being inserted into a miner’s block for confirmation.
• i.e. transaction limbo

What is it used for?

• When you sign and “send” a transaction, it first goes into the mempool of the node you are connected to, which is then broadcasted to the other peer nodes in the network.
• Mining nodes then also have access to this transaction in their own mempool and try to include it in the block they broadcast for validation.
• If the block is verified successfully, the transaction will be confirmed (by mining and non-mining nodes) and removed from the mempool.
• If the block is not verified successfully, the transaction will not be confirmed and fail.
• This will also remove the transaction from the mempool, but it is as though the transaction never occurred, thus no funds are lost.

​

Anatomy of an Address

Anatomy of an Address: Types of Addresses

Network Types

• Mainnet address = “real” money (is money even real?)
• Testnet address = “fake” money (like monopoly, but more fun)

Address Types

• P2PK = Pay To Public Key
• serialized public key
• P2S = Pay To Script Address
• serialized script/contract (ErgoTree)
• P2SH = Pay To Script Hash
• first 192 bits of the blake2b256 hash of the serialized script

​

Anatomy of an Address: Structure

• address = prefix byte || content bytes || checksum
• prefix byte = network type + address type
• network type:
• Mainnet = 0x00
• Testnet = 0x10
• address type:
• 0x01 - Pay-to-PublicKey(P2PK) address
• 0x02 - Pay-to-Script-Hash(P2SH)
• 0x03 - Pay-to-Script(P2S)
• content bytes = serialized ErgoTree bytes (contract)
• checksum = leftmost_4_bytes (blake2b256 (prefix byte || content bytes))
• Encoding = base58

​

Anatomy of an Address: Addresses and Boxes

• Each box must have a script/contract associated with it, thus an address.
• Script/contract is independent of box, thus multiple boxes can be created each with the same address stored within it, in R1.

​

Anatomy of a Token

Anatomy of a Token: What is token?

• In Ergo, a token, in the most abstract sense, is just a pair of two numbers:
• (tokenId, tokenAmount)
• Data type: (Coll[Byte], Long)
• Rules:
• Only one token can be minted per transaction
• The amount of a token out of a transaction can be less than OR equal to the amount in.
• Next Questions:
• What is minting?
• What is an NFT?

​

Anatomy of a Token: What is minting?

• By definition of what a token is, how do we obtain a tokenId?
• The minted token will inherit as its tokenId the boxId of the first input box into the transaction.
• That’s it.
• In ErgoScript, we can specify the tokenAmount.
• The output box will now have in its token register (R2), a new pair (tokenId, tokenAmount).
• (tokenId, tokenAmount) = (boxIdOfFirstInputBox, X)
• Where X is in the positive range of the Long type (i.e. 64 bit signed integer)
• It costs NOTHING to do, only the transaction miner fee.

Anatomy of a Token: What is an NFT?

• An NFT is simply the meaning we ascribe to the pair of the (tokenId, tokenAmount)
• How do we ascribe the meaning?
• EIP-4: Asset Standard EIP
• EIP-24: Artwork Standard
• The asset standards give meaning to the first input box (the issuer) and the output box containing the tokens (the issuance box)

​

Anatomy of a Token: NFT Minting Example

• The “minting” fee is really a “service/development” fee, since it does not actually cost anything to mint a token. It is costing you money for someone else to do it for you.

​

Anatomy of a Block

Anatomy of a Block: What is a blockchain?

• Blockchain: a chain of blocks.
• Off-chain database holds transaction information.
• Nodes connect to each other and sync with the one that has the longest-chain history, downloading transaction information to their local off-chain database
• Blocks in the blockchain are used to verify that new transaction information is correct
• Verification of new blocks can occur with a mining node or non-mining node depending on what sections of the block are used.

​

Anatomy of a Block: What is a block?

• Header
• Information about the block
• Transactions
• Transactions processed and verified by miner submitted into the block.
• Extensions
• New section not found in other PoW blockchains, holding additional information.
• Proofs of eUTXO Set Transformation
• Proofs of AVL Tree operations performed by miner on the eUTXO set
• Different sections enable different types of nodes to only download the data they need for verification instead of all the past transaction data from previous blocks. This lets you run an Ergo node on a Raspberry Pi for example.
• Off-chain database holds transaction information and eUTXO set

​

Anatomy of a Block: Proofs of eUTXO Set Transformations

• Used for verification of block by other miners and full node verifiers.
• Information about how the eUTXO states from the previous block have changed.
• The order of the set of eUTXOs increases or decreases depending on which transactions spent the previous eUTXOs in existence and how many new ones were created as their outputs.

​

​

Anatomy of a Block: Extensions

• Parameters for miner voting (like voting on soft/hard-forks, miner fee increase, storage rent fee increase, etc.)
• Additional information needed for things like NiPoPoWs
• Stored in Merkel Tree

​

Anatomy of a Block: Transactions

• List of transaction identifiers stored in Merkel Tree

Anatomy of a Block: Header

• Contains “links” to the other sections of the block
• txsRoot: Digest of Merkel Tree containing list of transaction ids
• extensionsRoot: Digest of the tree containing the extension fields
• proofsRoot: Digest of proofs for eUTXO set transformations
• Other information:
• Height of the block relative to the current blockchain height
• Miner Votes
• Other fun stuff

Anatomy of a Wallet

Anatomy of a Wallet: What is a wallet?

• Recall: Each eUTXO must have a contract associated with it, in R1.
• If the box has a P2PK address, then all boxes created with that P2PK address are associated together.
• Your “wallet” is simply the collection of all eUTXOs whose contract is associated to your public key.
• A wallet’s job is to search/collect these boxes from the blockchain (non-trivial) and display their contents to you in a seamless fashion.

​

Anatomy of a Wallet: Wallet Address Hierarchy

Structure Following BIP-0044:

• m / 44' / coin_type' / account' / change / address_index

On Ergo EIP-0003:

• m / 44' / 429' / 0’ / 0’/ address_index
• coin_type = ‘ergo’ in ASCII sum
• change = external address only, no internal change address
• address_index = incremented when creating a derived address

​

ErgoPad

• Website: https://ergopad.io
• Discord: https://discord.com/invite/E8cHp6ThuZ
• Telegram: https://discord.com/invite/E8cHp6ThuZ

FIN

Ergo Blockchain Crash Course:

ErgoScript Development Fundamentals

Outline

• ErgoScript Development Fundamentals
• Multi-Stage Protocols
• ErgoScript Fundamentals
• Design Considerations

Multi-Stage Protocols

Multi-Stage Protocols: Enriched Context

• With eUTXO model, within a transaction, we have access only to local state.
• Ergo is a Level 3 blockchain, which includes access described by the previous levels.
• Local State (in Ergo) = Level 1 + Level 2 + Level 3

​

p

Multi-Stage Protocols: What is it?

• When thinking about protocols for a dapp, most of the time one smart-contract will not suffice.
• Dapp protocols may consist of multiple smart-contracts, while the state of the protocol changes from transaction to transaction.

​

Multi-Stage Protocols: Turing Completeness?

• ErgoScript language is NOT Turing Complete
• Ergo blockchain can be used to chain transactions from eUTXO to eUTXO and block to block in such a way to emulate Rule 110, the cellular automaton rule.
• Since Rule 110 is proven to be Turing complete, by implication, so to is the Ergo blockchain.

Consequence:

• Theoretically possible to compute any program by treating each transaction as one step/iteration in the program.
• Not practical to do this in practice
• Useful way of thinking about your protocols sometimes, maybe your protocol is really a program being iterated over many transactions

​

ErgoScript Fundamentals

ErgoScript: What is it?

• High-level smart-contract language for Ergo blockchain.
• Syntax is a subset of Scala’s syntax.
• Low-level language is called ErgoTree, ErgoScript compiles to ErgoTree.
• It is also possible to write smart-contracts in ErgoTree directly, though difficult.
• ErgoScript language gives you tools to control and access all components of a transaction:
• Block Header
• Data Inputs
• Inputs
• Context Extension Variables
• Outputs
• Box contents
• Other advanced cryptographic features
• “Functional” language, so all variables are immutable.
• Very simple language, but can do complex things with it.
• This is why I explained the concepts first, so now you can understand what the language enables you to do, otherwise it makes no sense.

​

ErgoScript: Types

• Bible Reference:
• ErgoScript Language Specification
• sigmastate-interpreter
• Contract must compile to a boolean (Sigma Boolean)
• A contract essentially consists of many propositions that much be checked to be either true or false.

​

ErgoScript: Transaction Context

• Recall: 𝜈(value, 𝛿, 𝜌, tx) = true
• CONTEXT gives you access to transaction information (i.e. tx) :
• HEIGHT: block height in which the current tx will be included
• SELF: the current box (eUTXO)
• INPUTS: a collection of all the input boxes into the transaction
• OUTPUTS: a collection of all the output boxes out of the transaction
• CONTEXT.dataInputs: a collection of all the data input boxes into the transaction
• Other information

​

ErgoScript: Box Registers

• Recall: 𝜈(value, 𝛿, 𝜌, tx) = true
• Box type gives you access to all the registers in a box (dataInput, input, and output):
• R0-R3 are predefined
• R4-R6 can be any other valid ErgoScript data type
• Access other properties of a Box
• Can be used to check conditions such that correct data is inserted into register
• To persist data across different transactions (i.e. from one state of the protocol to the next)
• Many other use cases

​

ErgoScript: Context Extension Variables

• Recall: Context Extension Variables are variable values that get inserted into the box during transaction building time and not contract compilation.

​

ErgoScript: Contract Evaluation

• Recall: 𝜈(value, 𝛿, 𝜌, tx) = true
• The ErgoScript contract evaluates different propositional statements, the final statement must be either true or false
• All ErgoScript contracts must end with:
• sigmaProp(someProposition)

​

ErgoScript: Costing

• AOT: Ahead-Of-Time Costing
• When the contract cost is calculated at transaction execution, if the contract contains branches (e.g. if/else) then all branches will be followed.
• Will lead to various errors like “missing variable not found”
• JIT: Just-In-Time Costing
• Node v5 (soon) brings many improvements to ErgoScript, compiler, transaction costing, and many others (check out https://github.com/ergoplatform/ergo)
• Implements JIT costing such that problems like in the above will not happen.

​

Design Considerations

Design Considerations: Requirements

• Before writing any ErgoScript code (for complex protocols), good to have an idea of your requirements:
• What is the protocol supposed to do?
• What are the different transactions involved?
• What data is being transferred from stage to stage, if any?
• How is a user going to interact with the protocol and where?
• What occurs on-chain vs. what occurs off-chain?
• Create protocol diagrams showing what inputs/outputs are involved
• Understand what boxes are involved and what data they contain
• Know exactly what data types you will be using to calculate their size consumption
• Once you write ErgoScript, do the same things for any variables used
• You want to understand the limits of your system:
• What are the data/size limits you will need/can handle?
• How does it scale with more users, more boxes, etc?
• What are your constraints?
• Does your design fall within limits of transaction cost?
• How do your contracts deal with AOT/JIT costing
• Understanding the limits of your system will make you a better designer and ensures that you are designing it with the user’s safety in mind (i.e. not burning their tokens or siphoning their funds by accident)
• This is engineering professional practice 101

​

​

Design Considerations: Common Design Patterns

• Self-Replicating Box
• Box that is recreated with the same contract, but with the data that was stored in it modified in some way.
• Config Box
• A box with settings/parameters that can initiate a change within a protocol when used as an input in a particular stage.
• Singleton/Utility Token
• Used like a reference/pointer to keep track of a box. Since boxes always have a new box id when created, the singleton tokenId stays the same.
• Transaction Chaining
• Using outputs of a transaction as inputs to another directly.
• If a transaction early in the chain does not get confirmed, the following transactions will also not get confirmed
• Parallelization
• Take advantage of the eUTXO model, since one transaction can have multiple inputs/outputs.
• Instead of doing everything in one contract/box, can split tasks into their own box.

​

​

Design Considerations: Constraints

Storage Rent: If your project includes custom tokens, these will be recycled by the protocol if left in an eUTXO with too little ERG in it to pay the minimum transaction fee. This may be a security risk depending on your application and the purpose of the token.

• Fee parameters can be changed via miner voting.

Design Considerations: Protocol Specification

• EIP-0006: Informal Smart Contract Protocol Specification Format
• Useful for having written version of your smart-contract protocol, outlining each stage, the contracts involved at each stage, along with the boxes and their contents.
• Stage: A contract/box at a particular point in the protocol that is reached by the user.
• Action: What the user can do in order to progress to the next stage/state in the protocol, a stage can have multiple actions.
• Action Conditions: The conditions that must be satisfied in order for the action to proceed (i.e. a spending path).

​

Design Considerations: Stages of Development

• Requirements: Outline the project goals and design requirements.
• Protocol Specification: Make protocol diagrams and describe the multi-stage protocol according to EIP-0006
• On-Chain: All ErgoScript logic that will be verified by nodes.
• Off-Chain: All computation not occurring on the blockchain.
• Front-End: Usually front-end (if there is one) interacts with the off-chain code, which itself is used to compile contracts, build transactions, sign transactions, and ultimately submit them to the Ergo blockchain.

Design Considerations: Scaling

• When in the initial design phase, it is important to consider how your dapp will scale.
• Scaling applies just as much to the on-chain ErgoScript code as it does to the off-chain or front-end code.

Examples

• How does the protocol scale with increased data requirements within boxes?
• Is Plasma (AVL Tree) library needed?
• Do you need an L2 solution if you are dealing with high transaction volume?
• How does the transaction behave when there are multiple boxes with the same contract?
• How much computation is needed in your ErgoScript?
• Does it increase when more inputs/outputs are involved in the transaction?
• How many loops (fold, forall, exists, etc.) are you doing within your contract?

Design Considerations: Testing

• Testing can occur in three ways:
• Off-chain testing:
• Debugging application code without signing/submitting any transactions to the blockchain.
• Testnet:
• Run a version of your protocol on testnet with monopoly money and be the master of your own kingdom with all your testnet ERG.
• Mainnet:
• RIP

Design Considerations: Development Tools

• Scala/Java
• AppKit: Library used for interacting with the Ergo blockchain
• VS Code: IDE, ErgoScript Language Support extension for syntax highlighting
• IntelliJ: IDE, no ErgoScript Language Support (go ask Cheese Enthusiast)
• Scala Test/JUnit: Unit testing
• Node: Connect your own testnet/mainnet node for testing or use a public one
• For production, it is best to setup your own node that people using your dapp will end up interacting with.
• On-chain Scaling: GetBlok.io Plasma Library (AVL Tree support)
• Explorer Instance: Personal instance of the Ergo explorer in order to retrieve blockchain data more efficiently than using the public explorer.
• Python
• Useful, but not as fully featured as Scala/Java version of AppKit
• Ergo-Python-Appkit library from ErgoPad
• Ergpy library from MGPai
• Does NOT work if you want to use Plasma (AVL Tree) scaling solution from GetBlok
• Web/JS/Rust
• Sigma-Rust: Rust implementation of ErgoScript compiler
• Ergo-ts: Typescript library for interacting with the Ergo blockchain
• FLEET: Fluent Ergo Toolkit (developed by Captain-Nemo, RRRRRR)
• Various dapp-connector plugins for reactJS to interact with Ergo browser wallets

Design Considerations: Ethics

• YOU ARE INVOLVED WITH PAYMENT PROCESSING.
• YOU ARE MESSING WITH PEOPLE’S MONEY DIRECTLY.
• BE RESPONSIBLE, DILIGENT, AND JUDICIOUS.
• DO NOT BE RECKLESS.
• TAKE YOUR WORK SERIOUSLY.
• YOUR WORK IS A REFLECTION OF YOURSELF.
• BE A PROFESSIONAL.
• DO NOT BE AFRAID TO ASK FOR HELP.
• KEEP LEARNING.
• HAVE FUN.
• REMEMBER, WE ARE ALL MORTAL AND DOOMED TO DIE. NOTHING LASTS FOREVER. I AM GOING TO DIE. YOU ARE GOING TO DIE. EVERYONE YOU KNOW (AND DO NOT KNOW) AND LOVE IS GOING TO DIE. EVERYTHING IS TRANSITORY. ENTROPY ALWAYS INCREASES. THE HEAT DEATH OF THE UNIVERSE IS INEVITABLE.
• THEREFORE, WHILE YOU ARE ALIVE ON THIS EARTH, MAXIMIZE FREEDOM AND MINIMIZE SUFFERING. QED

​

Is this the real life?

Is this just fantasy?

Caught in a landslide

No escape from reality

Open your eyes

Look up your address on the explorer and see

Where did all my ERG go?

Be like this guy, think before you act.

ErgoPad

• Website: https://ergopad.io
• Discord: https://discord.com/invite/E8cHp6ThuZ
• Telegram: https://discord.com/invite/E8cHp6ThuZ

FIN

Ergo Blockchain Crash Course:

Examples

Outline

• Examples
• Extended Pinlock Example
• GuapSwap V2
• Whitelisting Minting/Direct Sale

Examples: Extended Pinlock

Examples: Grantor/Beneficiary Pinlock Protocol

• Purpose
• Show off basic transaction diagrams
• Show off super basic ErgoScript
• ErgoScript
• Compile time variables
• Accessing registers
• Blake2b256 hash function
• sigmaProp function

​

Examples: Grantor/Beneficiary Pinlock Protocol

​

​

Examples: Grantor/Beneficiary Pinlock ErgoScript

​

​

Examples: GuapSwap V2

Examples: GuapSwap V1

• Purpose
• More complicated contract
• How to structure your ErgoScript to make it readable and understandable to others
• Good contract structure and comments are important as contracts become more complex
• Nobody cares how good you are at programming or how smart you think you are, go stroke your ego in front of a mirror instead.
• You are writing code for others to understand, not just you.
• Adopt professional engineering practices
• ErgoScript
• Context extension variables
• Multiple conditions that need to be satisfied
• Making sure contract deals with multiple input boxes with the same contract, so ensuring contract can handle basic form of protocol scaling.
• substConstants function and dealing with ErgoTree bytes directly

​

Examples: GuapSwap V2 Protocol

​

​

Examples: GuapSwap V2 ErgoScript

​

​

Examples: Whitelist Minting/Direct Sale

Examples: Whitelist Minting/Direct Sale

• Purpose
• Understanding more complicated protocols
• Use of multiple design patterns
• Self replicating box
• Config box
• Singleton token
• Transaction chaining
• Parallelization

​

Examples: Whitelist Minting Protocol

​

​

Examples: Whitelist Direct Sale Protocol

​

​

What’s Next?

What’s Next?

• Read papers
• More examples of contracts and theoretical details of ErgoScript/ErgoTree and Ergo blockchain in general
• Examples of advanced topics:
• AVL Tree implementation within Ergo
• ErgoTree serialization
• Scorex Foundation code
• NiPoPoWs
• Logarithmic Mining
• Difficulty Adjustment
• Read the Ergo Manifesto if you have not already done so, go indoctrinate yourself.
• Ergo Docs
• Official docs website for Ergo platform, good reference when working on a project
• DeCo
• Interact with other students interested in learning the same things as you
• Learning with homeworks/project
• Get help from experienced ErgoScript developers
• NeTwOrKiNg
• Potential opportunities for internships with projects developing on Ergo (not a guarantee)
• Layman and advanced courses
• Dappstep
• Video tutorials on eUTXO and ErgoScript concepts with practical examples geared toward blockchain development using the web browser
• Learn cryptography
• Learn the fundamentals of cryptography, maybe even do your own research in the future!
• Get your hands dirty
• Go be naughty and build yourself an application
• Go learn, make mistakes, ask for help, and have fun!

ErgoPad

• Website: https://ergopad.io
• Discord: https://discord.com/invite/E8cHp6ThuZ
• Telegram: https://discord.com/invite/E8cHp6ThuZ

FIN