Chain Abstraction: Open Problems and Opportunities
Charting the Course for Chain Abstraction: Key Issues and Pioneering Solutions
Chain abstraction is the golden ticket that every new blockchain infra project seems to be chasing. While we’ve heard many talk about chain abstraction, a universal understanding of the concept is not yet established nor is a step-by-step guide outlining how chain abstraction should be achieved. The purpose of this article is to outline what chain abstraction is, address high-level steps to construct this future, and identify a few of the teams leading the effort.
Before we begin, however, we want to thank our partners, Particle Network and Everclear for helping us put this series together, and making it all possible.
What Chain Abstraction is
Chain abstraction is a vision for a more unified and seamless blockchain user experience, as Particle stated in their recent article, but it is a vision that is only possible by rethinking how we design and communicate between blockchains. Chain abstraction is achieved by optimizing both user and developer experiences – what I like to call high-level and low-level chain abstraction.
Mission and Vision
Mission: to build blockchain-based experiences that look and feel like the internet we use today.
Vision: a future where using blockchains requires no additional attention towards blockchains themselves or their UX frustrations; unreliable bridging, differences in liquidity across chains, single-VM wallets, multi-gas token management, high latency, and transaction failures – these will be left in the past. Users will be able to jump from app to app without care or concern about the technical backbones of the chains these apps are built on.
Admittedly, this vision sounds too good to be true, but every monumental step in technology feels impossible until we understand the elements needed to construct this future. Demystifying chain abstraction first requires us to break down this desired end-state into high-level and low-level features to pinpoint actionable steps that need to be taken. So, let’s dig into what a chain-abstracted future looks like for user and developer experiences:
User Experience
No technical hurdles that prevent or disincentivize users from jumping between their favorite apps on various chains. Using web3 should look and feel like users’ normal internet practices: we should be able to surf around from our finance, gaming, social, subscriptions, and messaging apps with a simple click or search.
Low latency. To have frictionless cross-chain experiences, chains will need to serve users with lower latency across the board. Lower latency can be achieved with higher transactions per second (TPS) and faster block times made possible by next-generation virtual machines, consensus algorithms, horizontal scaling, and near-instant cross-chain message relays. The likelihood of these improvements coming to Ethereum any time soon is slim, instead, a milestone Ethereum is working toward to become a higher-frequency chain is preconfirmations, which should go live on mainnet over the next few years.
Universal gas standards with reliably low or no fees for users. For chains to be abstracted away from UX, users should never have to care about what gas tokens are required to interact with applications. To achieve this, we will need chain-agnostic gas tokens that can remove the hurdle of using specialized blockspace, and eventually move toward fully protocol-subsidized gas markets.
Ability to use the same wallets with minimal or no lift from the user to switch networks. Wallets have a major opportunity to create more loyal users by minimizing the amount of wallets they have to manage to interact with more networks. Next-gen VMs and chains often bring with them the hurdle of needing new wallets, managing additional seed phrases, and safely securing more private keys. In a chain-abstracted web3, users should only need to manage one wallet.
No liquidity imbalances limiting what can be done in DeFi. One of the biggest problems with the current blockchain landscape is liquidity fragmentation. In the current state of blockchain UX, users need to consider how much liquidity is available to them on different blockchains before they use the apps there, as well as how much liquidity is pooled into the specific applications they want to use. These differences in liquidity availability come at a cost to users through a mixture of high slippage exposure, unreliability in cross-chain bridging, and decreased incentive to use innovative DeFi protocols built on new ecosystems. Liquidity hubs
Encrypted activities & no exposure to toxic MEV. This point shouldn’t be as much of a stretch as it seems on the surface. The first assumption is that a chain-abstracted future will rival web2 UX, and for this to happen, encryption needs to be offered as a standard to users like HTTPS. In this future, when a swap is confirmed, users get what they agreed to in DeFi frontends. Everything done onchain should be inherently protected with user choice around how, when, or to whom they want to disclose their data. Encrypted user experiences unlock the full expressivity of apps and their users, otherwise people will think twice about using blockchains throughout their daily activities.
Developer Experience
Users need and care about different things than developers do, but the desired user experience chain abstraction seeks to offer is not possible without optimization and unification at the developer level. Here are two developer experience-focused milestones for low-level chain abstraction:
Unified execution environments. Developers should be able to build what they want, how they want. This means that they should be able to write applications in their preferred programming languages. There is a lot of fragmentation between builders and their applications that is perpetuated by distinctly separate builder experiences, which is reflected in fragmentation at the chain level because most blockchains have only ever supported one execution environment for developers to deploy contracts within. VMs are of course restricted to supporting only languages that compile down to binaries understood by each VM. Multi-VM and blended VM ecosystems are two ways to unify developers, but the development of ecosystems that support this functionality is a large engineering task itself. Multi-VM blockchains like Arbitrum will soon support the execution of multiple forms of low-level (machine-readable) language, while blended VM blockchains like Fluent will compile multiple high-level languages (human-readable format) into a single low-level language.
More reliable code compiling. Unified execution environments will be accelerated by more inclusive and reliable code compiling. Code compiling is what translates code written in human-readable format (any programming language) to machine-readable format (large sequences of 1s and 0s, or binaries). Compiling is necessary because there are limited resources that can reliably translate programming languages into machine-readable formats, and most that are available are language-specific, meaning that only certain languages can be compiled down to the correct machine-readable formats. Compiler development is challenging and is known to come with operational bugs, so increasing the development and availability of compilers will accelerate the unification of blockchain developer experiences to be more inclusive of all preferences.
Who is building this future?
No teams are tackling every problem identified above, but several teams are attempting to unify developer and user experiences in their own ways. Below, I’ll introduce five teams – NEAR, Particle, Agoric, Arbitrum, and Fluent – tackling various elements of the chain abstraction puzzle. This list is again not exhaustive nor all-inclusive, but for the conciseness of this article, I’ll introduce high-level descriptions of each approach.
NEAR. NEAR’s recent push toward high-level chain abstraction seeks to allow users to control their onchain experiences from one place. This vision is being brought to fruition through NEAR accounts, which can be created with an email and let users interact with multiple blockchains from one place, eventually without needing gas tokens. This is being made possible through three core services: Relayers, FastAuth, and multi-chain signatures. To learn more about NEAR’s approach to chain abstraction, check out their docs.
Particle. One of the leaders of the chain abstraction push, Particle is building a cross-chain intent-based network that handles orders and stores the history of all activities in one ledger. The Particle chain will be used to submit cross-chain intents, coordinate a network of solvers and fillers across chains, and store the history of all these cross-chain activities in one chain. The Particle approach also consists of a universal gas token for users to pay for orders with and a universal account that presents the summary of all user balances from every chain in one interface. Learn more about Particle’s approach to chain abstraction, here.
Agoric. Agoric is tackling chain abstraction at the developer level. They offer the Orchestration API, which allows developers to more easily program sequence-based multi-chain services without users needing to be mindful of the blockchains between them. The differentiator here is that developers can now build services across multiple chains that can interoperate with each other more seamlessly, allowing them to focus more on user experience than low-level interconnectivity. For more on Agoric’s approach, check out this article.
Arbitrum. Arbitrum is approaching chain abstraction at the developer level by allowing multiple virtual machines to run inside Arbitrum One, the L2 we all know and love. Arbitrum recently announced Stylus, which will be their inclusion of the Web Assembly virtual machine (WASM) inside Arbitrum. This upgrade will make the Arbitrum ecosystem more inclusive to developers preferring to write applications in major programming languages like Rust, GO, and C/C++ instead of just Solidity for the EVM. Read more about Arbitrum Stylus, here.
Fluent. Fluent is also tackling chain abstraction at the developer level by introducing blended execution environments. Blended execution allows for composability and interoperability between multiple VMs – starting with WASM, EVM, and SVM – by “simulating” or compiling the EVM and SVM down to rWASM, Fluent’s modified version of WASM optimized for zero knowledge operations. Blended execution allows apps and tokens across supported VMs to natively communicate with each other without tradeoffs in high-level UX like needing to use different wallets or switch networks when jumping around between apps built on Fluent. For more information on Fluent, check out their documentation, here.
What’s next?
This article is meant to be introductory and only begins to cover the elements required for a chain abstracted future. The points above serve only to set a foundation for how to begin thinking about chain abstraction from a developer and user lens. These points are not all-inclusive, and if any reader wants to share additional insights on how to achieve high-level or low-level chain abstraction, please share your thoughts in the comments.
I’ll be following up next week with a subsequent article discussing the open design areas needed to solve chain abstraction and highlighting teams tackling each area.
Until then, I hope the thoughts presented above were helpful in constructing a clearer mental model for the future we’re building toward. Feedback is always welcome, especially about how this design space should be thought about and achieved.
Cheers.
& a huge thank you to our two additional partners who helped us craft this series: Arcana Network, and Nuffle Labs.
 | A guest post by
|