Original source: Delphi Digital
introduce
introduce
Delphi Labs is Delphi's protocol research and development department, with a team of about 50 people working on building new Web3 primitives. Previously, the team focused on researching and developing protocols on Terra. In the wake of Terra's debacle, Delphi Labs faced a big decision as to where to focus our builder efforts.
As Terra's debacle shows the potential downside of building on the wrong platform, we want to make sure we take our time, learn from our lessons, and make the right choices about where we'll be trying to move forward. Our goal is to look at each major L1/L2, current or upcoming, understand their pros and cons, and find out where the next most exciting DeFi frontier lies.
Before we get started, it's important to emphasize that this article should not be taken as an absolute judgment on which ecosystem is best, but rather on ourBackground of specific backgrounds, visions and valuesNext, which ecosystem is most suitable for our subjective analysis.
In the first section, we outline these design constraints, and the essentials of the platform that we wish to optimize. In the second part, we analyze each platform against these requirements and explain our final decisionChoose the Cosmos Ecosystems reason.
mdnice editor
Part 1 - Delphi Labs' own design constraints
While we try as much as possible to start from scratch, the LabsExisting background, vision and valuesmdnice editor
Born for DeFi
There are many different kinds of Web3 protocols and products, each of which faces different design constraints when choosing the right platform to build on. Delphi Labs' R&D efforts are primarily focused on DeFi protocols, as this is the vertical we are most interested in and fits best with our team's existing background and skill set.
mdnice editor
DeFi Repackaged
We don't think the ultimate DeFi user experience is every function (spot trading, lending, leveraged trading, yield farming, derivatives, etc.)use a separate protocol. We believe this will be repackaged into a single, vertically integrated UX that looks more like CEX.
Specifically, the DeFi credit lines provided by Mars can facilitate the creation of "universal DeFi credit accounts" that users can use to leverage and interact with whitelisted DeFi applications with a single account-level LTV.
This replicates the “sub-account”-like experience on centralized exchanges while maintaining the advantages of decentralization such as non-custodial, censorship-resistant, and integration of key DeFi primitives. This requires speed and synchronous composability (we believe an experience based on asynchronous cross-chain contract calls will never be able to compete with CEX), and a vibrant ecosystem that facilitates integration and liquidity.
mdnice editor
Trends we see in the field
There are two extreme views on the endgame of cryptocurrencies. The first is that all activities will be centralized in a common execution environment (i.e."Standalone" mode). The second is that there will be a large number of specialized execution environments, each with its own designs and trade-offs (i.e."Multi-chain" mode). Clearly, there is a wide variety of views between these two extremes.
Ultimately, we believe the key trade-off here is between the synchronous composability offered by a single machine and the benefits of specialization. Our view is that projects will increasingly choose to specialize, with the result that the crypto space will be multi-chained. In this section, we explain why we think this is the case.
We believe that specialization has three main benefits:mdnice editor
Lower/more predictable resource costs
Our underlying assumption is that the demand for block space, similar to the demand for computation, is elastic; the cheaper block space is, the more different types of computation can be moved on-chain. This means that no matter how fast the monolithic chain is, the demand for block space can outstrip the supply, and the cost will rise over time.
image description
ETH transfers over $500/tx during Otherdeeds minting
Collectively, this means that dApps on monolithic chains will:
a) Costs increase over time as more activity moves on-chain
b) face greater uncertainty in terms of resource costs, as it depends on other dApps' demand for block space
While some dApps may be willing to accept these trade-offs in exchange for the benefits of rapid prototyping, synchronous composability, and ecosystem network effects, we believe this trade-offDoesn't make sense for many applications.
An example of this is gaming, which is an area we're particularly excited about. As games put more and more of their economies on-chain, and ultimately the game logic itself, certainty around resource costs will become even more important.
If the popular NFT causes the tx cost to soar or the chain to stop due to mint, users cannot continue to play this game. That's a hefty cost, especially considering the game is largelyisolated ecosystem, and gain very little from composability.
While monolithic chains can continue to scale the block space vertically, this won't really solve the problem, as the demand for block space will continue to increase and applications will still compete with each other for that block space. A dedicated application chain provides afree market solution, allowing the block space to be used by the applicationHorizontal decompositionCustomizability
Customizability
All applications launched on a monolithic blockchain inherit and must accept a series of design decisions, including the platform's consensus model, security, runtime, memory pool, virtual machine, etc. In contrast, an application-specific chain can be customized across all components of its stack, optimized for that specific application or class. As Paradigm'sDan Robinson and Charlie NoyesAs told to us:
“Blockchain protocol design is ambiguous. There is no single “right” conclusion about scalability or security. Properties like trusted neutrality cannot be fully defined. Today, application platforms are static about these design decisions set point"
To see how customizability can be beneficial, we can look at a few examples.
Optimization for space trade-offs:An application-specific chain can adapt its scalability trilemma to the needs of that application, rather than accepting a given platform's decentralization-security-scalability choice. Games may be less concerned with decentralization/security, and thus can be run by smaller and/or permissioned validator sets with higher hardware requirements to improve performance. For example, DeFi Kingdoms (Crabada) started out as a smart contract dApp on the Avalanche C-Chain and eventually moved to its own subnet, sacrificing security for cheaper gas.
State machine customization:
The platform can customize all aspects of its state machine, including mempool, transaction propagation, ordering of block tx, stake reward distribution, execution model, precompilation, fees, etc. A few examples:
THORChainThe order of swaps on is determined by the swap queue logic baked into the state machine. Swaps that generate the highest fees are always at the front of the queue. THORChain nodes do not have the ability to reorder exchanges.
InjectiveThe order book can be settled through a batch auction that automatically runs each block to minimize MEV.
OsmosisThreshold encryption will be added to mitigate "bad MEV" (e.g. sandwich attacks), while internalizing "good MEV": the protocol will be able to arbitrage its own pool and funnel profits to OSMO stakers.
OsmosisAllow users to pay tx fees in any token transaction on their DEX. It also allows it to be bundled into exchange fees, further simplifying the user experience.
dYdXCharge swap fees on transactions instead of gas fees on txs.
Custom payment mode for verification:
Customized MEV solutions:
Performance/scalability optimizations:Solana, Sui, Aptos, Fuel, Injective, Osmosis, Sei, etc. utilize parallel execution to process transactions that do not involve the same state (i.e. separate transaction pairs/pools), greatly improving scalability.
Validators undertake additional services
NFT-focused chain Stargaze has validators that support IPFS pinning services, making it easier to upload NFT data on IPFS.
Injective includes a validator-secured Ethereum bridge, ensuring that the economic security of the bridge is the same as the economic security of the chain.
Mempool/Consensus Customization
Sommelieris testing a novelDAG-based memory pool design, able to provide availability and causality guarantees and reduce the work that consensus algorithms need to do; this breakthrough was first adopted by fast monoliths such as Aptos and Sui.
dYdXIt is running the order book matching engine to make its nodes perform calculations off-chain and settle transactions on-chain. This enables greater scalability.
ABCI++is a tool that adds programmability to every step of the Tendermint consensus process. Celestiaprivacy。
privacy
Secret Network is a general-purpose default private smart contract platform that leverages hardware to keep data secure and anonymous by using Intel SGX enclaves in a Trusted Execution Environment (TEE).
Penumbra is another blockchain that is private by default, but focuses more on DeFi and governance, and uses cryptography with Secret Network's privacy reliance on hardware (Intel SGX). Penumbra uses Tendermint and connects via IBC, but replaces the Cosmos SDK with its ownCustom Rust implementation. They are integrating threshold encryption directly into consensus which will allow them to do things like shielded swap.
Value Capture:In any blockchain, applications pass value to the underlying protocol in the form of fees and MEV, or more precisely to the underlying gas/fee tokens. In the long run, we thinkLargest dApp could be bigger than any single L1mdnice editor
sovereignty
A key difference between smart contracts and Lisk is that the latter are sovereign while the former are not. The governance of smart contracts ultimately depends on the governance of the blockchain. This introduces platform risk, new features/upgrades on the underlying blockchain may harm the user experience of smart contracts, and in some cases even break them.
mdnice editor
Disadvantages of specialization
cost
cost- Launching a standalone chain is more time-consuming/expensive than simply deploying smart contracts on an existing chain, requires more development skills, convening validators, and adding additional infrastructure complexity (index retrieval, wallets, browsers wait) .
Lack of synchronous composability- On a monolithic chain, all applications run on a shared state machine, thus benefiting from synchronous, atomic composability. Interchain infrastructure cannot currently facilitate this, and in any case would introduce additional trust assumptions.
In terms of cost, while private chains have never been as easy to deploy as smart contracts on existing chains, we believe that as the technology matures and development projects such as Interchain Security come online, the gap has narrowed significantly and is likely to continue to narrow.
The real downside is losingsynchronous composability. We’ve already seen the benefits of the growth of DeFi driven by token rehypothecation on Ethereum, and there may be a long list of undiscovered permissionless compositional use cases.
While this is important, there are two important counterarguments here.
First, we believe that only a few types of applications really benefit from synchronous composability. These are primarily DeFi use cases for which rehypothecation of tokens is arguably crucial (e.g. yield farming). That said, even in DeFi, it can be argued that synchronous compositionality is really necessary, as evidenced by the success of dYdX. For most other DApps, we believe that asynchronous compositionality is feasible as long as there are powerful cross-chain tools to port assets and make the user experience of interacting with different DApps seamless.
Second, specialization does not necessarily mean deploying a single application on a chain, but rather a cluster of applications that work well together or facilitate specific use cases. For example, while Osmosis is often seen as an AMM chain, it is developing into a DeFi chain with many different dApps deployed on it (money market, stablecoin, vault, etc.). We believe that applications that benefit from composability will naturally gravitate towards clustering on specialized chains, effectively allowing dApps that require it"composability."composability.
mdnice editor
Cross-chain architecture
To sum up, we believe that while the DeFi application layer is likely to be re-aggregated, the blockchain layer will be further fragmented, with dApp teams/communities increasingly choosing to deploy their own proprietary application chains. However, we think it is unlikely that each of these chains will spin off its own DeFi ecosystem because: a) it forces each chain to rebuild the entire DeFi ecosystem, which is a difficult task; b) leads to liquidity Fragmented and sub-optimal user experience.
Instead, we believe there will be some DeFi-focused hubs, with specific appchains deploying their tokens/economy on one or more of these DeFi hubs. An analogy we use to visualize is that specialized application chains are suburbs, and bridges provide the transport layer connecting these suburbs to financial hubs in city centers (i.e. DeFi central chains).
Given that composability is critical to the aforementioned re-bundled UX experience, and not wanting to bet on one chain, we expect the winning DeFi dApp to be deployed on several winning DeFi hubs, increasing cross-chain Liquidity/branding/UX network effects. So we want to make sure we spend some time exploring the architecture and which ecosystems facilitate this the most.
As of now, cross-chain applications follow two main approaches:
Independent deployments that do not communicate with each other (e.g. Aave, Uniswap, Sushi, Curve). This means that a dApp exists natively on each chain it is deployed on and can be synthesized synchronously with all native primitives. However, this also leads to liquidity fragmentation and poor user experience as traders/borrowers receive sub-optimal execution and LPs have to manually move capital to optimize utilization.
Deploy a unified application chain on which all liquidity resides (e.g. Thorchain, Osmosis). This is more capital efficient, but means that it cannot be synchronously combined with dApps on other chains.
Delphi Labs is currently exploring a third way, where application instances will be deployed on multiple chains (outposts), but connected by utilizing a coordination layer to facilitate communication and liquidity distribution between outposts. You can read more about how we think this third strategy might work on Mars here[1].
mdnice editor
Platform requirements
In summary, our constraints are:
We focus on DeFi applications
We believe DeFi will be repackaged into an integrated experience
We believe that the world will be more and more chained, and DeFi applications should structure themselves so that they can be deployed locally on multiple chains.
Based on these constraints, there are some key platform requirements:
speed:While it will never be as fast as CEX, ideally it should be as close as possible. The block time will determine how bad the experience is compared to CEX. Faster block times improve capital efficiency by allowing faster oracle updates, liquidations, and higher leverage. While this is not required, faster block times and high throughput can also enable on-chain order books, providing users with a better transaction user experience.
ecosystem:Aside from being non-custodial and permissionless, the biggest advantage of a DeFi super app over a CEX is composability and the number of integrations it can offer. While CEX is limited to its own products, the app can integrate with any DeFi primitive, allowing users to span margin LP positions, vaults, farming, staking positions, NFTs, and more. As part of this, on-chain liquidity is also important as it directly affects the trading experience.
While speed and ecosystem are the main requirements, there are several other factors that are important when choosing the right platform:
Decentralization:The main difference of Super Apps compared to CEX is decentralization, i.e. non-custodial, permissionless and censorship resistant. Decentralization is a heavy term, but ultimately any chain we deploy needs to have strong security and liveness guarantees. Many Rollups and chains achieve low latency, but it usually comes at the expense of one or both. Our assessment of centralization is subjective, but ultimately considers factors such as points of failure of centralization, resilience to regulatory attacks, governance/stake concentration, number of nodes, number of independent entities contributing to development, etc.
Cross-chain interoperability:In order to realize the vision of cross-chain architecture described earlier, the chain needs mature, reliable and trust-minimized cross-chain messaging and asset bridge infrastructure. Without this, instances would not be able to communicate with each other, or could only do so while exposing the entire system to additional risk.
Technology Maturity:As we’ve seen with Solana and other chains, especially those based on brand new, experimental innovations, immature technology leads to bumps in the development process and risks like downtime for early adopters. Downtime is very problematic for an application characterized by leverage (since liquidation needs to happen in a timely manner), and adding technical risk is generally not advisable when building an already complex protocol.
Code portability:mdnice editor
mdnice editor
ecosystem comparison
When looking at the blockchain space, we consider a variety of different ecosystems, where an ecosystem may consist of clusters of multiple domains, such as Cosmos zones, Avalanche subnets, or Ethereum Rollups, or standalone chains (such as Near or Solana ). While this may seem like comparing apples and oranges, it seems like a natural approach when narrowing down your options.
We then compared each option based on the factors given in the first section, and a summary of our comparisons can be found in the table below.
We'll expand on some of the motivations behind our rankings as we take a closer look at each ecosystem.
Ethereum L1
Let's start with the Ethereum base layer. Today, the Ethereum base layer fulfills the greatest need for block space and liquidity. As Ethereum shifts to a Rollup-centric world, more rollup activity will focus on Ethereum, further cementing Ethereum’s position as a liquidity hub.
ecosystem
ecosystem——Ethereum L1 has the largest and most developed dApp ecosystem, as well as the highest liquidity, allowing a large number of potential credit account functions to be integrated.
EVM Network Effectsdecentralized
decentralized- Ethereum is arguably the most decentralized L1 of all major carriers. Ethereum has multiple clients developed by independent teams and has the most diverse clients in L1. It also has the highest economic security, it is the most proven, and it has a social consensus that supports minimal changes at the base layer.
The biggest disadvantage isspeed/cost. Blocks of around 12 seconds make it extremely difficult to provide high leverage and generally hurt the trading experience, especially when inclusion in these blocks is often competitive. High gas costs drive an inefficient liquidation model that works against users. All of these lead to a poor user trading experience.
While EVM currently dominates the smart contract development market, we have noticed increasing competition in the field of virtual machines such as SeaLevel, CosmWasm, MoveVM, and FuelVM. We expect this competition to put the network effects of the EVM to the test.
Rollups
As a base layer, Ethereum sacrifices speed for elasticity, aiming to provide a fast user experience through Rollup.
Rollups promises Ethereum-level security at a lower cost and faster user experience, but this always comes with trade-offs. Unlike L1, no one knows the final order of txs until consensus is reached,Rollups can have a single privileged actor(known as the sorter), has full decision-making power on the order of txs. This allows rollups to strike a balance between user experience and decentralization, relying on L1 censorship resistance and finality while providing instant confirmation.
While this balance is more useful for the transaction experience we hope to provide, relying on a centralized orderer is not ideal as potential orderer outages could break the user experience. In the case of Mars, outages pose a significant risk, as the protocol could accumulate bad debts during the downtime. While Rollup plans to decentralize these sorters:
(i) Almost all teams are delaying it in their roadmap, (ii) Decentralized sorters will increase the delay of confirmations that can be offered to users, due to the requirement of a quorum of a group of sorters instead of a single sorter. inherent delay.
There are also issues with interoperability. Rollups have exit times, which add complexity to any low-latency bridge (requires evaluation and risk of coverage challenges). In general, cross-chain infrastructure lags behind alternatives, causing Rollup to currently be considered unsuitable for what we consider to be the best cross-chain architecture.
EVM ORU
The ability to scale execution of shared state is related to the choice of VM and execution model. First-generation ORUs on Ethereum, such as Optimism and Arbitrum, value EVM compatibility/equivalence. While they can leverage existing Ethereum tools, they also inherit the limitations of geth.
For this reason, we are unlikely to see them reach tps orders of magnitude higher (≈50 tps) than L1 geth forks such as Polygon or BSC.
In fact, this partly explains why Arbitrum is pursuing the vision of multiple Rollups, with Arbitrum One and Arbitrum Nova being the first batch. In a multi-rollup world, bridging plays a key role. Unfortunately, the design space for Rollup bridges is still immature.
Existing bridge functionality does not go beyond simple token transfers, L1 call data is still expensive (although future Ethereum developments such as EIP-4488 could alleviate this problem),ORU latency will continue to be a challenge for general purpose cross-chain applications.Again, this is a problem for us given our views on the best cross-chain architecture.
On the positive side, a major advantage of EVM ORUs is that they can easily leverage Ethereum's liquidity and community to bootstrap their DeFi ecosystem. Optimism and Arbitrum already have billions in TVL, with blue-chip protocols like Aave, Uniswap, Curve, Synthetix, and GMX driving user adoption.
On the other hand, the infrastructure for Rollup is still immature. While ORUs have large TVLs, almost none (including Optimism and Arbitrum) have permissionless fraud proofs in production and thus do not minimize trust. While we have every confidence that Rollup will work, it will require significant engineering effort and time.
While EVM compatibility makes sense for ORU given the portability of the existing Ethereum ecosystem, it does not benefit all existing protocols that may wish to pursue a cross-chain strategy.
We also see the potential for alternative L1 and ZK rollups to attract the use of ORUs as alternative Rollup technologies develop and the risk of new builders with no EVM experience entering the field.
Therefore, while the relatively high scalability, TVL, and capacity are attractive, thePoor connectivity, centralization risk, and an uncertain futurecollectively hinder the adoption of this option.
ZK Rollups
Like many, we believe that ZK proofs are the core pillar technology of the blockchain end game. At the heart of every scaling solution is cost-effective validation. ZK proofs allow anyone to prove the complete integrity of execution (without additional assumptions), making them useful as a safe and efficient bridge between discrete systems. We observe this today in the form of ZK-rollups.
Incentives to push the boundaries of zero-knowledge technologies have increased dramatically in recent years. Still, it is difficult to predict how long ZK rollups will gain significant market share.The ZK field is still in its infancy, some players are in various stages of preparation - mainly Starkware, zkSync and Polygon.
Starkware has been preparing ZK technology for some time, but offering their StarkEx product as a software vendor. StarkEx is not an open general purpose platform as we would expect in this space, but the technology itself is excellent[2], as evidenced by its adoption by some of the most used dApps such as dYdX, Immutable, etc. However, dYdX recently announced that they will be moving from StarkEx to Cosmos Lisk, mainly due to concerns about decentralization.
StarkNet is a recently launched permissionless open platform based on Starkware technology. Production ready and provides simultaneous composability with other StarkNet dApps. But just launched, its community, infrastructure, and DeFi ecosystem are immature — for example, the canonical Ethereum known as StarkGate<>There are deposit limits on the Starknet bridge (built by the Starkware team), and StarkNet has negligible liquidity (~650 ETH). Like other Rollups, StarkNet relies on a centralized orderer and plans to decentralize over time. [3]
Given that applications built in Cairo (Starkware's language) offer limited portability, this poses an adoption risk should this prove to be a losing bet. Nethermind's Warp team is developing a Solidity to Cairo translator, so Solidity may be used instead of Cairo, which of course provides more options and tools.
Many ZK-EVMs [4] such as Polygon Hermez, Scroll and zkSync 2.0 are in speed<>Different tradeoffs are made for EVM compatibility. While it's exciting to see their progress, they're still unreleased products and there's uncertainty about the timing of their future roadmap.
Finally, we note that all ZK rollups rely on a highly complex new technique that is truly understood by only a very limited number of domain experts. We believe this increases the likelihood of software implementation bugs and other unforeseen circumstances that could negatively impact complex DeFi dapps and make it harder to reason about their progress.
While we appreciate the potential of ZK technology to be the ultimate technology and will closely monitor its progress, the concerns above, as well as the general issues with Rollup, lead us to decide not to build there at this time.
Modular (Celestia Rollups)
As we outlined in Part 1, we see the future as multi-chain, with many utility chains, universal chains, and hybrid chains, each with different tradeoffs and customizations. This facilitates modular blockchain development stacks, such as those offered by Cosmos’ Tendermint and Polkadot’s Substrate. These provide a reusable and customizable collection of components for creating new blockchains through the SDK.
Celestia approaches modular blockchains from a different angle, decoupling execution from data and providing only the base layer for data availability and ordering. This enables Celestia to provide security for Rollup/AppChains in a highly scalable manner. It also means Celestia is only focusing on one element of the blockchain stack, which may be more effective than a magic glue approach.
This solves one of the major problems of the universe --Each chain is required to have its own set of validators-- This requires a lot of time and effort and is not feasible for many dApps. It also splits the consensus security of each chain, resulting in a low security budget at the end. Interchain security from Cosmos is another option, but it is not permissionless; requires mutual agreement of the Hub and consumer chains, and is not a scalable solution; Hub validators require additional resources to verify consumer chains. While this might be a good temporary solution, it's unlikely to be the end result.
The user-facing side of the Celestia network is its executive layer; notable ongoing projects are Cevmos, Sovereign Labs, and Fuel V2. Fuel V2 seems to be the closest project to the finish line, but it's still very early days. Fuel V2 uses the UTXO data model and a brand new virtual machine that promises fast and scalable execution. While we like their design choices and will be keeping an eye on them, they pose technical risks that we believe are too great for the applications we might be working on.
As with any new ecosystem, the cost of migrating to a new and largely untested language coupled with the new paradigm of UTXOs is considerable. We also have path dependencies on specific execution environments, and another Celestia Rollup in the future may be more successful at attracting adoption. There is also a risk that future Ethereum developments (such as EIP-4844) will reduce the need for Celestia's primary data availability use case.
While this sounds pessimistic, we are actually very optimistic about the future of modular blockchain networks.We see Celestia’s Sovereign Rollup as a potential successor, or possibly the ultimate scaling path for Cosmos-based chains.While these technologies are not ready now, they represent a huge potential mid-term solution while also preparing the way for a modular future. Celestia is certainly an ecosystem that we will be watching closely.
Polkadot
Polkadot's mission has always been to have a heterogeneous execution environment (parachains) with shared security. While this was a unique goal of Polkadot when it started this mission, given the existence of Rollups, this is no longer the case.
That said, one of Polkadot's unique strengths is the years of hard work and dedication that went into developing its cross-chain messaging protocol, XCMP (similar to Cosmos' IBC). XCMP is not fully functional yet, but once it is out, it will play a key role in interoperability to create cross-chain applications.
Substrate and Cumulus are SDKs provided by the Polkadot team for creating parachain-compatible blockchains. To be a parachain, it does not need to be built with Substrate/Cumulus, nor does it have to force a chain created with Substrate to be a parachain.
However, only parachains can interoperate. Due to the maximum number of parachain slots, only successful bidding through the auction process can become a parachain. This means that Polkadot's interoperability requires sacrificing sovereignty, and its parachain status can theoretically be revoked at any time. In contrast, Cosmos’ approach of providing optional interoperability modules without any connection to a central chain is the approach we prefer.
Polkadot scores highly for decentralization, with 996[5] validators, a diverse and thriving developer community, and multiple independent clients[6].
Despite the technology and large development community [7], the user adoption rate on Polkadot is not impressive.
Currently, the top three parachains — Acala, Moonbeam, and Parallel — have a combined liquidity of $150 million, far behind their competitors. This has also taken a hit recently as the largest stablecoin, aUSD, lost its peg following a free minting bug on the Acala parachain.
In terms of scalability, we mark Polkadot as ahead of many ecosystems, but behind Ethereum and Celestia. While Polkadot employs scaling techniques such as data availability sampling and dispute protocols, validators are still interested in performing state transitions of parachains (or parathreads), which limits their scalability. The same motivation applies to our scalability ranking for Near.
Overall, despite the positives, we don’t think Polkadot has any significant advantages over Rollup for Cosmos or DeFi dApps, and it does have some relative disadvantages.
High-speed monolithic chains (such as Solana and Now Sui, Aptos, etc.)
The everything-in-one-place approach that Monolithic takes is certainly attractive to developers. Rather than creating a new application chain, it is much easier to build a dApp as a collection of smart contracts on multiple levels: the development cost of writing a smart contract is much lower than writing application logic at the chain level; Contracts do not need to bootstrap new validators; existing wallets and infrastructure can be used; and it is generally easier to attract users when building on existing chains by leveraging existing communities.
Composing with other applications on the same chain is also much easier than trying to do it asynchronously across bridges. So, while contradicting our multi-chain vision, fast monolithic applications are indeed something we have carefully considered.
Solana
Ethereum was initially monolithic, but quickly became crowded. Solana is able to be the first trusted high-throughput chain to achieve sub-second block times — the lowest of any production chain. It does this while remaining decentralized, with 1972 validators and a strong Nakamoto coefficient compared to other PoS chains.
It appears many of these validators would be unprofitable without the Solana Foundation subsidy, so it remains to be seen what happens once the subsidy ends. Jump also recently announced that they will be developing a standalone Solana client called Firedancer, an important first step towards increasing validator diversity.
Solana has attracted a strong ecosystem of projects and a TVL of $1.5 billion, making it the #1 TVL among non-EVM compliant chains. The developer experience, initially considered difficult, has improved significantly after the introduction of the SeaLevel framework Anchor.
Solana has also managed to grow a meaningful and differentiated developer ecosystem, and we think it arguably ranks in the top three alongside Ethereum and Cosmos. This has also resulted in a differentiated culture, reflected in developers with more traditional/financial backgrounds and a thriving NFT ecosystem.
Solana's cost and speed make it an attractive place to build DeFi applications, and as such has a rich DeFi ecosystem with many AMMs, money markets, perps, and other DeFi products (including great ones like Mango).
While this opens up many potential integrations, the flip side is that it's also a pretty crowded space, with plenty of competitive DeFi dApps relative to user count/TVL. There is also a risk of further differentiation given the launch of fast monolithic challenger chains like Sui and Aptos.
Recently, the biggest challenge Solana has faced has been network outages. As mentioned earlier, for some DeFi projects, downtime is risky, because liquidation cannot take effect during the downtime, and the agreement will accumulate bad debts.
The root cause of chain stalls is cheap operations that expose the network to malicious attacks. As a workaround, Solana implemented priority fees. These issues, and the uncertainty of when they will be fully resolved, highlight the risks of adopting new technologies for DeFi applications, such as those we contributed to.
Accurate resource pricing remains a challenge for all permissionless blockchains. Today, blockchains have a single marketplace for fees, where all resources (I/O, storage, compute, bandwidth, etc.) are metered in the same abstraction called gas. This makes it challenging to accurately price operations relative to each other.
Eventually, Solana (and others) will implement localized fee markets so that congestion in a particular dApp doesn't hurt the user experience for everyone else. We are closely monitoring this development and its impact on Solana.
Overall, while Solana has faced a lot of criticism (often unfairly) for being unstable, centralized, difficult to build, etc., we've been impressed with the Solana Labs team and ecosystem's ability to improve in these areas. Solana has relatively achieved credible decentralization from multiple elements, and the development experience has also been improved. We also believe that stability will become a thing of the past and soon be forgotten.
However, we don't think Solana makes sense at this stage, given the imminent competition from challenger fast monomers such as Sui and Aptos, bridges that require additional trust assumptions, and the theory of monomers generally not fitting our multi-chain vision.
Aptos and Sui
Both Aptos and Sui aim to maximize network throughput per node, similar to Solana but with very different technical approaches. One of the core ideas of the design seeks to optimize the mempool propagation layer by allocating a DAG of transactions and guaranteeing availability.
Both have the potential to surpass the performance of a single validator through internal sharding of validators and isomorphic state sharding. Internal sharding means that the validator does not need to scale vertically, increasing its size to match that of the network, but it can spawn other machines behind the load balancer and shard the state as if it were a single node. This basically solves a problem with Solana where the validator specification would be a performance bottleneck and achieves scalability gracefully.
These ideas are promising and seem likely to yield some of the lowest latency and highest throughput in the L1 blockchain space. This is interesting to us because the more performant and scalable a monolith is, the less obvious the need for a new chain will be. However, given our general optimism for Web3, we still feel that the need for a broad range of use cases will spill over into new specialized chains, leading to the multi-chain architecture we have outlined.
Another advantage of these chains is that they use the Move language (or in Sui's case a Move variant). Our initial experiments using Move on these chains are very promising [8], and the parallelization is elegantly demonstrated. Therefore, we do not expect that the development experience of smart contracts will be a significant disadvantage compared to other ecosystems using new languages, especially considering that there is some time for development patterns to emerge. That's thanks in part to Move, which has been under development since Facebook's Libra (where many of the development teams came from).
These chains end up with similar drawbacks to other new technologies we have considered - immature DeFi ecosystem, community, connectivity and huge technical risk making them unsuitable for migrating projects with existing communities and in other ecosystems Technology choices made. As a counter, MoveVM and variants may be used across multiple chains, which does provide some optionality if migration is required. As they develop and the bridge develops, they may become suitable, and we'll definitely be keeping an eye on their development.
Polygon
With Ethereum late to market on its Rollup-centric roadmap, Polygon PoS fills a much-needed void by becoming Ethereum’s preferred sidechain. Polygon is very fast, with an average block time of around two seconds. Coupled with a very strong ecosystem, it really meets our two main requirements for building a good DeFi experience.
These factors have been driven in large part by the effectiveness of the Polygon team in business development and capital deployment, allowing it to gain significant market share while solidifying the EVM legacy. In the field of EVM, Polygon is second only to BSC in capturing Ethereum users, and has a very rich DeFi and game/NFT ecosystem and a TVL of $2B.
As usual, these advantages do come with disadvantages. In the past, Polygon has undergone deep reorganization many times, resulting in a poor user experience. Additionally, we noticed that governance decisions in Polygon are sometimes opaque and centralized. An example of this is the decision by the core team [9] to increase the gas price by a factor of 30, which seems to have been proposed without much involvement from the community.
It is worth noting that becoming a validator on Polygon is not currently a permissionless process. The purpose of Polygon is to have regular auctions where anyone can replace existing validators by staking a higher amount.
However, since the max cap of 100 nodes was reached, the auction has not been held and currently the only way for anyone to become a validator is for one or more of the existing validators to unstake. A previous community proposal [10] addressed this issue by outlining a mechanism for network self-regulation; an important step in the network's plan for progressive decentralization.
Last but not least, the security of the ecosystem depends on a small committee adopting the specifications of Ethereum<>The Polygon PoS bridge controls billions of dollars.
On the other hand, we see Polygon as an ecosystem, not a chain. The core team has invested significant resources into building new scaling solutions, including ZK rollups Hermez, Miden, Zero, DA Layer Polygon Avail, and more. We've spent some time researching ZK techniques in particular, and have been impressed with what we've found.
Polygon Edge is also promising and very close to our proprietary Lisk vision, although the technology is still in its infancy and connectivity between supernets is an unsolved problem. Overall, given its existing adoption, superior BD, and technical prowess of its upcoming ecosystem, Polygon has the 2nd highest score in our rankings and we may see it as a competitive choice for EVM-based DeFi dApps .
However, the current trust assumptions of the bridge and the current PoS chain are major factors in our decision that it's not the best place to build right now.
Near
The main differentiator for Near is its dynamic sharding architecture. The goal of this design is so that users and developers don't have to know which shard they are on. Instead, validators dynamically (every 12 hours or so) determine which tx will be grouped together based on statistical analysis, efficiently adding/removing shards in a seamless fashion. Sound like science fiction? Maybe, but it's a uniquely ambitious vision and deserves credit for it.
This architecture can achieve very competitive scalability with a block time of 1.3 seconds. It manages to do this while maintaining acceptable decentralization, currently has around 100 nodes, and plans to make validation more inclusive with "chunk-only producers" [11], which will significantly reduce hardware requirements .
However, the architecture does have some drawbacks. Smart contracts must communicate using an asynchronous mode, since they are not guaranteed to be part of the same shard. In fact, even today, application developers must perform asynchronous smart contract calls when Near runs on a single shard.
DeFi applications often require precise coordination of many contracts, and asynchrony can introduce additional complexity, failure modes, and finalization times. For example, liquidation involves at least 3 different smart contracts (money market, oracle, and exchange) working together. The asynchrony between these components introduces additional latency and security assumptions that can affect market solvency.
The Near community and ecosystem is not as strong as others, and currently there are few ways to integrate with the DeFi ecosystem. That said, the Near team has a strong vision and has been aggressively executing on it, having raised an $800 million[12] ecosystem fund and investing aggressively in BD, they have managed to attract some strong applications[ 13].
Near built an EVM compatibility layer called Aurora, which accounted for about half of the activity. This increases the portability of EVM-based dApps. It also has a trustless ethereum bridge called Rainbow, which has a strong connection to ethereum, although it currently lacks connections to other ecosystems.
Overall, the complexity of asynchronous calls, especially for highly composable DeFi applications, combined with the small existing ecosystem, lead us to view this as a short-term option - although we will be watching the ecosystem closely future progress of the system.
Avalanche
Architecturally, Avalanche is very similar to Cosmos, with multiple interoperable domains (subnets rather than zones). Just like Cosmos zones, subnets are sovereign networks with their own security. This architecture provides a smoother way for dApps to start with smart contracts, build communities and, once mature enough, become further customizable subnetworks.
As smart contracts migrate to subnets, they also relieve congestion on the main network, reducing fees. We saw an example of this in P2E game DeFi Kingdoms launching its own subnet. It makes us feel like this is a healthy way to grow the ecosystem.
The downside of Avalanche is that it is a relatively new ecosystem. As a result, existing cross-subnet functionality, infrastructure tools, and development communities are still immature.
Avalanche's competitive advantage lies in its novel consensus. Unlike others, Avalanche's consensus can accept a large number of validators without degrading consensus performance. Today, Avalanche's mainnet is run by over 1000 consensus nodes [14] while maintaining an impressive 1-2 second block finality.
However, the effectiveness of the number of consensus nodes is debatable when it comes to censorship (not accompanied by high Nakamoto coefficient) resistance and/or decentralization. Ultimately, the influence of each validator is determined by the weight of its stake. In permissionless settings, stake is often concentrated in a few hands due to centralization trends [15]. Due to the lack of careful measures of MEV and accountability, we find that the number of consensus nodes is not a very useful measure of decentralization.
Cosmos
Best described as an ecosystem of interoperable blockchains, Cosmos is a network of blockchains connected using the IBC protocol.
As mentioned in Part 1, we would like to see a shift towards dedicated or specific application chains due to the benefits of customizability. However, it would not be feasible to require each chain to design and implement consensus, storage, networking, etc. from scratch. The Cosmos SDK is a set of customizable modules that together act as a template for creating new blockchains, reducing the development effort for many dApps.
Substrate from Polkadot offers a similar toolkit, but from our conversations, it seems generally agreed that it is harder to use than the Cosmos SDK, and has far fewer appchains in production than the Cosmos SDK. As mentioned earlier in the Polkadot section, interoperability only applies to parachains, whereas Cosmos chains can interoperate directly without the involvement or approval of the Cosmos Hub.
IBC (Inter-Chain Communication Protocol) is an interoperability protocol for transferring arbitrary data between arbitrary state machines (blockchains). While any finalized blockchain can implement IBC and join the Cosmos network in the future, the only production-ready implementation is as a set of Cosmos-SDK modules.
IBC is trust-minimized, just like two IBC-enabled chains require a third-party relayer, it only requires the relay
the signature of the source chain validator to certify the block header, and
The merkle proof, which, together with the block header, proves that a certain tx exists in the block of the source chain. None of this can be faked.
We believeIBC's trust assumption is a huge advantage. Most bridges work by introducing one or more different stakeholder groups and relaying messages between the two chains, creating additional trust assumptions and attack vectors. IBC only needs to trust the chain it is connected to. Given that cross-chain messaging is at the core of the cross-chain architecture we are exploring, ensuring that bridge trust is minimized is a key consideration for us.
IBC provides functionality beyond messaging.
Cross-chain accounts is a new feature that allows blockchains to control accounts on another chain through IBC. With IA, the multi-chain user experience is greatly simplified. Instead of opening multiple accounts across chains, moving tokens between them, and paying fees in different denominations, users will be able to use dApps across different chains from one account.
For cross-chain projects, this functionality will allow, for example, governance on a central chain to control smart contracts on connected chains.
There is also cross-chain query, which allows one chain to query the state of another chain. However, these features are still immature and not quite ready for production use, but once ready, will significantly broaden the design space for cross-chain applications.
Despite its technical advantages, the Cosmos ecosystem is still small, with a TVL of less than $1 billion [16], most of which resides on chains without CosmWasm or IBC support.
The DeFi space on Cosmos is currently undergoing a major shift. As written in the introduction, Terra, the largest chain in Cosmos, recently went down, causing most of the assets in Cosmos to be destroyed or flee. Terra is both a blessing and a curse for the universe.
While the Terra crash hit the Cosmos ecosystem harder than any other ecosystem, it also brought with it a large and passionate community of users and developers, many of whom have now decided to stay.
We’ve seen Terra projects like Kujira and Apollo commit to launching Appchains, while others relaunch as smart contracts on existing chains, such as Levana on Juno and the upcoming Vortex (formerly Retrograde) on Sei Network.
In addition to the ex-Terra projects, other large projects have also seen the benefits of Cosmos, with dYdX being the most notable. Nonetheless, liquidity in the ecosystem is currently developing, so committing to building the Cosmos is a bet on future growth.
As for speed, block times vary from chain to chain and depend on a range of tradeoffs, such as the number and geographic distribution of validators. Historically, a fully decentralized Cosmos chain typically has a block time of around 6 seconds, which is average.
However, newer chains are improving on this, such as Evmos and Injective achieving block times of ~2 seconds on a globally distributed validator set, and Sei achieving block times of ~1 second on testnet.
Talking to the Tendermint team, there seems to be a lot of room for improvement through storage and consensus optimizations - sub-second block times seem feasible for some applications in the near future.
Also, the modularity of Cosmos is an advantage here, independent teams are able to improve the consensus on their own. An example here is Optimint [17] developed by the Celestia team, which will implement ABCI-compliant Rollup on Celestia, providing a potential future scalability path for the Cosmos chain.
As for decentralization, the number of validators on the Cosmos chain is much lower than Solana and the Ethereum PoS network. However, we don't think the number of validators is actually a good measure of decentralization. Instead, we prefer to look at the Nakamoto coefficient (number of colluding entities required to vet a transaction), which is 7-10 for most Cosmos chains, 2 for Ethereum 2.0, and 31 for Solana.
mdnice editor
Conclusion: Cosmos
After considering the options we summarized above, we decided the best approach would be to focus our R&D efforts on the Cosmos ecosystem.
As mentioned in the first part, we believe this space will increasingly fragment into a mesh network of general-purpose smart contract chains and specialized application chains connected by trust-minimized bridges. In such a world, there will be multiple DeFi hubs, each with its own tradeoffs, ecosystems, and communities. department
Well-architected DeFi dApps deployed on multiple platforms will benefit from liquidity and other network effects that will make it difficult for local DeFi dApps to compete.We believe Cosmos is best suited to benefit from a growing number of application chains and support state-of-the-art cross-chain architectures.
Plus, it’s fast enough for a seamlessly integrated DeFi UX with order books, high leverage, and fast trade execution. At the same time, we think it is sufficiently decentralized to provide strong security, liveness, and censorship-resistant guarantees, especially compared to many of the alternatives we considered, which are newer and thus have more centralization carrier.
Its biggest weakness is the ecosystem, the current TVL is lower than a single ETH L2. Relatedly, Cosmos also lacks hype, funding, and spreadability, likely due to the lack of a model L1 token to come together. While we believe that the influx of projects from Terra's debacle and the growing number of specialized application chains will be somewhat remedial, there is no denying that we are betting on future ecosystem growth. This remains the biggest risk to the universe and our theory.
For these reasons, we will focus on the Cosmos ecosystem for the foreseeable future. That said, we are not Cosmos extremists (except for Larry), so we will continue to actively research and monitor other ecosystems. Below are some of the areas we will be watching closely, suggesting that our papers may be revised.
The growth of the monomer chain relative to the application chain:This would invalidate our argument if most interesting dApps were deployed on monolithic chains and never moved to their own execution environments. After all, the current cost of deploying an application chain is much higher than the cost of deploying a smart contract on a monomer, and the popular universal chain has strong composability, brand and user experience advantages.
Additionally, something like isolated state auctions [18] can make monomers more competitive in terms of resource cost and predictability. We will keep an eye on the fastest monomer chains and reconsider our thesis if we see signs of this happening.
Emergence of a trustless bridge:In our analysis, we ignored many chains due to weak connectivity, meaning they either lacked bridging infrastructure entirely, or existing infrastructure was immature and/or had poor trust assumptions.
That said, there are multiple well-funded and brilliant teams working on bridge solutions, which we believe will improve over time. We'll be watching this closely to see if there is anything comparable to IBC in terms of trust assumptions, or if IBC (chain agnostic) spreads outside of Cosmos. We will also pay particular attention to connections between specialized execution environments, such as Avalanche subnetworks and Polygon supernetworks, as they best align with our multi-chain theory.
Maturity of high potential but current high risk technologies:Throughout the process, we looked at several emerging technologies that have the potential to be stellar endgames, especially in the Rollup space - ZKRollup and Celestia Rollup, especially Fuel V2. We will be watching this closely and look to deploy when we deem the risk is minimized.
All in all, this report took us down various rabbit holes, and we're more bullish than ever on the future of the space. There are multiple well-funded and talented teams working on order-of-magnitude improvements to scalability, connectivity, and DX/UX. Collectively, these improvements will enable entirely new cross-chain DeFi applications, which we believe will help drive more on-chain activity.
Original link
