We’ve come a long way since then:

• Bitcoin and Ethereum process at most tens of transactions per second. But newer L1s like Aptos (15,015 TPS) and Solana (10,605 TPS), or L2s like Eclipse (8,600 TPS), scale much higher.

• Bitcoin’s consensus produces a block every 10 minutes, Ethereum ~12 seconds, while Aptos (190ms) and Solana (400ms) are much faster.

Andy

@ayyyeandy

10,000,000 TPS.

1GB blocks.

1,000,000 rollups.

91

9:50 AM • Feb 27, 2025

Blockspace is no longer the scarce resource it once was. It is more available than ever and its commoditization is closer than many realize.

Performance still matters. It always will. But it’s no longer a differentiator, it’s table stakes.

Big, cheap and fast blocks, then what?

The world knows about crypto and traditional developers are intrigued.

Case in point: Eliza, a project bridging AI and blockchain, amassed a massive 14.6k stars on GitHub, becoming the most popular repo in the world for several months in the past year. Yet, during that time, only around 3,500 new developers joined crypto per month. While it's unclear how many were onboarded by Eliza, this contrast suggests that the conversion rate from web2 to web3 remains low.

mert | helius.dev

@0xMert_

it'd be hard for crypto to get much more attention from here

the most visible person on earth launched a coin, there's maybe 2-3 people on earth who can match that attention — and this is after polymarket was a headliner for the most visible election on earth

kanye is one

745

9:06 AM • Feb 7, 2025

It’s clear that developers are at our doorstep. The problem isn’t attracting them, it’s making sure they can easily walk through the door and feel compelled to stay.

Today, performance isn’t what holds developers back. Design constraints and poor developer experience do.

Building onchain today means making frustrating choices:

• You use TypeScript, Javascript or other common languages for almost everything, but now you have to work with Solidity (esoteric), Rust (hard), or an even more niche language (such as Cairo). Beyond just new languages, you’ll have to deal with new tools, frameworks, and the challenge of porting existing code.

• Then, you realize Solidity is extremely limited. It’s good at working with tokens but not good at general application logic. Let’s take a painful example. In most programming languages, developers rely on standard libraries. These libraries provide built-in functions for strings, math, hashing and everything else they need. Solidity? Forget it. No standard library. No native utilities for common tasks. No efficient way to handle data. The reality is that Solidity lacks essential tools that make development easier elsewhere.

• You want to build in a familiar way, but blockchains force you to pick between execution environments and make weird tradeoffs. Most developers don’t think in terms of VMs. They simply want to use the best languages and tools for the task at hand.

New developers arrive with fresh ideas but quickly hit a wall. Experienced crypto developers come up with new product ideas but hit a wall too. No one wants to choose between VMs. They just want to use what is familiar and what already works.

The current model forces them to adapt to constraints rather than focus on innovating and solving real problems.

Expressivity is all you need

Performance is no longer the limiting factor, it’s what developers can express.

Developers should be able to build with whatever tools they prefer, and it should all just work.

While Solidity allows developers to access basic primitives, languages like Rust allow for advanced features like procedural and declarative macros. These can greatly reduce the amount of boiler plate code developers need to implement. Furthermore,  while Solidity requires developers to manually handle storage and memory, Rust provides built-in tools that help developers handle memory more efficiently. These functions let developers express their intentions with ease. The former is just one example, add Python, TypeScript, and other languages, and you can quickly see developers gaining even more freedom. Freedom to write clear and straightforward logic, unlocking builders' creativity.

Every new computing paradigm - from the early days of software to the growth of the web, mobile, and cloud - has followed a clear pattern. Progress has always been driven by enabling expert creators to do more and lowering friction for the rest of us.

History will rhyme. Less constraints. More expressivity. More innovation. This time won’t be any different.

A follow-up piece will be out soon, exploring how Fluent’s blended execution is an effort to expand blockchain expressivity.

We appreciate the reviews from Jim (Lifi), Santiago R Santos (Inversion Capital), Yano (Blockworks), Will Villanueva (Bonkbot), Daniel Lubarov (Polygon), NoSleepJon (Hyperlane), Dankrad (Ethereum Foundation), and Wei Dai (1kx).

Follow Fluent on Twitter.
Join Fluent’s Discord.
Visit Fluent’s website.

Fluent offers a different approach: blended execution.

Blended execution blurs the lines between virtual machines (VMs) and lets developers use web3-native and web2-native programming languages in one unified environment. It’s a maximally expressive design that can support arbitrary VMs.

The Fluent blockchain will blend the EVM, SVM, and Wasm, enabling dozens of programming languages (Rust, AssemblyScript, C++, etc.) and full compatibility with Ethereum and Solana development standards. As Fluent’s implementation of blended execution is so extensible, Fluent can integrate new VMs over time as they gain popularity.

Fluent Labs has raised $8M, led by Polychain Capital, to expand its core team and advance blended execution as the industry standard.

Other investment firms include dao5, Primitive Ventures, Symbolic, Builder Capital, Nomad Capital, Public Works, MH Ventures, The Rollup and more. Angel investors include Balaji, Mustafa Al-Bassam, Jason Yanowitz, Santiago Santos, Dingaling, Ekram Ahmed, Cristian Manea, Will Price and more.

With blended execution, users can access applications from different VM ecosystems in one place without switching wallets. Pssst... just a little more patience before you can try it yourself. In the meantime, follow Fluent on Twitter so you don’t miss a step of the journey: https://x.com/fluentxyz

There are currently around 60 projects in the Fluent ecosystem across DeFi, infrastructure, consumer, and gaming. Early developers are building a range of applications on Fluent, such as the first fully on-chain quant, a Web3-native Product Hunt, and a Fantasy Top for OnlyFans creators. And many more teams are building in stealth.

Want to be next? Fluent Labs is hosting an event in EthDenver to meet builders and talk about app ideas. Join here: https://lu.ma/3luj2t8v. Not in Denver? No problem! Hop into the Discord and let’s chat: https://discord.gg/fluentxyz

• “Where are all the apps”

• “Token is the only product”

• “Money is the only use case”

Recently, altVMs have sparked a change. They usher in new technical features such as parallel execution, formal verification, local fee markets, dozens of programming languages, millions of software libraries, privacy, etc. but just as importantly a fresh mindset towards apps and builders. altVMs are making people optimistic again.

Jim

@0xJim

some news: going forward, my team is focusing 100% of our efforts on altVMs

that means building on @solana, @movementlabsxyz, @EclipseFND, @ton_blockchain, @fluentxyz & others that we’re bullish on

it also means much less building on Ethereum.

this was a hard decision for me

744

10:24 AM • Oct 16, 2024

How is Fluent contributing to that mission?

Blended execution is a new way to build smart contract applications using programming languages and tools from different virtual machines. This results in real-time, atomic composability between otherwise isolated environments, making it possible for developers to create cohesive applications, leveraging multiple programming paradigms.

Blended applications operate within a blended execution environment. They take the best tools for each part of an application and make them work as one, resulting in better performance, flexibility and usability.

Ok this sounds cool, but do devs care? Are people building? Do blended applications actually look different?

Yes :) Introducing the Fluent ecosystem, including 7 blended applications leveraging functionality uniquely possible on Fluent.

The ecosystem also consists of 50 other apps and infra providers, including Hyperdrive, Timeswap and Dora, joining the mission to build a net-new environment where EVM, SVM and Wasm apps can all co-exist.

Now, let’s zoom in on a few of these blended apps:

• Archetypal Labs is building The O’Ruggin Trail, a fully onchain text adventure written in Solidity that leverages blended execution to enable game modding in both Solidity and Rust. Ultimately Fluent will support AssemblyScript and Lua to broaden the design space even further.

• Griffy is a prediction market where users can trade in 150+ categories, from sports to celebrities. Griffy will be written in SVM Rust and support ERC-20 tokens, uniquely enabled by a blended execution environment.

• Blocarrat is the first fully onchain baccarat game blending Rust smart contracts for its game engine with Solidity contracts for managing wagers and settlement. Fluent’s parallelized environment offers real-time performance for live game play, and the blending of contracts enables a non-custodial wagering experience with ERC-20 tokens.

• Klyra is building a cross-chain compatibility layer for a market making and clearing protocol. Instead of having a separate system that checks balances between EVM and SVM environments, Fluent enables a single system where signed transactions can be accepted across multiple chains yet balances can be managed internally at one layer (think how Thorchain manages balances across chains but without multisigs). Solana transaction verification is achieved on Fluent using Rust by creating a simple precompile. While this is theoretically possible on EVM chains, parsing Solana transactions poses significant overhead that is expensive on a 32-byte stack due to incompatible cryptography (ed25519).

That’s just what’s being built right now. Other unique developer experiences uniquely possible on Fluent include:

• DeFi apps that support both ERC-20 and SPL tokens

• Encrypted onchain operations like hidden data for games or data-invisible AI computations using FHE

• Solidity programs that interact with Rust agents

• Private multi-sigs with cheap signature verification and dynamic custody set updates using the Schnorr signature scheme for threshold encryption

In the coming weeks, emerging blended apps will be spotlighted, showcasing how blended execution offers an alternative to current blockchain programming models, enabling fresh applications.

Let’s move beyond copy pasta mindset and build different. You can check out the dev resources and already experiment with deploying blended apps on Fluent Devnet. Got a question? Slide into the Discord or the Telegram builder’s chat and say hi 🤙

Wasm-based contracts were delivered first, EVM-compatibility was then enabled, and now for public devnet Wasm and EVM-based contracts can call each other directly. For the first time, blended applications composed of Solidity, Rust and Vyper contracts can be built on Fluent.

The First Blended Devnet

Fluent Public Devnet is an L2 execution environment where Wasm and EVM-based smart contracts can directly interact with each other. Specifically, one portion of an application can be written in Rust, and another in Solidity or Vyper, with real-time composability between them.

The first demo app on Fluent showcasing composable contracts across VM targets is a chess game. The game combines logic written in Rust, using the Shakmaty rust crate, with a Solidity smart contract designed to manage game interactions.

Fluent

@fluentxyz

Blended applications can call contracts written in various programming languages.

In this example, a Solidity contract natively interacts with a Rust contract. Checkmate.

16

11:45 AM • Jun 23, 2024

The chess game library, written in Rust, verifies the correctness of the player’s actions. Upon verification, it directly calls a Solidity token contract to increment the player’s rewards based on the outcomes of their in-game actions.

Developers are invited to experiment with composing Rust and EVM-based contracts on devnet. Fluent is in early stages of development and feedback is welcome to help iterate and improve the network. You can also reach out to share what you plan to build and explore ideas and implementations.

Deploy on Fluent

Fluent Public Devnet is now available and permissionless for developers. To deploy on Fluent, head to the Fluent docs for instructions to connect to the network, and view quickstart guides and blended app examples.

The developer channel on Discord is also available! Join to chat with initial contributors and the Fluent community.

This devnet provides a developer preview of the Fluent L2 execution environment, serving as an early sandbox for experimenting with blended execution of Wasm and EVM-based contracts.

The purpose of the Fluent public devnet is simple: get feedback from developers and help them build novel applications. Blended execution networks are powerful and new, but may exhibit some rough edges in the early days (and it goes without saying, the devnet isn’t meant for production!).

Rapid iteration on developer experience is key. Which language SDKs do you want to see? Which VM targets should be supported next? What tools or abstractions make dev’s lives easier? Share your thoughts to help shape Fluent as a home for expressive execution and novel apps.

This milestone is exciting, but it’s still early days with much work ahead. Stay tuned for upcoming developments:

• Rollup and zk functionalities

• Support for additional languages (Python, Typescript, etc.)

• Support for additional VM targets (the SVM, etc.)

• Apps and infra protocols joining the network

Why Blend?

Before blended execution, developers had to pick between the benefits of the EVM (users, tooling, integrations, etc.) and the benefits of next-gen VMs like Wasm, the SVM or MoveVM (web2 library support, efficiency, parallelization, formal verification, etc.). These single execution networks restrict programming environments and make it harder for developers to build compelling apps. Developers are forced into one-size-fits-all tooling.

With blended execution, developers no longer have to compromise. Blended execution networks are maximally expressive. Web2 apps reached the masses because developers could easily pick the best tool for each task and create unique app experiences. The blended execution vision is to replicate that ability in web3 environments.

So come give it a try! Look through the hundreds of thousands of Rust crates that have been built over the years. Build a DEX in Rust that uses ERC-20 tokens, enhance a social feed with Rust algorithms, play with generative art, or pursue any other project you can imagine.

Developers can test deploying blended apps using Rust, Solidity, and Vyper contracts on the Fluent public devnet today. Reach out on Discord to talk about what you’re building and how you found the experience.

Other Ways to Get Involved

If you’re not a developer but want to get involved in other aspects of Fluent’s journey, the Fluent community is growing. You can;

• Discuss ideas, share memes, and hangout on Discord

• Check out and offer feedback on Fluent docs and knowledge base

• Follow and engage with @fluentxyz on X

gblend everyone!

In order for users to interact with apps across different VMs, they must bridge between networks and manage various wallets and token standards. This introduces user friction and various trust and security assumptions based on how the bridges are designed.

We propose a new paradigm to unify VMs: blended execution.

The State of Execution Environments

Thanks to many years of blockchain R&D, scaling is now much less of a bottleneck. There’s plenty of blockspace.

Naturally, developers are now shifting attention to what they can do with this blockspace. This explains the momentum behind novel VMs and execution environments over the past year.

VMs bring a variety of different attributes to the table. They can be technical or related to the VM’s ecosystem and network effects. Here are some examples:

• Tooling and infra integrations (e.g. wallets, RPCs)

• Documentation and support (e.g. StackOverflow)

• Developer mindshare

• Popular apps and existing code

• Parallelization and efficiency

• Web2 library support

• Formal verification

App developers will pick a chain for any combination of these (and other) attributes. The EVM gets a lot of heat but maintains the best tooling and infra integrations. Both the EVM and SVM have a robust set of apps. The SVM is famous for parallelization and Move has become desirable for formal verification.

The problem, however, is that blockchains today support only single execution, where developers are restricted to the attributes of a single VM and are isolated from a much larger pool of apps and users.

What if you are most familiar with the SVM but want to tap into the vast expanse of EVM users? What if you are building a Solidity app but want to leverage a Rust library to build a feature? In single execution networks, developers must make tradeoffs between isolated ecosystems and their respective attributes.

Introducing Blended Execution

Blended execution supports apps from multiple VMs in one state machine, where each app is a first class citizen of the network.

Blended apps are seamlessly interoperable, regardless of which VM they pertain to. This lets developers leverage the contract logic and tools of the VM that best suit their needs, without fracturing user experience across disparate execution environments.

More formally, blended execution is defined as an execution environment that supports real-time composability across apps from multiple VM.

The First Blended Execution Network

Fluent is the first blended execution network - an Ethereum L2 that blends Wasm, EVM and (soon) SVM apps into a unified execution environment.

Contracts deployed in languages like Solidity, Typescript, and Rust can now compose without friction. And in time, additional VMs can be added too. The benefits of this approach are twofold:

Unification of apps and users: The best apps from different ecosystems get to live in the same place. By unifying different VMs, Fluent acts as an additional execution point for apps across ecosystems, with the advantage of tapping into a broader user base than a single execution environment can provide. These apps share state - enabling real-time interactions between contracts across VMs.

For example, an app written in Solana Rust (think Solend*)* can call an app written in Solidity (think Uniswap). No bridging between networks or switching wallets required for users.

Diversification of tools: Developers get to leverage the best tools across languages and frameworks for each of their app’s components. By building portions of a program using different coding paradigms, smart contract apps can more easily be built in the spirit of microservices, using the millions of existing libraries available for general-purpose languages like Rust, C++, TypeScript and more.

Using common token contracts (like the fungible ERC-20 of the EVM and SPL of the SVM), developers can build performant apps in languages like Rust yet financialized with familiar crypto token standards of blockchain-based VMs.

How Fluent Blends Execution

Interaction between EVM, Wasm, and SVM-based contracts on Fluent happens under the hood and is both atomic and synchronous. Calling a program in Solidity via a program in Solana Rust for example happens in one call, included in one transaction. No bridging and no shared sequencing to (attempt to) re-introduce atomicity required.

Digging in, each VM is represented by a core Wasm-based system contract (the VM’s “compatibility contract”) which defines its EE standards and provides an API to access these functions. A program in Solidity calls a program in Solana Rust by pointing to the SVM compatibility contract, for example.

Ultimately, all VMs on Fluent are emulated at the execution layer, and compiled down to the Fluent rWasm (reduced WebAssembly) VM, a minimally modified version of the Wasm binary instruction format, optimized for zero-knowledge (zk) operations. rWasm uses a novel account and state structure managed by the compatibility contracts, and transactions interoperate at this level.  For zk proving, the compatibility contracts are supported by an additional library, the Journaled ZK Trie (JZKT), which makes atomic composability possible and proving of the Fluent STF across standards efficient.

Over the coming weeks, we will release more information and technical documentation to explain how Fluent works under the hood.

Wrapping Up

Blended execution brings the best of multiple VMs to a shared execution environment. It unifies environments like Wasm for its verification logic, the EVM for its tooling, and the SVM for its developer experience.

Fluent is the first blended execution network, supporting apps from different VMs without fracturing composability. We see blending as the next paradigm in modular execution, enabling the best attributes across smart contract and execution layer design.

Blend apps on Fluent. Blend VMs on your chain. The question is: What will you blend?

Upgrading Developer Experience

In December 2023, Fluent launched a preliminary zkWasm developer version of the Fluent L2. This version was explicitly designed to facilitate the deployment of Rust smart contracts using the Fluent Rust SDK.

Today, we are rolling out Private Devnet V2. This version consists of two key enhancements:

• Rust SDK enhancements

• 100% EVM compatibility

It was time to level up how Fluent supports Rust smart contracts. In this release, we improved code standardization by adding input capabilities with block and transaction context information (block hash, origin, caller, etc.) and improved the developer experience by introducing a new ABI codec to manage input and output parameters.

Additionally, Fluent became 100% compatible with the Ethereum Virtual Machine (EVM), opening up a vast ecosystem of existing Ethereum smart contracts and tools. Fluent developers can now build smart contracts in Solidity and Vyper and use tools such as Hardhat. The aim is to make it as simple as possible to deploy Ethereum-centric apps on Fluent, and in the future, enable seamless composability between Ethereum-based smart contracts and those written in traditional programming languages. This opens up the design space for novel apps previously impractical using blockchain-based infrastructure.

Onboarding More Launch Partners

In tandem with the V2 release, we are excited to onboard our second batch of launch partners. A few of our Solidity and EVM-centric partners include Polymer Labs, Archetypal Labs, Rocknverse, 3cities and more.

If you're excited about the future of zkWasm on Ethereum and want to start building on Private Devnet V2, we invite you to join our early builders program. If you want to skip the line, feel free to DM Dino or Stephy with what you are building and why you think Fluent is a good match.

Other Ways to Get Involved

If you’re not quite ready to build on Fluent but still want to participate, there are several ways to get involved:

• Check out and offer feedback on our docs

• Ask questions and discuss ideas on Discord

• Follow and engage with @fluentxyz on X

• Explore open positions at Fluent

We envision a future where developers can enter the Ethereum ecosystem with the programming languages, frameworks and tools they love most and where the learning curve to build onchain is minimal. Realizing this vision starts with shipping a product and getting developer feedback - hence why we’re so excited about today.

This also marks the very start of zkWasm execution on Ethereum!

Initial Launch Partners

This week we’ll roll out a private release to our first cohort of launch partners.

This is a preliminary developer version of the Fluent L2 explicitly designed for deploying and interacting with Wasm-based smart contracts, utilizing a compatible go-Ethereum execution environment.

During this period, we will closely monitor the devnet, run extensive stress tests, and address issues that arise. Our aim is to iron out wrinkles and iterate towards a seamless developer experience.

🥁 Introducing our initial launch partners!

• Giza: Platform for verifiable ML models and AI apps

• Composable Finance: Cross-chain interoperability and intent execution protocol

• Paima Studios: Framework for gaming, gamification and autonomous worlds

• Tashi: Blazing fast decentralised gaming

• Turbo: Next-gen 2D game engine and marketplace

• Archetypal Labs: Onchain gaming studio and autonomous world infrastructure

• Gameplan: Sports metaverse with mini-games and exclusive fan interactions

• Hyper Oracle: Programmable zkOracle protocol

• Vistara Labs: Hardware availability layer for modular blockchains

• Modular Cloud: Block explorer and serverless data retrieval APIs for modular blockchains

We’ll be working closely with each of these projects and adapting the Fluent stack based on their input.

Join the Early Builders Program

Don’t worry, you have not missed the boat.

We started with an intimate group to make sure everything goes smoothly, but we’ll onboard more launch partners and builders on a rolling basis. This approach also allows us to constantly introduce fresh perspectives and diversity into the Fluent ecosystem.

If you’re excited about Fluent and the future of zkWasm on Ethereum, reach out!

More Ways to Get Involved

If you’re not quite ready to build on Fluent but still want to participate, there are several ways to get involved:

• Check out and offer feedback on our docs

• Ask questions and discuss ideas on Discord

• Follow and engage with @fluentxyz on X

• Reach out to jam with Dino and Krinza 🤙

One step closer to launching the Fluent L2 and our mission of helping millions of developers build onchain!

Note that this post isn’t attempting to dive deep, be comprehensive or focus on specific projects. The goal is to walk through popular rollup designs and offer easy ways to think about them.

Let's kick things off with a metaphor.

Making sense of rollups

Imagine yourself in a crowded city, where people are constantly rushing from one place to another. The streets are filled with cars, buses, and motorcycles, each representing a smart contract transaction carrying important information and computations.

As the city grows, the streets become congested. The number of vehicles trying to move at the same time overwhelms the road infrastructure, causing delays and gridlock. This congestion mirrors Ethereum's current state, where an increasing number of transactions strain the network's capacity to process and record them in each block.

Now, imagine a proposed transportation system that solves the congestion problem. Lets call it “rollup”, that introduces a network of high-speed tunnels beneath the city. These tunnels serve as alternate routes for vehicles to travel, bypassing the crowded streets above.

In this metaphor, the Ethereum blockchain represents the streets; the transactions are the vehicles, and rollups act as the underground tunnels, efficiently handling and processing the transactions while minimizing the strain on the main blockchain.

So what are rollups, exactly?

Rollups move computational work off of a given blockchain without losing the security properties of that blockchain.

Instead of directly processing every computational step on Ethereum (we’ll use Ethereum as an example, but rollups can be built on other blockchains), they consolidate, bundle, “roll up,” or summarize the information into a condensed form. This bundled data includes "proofs," “state roots” and other “transaction data”. For simplicity, let’s refer to all of this as “rollup data”.

Rollups are often blockchains themselves. Rollup blockchains take user transactions, process them and securely store all rollup data on the main blockchain. Again, you can think about rollup as compressing data to fit more efficiently on the main blockchain (AKA base chain).

But why do we need rollups in the first place?

Revisiting the city metaphor: streets + high-speed tunnels = more scalable city. Similarly, rollups allow the Ethereum ecosystem (kinda like a city) to handle a much larger volume of complex transactions, making the network (technically a network of networks) more scalable and efficient.

However, not all rollups are the same. There are different designs to consider, each with different security properties.

Blockchain functions

Before we get into the different types of rollups, lets refresh ourselves on the core functions of a blockchain (yeah, we doing basics again).

Four main functions of a blockchain:

1. Execution: executes transactions and lets only valid transactions result in state machine transitions.

2. Settlement: verifies proofs, resolves fraud disputes, and acts as a bridge between other execution layers.

3. Data Availability (DA): stores transaction data, ensuring its availability and accessibility.

4. Consensus: agrees on the order of transactions across the blockchain network, and that all participants reach a consensus on the validity and ordering of transactions.

Four functions into two layers: Security and Environment

Types of rollups

Optimistic Rollups

Optimistic Rollups rely on fraud-proofs.

This approach operates under good faith, allowing batches of transactions to be posted with the assumption that they are correct. If a batch is indeed valid, no further action is required within the rollup system.

If a batch is discovered to be false, the system initiates a series of processes to identify and penalize the responsible party. Optimistic Rollups employ a dispute resolution system that verifies fraud proofs and carries out appropriate punishments. Typically, two main parties are involved in this process: the user who submitted the batch and the user who suspects fraudulent activity and submits the fraud proof.

Both participants are required to provide a bond in ETH, which will be slashed in the event of misconduct by either party.

ZK Rollups

ZK (Zero-Knowledge) Rollups use validity proofs.

They operate under a "guilty until proven innocent" approach, ensuring that transactions are submitted along with evidence of their correct execution. This evidence is a "zero-knowledge proof," a concise representation demonstrating that each step of the program execution sticks to the blockchain rules. By combining numerous transactions into a sizable batch, ZK rollups enable simultaneous validation of multiple transactions.

Each batch of transactions includes a cryptographic proof that comes in the form of ZK-SNARK or ZK-STARK. This enable users to securely transmit transactions across a blockchain completely encrypted. These transactions remain confidential and unreadable by anyone, yet the proofs validate their legitimacy and integrity.

You can learn more, here!

Rollup Designs

Smart Contract Rollups (aka. Classic)

tl;dr: these are the rollups that we commonly encounter on Ethereum today.

Smart Contract rollups, such as Optimistic and ZK rollups (covered above), rely on a settlement layer (like Ethereum) to validate and order their blocks.

In this setup, the rollup focuses on executing transactions, while tasks like consensus, data availability, and settlement are handled by the underlying blockchain. To ensure trust and reliability, smart contract rollups rely on a set of smart contracts on the settlement layer. These smart contracts act as a bridge, establishing a secure connection between the rollup and the settlement layer.

Sovereign Rollups

Sovereign rollups bring additional features to the basic rollup architecture, introducing independence and autonomy. They publish their transactions to another blockchain for ordering (consensus) and data availability while maintaining control over their own execution and settlement.

Unlike smart contract rollups, sovereign rollups do not have secured bridges connecting them to a settlement layer. They lack a native trust-minimized bridge with the DA layer for settlement, which has been a point of contention.

What’s important to note is that sovereign rollups can still have general bridges for communication with external systems. These bridges allow them to interact and exchange information with other networks, even if they don't rely on them for settlement. This provides some degree of connectivity, but the absence of a secured bridge to a settlement layer remains a notable distinction for sovereign rollups.

(In a nutshell) Smart Contract vs Sovereign Rollups

Validiums and Volitions

Technically, validiums and volitions are not rollups but let’s consider them close cousins of rollups. They play an important part of the design space.

Validiums offer a different approach to processing transactions. Instead of executing transactions directly on L1, it processes them offchain before submitting them, along with a proof, to the parent chain. This part works the same as rollups.

What sets validiums apart from rollups is how they optimize data availability throughput by using a separate, offchain data availability layer. This trades off *some* security for use cases where high performance and low cost matter more.

Volitions are a blend of rollups and validiums. When using a volition, you can decide whether you’d like to operate in “rollup mode” or “validium mode”. In theory this decision will depend on the security / throughput needs of the use case.

Developers can configure the mode based on their application, or they can pass the decision through to end users.

Layer 2s and Layer 3s

Most of the rollups you are familiar with are Layer 2s (L2s). As we’ve discussed, L2 rollups post rollup data to the base chain.

However, there’s a new paradigm emerging where rollups post proofs to other rollups which then aggregate many proofs together and post that single proof to the base chain. Yes, we are describing rollups on rollups.

Note: this only applies to ZK rollups, not optimistic rollups.

Why L3s? The reason developers pick this design is to enable faster and cheaper ZK proving. This works via recursion, which you can read more about here.

Settlement rollups

When L3 rollups post proofs to L2 rollups, they are often said to be “settling” on the L2 rollup. Unsurprisingly, these constructions are called settlement rollups.

Note that the implementation of settlement rollups can vary. Some settlement rollups are, in reality, general-purpose smart contract platforms that L3 rollups use for settlement. Settlement rollups can also be designed specifically for verifying proofs and have no smart contract functionality at all.

Enshrined rollups

Enshrined rollups mean that the rollup software is part of the base chain. For example, if Ethereum took the Scroll codebase and integrated it into the core Ethereum protocol, it would have “enshrined” the rollup. This would mean that when Ethereum upgrades or forks, so would the rollup. They’d be attached.

Note that enshrinement applies well beyond the rollup context. A few examples:

• You can think of Ethereum as a consensus and DA layer with enshrined smart contract and settlement functionality, as opposed to Celestia which is solely a consensus and DA layer.

• EigenLayer is an independent restaking protocol built on Ethereum smart contracts, but there are discussions about enshrining similar functionality into the core Ethereum protocol. See PEPC.

• Cosmos chains offers enshrined stake delegation, whereas Ethereum delegates this to be implemented as smart contracts.

Based rollups

Based rollups are rollups without sequencers.

Well, technically, based rollups use the base chain as an enshrined sequencer (the transactions still need to be ordered somehow). In this construction, users send transactions directly to L1 and validators order the transactions like any other L1 transactions. Rollup nodes then use this ordered list as input to their state transition function.

Round up

While we hope this post made rollup architectures more digestible, we understand that the design space is large and it’s still a lot to take in. This is what makes it even more important to understand, especially to make the most informed decisions possible about which rollup architecture to use for specific use cases.

It’ll be interesting to see the design space be fully explored over the coming years and which designs win out. See you down the rabbit hole!

More resources:

1. The Complete Guide to Rollups and Rollups aren’t Real by Jon Charbonneau

2. Rollups, Rigor, and Reality by Kelvin Fichter

3. A thread covering High-level Rollup Architecture and Ecosystem by Stephy

The web has come a long way since 1989. What began with simple, static pages has blossomed into a world of full-blown applications supporting billions of users.

Because web “apps” required dynamic interaction with elements in the HTML document, JavaScript was introduced. It gained widespread popularity and was for a while the only programming language used in the browser.

JavaScript as a standard was useful yet limiting. What if some developers didn’t know JavaScript? What if JavaScript wasn’t the best language for certain use cases?

Enter WebAssembly: a low-level, portable, binary format and compilation target for high-level programming languages. It’s efficient, secure and flexible.

The introduction of WebAssembly (Wasm) meant that JavaScript no longer needed to be the sole language of the web. Developers could write performant code in languages such as Rust, Go, C, C++, etc. and compile them into Wasm modules to be executed in the browser. This opened up new possibilities for high performance web applications like 3D graphics, video editing, gaming and more.

Wasm Popularity in Web2

Wasm’s story didn’t end in the browser. Over time it broke free from its origins and started powering the world’s most complex distributed applications.

Here are just some of the many ways in which Wasm has been used:

Ecommerce and Backend Optimization:

1. Shopify: Uses Wasm to optimize backend operations for speed and efficiency.

Design and Collaboration Tools:

1. Figma: Transitioned from asm.js to WebAssembly resulting in a threefold performance surge.

2. AutoCAD's Migration: Similar to Figma, AutoCAD adopted Wasm to navigate the additional challenge of intricate Windows OS dependencies.

Multimedia and Entertainment:

1. Netflix: Employs Wasm to create immersive video interactions, enhancing user engagement and entertainment.

Software Development and Tools:

1. Adobe: Invests heavily in WebAssembly, expanding the possibilities of software development in a browser environment.

2. Microsoft: Integrates Wasm into Azure Functions, Visual Studio Code, and Edge, shaping modern development tools.

Gaming and Interactive Experiences:

1. Unity: Uses Wasm to craft high-performance games across platforms.

2. Pinterest: Uses Wasm to curate dynamic user experiences.

Infra and Financial Tech:

1. Fastly/Cloudflare: Employs Wasm to supercharge network performance, optimizing content delivery.

2. Visa: Uses Wasm to secure payment processing and protect sensitive user data.

Wasm has enabled innovation across many sectors. Between ecommerce, entertainment, software development, gaming, networking, and critical systems, Wasm's impact has been nothing short of transformative.

Wasm Popularity in Web3

Fast forward to web3, where Wasm has also been very desirable. It has been adopted as the execution environment for many of the top blockchain projects over the past five years. Here are a few noteworthy examples:

• Cosmos for its L1 SDK

• NEAR for its sharded L1

• Polkadot for its L1 SDK

The “why” for Wasm popularity in web3 is not much different than in web2. Efficiency, standardization, security and of course flexibility with programming languages. Here’s the vision for the Internet Computer as stated by Dfinity technical lead (at the time) Andreas Rossberg - who is also the co-creator of Wasm.

“Our vision is that developers may program from the Internet Computer in any language they would like.”

Support for general-purpose languages not only creates a more intuitive experience for web3-native developers, but it can also enable millions of new developers to build onchain. Each of the above projects (plus several others like Tezos, EOS, etc.) knew Wasm execution was a powerful idea.

Wasm Challenges in Web3

So what happened? Why aren’t millions of developers building onchain? Why have we not reached mass adoption? Wait a minute - forget mass adoption - why isn’t Wasm even the most popular execution environment in our still-very-niche web3 world?

No one has articulated the crux of the problem better than EigenLayer’s Sreeram Kannan. Historically, to innovate on execution environments (as well as any other core infrastructure), you had to spin up a decentralized trust network. You had to get a set of validators and you had to get a bunch of capital committed.

This is VERY hard to do in a sustainable way. Bootstrapping a truly decentralized and permissionless trust network (that isn’t subsidized by VCs or easy money seekers) is akin to starting a revolution, a very different skillset than engineering distributed systems.

“Creating a decentrallized trust network is like finding a unicorn. Decentralized trust is not a common property. It is emergent out of social consensus which takes years to build” — Sreeram Kannan

The reality is that very few blockchain projects - even projects with impressive technical innovations - have been able to bootstrap sustainable trust networks. One could argue that only two blockchains have done this so far: Bitcoin and Ethereum. This has made it hard for new execution environments like Wasm to reach escape velocity.

Ethereum’s Wasm Experiment

A natural question to ask is “if Wasm execution is so desirable, why haven’t Bitcoin and Ethereum adopted it?”

For Bitcoin, the answer is simple. Bitcoin’s trust network makes a few key promises, one of them being “no hard forks”. This immediately rules out replacing Bitcoin’s limited scripting environment with a more programmable Wasm environment.

For Ethereum, we’ll need to walk down memory lane.

Ethereum flavored Wasm (Ewasm) was originally proposed in 2015 and considered for a number of years. To be clear, Ewasm was “a restricted subset of Wasm to be used for contracts in Ethereum.”

Goals of the Ewasm project included an EVM transcompiler, a VM implementation, a metering injector and more. To get a better sense for the thinking behind Ewasm, check out the following resources:

• Rationale and benefits

• Comparisons with other VMs

• Progression over 3.5 years

So wen Ewasm?

The Ethereum Foundation eventually decided against Ewasm and stayed with EVM execution. While there were certainly challenges around backwards compatibility and execution sharding, the decision was part of a much broader strategic pivot. The pivot was explored by Vitalik Buterin and Casey Detrio, then later formalized as “a rollup-centric Ethereum roadmap”.

A Permissionless Future

Why pivot?

The Ethereum community didn’t phrase it this way at the time, but they had recognized the power of modular blockchain architecture and how it enabled permissionless innovation at higher layers of the stack. They knew this was a better approach.

This brings us to the present day. The rollup-centric roadmap is in full swing as Ethereum optimizes for credible neutrality, verifiability, security and data throughput while 1000s of (rollup) flowers bloom.

Rather than one execution sharding experiment, anyone in the world can customize a rollup, however they want for any use case they want. Some rollups will be EVM and others will be Wasm. Some rollups will use fraud proofs and others will use ZK proofs. Some will succeed and some will fail. But they’ll all be permissionless to try.

Where does Fluent fit in?

At Fluent, our mission is to bring Wasm execution on Ethereum to life.

We believe Wasm teams were onto something and we deeply align with Ethereum values. We think that ZK technology unlocks a new way to solve the problem and that 10x better developer experiences are needed to unlock access to secure blockspace.

If this resonates with you, come build with us!

Blockspace is Abundant but Inaccessible

Our industry is making great strides towards scaling blockchains while preserving end-user verifiability. The rollup-centric roadmap and modular blockchain movement have sparked a wave of permissionless innovation around rollups, zero-knowledge proofs, rollups-as-a-service (RaaS), light clients, and much more.

The result: Scalable, trust-minimized blockspace for the masses.

However, while we’ve unlocked secure, abundant blockspace on Ethereum, we haven’t yet unlocked developer access to this blockspace. Aspiring developers are faced with the hurdles of learning esoteric programming languages and blockchain-specific details. This steep learning curve creates a non-trivial barrier to entry and discourages many people from building onchain.

There’s a large pool of potential talent that remains untapped as evidenced by the 25,000 developers in web3 today and the staggering 25 million developers in the world.

Enter Fluent: Limitless Apps on Ethereum

The goal for Fluent is simple: Enable every developer to build scalable apps on Ethereum.

Think of Fluent as a translator between developers and Ethereum’s Infinite Garden. Developers should be able to step into the garden with little more than their core application knowledge - be it their app’s throughput needs or the programming language they know best.

Fluent’s job is to seamlessly translate their knowledge into the blockchain context. To make Ethereum speak their language.

A Glimpse at Fluent's Design

Fluent is a general-purpose, zkWASM execution layer (Layer 2) for Ethereum. The platform blends together three key innovations:

1. ZK Rollup

   Fluent leverages ZK rollup technology to relieve performance and cost constraints, enabling developers to build high-throughput applications while retaining the security properties of Ethereum.

   We’re currently using zk-SNARKs with UltraPlonk and KZG commitments, but are actively researching a Nova-based stack.

2. Wasm Execution

   Fluent uses a WebAssembly (Wasm) virtual machine to significantly lower the learning curve for developers. Wasm allows developers to build applications in general-purpose programming languages like Rust, TypeScript, C/C++, Go, and more.

3. EVM Tooling Compatibility

   Fluent maintains compatibility with Ethereum Virtual Machine (EVM) standards, allowing developers to execute and interact with Solidity smart contracts, use tools like MetaMask, and take advantage of EVM innovations. The result is minimal friction for EVM ecosystem users.

We at Fluent Labs are hyper-focused on not only these innovations but on weaving them together in a thoughtful and simple way to offer the best possible developer experience.

Looking Forward

This is just the start. We’re very excited for the road ahead. We envision a world where it’s easy for any and all developers to build onchain without compromising developer experiences or security properties.

The Fluent platform is currently under development, but testnet is right around the corner. We’re now taking applicants for our early builders program. Sign up here!

In the meantime, we’ll be sharing more about our progress and thinking. We value openness and plan to build in public. Here are some of the topics we’ll be talking a lot about:

• ZK research and performance benchmarks

• History and future of Wasm execution

• Sequencers and provers

• L3s and RaaS

• What’s possible with zkWASM rollups

• Rollup designs and business models

• Platform risk and censorship

Let’s make blockspace abundant and accessible to all.

Where to Find Us

• Twitter

• Discord

• GitHub

Very special thanks to our investors, advisors and friends who reviewed and offered feedback on this post 🫶