Explainer on how our design architecture powers the future of NFTs.

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

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

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

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

Interfacing with Immutable X

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.

Leave us some feedback here

We’d always like to hear your comments, and suggestions for improvement as we continue to adapt our explainer series

Please get in touch by adding “Design Arch explainer” to the subject.

Originally published at https://www.immutable.com.

We are the first layer-2 scaling solution for NFTs on Ethereum