The Problems Every Bitcoin Developer Faces — And How the ArchVM Tackles Them
This piece is by Amine ElQaraoui, Arch Co-Founder & Chief Technology Officer
I started working in Bitcoin with one goal: make life easier for other frustrated developers like me.
I had come from the Solana and Ethereum ecosystems and, like many developers, saw building on Bitcoin as the holy grail.
But the early developer experience was awful. And so my original vision was small: To build a platform that could give developers access to APIs, nodes, real-time data and other critical tools, similar to Alchemy on Ethereum.
However, it quickly became clear that developers needed more than just tools.
They needed fundamental infrastructure that Bitcoin was just frankly lacking. And the answer wasn’t in all these L2s and meta-protocols that were sprouting up and siloing liquidity.
There needed to be a true base layer solution.
We built Arch to address the biggest pain points of building on Bitcoin.
1. Bitcoin programmability is limited. Its native programming language wasn’t built for smart contract functionality, so we created the Arch VM, which gives developers a way to write more expressive programs that directly manage UTXO-based assets, such as native Bitcoin, Runes, and Ordinals.
2. Bitcoin is slow, and trying to make it faster introduces state management problems. Processing transactions at Bitcoin block times leads to poor UX and limits the ability for liquidity to flow quickly in Bitcoin DeFi. We realized that we don’t need to wait for Bitcoin confirmations if we can provide pre-confirmations on Arch (this creates a state concurrency challenge, which we address by anchoring Arch state transitions to Bitcoin UTXOs, and building a mechanism to rollback states if needed).
3. Bitcoin offers no native composability. There are no ways for Bitcoin apps to interoperate with each other on the base layer, which makes it difficult for DeFi liquidity to flow between them. We solve this with our unique architecture, including an account-based model that allows us to do cross-program invocation, invoking smart contracts from one app to another seamlessly within the ArchVM.
In this piece, I explore these problems and detail our solutions to them.
Expanding Bitcoin’s limits with the Rust-based ArchVM
Bitcoin is slow, clunky, peer-to-peer. Natively, it’s just not conducive to DeFi, which needs fast speeds and programmability to properly connect liquidity. Much of that is because of the limitations of Script, its native programming language, which was never meant to enable smart contracts.
Script works with no ability to reference arbitrary stack elements, and struggles to handle complex logic, with no loop or iteration capabilities. Those limitations make it very difficult to build stateful apps, and are compounded by Bitcoin’s slow block times, with no guarantees of state transitions and Bitcoin asset transfers being atomic.
The ArchVM uses Rust, the same programming language core to Solana and a host of other performant blockchains. Instructions can be sent to the Arch nodes to invoke Rust-based smart contracts capable of handling complex logic — in the Arch VM, these smart contracts are called “programs.”
Similar to in Solana, these programs are accounts containing executable code, organized into functions called instructions. While programs are stateless, they can include instructions that create and update other accounts to store data.
This model opens the door to a number of execution opportunities that aren’t possible with Script, some of which we’ll discuss here.
Increasing speeds while maintaining Bitcoin state through UTXO Management and Real-Time Mempool Indexing
If Bitcoin can’t handle smart contract execution, then programmability needs to be done through another VM. But how do developers maintain Bitcoin state while handling those transactions in a separate environment?
Arch manages Bitcoin UTXOs through an indexing system that can maintain constant communication with the base layer. This allows Arch to produce soft-confirmations that allow apps to proceed as if the transaction will be included in the next Bitcoin block.
We also deploy a tagging mechanic to track which transactions are dependent on each other.
This means we can chain state transitions together, allowing Arch to give those pre-confirmations while still guaranteeing block inclusion and reorg resistance.
If our rollback mechanism shows that a transaction was evicted from the mempool or got re-orged in a Bitcoin block, we can simply reverse the state transitions and any other dependent state transitions. Put another way: If consensus is rejected on the base layer, any affected transactions’ state transitions are simply undone on Arch.
Arch is uniquely able to do this with the granularity of a single app or transaction, so the whole network doesn’t have to be rolled back, as I will explain in greater detail in the next section.
Advanced Bitcoin composability through an accounts-based model that enables cross-program invocation
Because of its unique architecture, the ArchVM is able to maintain Bitcoin/Arch state for every transaction and every app independently — so developers can post state changes back to BTC at a granular level.
This is a marked difference from other projects that promise fast Bitcoin programmability but are either …
- L2s that require you to use trust-minimized bridges to mint new assets on the destination chain, then bridge back to the base layer
- Multisigs that don’t actually maintain state with Bitcoin but act more like a sidechain: You can deposit into them, batch transactions, then withdraw.
Developers can maintain interoperability and composability with other Apps built on Arch too, without the need to wait for BTC confirmations (e.g. you can trade within the same block.)
This is important. Because of our accounts-based model and the fact that users/apps do not need to wait for Bitcoin finality in order to trade the state multiple times, they can move fast enough to allow for advanced DeFi functions like cross-program invocation — the building of smart contracts within other smart contracts.
Cross-program invocation allows …
- Assets to be traded across different protocols without bridging
- Liquidity to be aggregated from multiple sources
- Traders to receive optimal pricing with lower slippage
… and a host of other benefits across various use cases.
Building Better Bitcoin Programmability
Bitcoin’s inherent limitations have kept developers from building on it, with most of those interested in programmability heading to Ethereum, Solana, and other ecosystems — until recently, when the introduction of Ordinals Theory in the fall of 2022 began reinvigorating development on Bitcoin.
That slow start has left Bitcoin developers without many of the resources they are used to having in other ecosystems.
We are working at Arch to introduce more and more resources for developers
It’s still early stages, but you can start learning more about what we’re building on Bitcoin with the ArchVM by …
Reading …
Consulting…
Reaching out…