Why SQD is excited about Fuel
The year is 2050.
No individual uses the Ethereum mainnet anymore. All the economic activity happens elsewhere.
This could well be the future. Already, the thesis for a lot of the Layer-2 activity has been that Ethereum’s mainnet is only for those that need very high security guarantees and are willing to pay the fees. Everyone else might just as well use something that’s built on top of it.
In theory, this sounds great. If it wasn’t for an increase in rollups that hit their capacity limits and users realizing that using a rollup with a centralized sequencer isn’t very decentralized. Especially optimistic rollups have come under scrutiny with delayed implementation of fraud proofs. Until then, you could have defrauded as you wish - since no one could have proven otherwise.
Obviously, this is a little exaggerated, yet it’s making an important point: trustless often means you should trust less and look a little deeper. One team that has taken this to heart is the team behind FuelVM.
What is Fuel?
Fuel launched its first iteration in 2020 as an optimistic rollup for payments. While it didn’t have smart contract capabilities, it was the first to have fraud proofs. They were ahead of the rest with that one, but over the years, they realized that something else was still missing from the growing L2 ecosystem.
Enter Fuel V2.
Their website calls it an Operating System Purpose-Built for Ethereum Rollups. As such, their TAM is all of Ethereum Rollups, 80+ according to L2 beat. On top of that Fuel operates also as an independent chain.
But what does it even mean to be an operating system for rollups?
Normal people never think deeply about operating systems. Except for Apple Users who seemingly can never sh*t up about their MacOS supremacy. Next time you meet one, ask them which OS powers 80% of the stock market…. It’s Linux. An open-source OS with a penguin logo.
Unfortunately for them, MacOS does not work on blockchains or rollups.
In general, OSs are low-level software that powers a computer's basic functions, like scheduling tasks. They control memory, hardware, software, and processes, making them incredibly powerful.
Each blockchain has its own system to accomplish these things: the EVM for Ethereum, SVM for Solana, and so on.
The team behind Fuel (OG Ethereum builders) believes that "Ethereum represents a philosophy or framework on building a fairer and more equitable world," and the technology they are building is designed to address the challenges Ethereum's modular and multichain L2 ecosystem creates.
Concretely, Fuel Solves at least 4 issues of Ethereum Vitalik has talked about:
- Multidimensional Gas Pricing
- Diversity in Ethereum VMs
- Fast Finality with Optimistic Rollups
- Stateful Compression
One thing Fuel does tremendously well, and we are generally hyped about is: Parallelization.
Parallelization
A buzzword of the current cycle, a commonplace computing approach every else in the traditional web. The way Fuel implements it is through having strict access lists. Whenever a user wants to make a transaction, they also have to indicate which contracts their transactions will touch on.
While this sounds intimidating at first, as an end-user none of this is a burden on you. It happens automatically in the back-end. All transactions on Fuel consist of
- inputs, a list of all the contract UTXOs the transactions interact with, as well as data to unlock the UTXO.
- Scripts: which batch function calls together, optimizing gas fees
- Outputs: the UTXO that is newly created
- Gas information: fees and limits
- Witness: meta data and digital signatures.
By specifying all the necessary inputs, the VM can execute all the non-contentious transactions in parallel. Since all outputs are included for validation, there is no need to execute overlapping transactions in sequence, meaning even validation is fully parallelized.
But wait a minute, UTXO? I haven't heard that since Bitcoin...
UTXO is short for Unspent Transaction Outputs, a different system for handling transactions and balances in a blockchain. Ethereum uses an account model, which is similar to holding money with a bank. Every time you want to transfer money, the bank you're transferring from checks if you have sufficient funds, and then the money is added to the recipient's account.
UTXO, however, is more like handing out cash to other people. Multiple transactions can be made concurrently between the same parties.
Every transaction sent creates a new unspent output. This means you can trace everything back, as each UTXO can only be spent once.
Why UTXO?
Since Bitcoin, no major chain (we're discounting Cardano here for reasons) has run on a UTXO model, so the uneducated guess could be that it's simply not that great.
Yet, Fuel proves that wrong. UTXO has benefits and allows a network design that would be impossible with the account model.
Reduce state bloat
The biggest bottleneck for scaling Ethereum at the moment isn't what you'd expect. It's state read and write access through its clients. The size of the Ethereum blockchain already measures over 1100 GB and will only increase from here. This forces operators to switch to SSDs for storage, which historically don't scale as fast as chains grow.
UTXO enables Fuel to prune state, reducing the cost of running nodes, decreasing overall state bloat, and therefore making running nodes more accessible - an important factor in maintaining decentralization.
Performance
As described above, UTXO plays an important role in enabling parallelized execution of transactions of Fuel. FuelVM can take full advantage of multi-core processing this way.
Native Assets
Who hasn't wondered why they need ETH when trying to swap $100 USDC to $100 USDT? It's hard to explain to someone used to TradFi why they can't just pay the fees from their initial balance. There are improvements in that realm, but ETH remains king when interacting on Ethereum. You can't use your USDC to pay those gas fees.
Fuel has a completely different approach similarly enabled by UTXO. Remember Ordinals? They were basically native assets on top of Bitcoin, which were created by adding data to a UTXO.
Similarly, Fuel treats all the assets as native assets. This speeds up transactions and uses less sate. One transaction can have multiple coin inputs and outputs, etc., without needing to differentiate and execute two separate transactions (smart contract calls vs. deployments) as is typical on Ethereum. Simple, clean, powerful.
The one challenge with UTXO is contention. Fuel solved this by requiring multiple parties to sign different parts of the contract UTXO. So whenever Alice initiates a transaction to Bob, it is done via the contract ID and not the UTXO (recall that there's always just one, which would make it impossible for 2 people to simultaneously use it).
Alice indicates which contract she wants to interact with without forcing the contract to be in a particular state before or after execution.
In short, Fuel is going about designing their network very differently from other teams that are currently working on scaling Ethereum. That in itself is exciting enough, as diversity is in our all interest.
But there's more to Fuel than smart architectural choices.
S(w)ay no more
I can hear the sounds of violins
Long before it begins
Make me thrill as only you know how
Sway me smooth, sway me now
- Michael Buble
You've heard of Rust, but have you heard of Sway yet? It's Fuel's native programming language inspired by Rust and created with the goal of improving on Solidity - there is much to be improved on that one - and the Move programming language. Overall, the creation of Sway rests on the idea of bringing modern principles of programming to Web3.
While a new language means friction at first, Sway might just be worth getting into. It has safety features such as checking for reentrancy attacks and might therefore save your project from Lazarus DAO or other highly profitable trading strategy pursuers.
You won't be thrown into the cold water either, as Fuel provides a holistic toolkit for anyone to get building with, which includes a package manager, VS code extension, testing infra and more.
At this point, surely Solidity vulnerabilities have caused sufficient havoc for people to consider at least trying another language. Anyway, we're looking forward to fewer exploits and dApps building on Fuel.
Speaking of those, there are already builders developing ahead of Fuel's upcoming mainnet launch.
Fully Onchain dApps
Fuel is a great platform for the onchain maxis. It enables the creation of dApps that want everything to be onchain while allowing users to use any asset or wallet to interact. This makes it especially attractive for any DeFi use case or marketplaces as devs only have to write the code once, and then automatically, all assets are supported.
A few dApps worth mentioning are:
- Spark, a fully onchain order book DEX, an alternative to swapping in AMM DEXs
- Thunder, allowing users to trade NFTS fully onchain
- Fluid: a Fuel Native Stablecoin, because who doesn't love to keep some liquidity in a stablecoin
- Griffy: a prediction market where everything is onchain.
We expect there to be a thriving ecosystem of dApps once Fuel goes live on mainnet. Which is very soon! Basically imminent.
Lastly, the Fuel team's commitment to powering fully onchain dApps as well as their focus on delivering decentralization by making it easy even for light clients to contribute, is impressive.
In a world of people copying each other, it's refreshing and encouraging to see a team building something different. In a sense, a contrarian move. But at the same time, if Fuel works out, the entire Ethereum ecosystem will benefit from it.
"In order to be irreplaceable, one must always be different." - Coco Chanel
SQD has partnered with Fuel to facilitate access to its data. If you're interested in building on Fuel with SQD data, get in touch.
For more details on indexing Fuel, check the SQD Docs.