Pillars of Hydralosophy (1)
Why Build Our Own L1?
As the Omnipool comes close to reality, we decided to launch a new knowledge series called Pillars of Hydralosophy. Its aim is to provide a basic understanding of some of the technological and research concepts underpinning the design of the HydraDX Protocol.
This blog series should be able to reach everyone’s attention. Newcomers to the ecosystem will find accessible information on topics such as L1s, shared security, XCMP etc. More seasoned Hydraheads might be interested in some recent cutting-edge features such as light clients, SPREE, or off-chain workers.
This first post tackles a fundamental question: Why did we decide to build our own L1 blockchain instead of going for an L2? From mitigating sandwich attacks to prioritizing particular transactions within a block, we provide several practical examples illustrating the possibilities which an L1 chain gives us.
Benefits of an L1
The main advantage of having your own L1 is the ability to have control over your chain and its transactions. Two fields in which this brings obvious benefits concern the security of the chain and the capacity to have better blockspace allocation.
Statistics from Crystal highlight DeFi’s chronic security flaws. It's unfortunate but true. Over the past eleven years, the market has seen 364 separate security events, with $14.6 billion stolen from various protocols and platforms. One-third of these hacks and breaches occurred in 2022.
One interesting observation from past experience is that projects which were in control of their own blockchain have been much better suited to mitigate the negative effects of exploits. They were able to take quick measures such as halting transactions, which has not been a viable possibility for many general-purpose blockchains.
Despite suffering a $3B DeFi exploit, Acala quickly managed to recover ~ 3.02B of erroneously minted aUSD and to burn ~$2.97B aUSD following a community vote. Acala's swift reaction was made possible by the ability to freeze certain transactions on their chain which prevented the perpetrators from further dispersing the funds via XCM or bridges. This helped them reduce a potential $3B loss to just under $3.7M.
DeFi application-specific blockchains support Targeted Function Pausing (TFP) which can help mitigate losses from errors and exploits. As disruptive as a pause of functions may be, positives of mitigating potential economic loss can outweigh any discussions about network disruptions and concerns about centralized decision-making.
If an exploit were to occur affecting any asset in the HydraDX Omnipool, having control of our own L1 would allow us to act quickly and mitigate the negative impact on the protocol. Combined with systems for early detection, we could easily limit certain or all transactions relating to some or all of the supported assets.
Better Allocation of Blockspace
Having your own L1 has another advantage with great potential for the DeFi use case - the possibility to allocate blockspace and to determine the order of transactions. HydraDX is exploring methods of limiting block producer authority in AMMs, manipulating oracle functionality for transaction efficiency, prioritizing trades, and batch processing.
These research areas aim to improve cross-chain liquidity by enabling control over specific protocol parameters. The presentation of our Research Lead at Polkadot Decoded 2022 gives some practical examples concerning Maximal Extractable Value (MEV). Besides the ability to mitigate MEV attacks, blockspace allocation techniques could be deployed to transform the benefits extracted by MEV hackers into benefits for the Protocol.
A sandwich attack is where an MEV bot identifies a trade (by Trader A) under processing by the network and front-runs it with a similar trade to cause an execution at the worst price. The MEV bot then sells the swapped tokens within the same block to earn a profit.
Currently, an AMM updates the price of any asset on a transaction-by-transaction basis, where the order of the swaps affects their price. However, this is inefficient because, in the real world, multiple simultaneous transactions occur in various directions.
At HydraDX, we foresee the end state of AMMs will create Universal arbitrage-free pricing within each block. We can target several platform factors through our L1, such as blockspace, oracles, and batch processing, preventing sandwich attacks. In a liquidity crisis created by overcollateralized lending, block producers may opt to receive high fees through sandwich attacks on numerous transactions.
However, with an L1 blockchain, HydraDX could achieve transaction bias by prioritizing liquidations, which would reserve block space and disrupt targeted block transactions. The MEV process looks like this:
MEV searchers sift through the public memory pool (where initiated transactions queue awaiting validation and processing).
After identifying an opportunity, MEV searchers send a bribe to miners.
Miners create a front-running transaction that benefits the MEV searchers.
Prioritizing transactions depending on the market condition disrupts the MEV exploitation process. MEV searchers encounter difficulties identifying profitable transactions due to the change in transaction processing.
We could also implement batch processing to avert sandwich attacks by thinking of blocks as a whole instead of individually processing each transaction. Instead of executing transactions individually, protocols could implement cluster processing to mitigate MEV exploits. Processing transactions in batches prevent nefarious actors from targeting single transactions to manipulate the execution price or time, protecting users from manufactured price slippage. These applications allow us to achieve Universal arbitrage-free pricing through our AMM.
Just-in-time (JIT) Liquidity
Uniswap‘s v3 release unveiled a new form of MEV known as JIT liquidity, where an LP utilizes MEV to provide liquidity within the same block of an ongoing trade to capture the trading fees from this trade.
In the scenario above, passive LPs would be left out of profitable trades and only be left as the liquidity of last resort, executing transactions that active LPs deem unprofitable. Having our own L1 would allow us to design the parameters and constraints that must be satisfied within each block produced on the network.
Such a constraint could be to define acceptable conditions for adding new liquidity positions. We could create limitations around LP block participation to ensure all LPs participate in profitable trades. In volatile markets where liquidation transactions may be frequent, an L1 would enable the fair distribution of transactions regardless of their profitability, ensuring every LP on HydraDX receives their appropriate earnings. This model could also prevent the subjection of passive LPs to bad trades.
L1 chains provide a flexible infrastructure which can be utilized by DeFi projects in their pursuit of future-proof design. Security and better allocation of blockspace are among the advantages made possible by this approach.
Against this background, the L1 AMM design has been one of the requirements which guided HydraDX’s choice of Polkadot as the most suitable platform to accommodate the long-term needs of the Omnipool. However, Polkadot has so much more to offer. To learn more, don’t miss Hydralosophy pt. 2 which will present some of the more and less known killer features of Polkadot and the framework behind it - Substrate.