Wavelet: Staking and Decentralization
Part 2 of the Wavelet Series: The workings behind the leaderless proof-of-stake mechanism and the rewards system in Wavelet
We previously introduced a general overview of some of the key aspects of Wavelet, that tackle the problems of the current market and set it apart from the competition in part 1 of the Wavelet Series, Wavelet: An Introduction.
In this article, we’re going to show you the workings of the rewards system of our ledger and a very unique mechanism that is one of the biggest pride of Wavelet: the leaderless proof-of-stake mechanism.
Only Choosing the Good
So we know the traditional proof-of-stake method involves a group of validators minting the next block of a chain, which forces the majority to depend on the said group of validators.
We also know that the proof-of-work method follows the longest chain rule, where miners put their block on top of the longest chain of blocks. This doesn’t make people dependent on a small group of validators, but it can become centralized, through processing power abuse, and also take a lot of time if ONLY one longest chain can’t be found immediately.
There are benefits for both methods, but there are deficits as well. So why not develop a new method that only utilizes the positives of both?
From the Beginning
To understand what we’re dealing with, let’s take an example where we start from the very beginning of our ledger, the genesis transaction, and then add in a few depths of transactions.
- So we start with the genesis transaction, which holds the initial information for Wavelet.
- A person called Chad builds on top of the genesis, so he references the genesis and builds a transaction (by paying a transaction fee in PERLs) where he stakes some PERLs. This makes Chad a validator. If the genesis transaction is depth 0, then Chad’s transaction is at depth 1.
- Now comes Alice, and she wants to build a transaction of simply transferring some PERLs. She has two choices, she could build her transaction by referencing either the genesis or Chad’s transaction. If she references the genesis, her transaction will be at depth 1 as well. If she references Chad, then her transaction depth will be 2 and the transaction fee she paid for her transaction goes to Chad since he’s a validator. She decides to build on top of Chad, so Chad gets the transaction fee as a reward (not something he can attain or spend immediately, explained later) and Chad’s transaction becomes a parent of Alice’s transaction.
- Another person, Bob, builds a transaction where he also stakes some PERLs by referencing Alice, making him a validator. As Alice is not a validator, the transaction fee from Bob goes to Chad as a reward, Bob’s transaction is at a depth of 3, Alice’s transaction becomes a parent to Bob’s, and Chad’s transaction becomes an ancestor to Bob’s.
- Jason decides to build a transaction of transferring some PERLs on top of Bob’s transaction. Jason’s depth is at 4, Bob’s transaction is a parent to Jason’s, and Chad’s and Alice’s transactions are ancestors to Jason. But now there are two validators, Chad and Bob. Through a random process where validator IDs and the amount staked is taken into account (explained later), only one of them will get the reward from Jason’s transaction fee.
This is a VERY simple example of the system in Wavelet. It has the staking element of proof-of-stake and the leaderless aspect of proof-of-work.
So you get a leaderless proof-of-stake system.
In reality, however, it’s not as simple as the example above.
There will be a lot more transactions to choose from and you don’t necessarily have to reference the transaction at the highest depth, although you are recommended to.
You also don’t have to reference only one parent transaction. You have the choice of referencing multiple parent transactions, which you are recommended to do as this allows for the reward ecosystem to flourish.
This ends up creating a complicated network of transactions. And as the reward system takes into account the parent and ancestor transactions along with the validator IDs, keeping track of who ends up getting the reward can be complicated.
But hey, we’re used to solving complicated problems at Perlin so keep reading to find out how we solved this.
The Reward System
Starting from the newest transaction built, the system checks through all parent and ancestor transactions for those who are eligible for getting the reward.
You are only eligible for rewards if you are a validator and if you don’t build any new transactions on top of your previous one (parent or ancestor transactions cannot be yours).
This means that you can’t simply reference your transactions to increase the chances of getting the reward. You’ll have to work harder and reference other transactions away from yours to increase the chances of getting rewards.
This will benefit other validators and the overall reward ecosystem and also enforce a decentralized system.
Once all the eligible validator(s) have been identified, all those validators’ IDs are taken and put through a hash function to construct a checksum. The last 16 bits of the checksum is taken as a threshold value.
This checksum is random, as is the nature of hash functions, and you take the last 16 bits of this random checksum.
The largest number you can represent with 16 bits is 2¹⁶. Due to the hash function’s randomness, you can get any value from 0 to 2¹⁶ (inclusive).
For the threshold value, we scale down the value of the last 16 bits in a way that the final range of values you can get for the threshold is from 0 to 1 (inclusive).
The validator(s) are ordered using the Breadth-First traversal (explained later) and then weighted depending on how much the validator staked, which is also scaled down to match with the threshold’s range. Whichever validator gets aligned with the threshold value gets the reward.
To look at this more easily, let’s look at a quick example featuring eligible validators Larry (staked 35), Tyson (staked 5), Emma (staked 10), and Nora (staked 50):
The threshold value from the checksum happens to be 0.4. After the Breadth-First traversal, the order ended up being Larry, Nora, Tyson, Emma.
The validators will occupy the range from 0 to 1 (inclusive) in the order from the traversal starting from 0. How much the validators occupy depends on how much they staked, which is scaled down to fit the range from 0 to 1 (inclusive).
- Larry (being the first in order) will occupy the range 0 to 0.35
- Nora (being second) will occupy the range 0.35 to 0.85 (excluding 0.35)
- Tyson, (being third) will occupy the range 0.85 to 0.9 (excluding 0.85)
- Emma (being last) will occupy the range 0.9 to 1 (excluding 0.9)
The threshold value, which is 0.4, falls into the range occupied by Nora, thus Nora gets the reward.
Claiming Your Rewards
Although the reward is in PERLs, you can’t just claim it any time. You need to accumulate a minimum amount (predetermined) of rewards before you can withdraw it as PERLs, which you can use for whatever you want.
Furthermore, withdrawing rewards is a delayed process. After you withdraw some amount of rewards, you need to wait for a predetermined number of consensus rounds (this is for another article) before your rewards get converted into PERLs.
The Breadth-First Traversal (BFT)
When you have lots of parent and ancestral transactions, it gets really complicated to find the order in which you’d go through all the transactions, especially when you have transactions with multiple parents throughout the ancestry.
The BFT tackles this problem in a logical and somewhat complicated manner, which can be hard to understand at first but is very straightforward once you get the hang of it.
This traversal goes through all the parent and ancestral transactions. When it goes through a transaction, the transaction is marked so that it doesn’t repeat the process on the same transaction multiple times.
Now, if there is only one parent transaction, it simply goes through the parent transaction and then moves on to the parent’s parent transaction(s).
If there are multiple parent transactions, then the order it goes through is from the transaction with the lowest validator ID value to the transaction with the highest validator ID value. Then it goes through the parent transaction(s) of the lowest validator ID value to the parent transactions(s) of the highest validator ID value.
Yea it’s still kind of hard to understand without being able to picture it…
Let’s use a simple example involving 5 different transactions (represented as circles), by 5 different people (name and ID value written on the transactions), referenced in the manner shown below (the arrows from one transaction points to its parent(s)).
So a new transaction is made by Alex and he referenced Clara and Kyle.
Clara has a lower ID value than Kyle, thus the order starts with Clara and then Kyle. Both of the transactions are marked as they are traversed so they won’t be traversed through again.
As Clara has the lower ID value, her parent transactions, Rohan and Sally, are traversed through next. Rohan’s ID is lower than Sally’s, thus the order updates to Clara, Kyle, Rohan, Sally. Both Sally and Rohan are marked as they get traversed.
Now that Clara’s parents have been traversed, it’s Kyle’s parents, Katie and Rohan, that get traversed next. Rohan has a lower ID value than Katie, but Rohan has already been marked and is not traversed again. This results in the final order of Clara, Kyle, Rohan, Sally, Katie. The genesis isn’t traversed in this process.
So there you go, a very simple example of the BFT. This is how the ordering of validators work in Wavelet when it comes to the rewarding process.
Some of you might need more examples of the BFT to get the gist of it, which is why a few underlined “Breadth-First traversal” or “BFT” phrases have been provided (they all lead to the same place) which link to a nice little animated demo with more examples of this traversal that you can experiment with.
The Reward Earned Is Valuable
To make the rewards valuable, we have set some protocols that make sure you can’t just laze around and become rich. Everything has a price, including PERLs, which is why you have to be active and work to earn them.
One protocol has already been mentioned in the “The Rewards System” section, where you can’t simply build on top of your transaction to get the rewards.
Another protocol is that the reward system doesn’t cover all the parent and ancestor transactions from the genesis. The reward system only takes into account the transactions to a certain depth below the new transaction.
This means that you can’t become a validator once and have the chance to get rewards forever. You have to continuously work and become a validator to continue getting rewards. This adds value to the rewards as attaining a lot of rewards means that you put a lot of work into getting them.
There’s also the tactical aspect of getting rewards. There is a querying process, which starts when a transaction made is a critical transaction, that finalizes all the transactions below whichever depth the critical transaction took place.
If your transaction gets finalized, others won’t be able to reference your transaction anymore. The only way you’d be able to receive rewards is if others have built on top of your transactions, to a point that your transaction is among the ancestral transactions of transactions that have not been finalized yet. If that’s not the case, then tough luck. You won’t be getting rewards through that transaction.
This is why you have to be active and continuously build transactions on top of different parents to maximize your earnings.
Overall, just be active and work a lot to prove your worth for rewards.
Welcome to the End of Part 2
If you have reached this far, then you now know the workings behind the leaderless proof-of-stake mechanism and the rewards system in Wavelet, and a few methods that not many know, or even heard of.
Congratulations on taking the time and initiative to enlighten yourself to a greater extent than is required by casual users.
This has been part 2 of the Wavelet Series and we look forward to going through other aspects of Wavelet in the next part of this series, in detail of course.
’Til next time,
And the next article,
Maikro~
Check out the other parts of the Wavelet Series:
Part 1: Wavelet: An Introduction
Part 3: Wavelet: Gossiping and Querying
Try out the Wavelet beta now:
Wavelet
Documentation
Build a Decentralized Chat on Wavelet Tutorial
