Wavelet: An Introduction
Part 1 of the Wavelet Series: An overview of Perlin’s new ledger that will bring the world of crypto to greater heights.
We discussed the problems with current ledger’s security protocols and how secure and scalable Wavelet is in a previous blog, Wavelet: Security Audit.
But how does Wavelet work? What makes it different from others? What’s… new?
To explain the full workings of Wavelet in detail, one article will never do it justice. The ideas and workings of the technical aspects are just too complicated, which some of you might realize while reading the whitepaper (if you understood anything and didn’t pass out while reading it that is).
So for the time being, indulge yourself in this brief overview of our ledger.
What is Wavelet?
Wavelet is a ledger that provides developers an easy and comfortable environment to build powerful applications.
To get straight to the point, here are the things Wavelet guarantees under a partially synchronous network (explained later):
- Total ordering of transactions: All nodes will finalize and apply the same set of transactions in the same order, allowing for consistency between the nodes.
- Transaction irreversibility: Once transactions are accepted and finalized, they cannot be canceled.
Furthermore, these guarantees allow Wavelet to include extra prospects and features:
- Succinct: transactions can be safely pruned, allowing for a low space requirement of a minimum 512MB of RAM (and a stable internet). Even smartphones can run Wavelet.
- Global-scale of network handling: System parameters can be adjusted naturally by our protocols depending on how much load the network is going through. This solves the issue with partial synchrony (explained later).
- Smart contracts: With the ordering and application of transactions being consistent across all nodes, Turing-complete smart contracts may safely be supported and executed.
- Decentralized governance: A leaderless proof-of-stake consensus model that incentivizes validators to consistently broadcast and approve valid transactions to receive rewards. Furthermore, this also effectively prevents dishonest nodes from engaging in and benefiting from fraudulent activities.
To further understand why our guarantees and features are relevant, we must first take a quick look at the market’s current situation.
The Current Problems of Popular Systems
Proof-of-work (POW)
Ledgers that utilize POW follows the system of the longest chain rule, where miners would aim to put their block on top of the longest chain of blocks sprouting from the genesis block.
Now, what would happen if all the current chains are of equal length? Nothing. The miner would have to wait until ONLY one of the chains become longer than the rest.
This can take a lot of time, so why not spend that time to learn about Wavelet instead?
Proof-of-stake (POS)
Ledgers that utilize POS put the majority of people under the hands of a small group, called validators, who are responsible for minting the next block of a chain.
Whether the chosen validator is elected or randomly chosen, if the number of validators is small, it allows for potentially fraudulent activities. On the other hand, if the number of validators increases, a lot more communication is required to finalize the next block of the chain, which will take time and processing power.
This makes you sacrifice either security or scalability, but… you don’t want to sacrifice either… oh, the pain… #firstworldproblems
Partial ordering of transactions
When it comes to transactions, the order is important. Period.
Certain projects utilize protocols that can only guarantee partial ordering of transactions. This means that the order you see your transactions getting processed may NOT be the same as how others see the order of your transactions.
*imagine this*
You go to a bank and make a new bank account. You first deposit $500 into your account, then you transfer $500 to someone else from your account.
It could be possible that another person, who views the transactions you made, sees it in the order: you transfer $500 to someone else from your account, then you deposit $500 into your account.
This ordering doesn’t make sense as it means that you had -$500 in your account at one point.
This is a very basic example, but if nodes in a network were to have the same issues of looking at transactions in different orders, consistency and security will be at risk.
With these issues persisting, we need a ledger that can offer both a secure and scalable network without any compromise.
So let’s give a warm welcome to Wavelet~
We’ll go through a few of the important aspects of Wavelet that set it apart from the current market.
The Protocols of Wavelet
Firstly, everything on the whitepaper is on the basis that communication is partially synchronous. It basically means that a percentage of messages that are sent can take an indeterminate amount of time to receive.
Wavelet runs two processes at the same time: gossiping and querying.
Gossiping
The gossiping process gets all nodes to communicate with each other and update the information of transactions on their graphs until they have the same graphs. This only happens when there aren’t any new transactions made for a certain period.
However, the transactions aren’t finalized through this process. That’s where the querying process comes in.
Querying
Overall, querying is a process of going through a node’s graph bit by bit, filtering information of transactions within the node to be consistent with other nodes. It’s a lot like proofreading the nodes’ graphs.
Partial Synchrony
With gossiping and querying working at the same time, a problem arises.
Querying is slower than gossiping, as proofreading a graph takes a lot longer than just communicating and building a graph.
The reason the querying process is slow has a lot to do with the fact that the players in the current market have a fixed number of transactions being processed by their querying protocols, no matter how many transactions are taking place.
It would be fine if the number of transactions is low, but if it’s too high, the querying process won’t be able to keep up with the gossiping process.
This makes the number of pending transactions increase at a much higher rate than the transactions being finalized, which could potentially overload the network and cause a lot of trouble.
The Load Factor
To fix the problem with partial synchrony, we developed a method that adjusts the number of transactions our querying protocol processes depending on how many transactions are taking place.
Behold, the Load Factor.
It simply lets a node accurately approximate the network load, which can further allow it to adjust the number of transactions our querying protocol processes and hence, solve the issue with partial synchrony.
The Design
Wavelet is a family of consensus protocols (processes that come into agreements within themselves to function): an overlay network, gossiping and querying.
Overlay Network Protocol: S/Kademlia
S/Kademlia was chosen as our overlay network protocol. With its formation of De-Bruijn network topology, it allows messages to be sent easily, even if troublemakers try to drop, redirect, or delay messages.
As a gossiping protocol requires the circulation of information between all nodes, we simply utilized S/Kademlia’s reliable messaging to get the job done.
Querying Protocol: Snowball
Snowball is a protocol inspired by the snowball sampling technique, where a node exchanges information, namely the critical transaction, with neighboring nodes multiple times in rounds. This process keeps repeating until the critical transaction being received is consistent for a large number of times specified beforehand.
This protects a partially synchronous network from troublemakers that try to jeopardize the consistency and fluidity of the network.
These are overall a few of the important aspects that Wavelet prides in, but wait…
There’s still so much more…
This is only the tip of the iceberg. The workings and functions in Wavelet are just so complex that, as said before, just one article will NOT do it justice.
So why not let this article be the start of a series? The Wavelet Series.
In this article, we introduced you to the workings of Wavelet on a basic level, which is all you need if you’re just going to be a casual user.
But, if you happen to want more and enlighten yourself to even greater extent (or just have lots of time and want to learn something interesting), we will provide you with further articles that will break down the workings of Wavelet even further.
Those articles will get much more technical and detailed, but if you do get through them, you will not only understand Wavelet but also complicated functions and systems that many don’t even know exists, but are important. Feel free to claim your bragging rights of knowledge after passing the trails of those articles.
As always, we want your honest feedback and constructive suggestions to help us refine Wavelet to perfection.
’Til next time,
Maikro~
Check out the other parts of the Wavelet Series:
Part 2: Wavelet: Staking and Decentralization
Part 3: Wavelet: Gossiping and Querying
Try out the Wavelet beta now:
Wavelet
Documentation
Build a Decentralized Chat on Wavelet Tutorial
