Polkadex has been wrestling with benchmarking the substrate runtime execution for close to 4 months. Benchmarking is the process used for load testing and obtaining optimal parameters for the blockchain at peak performance. As if the initial milestone of 300 transactions-per-second (TPS) throughput was not enough, we pushed it to 500 TPS by making the trading engine highly efficient onchain. We introduced the Fluid Switch Protocol (FSP) to have the orderbook access the liquidity pool, because high-frequency market making was impossible to achieve with the available network throughput.
When we started testing further with trade settlements originating from our cloud architecture (created explicitly for high-frequency trading, or HFT), we expected some tradeoff. However, we were only able to make incremental improvements when it came to HFT, for which the expected network latency is as low as 20 milliseconds (ms). Benchmarking results were also not promising, as the experience of externally connected bots was slow. We knew it was essential to improve throughput. It was also critical to improve the latency requirements so that a high-frequency trading desk could significantly improve its commercial participation. Since there are physical limitations to which we can reduce network latency in a distributed network, the best we could achieve is 100 ms, which is too slow for those trading desk requirements. We thought our team had hit a brick wall.
Rapidly innovating with what we had, we realized that however much we improved the individual trading experience, without achieving sub-100 ms latency for bots and market makers, Polkadex was never going to achieve what it set out to do. Without active commercial bots participation, liquidity will be affected and eventually thin out. We decided to look at different alternatives and found our solution in “state channels” and “commit chains”.
· State channels
State channels refer to the process in which users transact with one another directly outside of the blockchain, or ‘off-chain,’ and greatly minimize their use of ‘on-chain’ operations. It is one of the most exciting Ethereum scaling solutions in development and the closest a solution has become to production-ready.
· Commit chains
Commit-chains, also sometimes described as non-custodial side chains, do not introduce a new consensus mechanism like side chains — they rely on the parent-blockchains consensus, which makes them as safe as the parent-blockchain itself
After taking inspiration from the above two scaling solutions, Polkadex came up with a new off-chain commit algorithm called Offchain State Commits. It is a layer 2 scaling solution that creates verifiable off-chain trade executions for the orderbook.
For each block, the nth block receives a Tn snapshot, carrying a signature from the Polkadex cloud management key (a non-custodial operator), verified by off-chain workers that run the same algorithm to check for errors. Suppose the cloud management key is compromised and balances are manipulated for final output, blockchain will reward the off-chain workers for finding any or such bad actors and disallow the transaction to be written to the blockchain. Thus any such compromise is economically pointless.
Since this layer 2 solution fully resolves the verifiability expected for trade executions that are done on-chain, it eliminates the need for liquidity sharing from an automated market maker (AMM) Pool for the orderbook. The layer 2 solution, called Offchain State Commits, are horizontally scalable to accommodate thousands of trade settlements in a single write transaction on the blockchain.
Given the creation of Offchain State Commits as a viable layer2 solution, our original purpose of having the orderbook share liquidity from the AMM pool is now rendered obsolete. With this new scaling solution, the Polkadex orderbook achieves the same write-verifiability for an orderbook, even though it runs off-chain. Direct access to cloud APIs also means it can raise unlimited liquidity by engaging traditional market makers with zero network fees, just like in a centralized solution, which makes the need to share an AMM pool unnecessary. Given these advancements, we have effectively made trading faster and at greater throughput, all while maintaining a decentralized and trustless standard that customers can expect from 21st century trading on the Polkadot ecosystem.
