L2 Planet Learn: Celestia and Fuel
In this Issue of the L2 Planet Learn series, we focused on Celestia and Fuel Network.
Author's note: In order to understand this article well, it is necessary to have basic knowledge about rollup and UTXO.
John Adler, co-founder of Celestia and Fuel Network. The reason why I am writing this article is that I enjoy listening to him.
Celestia is a blockchain under development, Fuel Network is the first Optimistic Rollup to working on Ethereum Mainnet (only simple payment, token transfer, no smart contracts).
Although these two projects seem unrelated, it is not difficult to predict that they will work together in the near future. But of course, in order to predict this, first we must know what they are. Let's find out.
Monolithic and Modular
One of the most discussed topics in the blockchain world lately is modular architecture. This essentially means that the monolithic architecture blockchains we use today are fragmented but still interoperable.
Blockchains with monolithic architecture realize 3 basic elements together:
Execution, a computation that is, operations are performed in the system with the task of calculation.
With the Consensus task, the processes performed in the system are put in order.
With the Data Availability task, the data of the transactions made in the system are stored in an accessible way.
These three basic elements occur in the same system, which limits the potential of that system. The things that make up the system are actually the nodes, the computers themselves. When these computers try to do many things at the same time, they get into a bottleneck.
Blockchains that will work with modular architecture separate these elements from each other:
In the Execution Layer, operations are performed by computation and calculation in an off-chain manner. Rollups are used for this task. (The diagram shows Fuel, Arbitrum, and zkSync as examples)
The Settlement Layer includes Rollups and the Execution Layer. It's called "settlement".(Ethereum Mainnet is shown as an example in the diagram)
In the Consensus Layer, the transactions are put in order and the data of the transactions are stored in an accessible way. (Celestia and Eth2.0 are shown as examples in the diagram)
Thus, unlike monolithic architecture, the same nodes do not do many different works in modular architecture. The load on the system is reduced.
Celestia
Modular-blockchain structures like Celestia are designed to act only as of the Consensus Layer. So the goal of the Celestia blockchain is to execute the transactions and store the data.
So how can Celestia be used? Let's explain through an example called Celestium.
While Rollups (Execution) is placed on top of Ethereum Mainnet (Settlement), they can send their data to Celestia (Data Availability).
Thus, the rollup is on Ethereum, deposits, and withdrawals are made on Ethereum, so it does not miss the great network effect of Ethereum. But it also saves the cost of sending data to Ethereum by sending its data to Celestia, not Ethereum. It only sends Fraud Proof or Validity (Zero-Knowledge) Proof to Ethereum.
Transaction data sent to Celestia can be easily checked thanks to the Data Availability Sampling technique. Checking for the existence of data is important because, for the simplest example, Optimistic Rollup validators need to examine the data to detect invalid transactions with Fraud Proof. Similarly, if the data of the transactions made in zk-Rollup are not available, it cannot be known who owns what in that rollup.
The data Availability Sampling technique allows nodes to verify that the data of that block has been published without downloading the entire block's data. Monolithic blockchains do not currently use this, so nodes must download all data, be Full Nodes, in order to verify that data is published.
In the last case the system works like this:
The L2 Operator (validators in the rollup) sends transaction data made in the rollup to Celestia and the proofs to Ethereum.
Celestia validators send a data availability attestation to Ethereum.
The rollup contract makes sure that the data in Celestia is available.
So basically Celestia is used here as a "Data Availability Mechanism".
Relying on Celestia over Ethereum for data storage is an important choice. Problems that will occur in Celestia may affect this rollup on Ethereum, but Celestia has security measures in itself to deter malicious actors such as "slashing".
Fuel Network
Fuel Network describes itself as an "Execution Layer". As I said at the beginning of the article, Fuel is the first and only Optimistic Rollup that works on Ethereum Mainnet as trustless and permissionless. However, this rollup can only be used for simple payment and token transfers.
The vision of the Fuel team is different, they know that scaling should be in a system that can run smart contracts.
Parallel validation with FuelVM and UTXO: Fuel v2
FuelVM is a virtual machine, just like EVM. What distinguishes it from EVM is that it can run smart contracts with UTXO. Thus, the system can validate transactions in parallel.
Why is parallel validation important?
Due to the architecture of Ethereum, in Ethereum, nodes confirm transactions sequentially. In Fuel, on the other hand, nodes can confirm transactions in parallel.
Since the "state transition" of the transactions made with UTXO is clearly evident, the transactions of person A and person B who do not change on the same state can be approved in parallel. So nodes can do this because UTXO makes it clear that transactions don't conflict with each other.
This is essentially how a computer writes the unrelated words “FUEL” and “NETWORK”. Instead of typing the letters “F”, “U”, “E”, “L”, “N”, “E”, “T”, “W”, “O “R”, “K” in order, it looks like it can write two words at the same time.
Parallel operations ensure full efficiency from the CPU. The overall efficiency of the system increases as more than one CPU core can be used to validate processes. The use of more than one core of the CPU is important because while the number of cores increases in CPUs developed today, the quality of the performance given by a single core is not increased. The Fuel team thinks this is the way for developers to get the most efficiency with the greatest security. Since it is very difficult for EVM and Ethereum to allow parallel transactions due to their own architecture, they preferred to use a non-EVM-compatible architecture.
UXTO and Smart Contract
The UTXO model has been tested on smart contract platforms such as Cardano, but it has been found out to limit the user experience considerably.
This bad user experience is not experienced in Fuel because the contractID that defines that contract in Fuel contracts never changes, while the utxoID can change from block to block.
UTXO's restriction of user experience in Cardano is due to users signing the contract's utxoID. In Cardano, if two users want to sign a contract utxoID at the same time, only one of them can make a valid transaction and enter the block, while the other user has to sign the newly created utxoID. In other words, only 1 person can interact with that contract in each block.
This is not the case with FuelVM. In Fuel, users sign contractID, which is always fixed, instead of utxoID, which can change.
There is also a consensus rule:
When signing a transaction, txID, outputIndex, balanceRoot, stateRoot, and txPointer are set to 0. Because users do not know what these values are when they sign. These values may vary depending on someone interacting with that contract before “that transaction”. In other words, in the time between signing “that transaction” and adding it to the block, another transaction may interact with the contract and cause these values to change. Therefore, these values are set by the block producer as they should be, when "that transaction" is inserted into the block.
Thus, the “conflict to interact with the contract” between users is avoided. The UTXO model becomes available on a smart contract platform.
Sway
FuelVM has a new programming language called Sway, inspired by Solidity and Rust.
In fact, the first Uniswap-like application developed with Sway was announced during the testing phase.
You can test it at here
You can use block explorer at here
Conclusion
Modular building layers are being developed rapidly and we see that these developed projects complement each other. The main purpose of my post today was to show that Celestia and Fuel complement each other as Execution and DA Layer. Fuel developers state that the necessary optimization and scaling should be concentrated on the execution part because the problems in the DA part will already be solved with techniques such as DA Sampling used by Celestia.
Fuel v2 is not yet publicly available, it is still in development. If there is a public testnet before public use, I will try to participate.
Sources:
https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
That’s all from L2 Planet for now, hope to see you in other issues :)