Disclosures: Proximity Labs holds $NEAR, $AURORA and tokens that may be associated with other protocols mentioned in the article. These statements are intended to disclose any conflict of interest and should not be misconstrued as a recommendation to purchase or sell any token, or to use any protocol. The content is for informational purposes only and you should not make investment decisions based solely on it. This is not investment advice.
Introduction
Five main concepts are frequently discussed with respect to decentralized blockchain networks and crypto: decentralization, security, scalability, interoperability, and composability. As applications on Web 2.0 have successfully scaled and are considered to be secure (and some even interoperable), one might claim that decentralization and composability are the biggest innovations of blockchain and crypto, commonly referred to as Web 3.0.
While decentralization is widely discussed by the crypto community, composability is largely only discussed among tech enthusiasts, notwithstanding that it is one of the most powerful aspects of Web 3.0. This research article will focus on composability and will cover how NEAR Protocol, thanks to Nightshade, is enabling true cross-chain composability — a concept that has not received the attention it deserves.
We will also delve into how composability and interoperability are defined, how they relate to scalability, why they are of foremost importance, and the innovations taking place in NEAR DeFi thanks to this revolutionary tech.
Composability and its Importance
Composability is the ability to combine distinct components to create new systems or outputs [1]. Specifically in Web 3.0, composability allows dApps and DAOs within the same chain to seamlessly communicate and work with each other as developers can freely use, reassemble, duplicate, modify and integrate code from other applications into their products thanks to its open-source nature.
Composability shortens the development cycle as developers do not have to start from scratch, increasing time spent on innovation, experimentation and user experience. As Naval Ravikant [2] stated: “open source means each problem only has to be solved once”. A good way to understand composability is to think of Lego blocks. In Web 3.0, these legos are smart contracts that are able to be assembled into larger and more complex structures.
You get the picture: composability is to software what compound interest is to finance [3].
Figure 1. Graphic representation of composability. These lego blocks can be thought of as smart contracts that are able to be combined into larger and more complex structures to enable new functionalities. Examples of composability are token swaps on AMMs, flash loans, governance, identity management, your LP position from a DEX as collateral in a Money Market, borrowing against your NFT or lending it out, the possibility to combine DeFi features with GameFi, DAOs and more Web 3.0 primitives to come.
Differentiating Between Composability and Interoperability
While composability allows for smart contracts to interact with others within the same chain, interoperability is the ability for blockchains to communicate amongst each other, even though they differ in consensus, data availability or block formation. Interoperability implies seamless transfer of assets (fungible or non fungible) and messages, while composability typically implies protocols using shared infrastructure.
Interoperability between chains is a complex problem that many projects are trying to solve. Two main solutions to leverage interoperability have been proposed so far: (1) cross-chain bridges and (2) sharded blockchains.
Cross-chain Bridges
Cross-chain bridges propose an effective solution to connect chains with different target use cases and properties that might not otherwise be compatible, allowing users to move value across the global blockchain ecosystem. However, these bridges force developers to make a compromise between native asset transaction requirements, finality guarantees and unified liquidity. This is known as the bridging trilemma [5]. Most bridges use wrapped tokens, which favors instant guaranteed finality and removes the risk of reversion due to lack of liquidity, but are considered to be highly inefficient: for example, there might not be enough liquidity on the other side to perform the transfer. This also makes it impossible to have composability across different chains.
New solutions are tackling this problem, such as Stargate, a cross-chain bridge built on top of LayerZero [6]. It effectively solves the bridging trilemma and brings composability to the table as it can transfer native assets across different blockchains. However, these cross-chain bridges using omnichain protocols introduce other risks and major complexities into the equation, such as, but not limited to, exhaustion of the liquidity pools, loss of funds as pools are drained before the transaction is executed, rebalancing issues and widespread reversion.
Besides, these bridges are not capital efficient. Figure 3 shows how up to $35B in liquidity (for the represented bridges) were deposited across pools sitting idle. Cross-shard contract calls on NEAR, however, are much more capital efficient since no liquidity pools are required for assets to be transferred across shards.
Sharded Blockchains
Sharded blockchains initially arose to solve scalability, one of blockchain’s biggest challenges: how does a network grow to handle increased activity without compromising on security or decentralization? This is the famous blockchain trilemma, a concept coined by Vitalik Buterin that states that developers face the challenge of compromising on one of these three aspects to satisfy the other two [8].
A sharded blockchain is a blockchain split into multiple chains, often referred to as shards. Contrary to the traditional linear execution model followed by most blockchains, which requires every node to process every operation, sharding introduces the asynchronous processing of transactions, allowing simultaneous and in-parallel processing on each shard. Typically, each shard has its own set of validators. To read more about sharding, traditional limitations, single-shard attacks, and how NEAR Protocol copes with all of this, you can click here.
Sharded blockchains tackle scalability by leveraging its interoperability capabilities. In a sharded blockchain the problem is easier compared to bridges since the block structure and consensus are the same across shards. Sharded blockchains therefore solve the scalability problem by creating an ecosystem of heterogeneous blockchains that have a working interoperability subsystem, such as Cosmos with IBC protocol or Polkadot with parachains. This scalability issue has also been faced from other perspectives and there are other single blockchains claiming to have thousands of transactions per second (TPS) and many Layer 2 scaling solutions. However, due to their non-sharded designs, they would all hit an upper limit of what the network could handle eventually.
It is important to note that most sharded blockchains are not infinitely scalable, as they are often advertised, since any solution that uses a Beacon chain for coordination has limited capabilities. The Beacon chain is the coordination mechanism between shards that must perform bookkeeping computation, such as assigning validators to shards, or snapshotting shard chain blocks, that is proportional to the number of shards in the system. Since the Beacon chain is itself a single blockchain, with computation bounded by the computational capabilities of nodes operating it, the number of shards is naturally limited.
And, apart from scalability, we still have the composability problem. Even though these sharded blockchains might offer a truly interoperable ecosystem, composability between these chains is limited as:
- Users need to bridge to the specific blockchain within the broader ecosystem to make use of such particular blockchain or use case
- They lead to fragmentation: liquidity, incentives, users, developers, resources in general, etc
- Message passing and several cross-shard communication solutions are unproven in the wild and have not been effectively battle tested.
As a consequence, the user experience worsens since it requires tech-savvy knowledge, several transfers of funds, increased execution time, etc.
NEAR Protocol: Introducing Nightshade
Nightshade is NEAR’s solution to scalability and the key to allow for cross-shard composability. Contrary to other sharded blockchains such as Cosmos or Polkadot, NEAR is a single blockchain with multiple execution environments (shards) supported as smart contracts. As it does not have a Beacon chain either, Nightshade allows NEAR Protocol to effectively scale linearly with the number of shards, thereby having the ability to satisfy the demand for transactions as more and more users start to use NEAR. For the users, this means: more security, better usability, improved user experience and access to liquidity across different apps. Ultimately it prepares NEAR for mass consumer adoption of billions of users.
Nightshade models everything as a single blockchain in which each block “logically” contains all transactions for all shards and has the possibility to change the whole state of all shards. However, in practice, no participant downloads the full state or the full logical block containing transactions from every shard. Instead, each node on the network maintains only the state corresponding to shards they validate transactions for. The list of all transactions in the block is split into logical chunks, one chunk per shard. Under ideal conditions each block contains exactly one chunk per shard per block, which corresponds to shard chains producing blocks at the same speed as the beacon chain. However, due to network delays some chunks might be missing, but this is fine because NEAR is asynchronous (more on this later). In practice, each block contains zero or one chunk per shard, representing all transactions from that shard.
Figure 5. A model with shard chains on the left and with one chain having blocks split into chunks on the right [10]. If a transaction affects multiple shards, it needs to be executed in each shard separately. NEAR accomplishes this with asynchronous execution. The full transaction is sent to the first shard, and once the transaction is included in the chunk, and is applied after the chunk is included in a block, it generates a receipt transaction that is routed to the next shard where the transaction continues execution in a future block. If more steps are required, the execution of the receipt transaction generates a new receipt transaction and so on.
Figure 6. Asynchronous cross-shard transaction between 2 different shards on NEAR Protocol [11]. After Nightshade, NEAR plans to deliver Dynamic Resharding. This new tech creates the ability for the network to dynamically split and merge shards based on their utilization, with validators not needing to validate all shards. This will make NEAR almost infinitely scalable and resilient to short-term usage spikes, but this is a topic for another article.
Enabling Cross-chain Composability
Cross-chain composability can be defined by combining the previous definitions of composability and interoperability. Hence, cross-chain composability is the ability for dApps and DAOs on different chains (shards in NEAR’s case) to seamlessly communicate and interact with each other. Cross-chain composability allows smart contracts to be composed in a permissionless and seamless way, even if they are executing on different chains (shards) and running in different environments. For example, NEAR Native and EVM contracts are composable on NEAR’s mainnet today!
Because composability allows anyone in a network to take existing programs and adapt or build on top of them, it unlocks completely new use cases that don’t even exist yet [12]. Now, reimagine composability combined with interoperability across different chains: that is the power of cross-chain composability.
As previously stated, NEAR models the system as a single blockchain and therefore cross-shard contract calls are treated the same regardless of whether two contracts are on the same shard or not, or even running their code in the same smart contract environment. For example, a NEAR Native smart contract can make a cross-shard call to an EVM or ZK smart contract. Because NEAR is asynchronous and non-blocking, the user only sees a single transaction when cross-shard contract calls are made from one environment to another. This means that without bridging tokens or any complicated UX; developers and users can take advantage of whatever execution environment suits their needs. This all happens in a permissionless, seamless, customizable and user-friendly way: you can run a smart contract for the Aurora EVM [13], a rollup, a new environment that focuses on privacy or even for a single app within a private shard to enhance its performance.
The Aurora EVM: An Example to Understand the Genius behind NEAR’s Execution Environments
Aurora is the EVM deployed as a smart contract on NEAR — it is not a different blockchain. Aurora transactions are actually wrapped into NEAR transactions that are sent to the Aurora contract on NEAR. Even though gas is paid in ETH when using Aurora, what actually occurs is that NEAR was used for gas (paid by the relayer) to execute the contract on NEAR with the relayer collecting ETH from the Aurora user.
Contrary to a rollup, Aurora does not rely on sequencers and verifiers because it is a smart contract: an execution environment that looks and feels like an EVM whereas all settlement, data availability and execution is on NEAR with transactions verified by NEAR validators. The security for Aurora is the same as for every other contract on NEAR. As a result, Aurora has a lot less work to do than a typical blockchain because it doesn’t have to worry about consensus, validators, storage, or any other blockchain-related duties.
This design easily allows for cross-shard contract calls. You might be aware of the Rainbow Bridge, whose purpose is to transfer assets between Ethereum <> NEAR <> Aurora, and wondering if this bridge is used under the hood. However, the Rainbow Bridge is not actually needed for cross-shard contract calls between NEAR <> Aurora: the UI just signs the required transaction. This differs from cross-chain bridges built on omnichain protocols and from other sharded blockchains which actually need to bridge from one interoperable chain to another. The process on NEAR is much more efficient and less complex thanks to the core architecture of Nightshade.
If you want to read more about Aurora and the Rainbow Bridge, click here.
Now extrapolate the Aurora case to any private shard. Single apps are therefore getting the benefits of running their own shard:
- Customization and flexibility
- Layer 1 performance: instant finality, higher TPS, etc.
- Improved UX / UI: no need to bridge and direct access to concentrated liquidity
- Higher security
- Devs can access liquidity without needing to know different execution environments just by calling the methods of the private shard interface
- Without extra work such as consensus, storage, validators, etc.
And why is this so important? Because it makes NEAR a truly scalable and cross-composable blockchain. While other blockchains achieve scalability by adding more chains external to the main chain, NEAR scales within itself as a Layer 1 with unlimited shards as smart contracts, potentially running different execution environments that are composable between each other, not only interoperable. The end result is a great user and developer experience.
NEAR Protocol, with Nightshade, solves scalability, interoperability and composability in a way no other sharded blockchain or omnichain bridge has been capable of.
NEAR Protocol Scaling: Real World Applications
Nightshade’s capabilities in terms of scalability and cross-chain composability unlock a huge potential for devs and users and ultimately prepare NEAR Protocol for mass adoption. In this article some of the use cases and applications are going to be covered.
Forget About Bridging
Even though users might be interacting with other shards, they will not even notice since they will be on NEAR mainnet using their NEAR wallet. This is possible because shards in NEAR are composable and cross-shard contract calls are performed seamlessly thanks to being treated the same regardless of whether they are on mainnet or on a private shard. NEAR, contrary to other sharded blockchains, is a single blockchain with multiple execution environments supported as smart contracts: in the same way that applications are composable within the same chain, different shards are composable across the whole NEAR Layer 1 blockchain.
For example, you can perform a trade on Ref Finance and, if the exchange understands that the quote is better on Trisolaris, the trade will be performed there. The user doesn’t even notice that the swap is taking place on Aurora. You can even trade tokens on NEAR Mainnet that are only available on Aurora! This has been called multi-chain liquidity aggregation [14] and it is something that you cannot do in any other chain today. On Ethereum, for example, if you want to get advantage of the low fees, token availability, or liquidity provided by the scalability solutions such as Arbitrum or Optimism, you need to bridge your funds, which requires time and/or effort and knowledge by the user, as well as high fees and lengthy delays to exit back to the main chain. Solutions to exits such as liquidity providers relaying on additional sets of relayers can introduce additional risk.
Say Goodbye to Fragmented Liquidity
Contrary to other scalability solutions, NEAR offers liquidity concentration instead of fragmentation. Let’s explore some contrasting examples:
- Uniswap is a DEX available on Ethereum Mainnet and on Arbitrum and Optimism. If a trading pair has a $400k liquidity on Mainnet and $200k on each L2, that means that the price impact to perform a trade in any of those chains is going to be more severe than if those $800k were concentrated in the same pool. However, you can make the same trade on NEAR, thanks to cross-shard composability, and access the liquidity of 3 pools without even noticing and without the need to bridge. The user only sees one single transaction that has instant guaranteed finality.
- DEX aggregators can especially leverage this tech to get traders the best quote. And not only do these aggregators trade across shards but also across different types of exchanges. Imagine that you have an AMM on NEAR Mainnet, an AMM on Aurora, a couple of Order Books in two different private shards and one AMM on a rollup on NEAR. A DEX aggregator on NEAR can communicate across all of them and get the trader the best possible quote without forcing users to bridge to any of these shards or leave their NEAR wallet. As liquidity builds up on NEAR, professional traders will get the best quotes in the entire ecosystem, not just on a single app chain, L2, or shard; thanks to the liquidity aggregation across different DEX types and chains made possible with NEAR.
Welcome the Concentration of dApps with True Scalability
We have already seen that some successful applications have opted to develop their own chain, since performance decreases as the application gains popularity and becomes congested due to the limitations of the main chain. They might also prefer to make it more customizable and not have the limitations of a simple EVM smart contract. For example, dYdX opted to rebuild the platform as a standalone Cosmos based blockchain, or DeFi Kingdoms went for their own chain as an Avalanche subnet.
So not only are we having a more fragmented world in terms of blockchains as the number of options increases but we are also now getting applications that develop their own chain to get the performance they need. That might eventually become a problem. Before, a user needed to bridge their funds to use a new chain. Now, you also need to bridge your funds if you want to use a specific app! This is even true in the Ethereum 2.0 + L2 scaling model where both liquidity and apps will be fragmented across a number of L2s.
This does not occur in NEAR. For example, orderbooks, such as Orderly, Spin or Tonic, can have their own private shard — which is equivalent to developing their own chain — and thus enjoy customizable features and enhanced performance and speed. However, in contrast to dYdX on a new chain, users would not even notice they are trading in a new shard on NEAR as they will be executing orders on NEAR Mainnet from their NEAR wallet without having had the need to bridge funds to a new chain. This offers a great opportunity to devs / projects who aim for performance and customization without sacrificing user experience or ending up with liquidity fragmentation: projects go for their own shard but it does not affect users with extra steps and complexities such as bridging to any new dApp that gains some popularity and gets congested.
Summary
NEAR is a sharded blockchain modeled as a single Layer 1 that can scale dynamically and infinitely with the number of shards. Shards on NEAR are not different chains, but single or multiple smart contracts that can optionally run more optimized execution environments for their particular use cases. This optimized execution, running on a shared Layer 1 for data and asynchronous base layer execution, allows for true cross-shard composability without the need for bridging liquidity, third party liquidity providers, fragmented liquidity, cumbersome developer experience, additional network relayers or complicated UX.
Such scalability and cross-shard composability bring an unparalleled user and developer experience: more security, better usability, instant guaranteed finality and access to concentrated liquidity across different apps in a single transaction, among others. Numerous applications are currently being built to leverage these capabilities which add benefits such as liquidity aggregation across the whole ecosystem, users utilizing other execution environments (private shards) such an Order Book without even realizing since they won’t need to bridge their funds, optimized quotes for traders, cross-shard flash loans, real-world asset platforms for specific markets, etc.
Ultimately it creates a truly efficient market and prepares NEAR for mass consumer adoption of billions of users.