I’m Alex, the CTO of Immutable. In the first blog of our explainer series, I’ll outline the key design decisions we made while building Immutable X, why we made them, and the role it can play in the future of NFTs.
We set out to solve the current key challenges facing the Ethereum NFT ecosystem:
- Scaling (3–5 NFT trades/second)
- UX (transactions take minutes to confirm)
- Cost (fees for NFT trades are currently $30+)
- Liquidity (most NFTs are never traded)
- Developer Experience (NFT projects spend more time on technical challenges rather than improving their projects)
- Environmental Impact (a barrier to mainstream adoption)
Until now, the only way to solve these challenges has been by compromising the security, custody or decentralisation of these assets, usually by switching to a less secure blockchain or sidechain (both of which ultimately compete with, rather than scale, Ethereum). At Immutable, we refused to accept that this tradeoff was necessary — and, with Immutable X, we’ve succeeded.
TL;DR Whenever you mint or trade an NFT on Immutable X, you pay zero gas, and the validity of all transactions are directly enforced by Ethereum’s security using zero-knowledge proofs — the first “layer 2” for NFTs on Ethereum. We’re allowing users to choose between two Validium and ZK-rollups via a system known as “Volition”, and we’re starting by offering maximum scalability via Validium to allow applications to scale NFTs to the billions, all while remaining on Ethereum. Let’s go!
Choice of Scaling Engine
A critical decision for us when building Immutable X was the choice of the underlying scaling solution. This is a topic we’ve written about previously ( ELI5: NFT Solutions), but I wanted to write a piece that fully explained our thought process when making this crucial decision.
We weren’t interested in either switching to another blockchain, or to a sidechain, because of Ethereum’s established and growing network effects. We care about true decentralisation — investing so much time in blockchain technology, only to resort to what amounts to a database is a waste of everyone’s time. We are pro-Ethereum, and pro everyone on Ethereum. We believe that:
Immutable X scaling = Ethereum scaling = NFTs scaling.
Alternate L1 options, including sidechains like Matic, have achieved a level of scalability by compromising asset security, or decentralization or both. Corners are cut. We wanted to build a true L2, which inherited security from Ethereum L1 — as Vitalik says:
Difference between L2 and sidechains
Excluding sidechains leaves us to explore the massively growing rollup ecosystem — we considered the two major types (optimistic and zero-knowledge) when making our choices.
Optimistic rollups are a great fit for applications which primarily deal with fungible assets (e.g. ETH/ERC20s), and which rely on composability. However, for NFTs, they have some significant limitations. First, they require a 1–2 week withdrawal period. While it is possible to improve on this for fungible assets using fast withdrawals, it’s impossible to provide liquidity for fast withdrawals of unique assets (NFTs). They also require substantial reasoning about the incentivisation of fraud reporting, and their fraud proof model has some significant disadvantages.
We narrowed our focus to ZK-based solutions (rollups/validium). Due to their use of validity proofs, ZK rollups support instant withdrawals. In the words of Vitalik, “…in the medium to long term ZK rollups will win out in all use cases…”. The main current disadvantage of ZK Rollups (not supporting general computation) is less important for the NFT ecosystem, and will soon be eliminated due to the incredible work on projects like CAIRO.
We have chosen to use STARK proofs rather than SNARKs or another system, as STARKs can be set up without a secret ceremony, are post-quantum secure, and rely on simpler cryptography compared to other proof systems, which means they are substantially less likely to be attacked. We have also been able to work closely with the incredibly talented StarkWare team, who have consistently pushed the boundaries of proving capability.
In the end, choosing to build using STARK validity proofs was easy — it’s the engine which was able to solve the real challenges facing NFTs, without compromising user security, and the only solution we felt comfortable would continue to succeed indefinitely.
Giving users the option
The next key decision was which implementation of ZK-proofs we would go to market with; Validium (private, exceptionally scalable, increase in data availability requirements) or a rollup (no data availability requirements, but a small linear cost per transaction which adds up for large scale use). Data availability is an important concept for rollups, because in the failure case (a malicious or absent rollup operator), users must present the merkle path from their assets (in a leaf) to the root of the tree. When a ZK-Rollup publishes its proof, it stores the delta in state between all vaults in the proof itself. In a Validium ZK-proof, this security condition holds so long as the data is always “available” to clients who need it. The downside of ZK-Rollup data is that it introduces a linear cost to vault updates between batches, though this cost is small (around 1000 gas per vault update), compared to the 100,000 gas for a layer-one trade.
However, even with this 100x reduction in gas cost, ZK-Rollup data is still limiting. At 1000 gas per vault update, minting 7 million NFTs (e.g. the Gods Unchained genesis season), would cost around 7 billion gas. At 200 gwei, that’s an expenditure of 1400 ETH (~$2.5M USD), or around 30c per asset.
Our analysis showed this cost to be unsustainable for developers (including major game studios) who are considering minting Ethereum NFTs. If Fortnite goes on Ethereum, they’re minting billions of NFTs a year. We must enable that future cost-effectively, while never compromising on fundamental security. We considered charging on a per-mint basis, but soon realised that would be antithetical to our overall goal — allowing developers to ignore minting costs and focus on designing the best applications possible.
Thankfully, we’re working with StarkWare to allow users to have the highest possible data availability when required, as well as full mainstream scalability, through a system called Volition. This allows users to switch as to whether they want to use a Validium ZK-proof or ZK-Rollup solution.
To ensure that we can guarantee data availability, we use a “data availability committee” — a number of significant entities in the industry, who sign each batch to indicate their possession of the data from this root update (enforced via smart contract). This is very different from validators or block producers in a sidechain — data will continue to be available as long as any of the data committee remains honest, no consensus algorithms required. Further, as privacy is not required in our system, we will be publishing this data on IPFS at regular intervals.
Volition model
Nevertheless, even with these protections, Validium ZK-proofs alone aren’t our long-term goal for Immutable X. Immutable X is launching with vault space preserved for our expansion to Volition. Under a Volition model, users will be able to choose whether particular assets are held as a Validium ZK-proof or ZK-Rollup. We might see a high frequency NFT trading firm use validium zk-proofs for scalable transactions throughout the day, and then opt back into a ZK-rollup vault. Major game publishers and massive-scale applications will almost certainly be minting NFTs via Validium ZK-proofs to achieve global scale. Either way, the important message is: your assets are always secured directly by Ethereum’s security as a layer-two solution, and we support your choice. Transparency and optionality are core components of decentralization.
Interfacing with Immutable X
When deciding the right interface to offer for Immutable X, we chose to work backwards from the needs of our clients. Most NFT developers who are building on Ethereum currently spend a significant amount of time learning Solidity, learning blockchain development and deployment, and learning how to work with Ethereum events & nodes. Our goal with Immutable X has always been to enable them to focus on what matters — building compelling content for their users — rather than learning a wholly new development pattern and toolset.
We chose a familiar format: a REST API. Applications can access users balances, mint assets, or request that users sign transactions, all via a simple REST API. This API will support all basic NFT, ERC20 and ETH functionality. In future, we will allow applications to extend the logic of their particular NFTs, including full smart contract logic, while retaining the REST API interface.
Of course, this design means that clients are dependent on the uptime and stability of Immutable’s API. We see this as similar to most Ethereum applications’ current reliance on node providers like Infura and Alchemy. However, for nodes you are able to either use multiple providers, or host your own node, ensuring you’re not as dependent on an individual provider. Eventually, we may reach a similar point of diversification, including block exploring tools and an interface which multiple API providers could implement.
