Wavelet – 10k+ TPS DAG-Based Ledger with Proof-of-Stake & Smart Contract Sup...

Our First Major Development Release: Smart Contract SDKs, Graph Explorer, 10,000 TPS and more!— Github

No words can express my shock by the fact that after only 8 months of development, we’re finally ready to unveil Wavelet and bring it into the hands of the community.

There has been thousands of updates, community contributions, source code rewrites, and changes in Wavelet that it would be next to impossible to somehow fit it in this single blog post alone.

Yet, this only marks but the first step in our technical roadmap.

In spite of this, I cannot express my gratitude enough for the community and our core development team in making this possible.

We really, really cannot wait to show you what’s next; but before doing that, let’s start going through what has changed with Wavelet, and what we’re giving off to the community for our very first release.

Wavelet, Smart Contracts, Transaction Processors

Wavelet, being written just a month ago, was originally created to slash away the Achilles heel that made Avalanche intolerable for real-world applications.

The culmination of efforts over the past 8 months from our core development team spanned:

1. Testing and implementing numerous consensus protocols,
2. Heavily optimizing the time and space complexity of Avalanche’s original algorithms,
3. Stress-testing the ledger with nodes of both honest and Byzantine type,
4. Open-sourcing an embeddable WebAssembly VM, Life , catered towards decentralized projects,
5. Implementing smart contracts and ensuring ledger consistency/security,
6. Open-sourcing a developer-first P2P networking stack, Noise , with privacy and security in mind, and
7. Technically framing how a ledger should be constructed given arbitrary types of consensus protocols whose security relies from heuristics derived from a directed-acyclic-graph of transactions.

We’ve underwent 4 whole source-code rewrites of Wavelet , and finally are content with presenting to all of you in the community with what Wavelet has become as of today.

Thousands of commits and 4 whole source-code rewrites of Wavelet were made to make this possible.

We are extremely happy to present to the community compiled binaries of Wavelet that will let you run your very own testnets powered by…

THE very first, publicly available, open, permissionless ledger that makes use of a directed-acyclic-graph-based consensus protocol.

Send and receive PERLs, stake money and earn validator rewards, create and deploy smart contracts, create a cluster of nodes and establish your own testnet empire, extend the ledger out with Wavelet’s own plugin system.

All you need to do is download a binary we’ve built for your respective operating system, follow the instructions on this page , and enjoy.

Starting up 2 Wavelet nodes, staking 2500 PERLs, and deploying a smart contract.

Now, speaking of smart contracts…

We are fully open-sourcing WebAssembly smart contract/transaction processor SDKs for creating smart contracts/plugins for Wavelet!

With the smart contract SDK , you can write WebAssembly-powered smart contracts in Rust making unit testing easy, spotting erroneous mistakes simple, keeping your code minimal, and optimizing for minimal gas costs trivial.

Smart contracts are Turing-complete, have costs on a per-operation basis (charged as gas much like in Ethereum), supports persistent storage, and may interact with other smart contracts/users via. sending out transactions.

With the transaction processor SDK , you can write WebAssembly-powered contracts in Rust to easily extend Wavelet to support all new kinds of types of transactions.

WebAssembly transaction processor SDK written in Rust.

We really can’t wait to see what you guys come up with when creating smart contracts/extensions on top of Wavelet.

Every download of Wavelet comes with transaction processors that enables Wavelet to have support for smart contracts, proof of stake, and establishing PERLS.

Just a few examples that come into mind are: decentralized identity systems, decentralized exchanges, decentralized key-value stores/databases, atomic swap layers with numerous blockchains, and decentralized voting systems…

The possibilities really are endless.

Now, if you don’t have time to learn Rust by any chance, do know that we are working hard on creating AssemblyScript (very similar to TypeScript) and C++ variants of both the smart contract/transaction processor SDKs hopefully soon.

Experimental work has already been done for both; though much like our other open-source projects, we are reaching out to you all in the hopes that smart contract and transaction processor SDKs will eventually be written and supported in different programming languages by the community.

Numerous work has already been contributed to the ledger by members of the community ( we really can’t thank you enough! ), and we 100% are advocating for fostering a truly decentralized community.

You have our full support and can talk to us any time on our Discord (or even just file any issues you spot with our code on our Github!).

But one thing we must remind to you all is that Wavelet is still in its infancy; it is inevitably prone to potentially many bugs or errors we were not able to discover in our testing.

This also yields the reason to why we are only releasing compiled binaries for now, and not the entire source code of Wavelet just yet.

In releasing the source code, forks and copies of heavily bug-prone, outdated code will eventually arise of Wavelet which will needlessly confuse the community.

In the meantime, with the binaries, please do report to us any bugs you discover, and recommend changes to the Wiki we have over on our Github should anything not be clear.

We have made it a priority to fix any bugs reported by the community, and to release out bug-fix patches for Wavelet ASAP so may finish carving out a path for us to release Wavelet’s main net .

A stress test on Wavelet

After loads of stress-testing on Google Kubernetes Engine with 240 nodes of n1-standard-4 (4 vCPUs, 15 GB memory)-type, we are delighted to achieve a stable benchmark of ~10,000 transactions per second!

Our benchmarks were done with nodes distributed over three separate geographic regions (US, Singapore, and Japan), with a continuous (unbounded) load of 70% monetary, and 30% smart-contract-related transactions.

Nodes being stress tested on Google Kubernetes Engine.

Nodes are periodically syncing every 2 seconds, and the parameters for our consensus protocol are equivalent to those statedhere.

Additionally, transactions are pruned over time to reduce storage space taken by each node.

Now, why is this important?

Because we strive for Wavelet to be a ledger that is realistic enough to be ran on consumer laptops/PCs and internet lines, and unlike other projects, we are not gonna be lying to you with bogus theoretical TPS limits.

It’s an easy issue to see, though ledgers that claim upwards of more than 50,000 transactions per second are unrealistic to be ran in today’s world.

Imagine a single, arbitrary transaction to be about 1kb. If a ledger claims to support 10,000 transactions per second, any ledger node needs to be writing about 10mb per second onto their hard drive.

Any ledger node also needs to be sending about 10mb per second over an Internet line.

Any ledger node also needs to be performing verification of cryptographic signatures 10,000 times per second. As we know, the verification of cryptographic signatures is arbitrarily slow on many modern CPUs .

As a result, this already places normal consumer PCs in a relatively uncomfortable spot, yet supportable.

Now, imagine any ledger claiming to support 50,000 transactions per second. That’s 50mb of consumed disk space per second, which is 3GB of disk space being consumed and sent over an Internet line per minute .

You’d need supercomputers to run that damn thing, which ruins the entire point of an open, permissionless, decentralized ledger.

Unless you can make a claim against the fact we’re close to reaching the theoretical limit on the size of resistors s.t. we can support Moore's law, it is difficult enough for consumer PCs which we’ve benchmarked against to be able to support 10,000 transactions per second.

For good intentions, we have justified our results to remain stagnant at 10,000 TPS, and are open to the community to running their own stress tests with the binaries that we have provided.

Interacting with Wavelet

Apart from using the command-line for interacting with a Wavelet node, we have created a standardized node HTTP API that allows developers to build web/mobile/desktop apps and systems on top of Wavelet.

As you might notice, we have included a tool called wctl which lets you directly debug and interact with a Wavelet node via. its HTTP API.

On top of that, we are also open-sourcing a work-in-progress web app that lets you directly visualize the frontier of Wavelet’s directed-acyclic-graph which you may now download and run called Lens .

Perlin Lens — a graph (“block”) explorer connected to a Wavelet node.

We are opening it in hopes for the community in adopting it to creating the first generation of graph (rather than block) explorers for Wavelet, as Lens as of now is limited in functionality in comparison to a wctl and Wavelet’s command-line interface.

Old design and animation of Perlin Lens being spammed with transactions.

Lens was written in TypeScript, React, Blueprint.JS, and Pixi.JS, and we are openly hiring frontend developers, and advocating for community PRs in developing it out to be a powerful explorer for Wavelet nodes.

Some examples of what still needs to be done for Lens are:

1. More-granular transaction status updates and visualizations,
2. Performance improvements on the 2D Pixi.JS graph visualization ( a Wavelet node is so fast in processing transactions that the website lags plotting transaction updates on the visual graph! ), and
3. Alerts and validation checks for all forms and fields.

Should you require any more HTTP API endpoints for adding new features to Lens, or for integrating Wavelet into your own app, feel free to suggest them to us directly to us by opening up a new Github issue here !

Some other technical keynotes/updates

1. We’ve created a novel method in distributing out validator rewards via an interesting coin-flipping technique using some new metrics we’ve derived based off of Wavelet’s directed-acyclic-graph of transactions. This new method emphasizes on being able to uniformly distribute out validator rewards to validators that deserve it, in as decentralized of a manner as possible.
2. The Proof-of-Stake implementation shipped with Wavelet is nearly complete to the extent validators are properly rewarded for playing a part in filtering out Byzantine transactions for the network. The only feature that is left is delaying stake withdrawal (stakes should only be withdrawable after N days/weeks/months). This is still tentative* , however the minimum stake necessary is 2500 PERLs.
3. Transaction fees have been implemented, and are on a per-monetary transaction basis. I want to emphasize * that transaction fees are still to be discussed, changed, and voted for by the community; the Wavelet nodes by default have been arbitrarily set to have transaction fees be either 2 PERLs, or 5% of the value of monetary transactions (whichever one is larger).
4. We have deprecated syncing via IBLT’s, and are now using a new randomized algorithm for selectively picking and syncing transactions from remote peers periodically. The algorithm randomly selects sub-graphs of the DAG closer and syncs vertices in topological order periodically.
5. We have transformed much of Avalanche’s algorithms to be incremental, and created an event loop architecture system over Avalanche to maximize concurrency. Should Byzantine behavior muck around, we have created a persistent AVL tree to be able to efficiently rollback or apply batches of transactions s.t. we minimize the work necessary in combatting Byzantine activity.
6. A massive refactor for noise, our P2P networking library is coming soon to significantly improve developer ergonomics and overall security/networking performance.

Closing Thoughts

First and foremost, please join our Discord ! We would love your thoughts on our work thus far, and should you be open to contributing, we would love to assist you in any way we can.

What has perspired from Perlin ever since we started 11 months ago has resulted in us open-sourcing widely-used libraries, and in amidst us progressing forward with our mission, inspired the creation of a whole new open, permissionless ledger that boasts smart contracts, high TPS, and a novel Proof-of-Stake protocol that brings PoS closer to that of the theoretical security of PoW.

Students, developers, and startups/enterprises with the Wavelet binaries can now start developing smart contracts, extending the ledger out by creating transaction processors, and create whole new decentralized systems and applications just out of Wavelet alone.

Although what culminated out of these 8 months might seem like a lot of work, I want to emphasize however that we are just getting started .

We still are going strong in going forward with our mission on truly decentralizing compute, and with it pave a new light in which we are going to be constructing a new form of Universal Basic Income (UBI) by having billions of dollars worth of computational power from devices from developing countries and underutilized datacenters empower entire systems managed by the largest companies in the world.