DAM’s Multichain dApp Architecture: Why Hub and Spoke Need Not Apply
Why do people keep trusting cross-chain bridges implicitly? Do people forget so easily about hacks that have happened just months before? No, probably not. There’s something else that drives people to keep using bridges, to explore new blockchains, and to keep putting their money in harm’s way by wrapping up their assets to use them somewhere else. That something is exactly why the future of crypto will not be constrained to one chain.
So we at DAM set out to figure out how to best allow for that freedom, while still keeping an extremely high level of security, composability, and no reliance on any bridging technology to be 100% truthful, much unlike our bridge-using dApp predecessors before us. This immediately ruled out the current en vogue architecture of multichain apps: the oh so beloved hub and spoke.
Some definitions as used in this article:
Base layer — cross-chain infrastructure that works underneath sovereign blockchains, relaying messages between them
Bridge — an implementation of a base layer that focuses on passing coins/tokens/nfts specifically by wrapping the assets and putting that representation on another chain
Pipe — an implementation of a base layer that uses burn and mint in order to deploy native tokens to each blockchain
Hub and spoke dApps have a couple different problems from our point of view, so let’s lay them out.
They are slow to use
The requirement of needing to send multiple cross-chain messages slows down the user’s ability to interact with the dApp. If one slow cross-chain message can take hours, then multiple back and forths between blockchains will immediately have users annoyed and delayed, potentially for days.
They have high up front gas costs and no gas savings if the hub network becomes congested
If all messages are being routed to one chain, then ideally this chain must be simultaneously very secure with multiple decentralized miners/validators — remember every single bit of financial maths is taking place there — while also not being used much at all, so the dApp actually comes out ahead from the high amount of gas it had to send upfront to pay for multiple cross-chain messages. If the chosen hub becomes congested, the protocol is out of luck. The users have saved no money, and the entire multichain app may come to a standstill.
Users have no ability to get away from using the hub network
In most cases, this is not going to be very controversial. However, if a network has a history of going down or being hacked, users may shy away from using the dApp at all because of the risk that entails having all proof of what they own in a blockchain ripe for hacker attacks. Unless the dApp does a full redeploy of their hub, they cannot escape it.
They have low modularity which means low chain deployment velocity, especially with multiple base layers
There are two components to low dApp deployment velocity. First, any dApp that must be connected to a hub to function properly must wait until the bridging layer has arrived to begin its deployment, while one that works entirely contained on one chain can be easily augmented after the fact by bridging layers. Second, these dApps will have lower composability because they require more scaffolding to enable access to the hub, usually in the form of bespoke messaging setups to support the hub. This leaves the option of relying entirely on one base layer, or building out multiple messaging systems to plug into each base layer.
They have heavy trust in base layer technology to pass on 100% truthful messages for calculation
The final and most important flaw: the high level of complexity that hub and spoke multichain architectures entail also means that monitoring every transaction 100% of the time is infeasible. This means implicit trust of the base bridging layers is the default, and in the case of DAM’s dealing with information about user funds, this was entirely unacceptable.
Our Architecture
In order to fix all of the aforementioned problems, we decided to follow the age-old law of software development: KISS (Keep It Simple, Stupid). Keeping our dApp as simple as possible from the outset while still allowing for multiple components to be added after that fact solves each of these problems.
DAM is self-contained
The only time a user has to worry about base layers is when they are teleporting their d2o to another chain, otherwise, every single one of DAM’s smart contract deployments can be used entirely independently from every other deployment. Each deployment has the ability to incorporate our first feature, one-to-one minting of d2o, as well as our coming features like whole-portfolio-based lending, leverage, and staking. This allows the dApp to be very quick: users can do everything they wish local to that blockchain first, and move their money in one quick teleport right after. There is no need to pass multiple messages between multiple chains, and therefore no need to reserve massive amounts of gas on the source chain.
DAM is chain agnostic
DAM does not force the user to interact with a specific blockchain, unseen by the user, in order to use our app. Eventually, DAM will be deployed and connected to a large spider web of different blockchains. With a hub and spoke architecture, in order to move tokens to a different blockchain, the protocol needs three different blockchains all communicating together through the base layer: the source chain, the hub chain, and the destination chain. DAM’s architecture cuts out the hub entirely, meaning that users only need to interact with 2 chains at any given point, straight from source to destination. This means more effort on the devops side for us, but allows for quicker and smoother use of the dApp. Also, because a user never has to touch a hub chain, they can entirely avoid networks that they deem to have unreasonably high gas fees.
DAM has base layer modularity
The worst case scenario in a dApp that is focused on being able to go everywhere is a base layer lock up allowing users to go nowhere. In order to safeguard against the risk of a base layer crashing, we’ve designed DAM’s system to be modular with regard to which pipe a user can use in order to get where they want to go. Currently, we’re using both LayerZero and Hyperlane. That means that if one fails, DAM can rollover users to the other with little interruption, and in the future, allow users to pick and choose which pipe they want to rely on. This modularity also prevents DAM from being locked into one specific base layer and its governance decisions. If the DAM community ever decides we need to cut a base layer out, it can be done with just a couple smart contract calls.
As well as the aforementioned security and governance benefits of being modular, supporting multiple pipes also allows for high velocity in emerging blockchain deployments. With Hyperlane, DAM is already working on the ability to deploy it ourselves, which means we can move incredibly quickly to new chains. Users will no longer have to wait for their preferred centralized exchange to implement support for new chain X, because DAM will already be deployed there!
DAM does not trust any specific base layer
Too often DAM has seen other protocols and their users trust these base layers implicitly, and when they get hacked, the protocol and its users are ruined, along with any other protocol they were working with! This is why DAM takes a cynical view on the security of these base layers, and assumes that eventually they will be exploited. As a result, we’ve developed our smart contracts with the ability to stop these base layers in their tracks, as well as our d2o Guardian, a robot that keeps an eye on every single teleport in order to ensure an appropriate burn happens first.
In Conclusion
DAM’s entire protocol is designed around security, simplicity, and ease of use from a user perspective. We wanted to make it as easy to understand and use as possible while not sacrificing an inch in the way of security, and the hub and spoke model just didn’t seem to fit with that ethos in our opinion. A fully self-contained point-to-point architecture did allow for all of this, and that’s why we chose it. However, if the day ever comes that base layers are totally hack-proof, gas costs cease to exist, and teleports become instant, DAM’s smart contract modularity is so high that we could implement a hub and spoke model simply by attaching slightly modified collateral housing contracts.
