Finding a home for your DApp in a scalable world

By: Barnabé Monnot

Blockchains won't scale alone. Networks of blockchains, built from heterogenous designs, will communicate with one another via bridges. Assets will move from one place to another, their laws of motion written by the blockchain and bridge protocols they transit upon.

DApps must prepare to adapt to this reality. Users of a DEX expect a unified interface, but the DEX's architecture itself may be split up across multiple domains to maximize efficiency and user experience.

It is similar to how modern web applications work: their backends aggregate resources from multiple places, such as databases, caches, compute clusters etc. On web3, assets are first-class citizens. Tokens are minted on one chain, but may be used across several others. They may even be minted in multiple places, as some centralized stablecoins are.

Protocols and applications are still figuring it out, and much of the infrastructure is yet to be built. Still, trends appear, and it is possible to discuss established and upcoming solutions, while drawing early conclusions and insights. Let's dive into the networked world of web3 applications.

Where assets live

Since much of web3 relies on ownership, we need to spend some time understanding how digital assets come to be on blockchain networks.

Native assets

Blockchains are typically organized around a single asset "native" to the chain. When miners discover a new Bitcoin block, they are rewarded with freshly minted BTC and transaction fees, and more of the latter than the former as time goes on. When Ethereum validators finalize a new block in Proof-of-Stake, they receive new ETH too. While Cosmos embodies a world of different assets, most of these assets are native to their own chain, with various schedules governing their issuance.

The notion of finality matters a lot in the following discussion. Finality refers to the property that a transaction executed on a chain is not eventually reverted. When Alice moves an asset from chain A to chain B, chain B needs a guarantee that the original deposit on chain A won't be reverted. Otherwise, Alice gets to "duplicate" her asset for free: she keeps her deposit on chain A, and gets to use the assets on chain B too!

The native asset secures the chain, so its value scales up the chain's security budget. A chain equipped with a finality gadget, as Proof-of-Stake Ethereum and Tendermint (used by much of Cosmos, also Polygon PoS) chains are, needs two thirds of their validator set agreeing to finalize a block. The validator set is made up of entities staking some amount of the native token, and as the token gets easier to obtain (for instance, during a market crash), it gets easier to cross the threshold necessary to finalize one's own wishes, including reverting a deposit.

Non-native assets

On chains with programmable execution, such as smart contract-enabled chains, assets may be minted from a smart contract instead. On Ethereum, ERC-20 assets are known as fungible tokens, or just tokens, while ERC-721 assets are the famous non-fungible tokens (NFTs, challenged by other ERCs such as ERC-1155). Similar interfaces exist on other chains too.

Non-native assets are not tied to a single chain. Stablecoins such as USDC or USDT mint their tokens across multiple domains. But for a single token, it is always possible to point to where that token is "rooted". For instance, say Alice mints 10 USDC on Ethereum, while Bob mints 20 on Solana. Alice's USDC are rooted on Ethereum, specifically on the smart contract where Alice's account is credited with 10 USDC, while Bob's are rooted on Solana.

Native assets are trivially rooted on their own chain, yet as first-class citizens of their chain, they may not abide by common token interfaces. This is why many DApps use Wrapped ETH (WETH) to function, a simple 1:1 pairing between ETH and an ERC-20 representation of ETH.

How assets move

DApps are deployed on any chain able to host them. A DApp written in Solidity compiles down to bytecode executable on any EVM-based chain, and EVM-equivalent environments are often hosts to copies of popular DApps originally deployed on Ethereum's base layer itself (see Development in a scalable world).

In a networked blockchain paradigm, DApps mobilize assets rooted on multiple domains. Bob, a user of the Cosmos app-chain Osmosis, could trade ATOM tokens native to the Cosmos Hub with Wrapped BTC, which are rooted in Ethereum but themselves a representation of an asset native to the Bitcoin blockchain. What a headache for accountants! 🤯

Fortunately, armed with trustless technologies (or, erm, as trustless as possible, see Bridges), keeping track of every asset and ensuring we don't duplicate or lose them along the way is done for us. Much of this logic is held in bridges. Bridges have two endpoints, the originating chain and the asset's destination. How they are built determines much of the security of DApps interacting with assets rooted on a different chain than the DApp itself.

Cosmos and inter-blockchain communication (IBC)

The IBC protocol connects chains in the Cosmos ecosystem and beyond. IBC is opt-in, and as such, any chain satisfying the requirements of the protocol can feasibly open itself to IBC. A major requirement is provable finality. To transit on IBC, an asset's deposit on the origin chain must have been finalized. IBC allows the destination chain to interpret that finality has indeed taken place on the origin chain, and the asset can be transferred safely.

IBC chains talk to one another by interpreting each other's chain data.

For instance, say Bob wants to send his ATOM from the Hub to the Osmosis chain. Participating in IBC, Osmosis validators run a light client to the Hub chain. The light client on Osmosis simply looks at new blocks on the Hub chain, and listens to deposit events, such as Bob depositing his ATOM on the Hub's IBC relay for transfer to Osmosis. Relayers deliver messages from the Hub's IBC inbox to Osmosis, and Bob's ATOM is ready to be used on Osmosis. This model is extensible to general function calls from one chain to another, e.g., Bob calling a smart contract on some IBC-enabled chain from another, providing an asynchronous form of sharding.

Risks of contagion exist in this model, however. If an IBC-enabled chain is attacked and finalizes an invalid transition, e.g., Alice stealing Bob's assets, then other IBC-enabled chains will take this invalid transition as gospel, and allow Alice to move Bob's stolen assets on her destination chain account. Alice could then dispose of the stolen assets on the destination chain, for instance swapping them with assets from a non-compromised chain.

Rollup bridges

The honest majority assumption underlying IBC transfers is somewhat resolved with rollups. A DApp deployed on a rollup is able to use all liquidity currently present on the rollup. Validity rollups are secured with validity proofs (SNARKs/STARKs), ensuring correctness of their state transitions, while optimistic rollups rely on an honest minority assumption, where a single challenger is able to defeat an invalid transition (see a deep dive on rollups).

Rollups do not necessarily have a native token. Some rollups on Ethereum have chosen to use ETH for their operations, e.g., booking user fees, while issuing a "rollup token" for governance or protocols related to decentralized sequencer selection. Other rollups use their own issued token for all functions, only swapping to ETH when necessary to pay for data availability on Ethereum.

Some DApps deployed on a rollup also deploy their own token on the rollup directly, i.e., the token is rooted on the rollup. Since rollups extend the "zone of sovereignty" of the base layer, tokens rooted on the rollup still move around freely, either to the base layer or other adjacent rollups. Think of a zone of sovereignty as multiple chains between which assets can move securely, as each chain of the zone validates incoming assets.

Pooled liquidity designs take advantage of this fact. For instance, a DApp deployed on a rollup may invoke liquidity held on the base layer. Optimistic rollups with long withdrawal periods may not fit the bill here, but validity rollups prove correctness and allow withdrawals as soon as a batch of their own transactions is published and proven on the base layer. Pooled liquidity on the base layer is then efficiently matched to parallel markets deployed on distinct rollups, amortizing costs across all trades made on the rollups. Aave, a popular DEX, explored such a solution with the StarkNet rollup, as did Loopring, a validity rollup, and StarkWare with their distributed AMM (dAMM) design.

Pooled liquidity

Which home for my DApp?

Now that we understand how tokens come to be, where they live, and how they move, we recognize the primacy of liquidity for DApps. Synchronous, low-cost transfers from one domain to another may be possible within a single zone of sovereignty, for instance between validity rollups built on the same settlement layer. Otherwise, more resources may be necessary to operate the complex interplay of bridges and chains, potentially inducing higher costs for users, more latency or different security properties.

These are all trade-offs, but as the ecosystem matures, categories of DApps start finding the patterns which suit them the best. Let's explore some of them.

Ethereum outlook

Ethereum is pursuing the vision of a general-purpose execution+settlement layer at the base layer, on which (smart contract) rollups deploy themselves and publish data to the data availability (DA) layer, all secured by Ethereum validators. Yet some rollups argue for going a step further: making the (L2) rollup itself a settlement layer to other (L3) rollups deployed on the L2 rollup.

This approach, proposed by StarkWare, is known as fractal scaling. All data, even from L3 rollups, must still be published on the Ethereum DA layer for the L3 rollup to inherit Ethereum security, so there is no savings there. But having "rollups on rollups" could make sense in some cases. Constructions on top of the settlement rollup would not have to restrict themselves to the rollup's execution environment:

• A privacy-focused L3 could be built on top of a more general L2. The L2 would be responsible for managing operations with the base layer, providing scale to the other chains deployed on top of it.

• A validium, i.e., a rollup-like blockchain which does not publish its data to the DA layer, can also be deployed as an L3. Proofs of the validium are posted to the L2 settlement layer, where verification is cheap, while more infrequently "proofs of proofs" of the _whole ecosystem_ (settlement L2 + L3 constructions) are posted to the base layer.

Cosmos outlook

In the Cosmos ecosystem, other patterns emerge. Evmos is an L1 chain in the Cosmos constellation providing an EVM execution environment to its DApps. In the "Cevmos" vision, Evmos is a settlement layer to rollups deployed on top of it, while the rollups publish their data to the Celestia data availability and consensus layer. Rollups deployed on top of the Evmos settlement layer all share in a single zone of sovereignty, once again allowing assets rooted anywhere in the zone to move around securely.

Meanwhile, more sovereign DApp chains in Cosmos who do not wish to use a settlement layer other than themselves could "rent" security from other chains, a feature called Interchain Security (ICS). In this design, the validator set from a chain (e.g., the Cosmos Hub's, currently the largest validator set) could be "rented" by other _consumer chains_ to guarantee their security. This is a more opt-in approach than Ethereum's rollups, who must always pay for security to the Ethereum base layer via settlement and data availability fees.

Beyond renting security, the vision of the Cosmos Hub consists in operating a large scale market for blockspace across multiple chains. Transfers and swaps across chains induce revenue for operators, who match liquidity and make markets. DApps, either deployed on chains or as app-chains themselves, are able to access this liquidity, as competitive pressure to make maximally efficient use of blockspace drive optimal liquidity provisioning.

Conclusion: A matrix

While web2 was powered by data and compute, web3 resolutely organizes itself around assets. DApp architecture must answer the following:

• Whether the application expects to compose with other protocols on nearby or far-away chains, or if it looks more like a self-contained, internal economy.

• The value of user interactions and the security guarantees it should be able to provide.

Some archetypes are already emerging. DEXs are marketplaces for assets near and far, with high value interactions. Meanwhile, on-chain games have a mostly self-contained economy, with low value interactions. Enterprise applications are again mostly self-contained, yet high value. Some NFT marketplaces bridge collections across many domains, with most pieces sold at a rather low value.

As infrastructure matures, product-market fit will emerge. Surprises are never out of the question, yet thinking about the options from first principles should prepare you well enough.