Increasing scalability has always been the number one priority for blockchains trying to capture more users. A quick gander at L2fees.info and L2beat shows transaction costs of less than $0.01 at numerous L2s, not far off Solana’s miniscule fees. So while it’s too early to say we’ve achieved scalability, we’re awfully close.
Now, the mindshare of researchers, builders and investors turns to solving the thorny problems that prevent mainstream adoption. Unresolved MEV issues and the lack of regularity clarity are hurdles to overcome, but the primary obstacle to mainstream adoption is the poor UX from a lack of chain interoperability, especially among Ethereum L2s. To achieve frictionless interoperability, researchers and builders have coalesced behind the abstraction meme, be it account or chain abstraction. Below, Zhev looks at how these aim to improve UX, and which meme will ultimately win out.
- Chris
Blockchain builders are stubborn, with strong opinions. This has led to the dominance of ideologically-driven development that is rigid, and as such, esoteric debates loom larger than the user preferences of the market.
Divergence among these ideologies has ostensibly led to the fragmentation of capital and innovation across siloed ecosystems. This certainly makes things spicy and occasionally grants us front-row seats to spats of drama between these ecosystems. Yet there is no doubt that the future of the “new internet” will be far less tribalistic than it currently is. Eventually.
The next billion users won't be concerned with underlying ideologies. Rather, they’ll care about the outcomes of their transactions and ultimately UX. Yet the current fragmented landscape hinders developers trying to build seamless experiences.
Interoperability is key to enhancing UX, but bridges are too clunky in their current state. A broad reworking of mechanisms at the very base layer – where most of the problems emanate – will be needed for an interoperable future to remain feasible.
In this piece, we evaluate the basic properties of blockchains that cause fragmentation, and provide an overview of prominent mechanisms being explored to solve this (within and beyond single ecosystems). In this way, we take a bottom-up approach to understanding the latest meme craze of abstraction at both the account and chain levels. And how these influence the interoperability discussion.
Inspiration via Particle Network
Blockchains are notoriously referred to as a shared ledger, but those in the know call this ledger the blockchain state. On blockchains, a state is not static. It’s always being updated with additional transactions.
How these transactions are added to the state (or ledger) is called a state model, which decides what is a valid transaction, how consensus is reached, and how to maintain a shared ledger state across an honest majority of a blockchain's nodes. Most importantly, the state model specifies how a chain should handle conflicting state updates. For example, when two transactions want to spend the same asset, or when two conflicting transactions want to access the same state.
Blockchain interoperability means a single user initiates a transaction that affects the state model on two separate chains in some trustless and decentralized way. Not all state models are the same. In fact, the two largest blockchains have vastly different structures.
The two major state models are:
Bitcoin uses the UTXO model, with limited programmability. However, this drawback comes with various execution advantages. The most notable is transaction localisation, which means that instead of creating a new branch as part of a global state tree for each interaction (as in the account model), isolated state transitions can be represented and executed as an isolated local state tree.
The account model, meanwhile, is mostly used by Ethereum and other smart-contract chains. It’s less rigorous because it leaves determination of a transaction's state to smart contracts. This makes things a bit complicated as smart contracts mostly specify state changes based on the chain's current state. In the presence of multiple contracts, this can easily lead to unexpected outcomes if the current state is modified by another transaction before the smart contract's desired state change can be attained.
The key takeaway: as long as settlement occurs on a global state tree with a single-threaded and sequential execution scheme, there will always be implicit interdependence between smart contracts. This means that transactions are neither time- nor state-invariant, and can be invalidated due to another valid transaction that comes before them. It also means a “double spend” isn't apparent until a contract is executed – as opposed to a UTXO model, where an invalid state change could be determined without using any of the execution layer.
The widespread adoption of the account model makes it an ideal component to build interoperability infrastructure. Yet to do this, a new perspective around accounts, rather than blockchains themselves, is needed. This certainly seems consistent with the broader trend: Stephane Gosselin of Frontier Research recently compared the shift from a chain-centric view of crypto to an account-centric view to the shift from a geocentric worldview to a heliocentric worldview.
Ethereum accounts are decomposed into four fields: a nonce, a balance, a codeHash, and a strorageHash. These help define the two types of accounts in Ethereum: externally-owned accounts (EOAs) and contract accounts (CAs). EOAs can be controlled by anyone holding the private keys and have empty codeHash and storageHash fields (and by extension, don't have access to persistent storage).
CAs are controlled by code deployed on to the network (aka, a smart contract). Their interactions are entirely pull-based, i.e., they can only send specific transactions in response to a transaction from another account. Thus, the actions of a CA are somewhat static and predetermined by its code's logic. They have to be built/derived from an account creator's address and its nonce value, and the account creator must be an EOA account with a balance to pay for the account's storage usage.
In short, EOAs provide users with full autonomy (i.e., they can begin transactions) at the cost of programmability (i.e. their logic is strictly constricted), while contract accounts take the other route (programmability at the cost of autonomy).
Achieving interoperability is important because to operate on a new chain, a third party must send a transaction on the user’s behalf. Of course, blockchains are built to prevent this, so new protocol rules will have to be introduced.
Currently, for transactions from any account to be considered valid and then executed, there are four checks (or what we call “constraints”) it must satisfy: 1) Authentication 2) Authorization 3) Replay protection, and 4) Gas payment.
For EOAs, each of these checks are constrained to ensure a single valid result. Authentication and authorisation are provided by the EOA’s private key; replay protection is provided by the transaction's nonce, and gas payment must be provided by the account from which the transaction originates. These enshrined constraints limit EOAs.
Contract accounts allow more programmability around these validity checks. Authentication and authorisation of transactions are dependent on its code's logic, granting a lot of leeway around key management and access policies (gas payment may be settled by another account, e.g., its caller). The lack of granular constrictions allows transactions originating from contract accounts to be more programmable, granting them coveted features such as atomicity.
Okay, now that we understand the general structure of accounts on Ethereum and what is needed to send a valid transaction, we can look at the account-based technical solutions aiming to enhance interoperability.
Like Bitcoin, Ethereum launched only with EOAs but first imagined “smart accounts” in 2017 with the introduction of EIP-86. Smart accounts are supposed to combine the best properties of EOAs and CAs in order to birth a new, composable primitive, but the process has been slow and tedious.
The challenge for the Ethereum community is needing to upgrade two different types of accounts (EOAs & CAs). Although researchers said they were moving forward with both, it always seemed like upgrading EOAs was less of a priority, given the view of many - including Vitalik - that smart contract wallets are the endgame for regular users.
A vision for this smart contract wallet-led future began to coalesce around the idea of Account Abstraction, which would make all accounts on Ethereum contract-based. AA would remove all deterministic constraints on accounts from the consensus layer, and define probabilistic constraints within the execution layer, which would create a single standard for accounts across the EVM world.
The cornerstone of this vision is ERC-4337, which was implemented last year and allows accounts to package up the actions they want to take into a UserOperation, which is sent to a dedicated mempool where bundlers can put them all into a transaction that makes a single call.
A dedicated mempool is a huge step but achieving the full vision of AA would require a lot of changes to the Ethereum protocol, including the consensus layer, which is always a sensitive area. As such, Ethereum has been slow in implementing upgrades to its account model that would enhance interoperability.
So even if smart contracts and AA are the future, EOAs are still in wide practice today so many application developers have been pushing for upgrades alongside the push for protocol changes to enhance smart contract wallets.
ETH researchers listened and planned EIP-3074 for inclusion in the next Pectra update, but received significant pushback from supporters of EIP-4337. They argued the new transaction type proposed would be incompatible with EIP-4337 and solidify the two parallel track models for EOAs and CAs. There were also concerns about increasing censorship but the important point was that EIP-3074 would hurt the long term vision of Account Abstraction and EIP-4337. There also may have been competitive worries about getting new users on smart contract wallets if EOAs had the same functionality.
Responding to the pushback, EIP-3074 was withdrawn and Vitalik wrote EIP 7702 in 22 minutes to achieve the same ends as EIP-3074 but is forward-compatible with EIP-4337, and importantly, does not introduce any new opcodes to the EVM.
We believe there is a middle ground that maintains Ethereum’s gradual approach to achieving AA yet also enhances the experience of EOAs, so that interoperability infrastructure can be built now. Given that upgrading EOAs with more programmability means that only some of the deterministic constraints are removed from existing account standards, we refer to this as “constraint abstraction”.
Constraint abstraction is considered a viable alternative due to many factors: including, the complexity associated with absolute abstraction, EOA enshrinement in dAPPs’ UI/UX, and users’ fears.
Hopefully, you’ve memorized the EIP numbers
Having parts of an account as modules rather than irreversibly integrated verticals opens up various channels for interoperability. These channels that can transcend chain boundaries represent a new approach to solving the fragmentation problem, and have been collectively referred to as chain abstraction.
Similar to account abstraction – an intended end state with numerous pathways to its realization – chain abstraction seeks to unify and simplify users’ actions across all (most, if you seek to be pragmatic) existing ecosystems. While it’s easy for any one chain to point fingers and proclaim that their stack is better, it should be all too obvious at this point that the best way forward is a collaborative effort for UX simplification.
OneBalance, which emerged out of Frontier Research, was created with this purpose: a collaborative that transcends execution environments to provide a single account standard for users across all ecosystems.
It describes its proposed solution – credible accounts – as “ultra HTLCs”, and we tend to agree. HTLCs are a great primitive that never got their medals due to the complexity associated with implementations when first ideated. Maybe now we have a reliable mechanism to abstract this complexity from users.
Without clear technical definitions, the difference between account, chain and constraint abstraction is mostly on the meme side of things. What is apparent is that whatever direction the industry moves, the new system will be powered by intents and the assumption that a set of more specialized agents – driven by some definable amount of (non-detrimental) extractable value – would be willing to compete to help users settle their requests.
While there are various fanciful definitions for intents, they are simply a user expressing their desired outcome/goal for a broadcasted request. A simplification of their request, removing unnecessary restrictions in the “how” of the request and placing them in the “what”.
Specialized actors referred to as “solvers” then take it upon themselves to identify the most cost-effective pathway (the “how”) that respects the user's goal (the “what”).
HTLCs failed to take off when they were first introduced in 2017-2018 due to the perceived complexity. Now more than ever, with the presence of MEV-hardened solvers in the mix, it'd be great to see them get the love they deserve. HTLCs are one of the simplest iterations of a technology powering interoperability; on the other hand the rise and funding of intent-centric designs has shown that user welfare is paramount.
We believe that if crypto wants to take the onboarding problem seriously, then it must prioritize user welfare at every possible level. With interoperability, we believe intent-powered HTLCs are a step in the right direction. We also believe a lot of the current work being branded chain abstraction is unnecessary; most of the solutions have existed in the shadows for a long time due to complexity of use. It is now simply time for synergy.
There has always been a need for a simple UX and a desire to implement interoperability. What’s been missing is the motivation (driven by market demand for cross-chain trading) and the increased capability of solvers to execute the complex cross-chain transactions. Solvers would be a good fit, but there is a risk, abstraction further entrenches block builders.
New innovations must now be encouraged to synchronize with old ones without introducing extra vaporware. And intents + HTLCs seems a great place to start in redefining cross-chain UX.
That’s it! Feedback appreciated. Just hit reply. Great to have Zhev go deeper at the protocol level. Lots of of great discussion in the Ethereum research community this week as well.
Dose of DeFi is written by Chris Powers, with help from Denis Suslov, Zhev and Financial Content Lab. I spend most of my time contributing to Powerhouse, an ecosystem actor for MakerDAO. All content is for informational purposes and is not intended as investment advice.
Continue reading:
Now, the mindshare of researchers, builders and investors turns to solving the thorny problems that prevent mainstream adoption. Unresolved MEV issues and the lack of regularity clarity are hurdles to overcome, but the primary obstacle to mainstream adoption is the poor UX from a lack of chain interoperability, especially among Ethereum L2s. To achieve frictionless interoperability, researchers and builders have coalesced behind the abstraction meme, be it account or chain abstraction. Below, Zhev looks at how these aim to improve UX, and which meme will ultimately win out.
- Chris
Blockchain builders are stubborn, with strong opinions. This has led to the dominance of ideologically-driven development that is rigid, and as such, esoteric debates loom larger than the user preferences of the market.
Divergence among these ideologies has ostensibly led to the fragmentation of capital and innovation across siloed ecosystems. This certainly makes things spicy and occasionally grants us front-row seats to spats of drama between these ecosystems. Yet there is no doubt that the future of the “new internet” will be far less tribalistic than it currently is. Eventually.
The next billion users won't be concerned with underlying ideologies. Rather, they’ll care about the outcomes of their transactions and ultimately UX. Yet the current fragmented landscape hinders developers trying to build seamless experiences.
Interoperability is key to enhancing UX, but bridges are too clunky in their current state. A broad reworking of mechanisms at the very base layer – where most of the problems emanate – will be needed for an interoperable future to remain feasible.
In this piece, we evaluate the basic properties of blockchains that cause fragmentation, and provide an overview of prominent mechanisms being explored to solve this (within and beyond single ecosystems). In this way, we take a bottom-up approach to understanding the latest meme craze of abstraction at both the account and chain levels. And how these influence the interoperability discussion.
Inspiration via Particle Network
The basics of blockchain state models
Blockchains are notoriously referred to as a shared ledger, but those in the know call this ledger the blockchain state. On blockchains, a state is not static. It’s always being updated with additional transactions.
How these transactions are added to the state (or ledger) is called a state model, which decides what is a valid transaction, how consensus is reached, and how to maintain a shared ledger state across an honest majority of a blockchain's nodes. Most importantly, the state model specifies how a chain should handle conflicting state updates. For example, when two transactions want to spend the same asset, or when two conflicting transactions want to access the same state.
Blockchain interoperability means a single user initiates a transaction that affects the state model on two separate chains in some trustless and decentralized way. Not all state models are the same. In fact, the two largest blockchains have vastly different structures.
The two major state models are:
Unspent transaction output (UTXO) model: State is managed by tracking individual transaction outputs (represented as assets) – that can either be spent or not – and the restrictions on spending them (represented as the asset's holder). Spent outputs and their corresponding inputs are trackable to a public key, which can be used to approve said input for future spends by verifying key ownership. Thus, each asset is tracked using the last transaction in which they were spent, and the current restrictions on spending them again (its current holder).
Account model: Maps an address to its balance and current state. As opposed to tracking each asset in the network, this model tracks each account in the network and balances for each asset on a unified ledger. All interactions in an account-based chain are implicitly interlinked, so there’s only one global tree of interdependent transactions which are both state and time-variant.
Bitcoin uses the UTXO model, with limited programmability. However, this drawback comes with various execution advantages. The most notable is transaction localisation, which means that instead of creating a new branch as part of a global state tree for each interaction (as in the account model), isolated state transitions can be represented and executed as an isolated local state tree.
The account model, meanwhile, is mostly used by Ethereum and other smart-contract chains. It’s less rigorous because it leaves determination of a transaction's state to smart contracts. This makes things a bit complicated as smart contracts mostly specify state changes based on the chain's current state. In the presence of multiple contracts, this can easily lead to unexpected outcomes if the current state is modified by another transaction before the smart contract's desired state change can be attained.
The key takeaway: as long as settlement occurs on a global state tree with a single-threaded and sequential execution scheme, there will always be implicit interdependence between smart contracts. This means that transactions are neither time- nor state-invariant, and can be invalidated due to another valid transaction that comes before them. It also means a “double spend” isn't apparent until a contract is executed – as opposed to a UTXO model, where an invalid state change could be determined without using any of the execution layer.
Accounts on Ethereum
The widespread adoption of the account model makes it an ideal component to build interoperability infrastructure. Yet to do this, a new perspective around accounts, rather than blockchains themselves, is needed. This certainly seems consistent with the broader trend: Stephane Gosselin of Frontier Research recently compared the shift from a chain-centric view of crypto to an account-centric view to the shift from a geocentric worldview to a heliocentric worldview.
Ethereum accounts are decomposed into four fields: a nonce, a balance, a codeHash, and a strorageHash. These help define the two types of accounts in Ethereum: externally-owned accounts (EOAs) and contract accounts (CAs). EOAs can be controlled by anyone holding the private keys and have empty codeHash and storageHash fields (and by extension, don't have access to persistent storage).
CAs are controlled by code deployed on to the network (aka, a smart contract). Their interactions are entirely pull-based, i.e., they can only send specific transactions in response to a transaction from another account. Thus, the actions of a CA are somewhat static and predetermined by its code's logic. They have to be built/derived from an account creator's address and its nonce value, and the account creator must be an EOA account with a balance to pay for the account's storage usage.
In short, EOAs provide users with full autonomy (i.e., they can begin transactions) at the cost of programmability (i.e. their logic is strictly constricted), while contract accounts take the other route (programmability at the cost of autonomy).
Transaction validity
Achieving interoperability is important because to operate on a new chain, a third party must send a transaction on the user’s behalf. Of course, blockchains are built to prevent this, so new protocol rules will have to be introduced.
Currently, for transactions from any account to be considered valid and then executed, there are four checks (or what we call “constraints”) it must satisfy: 1) Authentication 2) Authorization 3) Replay protection, and 4) Gas payment.
For EOAs, each of these checks are constrained to ensure a single valid result. Authentication and authorisation are provided by the EOA’s private key; replay protection is provided by the transaction's nonce, and gas payment must be provided by the account from which the transaction originates. These enshrined constraints limit EOAs.
Contract accounts allow more programmability around these validity checks. Authentication and authorisation of transactions are dependent on its code's logic, granting a lot of leeway around key management and access policies (gas payment may be settled by another account, e.g., its caller). The lack of granular constrictions allows transactions originating from contract accounts to be more programmable, granting them coveted features such as atomicity.
Building an account layer
Okay, now that we understand the general structure of accounts on Ethereum and what is needed to send a valid transaction, we can look at the account-based technical solutions aiming to enhance interoperability.
Like Bitcoin, Ethereum launched only with EOAs but first imagined “smart accounts” in 2017 with the introduction of EIP-86. Smart accounts are supposed to combine the best properties of EOAs and CAs in order to birth a new, composable primitive, but the process has been slow and tedious.
The challenge for the Ethereum community is needing to upgrade two different types of accounts (EOAs & CAs). Although researchers said they were moving forward with both, it always seemed like upgrading EOAs was less of a priority, given the view of many - including Vitalik - that smart contract wallets are the endgame for regular users.
A vision for this smart contract wallet-led future began to coalesce around the idea of Account Abstraction, which would make all accounts on Ethereum contract-based. AA would remove all deterministic constraints on accounts from the consensus layer, and define probabilistic constraints within the execution layer, which would create a single standard for accounts across the EVM world.
The cornerstone of this vision is ERC-4337, which was implemented last year and allows accounts to package up the actions they want to take into a UserOperation, which is sent to a dedicated mempool where bundlers can put them all into a transaction that makes a single call.
A dedicated mempool is a huge step but achieving the full vision of AA would require a lot of changes to the Ethereum protocol, including the consensus layer, which is always a sensitive area. As such, Ethereum has been slow in implementing upgrades to its account model that would enhance interoperability.
Balancing future desire with current needs
So even if smart contracts and AA are the future, EOAs are still in wide practice today so many application developers have been pushing for upgrades alongside the push for protocol changes to enhance smart contract wallets.
ETH researchers listened and planned EIP-3074 for inclusion in the next Pectra update, but received significant pushback from supporters of EIP-4337. They argued the new transaction type proposed would be incompatible with EIP-4337 and solidify the two parallel track models for EOAs and CAs. There were also concerns about increasing censorship but the important point was that EIP-3074 would hurt the long term vision of Account Abstraction and EIP-4337. There also may have been competitive worries about getting new users on smart contract wallets if EOAs had the same functionality.
Responding to the pushback, EIP-3074 was withdrawn and Vitalik wrote EIP 7702 in 22 minutes to achieve the same ends as EIP-3074 but is forward-compatible with EIP-4337, and importantly, does not introduce any new opcodes to the EVM.
Account Chain Constraint abstraction
We believe there is a middle ground that maintains Ethereum’s gradual approach to achieving AA yet also enhances the experience of EOAs, so that interoperability infrastructure can be built now. Given that upgrading EOAs with more programmability means that only some of the deterministic constraints are removed from existing account standards, we refer to this as “constraint abstraction”.
Constraint abstraction is considered a viable alternative due to many factors: including, the complexity associated with absolute abstraction, EOA enshrinement in dAPPs’ UI/UX, and users’ fears.
Hopefully, you’ve memorized the EIP numbers
Chain abstraction
Having parts of an account as modules rather than irreversibly integrated verticals opens up various channels for interoperability. These channels that can transcend chain boundaries represent a new approach to solving the fragmentation problem, and have been collectively referred to as chain abstraction.
Similar to account abstraction – an intended end state with numerous pathways to its realization – chain abstraction seeks to unify and simplify users’ actions across all (most, if you seek to be pragmatic) existing ecosystems. While it’s easy for any one chain to point fingers and proclaim that their stack is better, it should be all too obvious at this point that the best way forward is a collaborative effort for UX simplification.
OneBalance, which emerged out of Frontier Research, was created with this purpose: a collaborative that transcends execution environments to provide a single account standard for users across all ecosystems.
It describes its proposed solution – credible accounts – as “ultra HTLCs”, and we tend to agree. HTLCs are a great primitive that never got their medals due to the complexity associated with implementations when first ideated. Maybe now we have a reliable mechanism to abstract this complexity from users.
Intents, again
Without clear technical definitions, the difference between account, chain and constraint abstraction is mostly on the meme side of things. What is apparent is that whatever direction the industry moves, the new system will be powered by intents and the assumption that a set of more specialized agents – driven by some definable amount of (non-detrimental) extractable value – would be willing to compete to help users settle their requests.
While there are various fanciful definitions for intents, they are simply a user expressing their desired outcome/goal for a broadcasted request. A simplification of their request, removing unnecessary restrictions in the “how” of the request and placing them in the “what”.
Specialized actors referred to as “solvers” then take it upon themselves to identify the most cost-effective pathway (the “how”) that respects the user's goal (the “what”).
Let the solvers deal with the complexity
HTLCs failed to take off when they were first introduced in 2017-2018 due to the perceived complexity. Now more than ever, with the presence of MEV-hardened solvers in the mix, it'd be great to see them get the love they deserve. HTLCs are one of the simplest iterations of a technology powering interoperability; on the other hand the rise and funding of intent-centric designs has shown that user welfare is paramount.
We believe that if crypto wants to take the onboarding problem seriously, then it must prioritize user welfare at every possible level. With interoperability, we believe intent-powered HTLCs are a step in the right direction. We also believe a lot of the current work being branded chain abstraction is unnecessary; most of the solutions have existed in the shadows for a long time due to complexity of use. It is now simply time for synergy.
There has always been a need for a simple UX and a desire to implement interoperability. What’s been missing is the motivation (driven by market demand for cross-chain trading) and the increased capability of solvers to execute the complex cross-chain transactions. Solvers would be a good fit, but there is a risk, abstraction further entrenches block builders.
New innovations must now be encouraged to synchronize with old ones without introducing extra vaporware. And intents + HTLCs seems a great place to start in redefining cross-chain UX.
Odds & Ends
SEC sues Consensys over MetaMask swaps and staking services Link
Gnosis to launch threshold-encrypted mempools through Shutterized in July Link
Balancer begins planning v3 Link
James Prestwich on the Infinite Jungle podcast from Galaxy Link
Arbitrum proposes TimeBoost, a new transaction ordering policy Link
Reading list for Trusted Execution Environments (TEEs) Link
Curve founder suffers liquidation cascade on CRV-baced loans Link
Restaked ETH reaches $13bn (3.7m ETH) in market size Link
Thoughts & Prognostications
Blob Inversion: An investigation into the June 20th 2024 blob spike [Blair Marshall/Block Native]
Were rollups meant to be on Bitcoin all along? [Peteris Erins/Auditless Research]
Inclusion Lists Don’t Fix Multi-Block MEV in Attester Proposer Separation [Charlie Noyes/Paradigm]
Making sense of some niche modular infrastructure [knower’s substack]
Meme coin mania [Tanay Ved & Matías Andrade]
The unseen bidding war: Rsync’s strategic maneuvers [EigenPhi]
The state of Polygon [Saurabh Deshpande & Siddharth/Decentralised.co]
Dude, where’s my (stablecoin) yield? [Kinji Steimetz/Messari]
That’s it! Feedback appreciated. Just hit reply. Great to have Zhev go deeper at the protocol level. Lots of of great discussion in the Ethereum research community this week as well.
Dose of DeFi is written by Chris Powers, with help from Denis Suslov, Zhev and Financial Content Lab. I spend most of my time contributing to Powerhouse, an ecosystem actor for MakerDAO. All content is for informational purposes and is not intended as investment advice.
Continue reading:
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
