The design space for blockchain has recently been opened: we no longer just have “monolithic” blockchains, but also:
- “Modular” blockchain
- Data availability and consensus layer
- Rollups and execution environment
- Application-specific chains, and more
With so many options, the most important question is not which design is the best choice for a decentralized platform, but which design gives a decentralized platform the best chance of competing with a centralized platform?
Due to the different use cases of blockchain, it is impossible to find a one-size-fits-all answer. This article will focus on application chains as one of the most feasible and underexplored ways to address this challenge. It will delve into how application chains facilitate the creation of truly novel products and features, as well as explore the sovereign benefits they offer. While app chains have surfaced in various cryptocurrency verticals like DeFi and gaming, this article focuses on DeFi app chains.
Advantages of Appchain
When we consider the various architectures mentioned above, it’s not immediately clear which options best address important UX pain points while maintaining sufficient decentralization. Each approach has trade-offs, but the application chain offers a crucial unique advantage – sovereignty.
From a technical point of view, sovereignty can be considered vertically integrated. This means that application developers can control and customize each layer of the blockchain stack to meet the specific needs of their applications, in a way that allows for optimal integration between each layer.
Example: Apple’s vertical integration
In addition to technology sovereignty means less reliance on middleware solutions, it also exempts applications from competing for block space with unrelated or competing applications, as well as reducing reliance on development roadmaps and governance for any other project. These benefits are especially compelling for projects that have reached a certain scale, require more throughput, require frequent upgrades, and/or want to anticipate how the platform they are building will change and evolve.
Technical sovereignty also allows application developers to unleash their creativity by experimenting with different consensus models, custom node requirements, state models, and other exciting features, which will be explored by example in the next chapters. Just as many new L1s have emerged specifically to make changes to the core architecture that lack social consensus and cannot be implemented on existing chains, application chains bring the same level of optimization to individual applications.
In the social aspect, sovereignty is fundamentally about individual applications having the ability to put their values first and deal with the set of trade-offs that make the most sense to them in an extremely specific manner. It allows communities to control their own destiny and even take actions such as hard forking blockchains, whether for political or technical reasons. Most projects willing to undertake the technical feat of building application chains are primarily for technical reasons, but the need for social sovereignty should not be underestimated. There are applications that choose to enter this horizon now and in the future simply because they feel that other ecosystems do not fully share their values.
Trade-offs and concerns
Appchains are not the perfect solution for all projects and ultimately represent a view of the trade-off between what blockchain and applications should do. Many critics argue that (1) loss of synchronous composability and (2) liquidity fragmentation are reasons why the application-chain approach is not suitable for DeFi, however these concerns are not so straightforward. Just as liquidity on GM L1 has been concentrated in a handful of popular applications, the same could happen within the ecosystem of DeFi application chains. Rather than users switching between DEX chain, lending chain, perps chain, liquidity staking chain, etc., all these functions are eventually integrated into the core products of several highly liquid DeFi application chains, greatly reducing the problem of fragmentation. It’s also worth noting that while the Ethereum mainnet remains the center of gravity for DeFi, its rollup-centric scaling roadmap has its own implications for synchronous synthesis and liquidity fragmentation.
While application chains are by no means unique to the Cosmos ecosystem, many application chains choose it as their “home” because of the robustness of developer tools and the asynchronous composability primitives that don’t yet exist for an ecosystem like Ethereum.
User experience pain points
When it comes to the current state of user experience for most DeFi projects, here are some pain points:
This list isn’t exhaustive, but it does begin to paint a picture of how much DeFi applications need to do well to really stand a chance of competing with CeFi. The next section will highlight some of the DeFi application chains that are addressing some of these issues.
Convincing features and experimentation
The best way to fully grasp the power of application chains is to explore some of the most compelling and innovative user experiences being built today, most notably Osmosis, Mars Protocol, Penumbra, and dYdX.
Osmosis is an emerging mobility hub within the applicationchain DEX and Cosmos ecosystems. Osmosis was originally inspired by co-founder Sunny Aggarwal’s blog post called DAOifying Uniswap Automated Market Maker Pools, with the core idea of bringing the customizability and sovereignty of Cosmos to the world of AMMs. Today, the protocol allows users to create liquidity pools with unique and changeable parameters, allows experimenting with different kinds of bonding curves, multiple asset pools, etc. Hybrid liquidity models for experimental order book matching and centralized liquidity pools are also underway.
As a pioneer in the world of DeFi application chains, Osmosis has introduced a number of innovative features to the market, including super-flow staking that provides an elegant solution to the incentive problem of having to choose between staking yield and DeFi yield. Users can stake any LP share token containing $OSMO, which incentivizes contributions to on-chain security while also driving additional value back to the community. This capability is possible because the Osmosis chain is able to identify application-level assets and use them in PoS consensus, and with more features and asset types coming online, there’s no reason to disadvantage using it for other similar use cases.
When it comes to creating a CEX-like user experience, Osmosis is working to offer margin trading and lending as part of its core offering. The team is currently working with Mars Protocol to integrate the loan directly into the Osmosis trading engine, which will enable phased clearing, cross-collateralization of assets and the use of Osmosis LP tokens as collateral for margin trading. Osmosis author Steview Woofwoof succinctly outlined the benefits of this design in a Medium article earlier this year:
“Phased liquidation ensures that unexpected fluctuations do not immediately catastrophically liquidate leveraged positions. Efficient cross-margin means that because the DEX and lending engine are so tightly integrated, Osmosis (unlike stateless DEX) can track all your collateral from different assets and pools block by block, so it can basically act as a large collateral pool against all your lending and margin positions.
Another benefit of establishing a lending protocol in a DEX is that it eliminates the need for oracles. In fact, Osmosis’s price feed may be machined by predictions for use by other platforms. Of course, it may still be useful to use an external oracle for backup or to add security to certain types of attacks (price manipulation, dDOS, etc.). ”
Osmosis is also exploring several creative ways to deal with MEV on its DEX, which are significantly easier to implement as an application chain, including:
Threshold encryption: User transactions are encrypted before being broadcast to block producers, and decryption and execution are only allowed after blocks have been voted on and finalized.
Fee discrimination: Charging different fees for different types of transactions (i.e. making arbitrage transactions more expensive).
Skip: Build Flashbots-like functionality into the base protocol (i.e. auction sessions within a block).
Internalize MEV: Build arbitrageurs within the protocol, run at the beginning of each block, and hand over the revenue to the maker of $OSMO.
Mars is a cross-chain credit protocol being developed by Delphi Labs and a pioneer in a new DeFi original technology called “contract-to-contract” (C2C) lending. Initially deployed on Land, the Mars team later took a step back, re-evaluated their product strategy, and decided which ecosystem to invest in going forward. After investigating the entire L1 and L2 situation, the Mars team finally chose a unique Outpost & Hub model that allowed them to enjoy the benefits of deploying to existing L1 and the benefits of applicationchain sovereignty.
Outposts is an instance of Red Bank, a non-custodial and over-collateralized lending protocol that is deployed on a variety of different chains, allowing for atomic synchronous synthesis with other applications on the same L1. This is also the source of liquidity for C2C lending, as authorized smart contracts can borrow from Red Bank without the need to submit collateral. The current plan is to build the first Outposts on Osmosis.
Mars Hub is an application chain with two key functions:
- Manage all outposts (including voting on which contracts can be approved for C2C lending).
- Revenue is collected from all outposts and distributed to stakers and validators of $MARS
So far, the cross-chain strategy of most DeFi protocols has been to redeploy on all popular L1s, or to build an application chain that requires bridges to connect to other chains. This Hub & Outlet model attempts to achieve the best of both worlds by combining with the existing highly liquid DeFi ecosystem and simplifying governance and the accumulation of token value – both of which should mitigate the fragmentation problems suffered by some of the major approaches.
The team at Delphi Labs places a strong emphasis on building the best user experience for DeFi, and once live, Mars will be one of the most ambitious attempts to date to compete with the user experience of centralized exchanges. The development roadmap includes a number of other exciting new features such as the Rover Credit Account, which will enable users to trade a variety of DeFi products with leverage from one account and clearing threshold, while also replicating the “sub-account” experience that many people enjoy on a central exchange.
Penumbra is a cross-chain shielded asset pool and application-chain DEX that leverages privacy to improve the user experience for on-chain trading and market making. The vision for the project stems from frustration with the lack of adoption and interest in privacy-preserving tools like Zcash, and the desire to build a product that is better precisely because of its privacy. However, as the past few years have shown, privacy has proven to be a much harder issue than many initially thought (especially when building a private DEX).
There have been many well-funded attempts to build ways to do private computing on the blockchain, yet Penumbra’s team is not happy with any of the existing methods. Instead, they decided to ask a more subtle but extremely important question.
If useful blockchains revolve around a public shared state, how can we build a private ledger with useful functionality?
For Penumbra, the concept of a public shared state is at the heart of what makes blockchain useful precisely because it means that anyone who wants to use it only needs to coordinate with the blockchain itself, not with an off-chain counterpart. Because of this, they argue that while previous attempts to design privacy-preserving L1 and Rollups may address privacy concerns, they do so in a way that severely limits the level of meaningful interaction users can have with public shared presence.
Ideally, private computing would be conducted in a way that protects the privacy of individuals, while also allowing for transparency of important aggregate data. However, it turns out that building a system that can manage these trade-offs requires a state model that is fundamentally different from anything currently on the market, so the Penumbra team has been building one from scratch. Furthermore, while they are currently very intentionally focusing only on trading and market-making use cases, the team’s ongoing research and design work could have broader implications for privacy and scalability in other contexts.
Privacy on the blockchain is achieved by transferring user data and execution off-chain: on-chain user data with cryptographic promises to data and plaintext execution with zero-knowledge proofs of the correctness of state transitions. This requires a different state model. Rather than a global, mutable state-centric state model where valid transactions change during execution, the concept of immutable, composable state fragments that each transaction consumes an input state fragment and produces an output state fragment (which is conceptually similar to Bitcoin’s UTXO model). This allows state fragments to be replaced with commitments to these state fragments, and transaction content can be replaced with proof of valid state transitions. The problem with this approach, however, is that since execution moves off-chain, accessing the shared state is no longer possible, as the exact final output of the proposed state transition must be taken as input to the transaction. For example, a DEX transaction will need to freeze the exact status of the AMM reserve and the exact output price before submitting the transaction to the chain.
Unique State mode
Penumbra’s state model is primarily designed to facilitate the interaction of private and public shared state, and it is achieved by using an actor model that explicitly separates off-chain computation, which is private and deals with per-user state, and on-chain computation, which is public, which deals with shared state.
In the Actor model, the user creates a message (not a transaction), encrypts it, and sends it to the smart contract. Each smart contract then executes once in each block and takes as input all the messages sent to it in that block, allowing transactions to be batched or using any other type of custom application logic. This also has some nice scalability advantages, as each contract is executed only once, so the computational cost can be diluted across all transactions in the block. The validator will then decrypt some information about the total batch before executing the transaction asynchronously and producing a common output.
This asynchronicity is achieved by minting a private NFT that records the intermediate state of execution and models future states. Once the contract responds with an output message, the private NFT is consumed and modeled to prove the correct future state, at which point the message from the contract is minted for the executed private output. The trade-off here is that execution can happen on multiple blocks.
To protect the privacy of principals and the responsibility of validators, the Penumbra team had to take a new approach to designing staking. Instead of treating “unsecured” and “secured” as distinct states of the same staked token, secured staking is recorded as delegated tokens. These tokens represent a percentage share of the validator delegate pool, just as LP tokens represent a share of the liquidity pool. While the size of each validator’s delegate pool is part of the public chain state, delegate tokens are kept private by being exchanged with each other and residing in multi-asset shielded pools where all value on Penumbra is recorded. Finally, staking rewards are calculated by tracking the exchange rate between staking tokens and delegated tokens, which has the benefit of good tax efficiency, as only unstaking is a taxable event.
Ultimately, the bet Penumbra is making is that privacy is actually an integral part of the trading experience, and even more, and the customization they make will drive better execution, as enabling private strategies means getting more sophisticated and well-capitalized players into the space, which will lead to better liquidity, better pricing, and less slippage. Our vision is to create a user experience that offers more privacy than CeFi while having the open and permissionless benefits of DeFi.
After becoming the largest application deployed by Ethereum L2, perpetual exchange dYdX recently announced that they plan to build V4 as an application chain. In official communications following the announcement, “a unique combination of decentralization, scalability, and customizability” was cited as the main reason for the move, however, it is worth digging deeper into each of these reasons.
In the face of regulatory resistance, especially in the United States, many DeFi projects are forced to face the possibility of a serious blow, and the resilience of their projects in the face of such actions. dYdX V3 is currently deployed on Ethereum L2 (StarkEx), and while I won’t get into the details here, we’ve written a lot about the challenges surrounding fully decentralized rollups. While solutions are being actively researched and developed, projects that require near-term solutions and predictability may not be able to wait for the fully decentralized rollups vision to materialize.
Given that dYdX V3 currently processes about 10 transactions per second and about 1,000 orders/cancellations per second, the team surveyed the entire blockchain space to find a chain that would allow them to increase throughput by orders of magnitude. Because they couldn’t find such a chain, they adopted a more creative solution: a decentralized off-chain order matching network. Recognizing that dYdXChain only needs to reach consensus on which transactions have been settled, rather than on all orders, will be an unlock for truly superior scalability on V4.
On a technical level, this design is driven by the fact that application chaining allows for custom node requirements, such as requiring validators to help run oracle networks or bridging infrastructure.
In an interview with Bankless, dYdX founder Antonio Juliano shared his grand vision for a fully vertically integrated product and user experience, which includes not only building a basic L1, but also building custom execution modules, an off-chain order network, an oracle network, an alchemy-like indexer, a mobile app, and a custom wallet. Juliano himself described the effort as “very risky”, but he also made it very clear that he considered it the best option to create the highest quality user experience for dYdX products.
For all the benefits and innovative experimentation highlighted above, it’s important to acknowledge that building an application-specific blockchain is technically much more challenging than deploying an application as a smart contract, or even in a dedicated execution environment (rollups, subnets, etc.). A superior user experience is not only a way for decentralized products to beat their centralized competitors, but also an integral part of building a moat in an open-source, permissionless world.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/how-to-design-application-chains-in-defi/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.