Building Web3 Internet of Finance
We can’t help writing about what we work on in
Here we would like to explain these things simply but in-depth and showcase how we use state channels to make cross-chain transactions instant and low-cost.
Let’s dive in!
The more crypto adoption is gaining momentum, the more it becomes challenging for blockchain networks like Bitcoin and Ethereum to provide participants with the due user experience. The original design of the network gets less and less suitable to process the growing transaction numbers without losing speed and increasing transaction fees.
It’s good to remind here that the Ethereum network can handle ~15 TPS (transactions per second), and the Bitcoin network can handle ~5 TPS. That was great at the beginning but no longer feasible at the present moment.
Clumsy and semi-functional network design becomes a major turnoff for potential users considering joining a network, as well as for existing users to keep continuously exploring a network. From the marketing perspective, it’s literally killing the user retention rate.
Herewith, the growing number of decentralized applications (dApps) creates an extra load on networks. As dApps are getting more complicated, they require more computational power to function, but at the same time, they seek faster transaction speed and lower fees.
So as we see here, blockchain scalability and its mass adoption are pretty interdependent things. This is why solving the scalability problem is so vitally important for the whole crypto industry to keep progressing and widespread.
Roughly saying, there are two main approaches to handling the scalability problem. These are “off-chain” and “on-chain” approaches — a few words on each.
“On-chain” means that we make some improvements on the blockchain level (Layer 1). Here we can, at least, try to innovate the existing consensus algorithm, replace it with a better one (f.eg. Proof-of-work with Proof-of-stake), or create a groundbreaking new one from scratch.
The end goal here would be to achieve better bandwidth and throughput and decrease the computational power required for transaction processing.
As an example, Ethereum is currently undergoing on-chain scaling through sharding.
Briefly, sharding is the process of splitting a database horizontally to spread the load. In the Ethereum context, sharding will reduce network congestion and increase the number of transactions per second by creating new 60+ chains, known as “shards.” This will also reduce the load for each validator, as they will no longer be required to process the entirety of all transactions across the network.
The consensus mechanism will move from highly computational and clumsy proof-of-work (PoW) to proof-of-stake (PoS) with lower hardware requirements.
While on-chain scaling is a great way to go in the long term, however, this is an extremely complicated task. It requires massive efforts and enormous time (it can take years) to get accomplished.
A way more flexible alternative to on-chains is “off-chain” solutions that do not modify the base blockchain. Off-chain or interchangeably, Layer 2 solutions, are built upon blockchains and exist in the form of their superstructures.
The main job of off-chain solutions is to improve users’ transaction experience by getting rid of existing blockchain networks bottlenecks, like slow speed and high fees.
The core principle of the off-chain solutions’ work is moving transaction sessions out of the blockchain and publicly recording only their final balance.
The most applied off-chain solutions are:
Below we will cover how they differ while focusing on state channels.
A state channel is a mechanism enabling transacting parties to interact off-chain and further record with a blockchain only the final state between them. It's like two traders would make x-number of transactions between each other during a day, and by the evening, would officially post the final net balance between them. This trick allows to overcome all the challenges arising out of blockchains' clumsy nature, making transactions fast and cheap while still being the same secure as if they were conducted directly on-chain. Here is how to use them:
To initiate a state channel, counterparties shall deposit a required amount of collateral (i.e., funds) with a multi-sig contract. Then the collateral of both will be deducted and sent to a smart contract running the state channel. A deposit transaction will deduct money from the party's accounts and transfer it to a particular smart contract that cooperates with this state channel. This depositing mechanism is aimed to ensure that no double-spend will occur neither on the on-chain nor on the off-chain sides of interactions. And this is where the first fee payment happens.
Since a state channel is open, parties are free to conduct the transactions as much as they prefer through cryptographically signed messages. Their "P&L" inside the channel will alter with each transaction that happens.
Settlement and channel closing
Finally, any party can initiate an on-chain transaction when all the transactions are done. For that, both parties should agree on the final state of the channel and submit it to the blockchain for the record. And now it's time for the second fee payment.
What if there is a dispute?
If a participant rejects confirming the final state or simply doesn't respond, the other party can register a dispute on-chain. Then this party will have to submit to a smart contract the latest state of their digitally signed transactions recorded off-chain to prove their claims are legitimate. Another party can disagree that the provided state is the latest and submit the more updated state in response. In the end, the parties would turn to the settlement or the force-execution phase (depending on the specifics of a channel design).
Summing up, the key benefits of state channels are:
Like with any technology, the application of state channels has its limitations.
Mainly, these limitations look as follows:
Here is a quick historical data on how state channels have been implemented:
Here I would just share some great examples of ongoing projects relying on state channels, including ours (why not?😊):
Payment channels are a specific use case of state channels. They are only designed to support payments between two or more parties.
The most well-known example of payment channels is Lightning Network.
Comparing payment channels with state ones, the latter have much broader applications and are not limited only to payments.
For example, state channels can also be used for scaling a dApp or a blockchain (like Celer Network), in real-time gaming, etc.
Essentially, state channels are an answer for any decentralized application which needs a high throughput, privacy at a transaction level, and the same level of security as a Layer 1 blockchain.
Unlike a state channel, a side chain is a separate blockchain that is connected with its parent blockchain (the main chain) through a two-way peg.
Sidechains run in parallel with their main chains and have their own consensus algorithms.
Though side chains are similar to the main chain in terms of smart contract language and code deployment, they have different validator nodes and, unlike state channels, side chains do not inherit the main chain’s security properties.
A two-way peg enables the transfer of assets between the main net and side chain. The side chain’s consensus mechanism (ex: PoS) allows it to process transactions at a higher throughput. The transactions are batched and brought on the main chain, which reduces the computational load on the main chain and thereby reduces the gas fees.
Examples of sidechain projects:
Rollups are a group of solutions that use different techniques to ‘bundle’ transactions and submit them to the main net, thereby increasing the speed and reducing the fee per transaction.
Like state channels, rollups perform transaction execution outside Layer 1, and then the data is posted to Layer 1, where consensus is reached.
The main difference between state channels and rollups is that the latter involve an intermediary to process transactions — a rollup operator. Also, state channels are suitable for a wider variety of use cases than rollups at the present moment.
Examples of rollups:
At the core of Yellow’s architecture is an overlay mesh peer-to-peer (P2P) network that uses state channels for two primary purposes:
Below is how it works.
To open a trading state channel, the counterparties need to agree on the amount of YELLOW tokens to be provided as collateral and then deposit them with a smart contract called Adjudicator. Once this is done, the state channel is active, and the counterparties can start trading.
The trades are facilitated by the matching engine ‘Finex’. The engine allows the exchanges to place bulk orders and cancellations with a validation process that ensures trades are being executed within funding limits. The transactions are then maintained with a metadata index without processing them in the blockchain.
The settlement process may be initiated by any party at any time and should be validated by all the parties involved.
After that, the trading channel closes.
Wrapping it up
Essentially, Yellow Network is a Layer 3 that operates independently of blockchains but facilitates their interconnection and cross-functionality, massively relying on state channel technology. As a result, Yellow’s architecture enables a matching throughput of around billions of messages per day, which is significantly faster than any paired Layer 1 and Layer 2 solutions available today. At the end, it would even enable high-frequency trading in the same manner as it’s done in traditional finance.
Compared with other scalability solutions, state channels still maintain their winner position. They are easier for implementation, cheap and fast in terms of their functionality, absolutely disintermediated, and secure ̶a̶s̶ ̶h̶e̶l̶l̶ the same as a blockchain they operate with. Moreover, state channels are feasible for more use cases than their alternatives.
When it comes to Web3 multi-chain trading, state channels are the best bet, as they help overcome blockchains’ interoperability challenges and provide speed, enabling even crypto HFT. Yellow Network is the perfect example to prove that.
By Julie Plavnik for Yellow Network.
Check out OpenDAX v4 stack GitHub: https://github.com/openware/opendax
Follow Yellow Twitter:
Join the public Yellow Network Telegram: https://t.me/yellow_org
Read Yellow Network HackerNoon blog: https://hackernoon.com/u/yellownetwork
Stay tuned as Yellow Network unveils the developer tools, brokerage nodes stack, and community liquidity mining software!
Also published here.