An outage of the AWS us-east-1 region has had a global impact on users and businesses world wide. To a lot of dev-ops engineers, this can come as a surprise based on how easy it is to decentralise a web product. AWS themselves make it incredibly easy for businesses to setup redundancies to protect against a single region outage. For some reason, we’re seeing large sites go down, even some of Amazons. The sites include Disney Plus, Prime Video, Alexa and Ring.
For those that are following cryptocurrencies closely will know of the term, dApp (decentralised application) or DeFi (decentralised finance). To most this term is often associated with high-availability and reliability. If an application is decentralised on a decentralised blockchain, then surely it must be protected against single region outages?
One example is the decentralised exchange dYdX that posted on Twitter (https://twitter.com/dydxprotocol/status/1468293558360805381), they were impacted by the outage. On their website they have stated they are decentralised, so how come they went down when us-east-1 went down? This comes down to what you considered to be decentralised and who you ask. Does decentralisation refer to the entire product or to just a section of if? Typically, this aspect is not defined at all and without clarity it can cause confusion.
Most users would assume that decentralisation refers to the entire application. From the moment they enter the web address (or open up the application), to the moment the transaction is placed is decentralised. By all rationale this should be the definition and there are certainly a lot of applications that follow this approach.
Unfortunately, there are also developers who choose to connect to the blockchain using legacy systems. Why? It could be that it’s because it’s what they’re used to. Big tech companies like AWS, Microsoft and Google have made system administration incredibly easy, but they have also made system administrators lazy.
In other situations though it’s nearly impossible to be a true decentralised exchange. In the case of dYdX, for all intense and purposes they can be considered decentralised. They use smart contracts on the Ethereum blockchain, which means that trades are in fact decentralised and that there is no “middle man” holding users funds. The downfall is that to interact with the blockchain is through legacy systems and to speed up transactions dYdX process transactions off-chain on their own “order books”. This design means they are not a true DeFi.
So what does a true DeFi look like? To answer that, we will need to break down the main parts.
Layer 1. Handling Transactions
This part is the one that most DeFi applications use as the benchmark to be considered DeFi. This layer users can anonymously create a transaction without depositing funds to a third party, and receive the traded funds without knowing who they traded with. Typically, this is handled by liquidity pool managed by a smart contract. If the smart contract code can be viewed and verified that it is not malicious then by all intense and purposes it is DeFi.
Layer 2. Handling Orders
When it comes to handling orders, this part is where a lot of DeFi apps stop. The main reason is speed. Since there are very few blockchains that can handle transaction speeds as fast as current world standards like Visa, they will process the order off-chain.
For example, Bob placed an order to swap 50 ADA for 1000 MINT tokens, the order doesn’t get submitted to the blockchain. Instead, it gets placed into the off-chain order book. Then Sally might come along and submit an order to swap 1000 MINT tokens for 50 ADA. The order-book recognises that we have a trade ready to go and submits the transaction to the blockchain. Usually these would all be bundled up and submitted.
In principle this solves several issues, but there’s one glaring issue. It’s not decentralised. This is the issue that dYdX faced. The off-chain order books were in the us-east-1 region, the one that went down. While the Ethereum network wasn’t impacted, users weren’t able to make trades.
A big issue with this approach is depending on the implementation, if the order book is handled by a single entity it can no longer be considered decentralised. A single entity has the potential to manipulate the order of the transactions or block certain transaction. For example, if all BUY orders were blocked, it will drop the price.
Layer 3. Interacting with the system
This layer is the one that users interact with. When a user types in the web address, it typically goes through a legacy system of load balancers and hopefully handled by servers that have redundancies in other regions. There’s still the potential though for the front-end to go down, such as the DNS servers failing and the website can’t be resolved. It’s also open to political geo-blocking.
So how do we solve this and create true DeFi / dApps?
Seeing as Layer 1 is mostly implemented by DeFi developers, there’s nothing to improve on here.
Layer 2 is harder to achieve when the blockchain system hasn’t implemented a scaling solution. While Cardano is working on this (known as Hydra), there are solutions. SundaeSwap seems to have created a mini Hydra solution called Scoopers. This takes the “order book” concept but decentralises it. Instead of a single entity handling the order books, a number of Stake Pools have been selected to manage the order books and submit the aggregated transactions to the block-chain. This removes some of the security risks and adds decentralisation to the order book concept. If most of the Scoopers are on different hosting providers and in different regions, they would continue running.
Layer 3 requires moving the front-end application off legacy systems. There’s several ways to do this. The most obvious one is the application is bundled up as an installable application on the user’s device. The application then could use a Lite Wallet, but these are typically run on legacy systems and are prone to the same issues. To be truly decentralised, the Layer 3 needs to only depend on the blockchain and the Layer 2 solution. For this the application would need to be running as a Full Blockchain node. As in, the application would need to download the entire blockchain and talk to other blockchain nodes directly through their IP addresses.
This is not the most practical solution for a lot of people. Not many people want to or are able to download hundreds of Gigabytes of data. If a user wants to use a true DeFi application, this is the closest you can get as there’s no entity in the middle that can go offline.
For users that can’t run a Full Node, a decentralised Lite Wallet would be required. Put simply, this solution would allow an application to interact with any of the public relay’s nodes directly. Cardano doesn’t have this feature available at this point.
In summary, DeFi is a term that is often used but typically executed in a way that doesn’t bring true DeFi. Cryptocurrencies and DeFi are both still young technologies and are being continually improved.