Learning Ergo 101 : eUTXO explained for human beings
In this blogpost I will try to document what I have learnt about Ergo Blockchain in the last months.
Ergo (https://ergoplatform.org/) is one projects that really caught my attention. Because Ergo is still a young project documentation is still not widely available so as part of this and upcoming blog posts I will be sharing what I have learnt.
This blog post is about the fundamentals, the paradigm on which Ergo is built. Understanding the paradigm is important so we can model problems and solutions. Interestingly this same paradigm also applies to Cardano and I guess a subset of other Blockchain systems out there.
In this post I will ignore details in favour of understanding.
I’m in my learning journey so if you find any conceptual mistakes in this post please be kind and feel free to let me know to correct them 🙏
Blockchain Paradigms
Let’s step back a bit first. Consider programming: There are different paradigms for programming: Functional Programming, Object Oriented..among others.
A programming language usually implements one of these paradigms or a combination of them. These paradigms affect how you consider solving problems.
Each paradigm gives you different tools and abstractions . It also provides you with different advantages for example: Functional programming might be really useful when it comes to parallel processing, however it imposes certain principles: variables can’t be mutated.
In terms of blockchain technology the same intuitions applies to paradigms.
In the space of programmable Blockchains there are currently two paradigms :
- Account based
2. eUTXO (extended Unspent Transaction Output)
The account model is used by Ethereum.
eUTXO is used by projects such Cardano and Ergo.
In this blog post I won’t cover how the account based model work. I will focus on explaining how eUTXO works.
eUTXO stands for “extended Unspent Transactions Output”. Cardano and Ergo are different implementations of this paradigm. I will cover them from the perspective of an engineer building solutions on top of them.
eUTXO (extended Unspent Transactions Output)
Let’s first conceptualise how the Ergo blockchain looks like for someone who is building solutions on top of it.
- Consider the Ergo blockchain as a Dataset of Boxes.
- Each Box contains assets: Cryptocurrency (Either ERG and/or other tokens)
If I were to picture the Ergo blockchain it would look like as the drawing below:
- As a user of the Ergo blockchain you can interact with some of those boxes.
- Applications built on top of Ergo work by using existing boxes and creating new boxes
- Each Box contains crypto assets (namely Erg or other coins)
If we were to zoom into one of those boxes, it might look like the image below:
A Box is made of :
1. Some assets : Crypto assets.
2. Some data that dApps and programmers can use. (lets forget about this for the time being)
3. A script (let’s forget about this for the time being)
Zooming out again we can think of the Ergo blockchain as a:
Dataset of boxes where each Box contains some Crypto assets.
In this dataset of boxes :
1. Each box can be operated only and only once!.
2. Once a Box is used it cannot be operated anymore and it is considered to be “Spent”.
3. Unused Boxes are called “Unspent” and can be used as inputs in operations.
Going back to our illustrated Ergo blockchain, more accurately it looks as follows:
In our illustration some boxes (marked with the red X) are flagged as Spent. Spent boxes cannot be used anymore. We can inspect them, but we cannot interact with them anymore, they exist as some sort of historical reference.
With this in mind, developing solutions on top of eUTXO blockchain means:
1. Interacting with unspent boxes
2. As a side effect of interacting with boxes: (i) interacted boxes get spent and (ii) new unspent boxes are created.
In fact as an engineer coding solutions there is only one operation you can do on top of existing Boxes: A transaction.
Transactions
Imagine a transaction as a programming function that is already defined. You can use this function and it looks like as in the illustration below:
Input boxes : These are existing unspent boxes in the blockchain. They will be flagged as “spent” if this transaction is successful.
Output boxes: These boxes do not exist yet. If your transaction is successful then these boxes will exist in the blockchain as unspent.
Output boxes are essentially the state of the world that you want to exist.
Essentially you tell the Transactionfunction what do you want the world to look like. The transaction function will sort out how to make it happen on your behalf.
But, are all transactions successful?
can I just apply a transaction operation on any box that I want ?
> NO
This is really where the “smart contracts” part come into play.
The Script field
Remember that boxes contain a field called script ?
- Each box has a script.
- A script is a chunk of logic which evaluates to a boolean value: True or False.
- At transaction time the script of the input boxes is evaluated.
If the evaluation returns true then your transaction is successful and the output boxes are created. - In the ergo blockchain the programming language you can use to define the script field is called ErgoScript.
- ErgoScript is on purpose quite limited
- Because ErgoScript is very constrained the Ergo blockchain can know in advance the cost of executing that script. This might not be very relevant for this blog post , but this is a core differentiator from other blockchain systems. This is the reason why transaction costs in Ergo are fixed.
- As a programmer you can define your own script and use them in your boxes.
- By using the script field along side boxes and transactions you can model solutions to problems. This is the core of building DApps in Ergo and Cardano.
Interestingly I’ve read content written by members of of the Cardano community, and it seems they explicitly avoid the term “smart contract” and instead call them “validators”. Because Cardano and Ergo work under the same paradigm it seems to me a more accurate term. Unlike other paradigms were you code a lot of logic, in the eUTXO we just focus on scripts that validate whether a transaction should be allowed or not.
But wait.. if we only have boxes. How does a wallet own Erg in the Ergo blockchain?
Right, during my explanations you never heard that the Boxes had a user field or wallet_number right? but how can Ergo or Cardano support wallets otherwise?.
You can think of a Wallet as pair: PrivateKey and PublicKey.
Consider a wallet with let’s say: 100 ERG. What this actually mean is:
- There are one or more unspent Boxes that in total contain 100ERG
- Those Boxes’ script corresponds to the wallet’s public key (public address).
This script is guarding the box such that If you want to use any of those boxes in a transaction, you need to provide a signed message proving you are the owner of the companion private key. - When your wallet app wants to know your balance it scans the blockchain looking for unspent boxes whose script corresponds to your public wallet address.
Final thoughts
The eUTXO model is very interesting . If you are familiar with Functional programming you can see how some concepts are similar. For example in eUTXO there is no mutability: You can’t mutate a box. You can only create new ones. Just as in functional Programming there is not a global state.
From my perspective, as an engineer, immutability and not global state makes things much simpler.
As someone who is interested in how to solve problems using the blockchain I like the limitations of having a single operation over Boxes. This simplifies the things that could go wrong.
Furthermore it also provides a good abstraction layer, I don’t know what lower level operations are taking place for a box to be created or be flagged as spent. As a programmer I only tell what “state of the world” I want and the transaction operation takes care of the rest.
In my next post I will try to describe the life cycle of a “smart contract” in the Ergo blockchain and what tools are available to code them.
