TL;DR 

• Fuel V1 was launched as the first optimistic rollup, but the total value locked on it is rather low. Fuel team is planning to launch an innovative V2 in accordance with some proposals. 
• Fuel distinguishes itself as a modular execution layer among many scaling solutions. 
• Fuel’s innovation is to offer a structure allowing parallel transactions utilizing the UTXO model instead of Account model. 
• To enable this, they developed FuelVM where smart contracts can be executed using the UTXO model. 
• Sway programming language allowing the development of smart contracts compatible with FuelVM was also designed by Fuel Labs. 

Introduction 

Currently, scalability is one of the subjects in blockchain attracting a fiery competition. Especially considering the high potential on Ethereum where the value of cryptocurrencies has been gradually increasing, it could be argued that the cake to be shared is growing day by day. While the cake of scalability is growing, what the users are going to encounter is obvious: New Layer-1 and Layer-2 Solutions.

The importance of more sustainable and accessible solutions for the end users allowing ease of use in terms of transactions is also increasing. Given that each different approach will be more important in the future, it could be assumed that the competition among new chains will advance the crypto ecosystem.

1- What is Fuel Network? 

Fuel is the first optimistic rollup on Ethereum with its first design “Fuel V1”. The first version was launched in 2020 on Ethereum in order to create a peer-to-peer means of payment with immutable smart contracts utilizing fraud proofs. The main objective of the project is to provide an optimistic “rollup” infrastructure in an attempt to allow fast, secure and affordable transactions.

Fuel Labs, the organization developing Fuel Network, is currently working on “Fuel V2”. The concept that brings along many innovations with Fuel V2 will constitute the main outline of this report.

Fuel offers a modular approach positioning itself as the fastest execution layer. Modularity, execution layer and other important topics will be discussed in more detail in the following sections of the report. Although Fuel is an execution layer, it should be noted that it is also intending to provide solutions to the challenges encountered with many Layer-2s and Ethereum Mainnet in the race towards scalability. 

FuelVM, the virtual machine aiming programming in accordance with the transaction design of Fuel V2, is also presented as an important upgrade in the project. Moreover, for the introduction section, we believe it is sufficient to mention that Fuel Network is a protocol attempting to increase the quality of applications with the smart contract language Sway, which was developed specifically for Fuel. 

1.1- What Makes Fuel Network Noteworthy? 

Simple Answer: Difference.

We have seen many protocols as Layer-2 solutions so far. From Arbitrum and Optimism, optimistic rollups utilizing fraud proofs, to StarkNet that uses relatively complex zero knowledge proofs, the approach was rather obvious. And we can define this approach as attempts to create an ecosystem on Ethereum by hosting as much liquidity, value locked and many applications as possible. What distinguishes Fuel from its counterparts is that it stands out as a modular service. 

The solution that Fuel attempts to provide is to establish the most efficient environment to execute smart contracts both in terms of affordable transaction fees and faster transaction speed. In this context, there are two methods that you will be seeing frequently throughout the report: UTXO-based structure and Parallel Execution. Fuel’s own virtual machine, FuelVM, has UTXO-based design with a different behavior of its state machine with regards to the transactions. Parallel Execution, the method that enables this, renders Fuel Network worth considering separately from its counterparts (namely, other optimistic rollups). 

Then, let us take a deep dive into Fuel’s architecture! 

2- What is the “Execution Layer”? 

We have discussed three components of a monolithic chain architecture in our previous report on Celestia. These are Consensus, Data Availability, and Execution layers. In simple terms, it was also mentioned in the report that separating these layers provided solutions to many problems, especially scalability. 

As for what the execution layer means, we can define it as the layer where only transactions related to the blockchain are executed with a modular structure outside the monolithic chain. In this layer, transactions are rendered to be processed in the state machine. As it’s already known that rollups are scaling solutions operating off-chain, we can also state that Fuel is a layer managing transactions outside Ethereum mainnet. 

Each transaction on a blockchain results in a state change in the virtual machine of that chain. Data to be recorded in the next block is determined according to the output of each state transition. What the execution layer has to successfully accomplish is to create the accurate roots for recording each transaction and transfer these to the other layers for verification. 

2.1- So, What is Modular Execution Layer?

Let us assume that each transaction executed proceeds in a way that produces new blocks with an accurate technique and accessible roots. The goal of the modular execution layer, which would process this off-chain in a rollup, is to increase the transactions per second (TPS). And just as important, it is also to reduce latency. Accordingly, it will be possible to reduce the consensus time of blockchains as well. 

While the modular execution layer has high TPS, its main responsibility is to group the batch of transactions in an accurate way with data availability. Additionally, it also has to send these batches of transactions (in fact, transaction roots) by designing a verifiable computation system. Of course, with a verifiable computation system, what comes to one’s mind are fraud or validity proofs.

For Fuel Network, it should be noted that there are potential challenges due to being an optimistic rollup utilizing fraud proofs. Especially if a modular execution layer is using fraud proofs. 

2.2 – Why Does Fuel Prefer Modularity? 

Here, let us go beyond the general definition of scalability and refocus on transactions per second (TPS). In order for transactions in the rollup to be simultaneous and fast, it needs a certain bandwidth. We can interpret bandwidth as the capacity for processing transactions. Actually, Solana is doing this, and we will be discussing the differences in more detail in the following sections of this report. Solana, one of the Layer-1s with monolithic architecture, increases bandwidth of a single block by increasing block size. However, the increase in block size creates various risks and results in a node structure with difficult liveness. 

Alright then, let us take a look at Fuel’s claims again: 

• Act as the fastest execution layer
• Be a high-security layer
• Allow flexible network throughput 
• Have permissionless access 

Expecting to achieve all these in a monolithic structure will of course remind us of the scalability trilemma. We have already seen in the past that sudden increase in network usage such as successive minting of NFT collections, when important token sales take place or special events for limited time periods has also had a significant impact on gas fees on Layer-2 networks. For these reasons, Fuel Network stands out with a modular “execution” design. 

When we take a deep dive into modular architectural approaches, we already know that Ethereum has updated its roadmap with a rollup centric, which also includes sharding. Considering the fact that Celestia will be providing data availability as a service, we can see that there’s a serious potential for execution layers. 

Especially, the fact that Fuel Network is developing a unique virtual machine, transaction architecture, and a smart language to increase the efficiency of the execution layer with V2 indicates that they want to benefit from this potential. 

3- Architecture of Fuel Network 

Fuel has many technical components, the technical details of which have been briefly discussed above. Before going deep into these components separately, we believe it is useful to explain the components in terms of terminology. 

3.1- What is UTXO and Why Fuel Uses UTXO?: 

UTXO (Unspent Transaction Output) is a state accounting method, widely-known in cryptocurrency terminology. The purpose of UTXO is to systematically monitor P2P (Peer-to-Peer) transactions. In this way, data such as how and between whom the transaction takes place on a blockchain or the remaining balance of these parties can be specified as unspent outputs. The main purpose of using UTXO is not to deal with Ethereum “Account” standards or protocol-level wallets. For this reason, blockchains such as Bitconi and Cardano preferred to use this model. The model is entirely based on individual transactions. In fact, to have a better understanding, we can imagine all the scenarios in which certain people constantly exchange cash with one another. 

All transactions and UTXO outputs transition the system into a new state. And naturally, each state transition requires verification. In this context, with the relevant consensus model (assuming Nakamoto Consensus for Bitcoin), considering each node aims to constantly keep everything up-to-date by downloading the last state of the block for the verification in the relevant blockchain, it is more accurate to say that batches of transactions instead of single transactions are kept as a block. Accordingly, state changes of blockchains utilizing the UTXO model takes place with groups of transactions rather than a single transaction. 

The alternative to the UTXO model for state transition in blockchains is the Account Model that we see on Ethereum. While we should note that we will not be discussing the details of Account Model, we believe it is of importance to indicate that Fuel differs with adopting the UTXO model from other Layer-2 solutions, which typically utilize the Account Model. 

In sum, for UTXO, what needs to be understood is simply the output regarding the individual wallet holding a specific coin. 

Moreover, we believe it is useful to discuss what Cardano failed to achieve despite using a UTXO-based model. Cardano aimed to develop some products on UTXO-based blockchains. And, we should also mention that there have been development processes creating various arguments in this regard. 

The story begins with the first AMM (Automated Market Maker) experiment on Cardano. The main problems here were related to the UTXO modeling of the smart contract. With AMMs, it is possible to make similar or parallel transactions on a single pool, i.e. the contract. However, the problem was that the UTXO state of the smart contract would change with the first transaction. Long story short, it was only possible to make one transaction in each block.

If we go back to Version 1 structure of Fuel, we can define it as a peer to peer payment rollup adopting the UTXO model. As it was UTXO-based, it would be possible to develop immutable smart contracts within that time frame. Unlike upgradeable contracts, the immutable contracts would continue to have simple structures. However, it was promising to have developments in a state model based on UTXO over the above-mentioned Cardano paradigm. 

So far, we have briefly discussed the story of development adventures with UTXO. In the following sections, Fuel V2’s golden child, FuelVM, will be discussed in as great detail as possible. 

3.2- FuelVM from A to Z 

We have discussed the restrictions of developing with UTXO. The first approach discussed to enter the world of smart contracts was to make developments in the Ethereum Way. At the end of the day, as Fuel will be responsible for “Execution” as a Layer-2 solution, this thesis is meaningful. 

Before the deep dive, it is useful to understand what a Virtual Machine (VM) is. VMs are physical machines that mimic a virtual computer having an external hardware infrastructure. Probably the most important example for a virtual machine on blockchains is the EVM (Ethereum Virtual Machine) run by nodes to execute smart Ethereum smart contracts. In this context, at the end of the day, Fuel will have to run EVM as it will be a modular execution layer on Ethereum. However, this execution should be with UTXO states. 

Accordingly, a traditional UTXO holds the following info: 

1. Amount of coins 
2. Spent “hash” indicating the coin holder

.. 

However, the UTXO will need the following in order to run EVM 

1. Amount of coins
2. Contract ID 
3. Contract Code “Hash” 
4. Storage Root 

In other words, it will need to have a structure similar to typical smart contracts. 

• Execution Model 

First of all, a new UTXO needs to be generated in return for any transaction. However, it will need to ensure the continuation by changing the relevant state while the state is at the same contract ID. Accordingly, the users will interact with the contracts that will be created. Afterward, the generated UTXO contracts should be able to interact with one another. In other words, the transactions to be made should be able to announce to the network which contract they will be interacting with. Finally, it will be necessary for these structures, which can be called contracted UTXOs, to have a unique structure with the contract ID in addition to typical UTXOs. 

• Transaction Format 

Here, there is a critical point. Each UTXO contract to be generated can be used multiple times in a single block depending on the contract ID. Therefore, in the transaction to be made, the user will sign the contract’s ID instead of the UTXO of the contract. In this way, the users will not have to be interested in the implicit UTXO states while deciding on which contracts to interact with. And for the verification here, actually, it is the block producer to determine what UTXO contract to be used by the transaction. 

Due to the deterministic structure of UTXO states, here, it is necessary to get the users to depend on the conditions of blocks. The fine point here is that the users making the transactions in Fuel will only decide on the contracts to make those transactions. On the other hand, the transactions execute the UTXO contracts, or the appropriate codes in that block. At the end of the day, it is the users who hold the reins. Actions of users are overlapped with the decision of the block producers. 

In terms of applicability on Ethereum, we have actually mentioned how close a UTXO-based contract can resemble the Account-Based model. And on the way to this, as mentioned previously, there are various motivations for scalability for a modular execution layer. These motivations can also be considered as advantages of a UTXO contract compared to an Account-Based one. 

1. It is possible to manage which contracts are to be interacted with utilizing UTXO outputs. Accordingly, it will be possible to make transactions with the same outcome while also executing these transactions in parallel. The advantages of parallelization will be discussed in more detail under “Parallel Execution”. 
2. Unlike Account model, it is not necessary to trace accounts with a balance of zero in the UTXO model. Hence, the items that do not create a specific “nonce” value will not need to be traced. It will enable savings in terms of state sum as well. 

3.3- What is “Parallel Execution”? 

In the broadest sense, Parallel Execution can be defined as executing multiple operations with multiple providers within the same time frame. For instance, processors are developed with a multi-core structure with a modular architecture. Execution of multiple operations by these processor cores from the same point separately can be given as an example for parallel execution.

Alright, coming back to blockchains, parallel execution is a widely discussed concept, and it was actually patented in 2016. It is about the parallelization of a transaction before it is executed simultaneously with multiple nodes on a blockchain. 

If we are to take a look at the topics discussed and where they are used briefly; 

• Solana Sealevel: Except for the UTXO model, parallel execution was made possible with some modifications to the Account-Based model. There is also a proposal which aims to design state transactions accordingly for an EVM-oriented architecture. States to be used in the transactions are collected before execution, and executed parallelly. 

• EVM-oriented parallel execution: As a reference, the improvement proposal “Easy Parallelizability” by Vitalik Buterin in 2017 can be reviewed.. In terms of scalability in Ethereum, one of the moves that can be taken is to speed up EVM. In fact, it is necessary to speculate on EVM transactions for this proposal that would enable the fast verification of transactions by the nodes. The argument is that 70% of the execution of a transaction on EVM takes place by storing states. The remaining 20% of the execution process is spent trying to access the randomly distributed states, unlike parallel execution. Therefore, the current execution method on a way to fast EVM has been interpreted as a bottleneck. For this reason, the aim was to execute transactions in parallel by speculating the state model of Ethereum to parallelize it. 

The challenge for the parallel execution in the Ethereum improvement proposal is due to the fact that random transactions are taken into nodes one by one. The size of the states held by Ethereum blocks with a Merkle tree is relatively large. Therefore, the node that needs to pull all the data would need a greater RAM (Random Access Memory). And this would result in challenges for verification and node setups, which will be discussed in the following sections of this report.

• Sui Network: In short, they plan to rearrange the global state of the blockchain with a DAG-based consensus model. With this approach, they parallelize the transactions on the same blocks in order to run the rearranged global state in parallel, just like Solana. Main propositions of Sui are built on Move language and on MoveVM. As a programming language being developed since 2018, Move is working on eliminating the smart contract development limits on parallel execution. 

• Potential Parachain with Parallel Execution, Gear: Customizable subunits of Polkadot, Parachains basically work with the “sharding” method. Beyond the EVM focus, the development takes place on WASM (Web Assembly) contracts. For the parallel execution capability, the “Actors” sort the states separately and direct them to a queue. The plus side of this architecture enabling parallel transactions asynchronously is that it does not wait for another transaction to be completed before executing them. 

We have already mentioned that the UTXO model is composable in order to compile the necessary information to parallelize the transactions. UTXOs that do not directly overlap are rendered executable transactions with an asynchronous initialization. Moreover, this parallelization is important not only for the transactions to be included in the blocks, but also the Fuel nodes where we will be carrying out verifications between blocks. The potential increase of CPU efficiency will provide acceleration both in terms of verification and execution. 

There is a challenge awaiting Fuel, which is also a dilemma for parallel execution. The basic issue about execution is to collect the signatures of each transaction that takes place on the blockchain. As mentioned earlier, parallel execution is possible as long as the collected signatures are parallelized from the same point. The signatures to be subject to this parallel execution can be considered as “access list“. 

At this point, it is necessary to optimize as much as possible while adding the transactions to the block and transferring the necessary proofs for verification to the relevant full nodes of Fuel. The reason for the optimization is to eliminate the need for more RAM considering the efficiency/security dilemma for parallel execution. This actually causes the number of Solana validators to be quite limited in a way that you can even fit them in a room. (Hardware requirement) 

3.4- Fraud Proofs 

We have mentioned that Fuel Network adopts the Optimistic Rollup architecture. Rollup can be defined as external chains by undertaking the transaction load and sending proofs to the mainnet. Therefore, the point where Fuel can contribute especially to scalability will be a new state design in which it collects signatures for transactions in addition to how it will render this new state design part of the proofs. 

Fraud proofs are basically a method, not a proof. The rollup sends the transactions on it in a batch to Ethereum mainnet assuming they are valid. However, the verification depends on one of the nodes of the chain or any contract starting to check the transactions. 

3.5- So, What is the advantage of UTXO design for Fuel as it is an Optimistic Rollup? 

Actually, the first proposal regarding this subject had been put forward by John Adler in the first version of Fuel. 

Comparing it to the account model; 

A fraud proof is required for the verification. For instance, when one of the nodes in the chain wants to perform this verification, it will try to check whether the previous and later versions are the same. However, to smoothly carry out this verification, dynamic state structures such as “Sparse Merkle Tree” or transactions should be sorted. This is a requirement for the Account Model. 

With UTXO, the following can be achieved: 

Transactions can be indexed to a sequential state tree. With the indexing process, transactions to be reviewed for verification can be referenced in the same block. While this is possible to carry out based on the input and output IDs of transactions, the remaining block data could still remain. In such a setup, the following takes places gradually under the supervision of a fraud proof: 

→ Is the transaction included in the cluster of sequential incoming transactions? 

→Do I have a witness, a proof verifying that the transaction took place before the state? 

→Do I have a witness, proof that the transaction took place after the state? 

UTXO must create a produced output and a spent input. In this case, it is also checked whether all input outputs in the block have taken place by a single transaction. The entire approach to a transaction above is ensured by a separate state for the block; thus, enabling a compact design.

What is aimed with compactness here is to create light client nodes to provide security for Fuel. On the current Ethereum chain, light client nodes can only hold the block header information while relying on full nodes for data availability due to their limited bandwidth. However, it is one of the missions to carry out the verification with a single block header from the state data in a compact way. Another mission is to provide dynamic working nodes which would not be affected by the number of transactions. If we have to put more emphasis on nodes, we can also mention that there will be pruned state structures for both Ethereum and Fuel in the future. Fuel will be able to validate previous UTXOs with data availability through the fraud proofs, thus it will gradually create “semi-stateless” or “stateless” node clients. 

So far in the report, we have discussed the features of state modeling for Fuel. However, as it is a rollup, it will gain significance with the applications built on it. As we have explained the structure, we can move forward to the details about the Swag programming language, which will run and configure FuelVM. 

4- FuelVM’s Companion: Sway 

Sway is a smart contract language developed by fuel Labs to build applications on Fuel. Sway, which is a Rust-based language, is similar to development languages of Solana, Aptos, and Sui. Also, it is no surprise that these blockchains are also capable of parallel execution. 

The benefit of Sway as it’s a Rust-based language is: “Low-level Compiling”. Considering from a hardware perspective, node requirements must be low for a rollup as it is also utilizing fraud proofs. Rust is relatively the most appropriate language for this. Another important feature of Sway is that it is a Domain-Specific-Language. Sway includes functions developed for the purposes of FuelVM. Moreover, there is also a tool called FORC (Fuel Orchestra) for the installation and package management of Sway among other things. This is in a way similar to “Cargo” used for quick installation of Rust. 

Sway’s contract design consists of four components: 

• contract 
• predicate
• script
• library

The first three of these program types can also be placed on the blockchain Fuel. However, “library” is a component that can be used over and over again, as in the case for typically familiar software libraries. Each separate file developed with Sway consists of declaring these program types separately. These can also be likened to contracts implemented in a nested manner. 

Contract: Records the state similar to the contracts on Ethereum. It can perform token transactions or can constitute the basis of the program. The critical point for FuelVM is that transactions to be executed parallelly will communicate according to the contract ID. At this point, contract ID is deterministic and immutable. Furthermore, there is no “self-destruct” function on contacts developed using Sway. When a contract is deployed on the network, it is intended to live forever. 

Script: It is a side component enabling the contract calls at the Bytecode level. The important point, which will be underlined again when examining applications developed with Sway, is that it is able to perform atomic transactions. With a single “approval”, structures enabling consecutive “swap” or other transactions are developed on this component. It is, in a way, similar to Account Abstraction; however, its design is different in terms of security.

Predicate: It is a script file enabling whether the “Predicate” value is true or false in a development environment where UTXO outputs are spent and produced.

In general, it is possible to state that this component is developed for UTXO and is aimed at facilitating state management for the developer. 

There are no benchmark tests yet on how the developments related to Sway and Sway will perform in FuelVM. For benchmark tests, Fuel Labs team is waiting for a more stable network state, where everyone will be able to gather the same outputs in a consistent manner. 

4.1- Sway’s Potential – Fuel Ecosystem 

We have mentioned that sway is developed as a domain-specific-language. The factor that can reveal its potential is that Sway will be used on a modular execution layer. Since fuel will appear in many places with its fast computation method and as an execution method, it will lead to the need for more development with Fuel. And this may have a natural effect on the growth of Fuel ecosystem, increasing the number of developers. Especially in the scenario where Fuel is also included in the modularity roadmap of Celestia, in addition to Fuel as a Layer-2, it may be possible to enable compatibility of fuel and its dApps with many alternatives such as EVM and WASM. 

If we talk about a relatively “bullish” narrative; we can also indicate that the budget allocated for Fuel ecosystem development is rather high. In the past months, basic dApps have been developed during hackathons. Especially in a scenario where the new smart contract languages will try to appeal to Solidity developers, enabling the development of EVM-compatible basic applications may result in a sustainable growth here. Grant programs, hackathon rewards and many other opportunities are available for Fuel. 

There are a few other factors that can encourage a developer to develop using Sway as well. In addition to libraries developed by users, a library where certain contract standards are specified and easily integrated such as OpenZeppelin for Solidity is also developed for Sway. Moreover, developer kits such as “formatter” which can be installed as extensions are also an option for Sway. 

The fact that it is a Rust-based language may also increase developer adaptation. In this way, it may enable Web2 developers to quickly join the world of Web3. We can also mention that the community interaction to answer the questions of developers is also not bad at all. Individuals in Fuel Labs team support external tests on Sway and make updates based on the outputs. 

Right now, many basic things such as NFT, Multisig Wallet, DAO, and Fundraiser have been developed on Sway’s own documentation. At the same time, we should also mention that “Name Service” was developed during ETH CC Hackathon, and many projects have emerged at Fuel-specific hackathons. We can also say that August-September of 2022 will be rather rich in terms of developments. 

• Sway Swap: DEX developed by Fuel Labs and open to user experience on the testnet. An example to understand the “approval” and consecutive “swap” transactions. 

5- Fuel’s Potential Token Story 

Transactions on an optimistic rollup are sorted by the Sequencer and the data of these transactions is then sent to the mainnet. Afterward, the waiting period begins for the finality of transactions on a rollup. During this waiting period, the Verifiers check the accuracy of data sent to the mainnet. While waiting period and cryptographic proofs on rollups, a problem appears while enabling the operation of the system as secure as mainnet: censorship resistance. 

Censorship resistance is becoming increasingly important every day. Sanctions on accounts linked to Tornado Cash reminded web3 users of the importance of censorship resistance again. Many American-based company blocked the blacklisted wallets from their frontend as a result of the OFAC decision. Since this does not prevent direct interaction with the contract on-chain, it is possible to move the assets in the wallets as desired; however, DYDX, an appchain operating as a rollup, also blocked the relevant wallets. Since this was implemented at the sequencer level, blocked wallets are not able to use DYDX platform except for certain transactions. Although the blocked wallets are able to withdraw their assets using the exit function on rollups, there is a direct blacklisting at the platform level. So, there is still censorship. It is worth noting that DYDX does not produce decentralized blocks and the sequencers it not decentralized. On the other hand, on Arbitrum network, the users are able to perform their transactions through Ethereum mainnet after the end of the waiting time without getting blocked by the sequencer. The main problem here, though, is that censored users are faced with risks such as delay time, the ability to access fewer functions, and in some cases, platforms freezing their assets. Eliminating these risks and ensuring the liveness of the rollup can only be possible by decentralizing the sequencer. Here, different tokenization models emerge in order to decentralize the sequencer. Before Fuel’s token model, let us take a look at the pros and cons of PoS token model for rollups. 

Proof of Stake token model: On a rollup producing decentralized blocks and adopting the Proof of Stake token model, if the majority of sequencers decide to censor the blocks, they can freeze the users’ assets. This possibility of censorship is undesirable for a Layer-2 network targeting censorship resistance as much as the mainnet. 

Fuel’s token model:

One of the most important reasons for the complexity of consensus and leader selection in blockchains is to guarantee security. Unlike other blockchains, rollups do not need algorithms such as complex leader selection, consensus or fork rules as they share security with mainnet. So, where will the token be used? 

• Sybil Protection Mechanism: 

The primary problem to overcome for decentralized block production is the prevention of sybil attacks. Since rollups, like other blockchains, have limited block space, tokenization of this block space can be seen as an ideal sybil attack protection mechanism if the fee and MEV revenue of the platform is shared with the token holders. Limited blockchain capacity means that the users will have to pay a certain fee to get their transactions approved on the blockchain. As it will be the sequencer producing the block who would collect the fee, the necessary reward mechanism against sybil attacks can be established. 

• Decentralized Block Production: 

We have discussed that the users might be censored in the scenario where the majority of the validators in rollups adopting the PoS token model prefer censorship. Rather than an inflationary PoS token model, Fuel network’s token model is only for the selection of the leader. If a user wants to generate revenue from the platform or to increase the chance of finding a block, they will need the token. Here, Proof of Burn mechanism is proposed for finding blocks. 

• Proof of Burn: 

For block production, everyone bids the amount of tokens they can burn like in the case of an open auction. In return, they can produce the relevant block to earn the block rewards. Hence, the token offered is burned to add value to the token’s price. 

6- Final Remarks 

Many of Fuel Network’s claims are on what it can achieve and accomplish in the future. It is a well-known fact that Ethereum scalability has turned into a fiery race, and at this point, technology developers are trying to get their own share from the cake. However, “I think”, what needs to be clearly said is that Optimistic Rollups have their own place in this future. It is obvious that Optimistic rollups are still in the race compared to ZK (Zero Knowledge) Proof based rollups in addition to the total value locked on Optimism and Arbitrum until now. At the end of the day, all these technologies are rather promising, and the development of another rollup technology will not easily block Fuel Network in this race. 

As the share from the scalability cake has already been shared at the beginning of this report, I believe responsiveness to the needs is rather significant. Standing out as an execution layer is also an important point. In addition, it should also be noted there is a practice of modularity along with Celestia. For this reason, I also think that Sway has a structure that is open to interoperability. 

And the most promising feature is that it is not EVM compatible! Let us admit that EVM has developed lots of things so far. However, I think the flexibility from not being EVM-oriented will have a significant place in the future of blockchains. FuelVM has the potential to gather an audience around itself thanks to its performance scaling and experimental approach. Although these approaches can be thought to be newly developed, especially with Fuel V2, the idea of a UTXO-based VM, state listing accordingly, and many other topics have been considered for years. Therefore, I can say that it is difficult to point out a major detail where FuelVM may be lacking. 

In any case, the future holds the answer to many things. Complex applications for a UTXO-based smart contract architecture have not been developed yet. Technically, Fuel Network has not been subjected to a stress test. There have not been realistic tests on how a crowded execution layer can compile many transactions with fraud proofs. We should be aware that such factors should not be ignored for realistic scalability. 

---

Disclaimer: This article has been written for informational and educational purposes only, does not contain investment advice, and should not be considered by the reader as an advisory text. Financial losses may occur on dApps developed on blockchains due to software vulnerabilities. Users are recommended to do their own research before using and investing in projects. The author or Lytera may not be held responsible for any losses that may occur.