SOME INFORMATION
ABOUT
FUEL NETWORK
What is FUEL
Blockchains are moving away from a monolithic design, where consensus, data availability, and execution are tightly coupled. The future is modular, where execution is separated from data availability and consensus (e.g. tomorrow's Eth2, or Celestia). This separation allows for specialization at the base layer, delivering a significant increase in bandwidth capacity. At Fuel we are building the fastest execution layer for the modular blockchain stack.
Fuel v1 began as a layer-2 (L2) scalability technology for a monolithic Ethereum. It was the first optimistic rollup on mainnet Ethereum, deployed at the end of 2020.
Today, Fuel is the fastest modular execution layer. Fuel delivers the highest security and flexible throughput, with a focus on a superior developer experience.
Fuel v1 began as a layer-2 (L2) scalability technology for a monolithic Ethereum. It was the first optimistic rollup on mainnet Ethereum, deployed at the end of 2020.
Today, Fuel is the fastest modular execution layer. Fuel delivers the highest security and flexible throughput, with a focus on a superior developer experience.
Here’s how we do it:
01
Parallel transaction execution
Fuel delivers unmatched processing capacity through its ability to execute transactions in parallel by using strict state access lists in the form of a UTXO model. This enables Fuel to use far more threads and cores of your CPU that are typically idle in single-threaded blockchains. As a result, Fuel can deliver far more compute, state accesses, and transactional throughput than its single-threaded counterparts.
02
Fuel Virtual Machine (FuelVM)
Describe this step of your work or your client's step to get results. Add some specifics about the service, what it includes. And tell what your client can get. What kind of clients do you work with, what inspires your work? What is your team proud of? What are your values and motto? Add a simple explanation in one or two sentences.
03
Sway Language
Describe this step of your work or your client's step to get results. Add some specifics about the service, what it includes. And tell what your client can get. What kind of clients do you work with, what inspires your work? What is your team proud of? What are your values and motto? Add a simple explanation in one or two sentences.
Why Modular Execution?
Fuel was designed and built specifically to be fraud-provable, which enable support for trust-minimized light clients. Trust minimized light clients and shared data availability enables trust minimized bridges to other modular execution layers, something impossible to achieve between L1s.
What this means in practice:
Fuel’s optimization for fraud proofs is the use of the UTXO model, which in turn means Fuel has no global state tree or account trees. If you wanted to apply the general construction of a fraud proof to a chain that uses the account model like Ethereum, the cost could be unbound, making it extremely expensive to produce a fraud proof. In this general construction of a fraud proof, given a pre-state and a state transition, you locally execute the transition and compare the output to the post-state produced by the block producer. If these differ, the post-state by the block producer was invalid. If you apply this general fraud proof model to Ethereum today, someone could create a transaction that calls many different contracts, and those contracts could each have up to 24kb of bytecode. In order to locally re-execute, you need to provide all the bytecode for all the contracts that were interacted with.
What this means in practice:
- Long-term liquidity access
- Users can validate the chain without having to run full nodes
- Safely bridging assets
Fuel’s optimization for fraud proofs is the use of the UTXO model, which in turn means Fuel has no global state tree or account trees. If you wanted to apply the general construction of a fraud proof to a chain that uses the account model like Ethereum, the cost could be unbound, making it extremely expensive to produce a fraud proof. In this general construction of a fraud proof, given a pre-state and a state transition, you locally execute the transition and compare the output to the post-state produced by the block producer. If these differ, the post-state by the block producer was invalid. If you apply this general fraud proof model to Ethereum today, someone could create a transaction that calls many different contracts, and those contracts could each have up to 24kb of bytecode. In order to locally re-execute, you need to provide all the bytecode for all the contracts that were interacted with.
Fuel’s technology comes together to provide a superior developer experience. Here’s how we do it:
Sway and Fuel Toolchain
The FuelVM is designed to be vertically integrated with tooling.
Unlike EVM which was designed without a language from the start, the FuelVM is built alongside its companion language, Sway, ensuring it has handy and efficient ops, such as getting specific parts of a tx. Sway is a Rust-based DSL created specifically to leverage a blockchain VM without needlessly verbose boilerplate. Sway leverages Rust’s safety and catches errors and bugs at compile-time, giving developers peace of mind.
Fuel Labs has also developed the Fuel Toolchain: the full stack of tools for enabling/assisting the Fuel application development experience. Read more about the Fuel Toolchain.
Sway and Fuel Toolchain
The FuelVM is designed to be vertically integrated with tooling.
Unlike EVM which was designed without a language from the start, the FuelVM is built alongside its companion language, Sway, ensuring it has handy and efficient ops, such as getting specific parts of a tx. Sway is a Rust-based DSL created specifically to leverage a blockchain VM without needlessly verbose boilerplate. Sway leverages Rust’s safety and catches errors and bugs at compile-time, giving developers peace of mind.
Fuel Labs has also developed the Fuel Toolchain: the full stack of tools for enabling/assisting the Fuel application development experience. Read more about the Fuel Toolchain.
Fuel brings scale to Ethereum without sacrificing decentralization.The FuelVM is designed to reduce wasteful processing of traditional blockchain virtual machine architectures, while vastly increasing the potential design space for developers. The FuelVM can use all the threads and cores of your CPU to validate transactions.
As a Modular Execution Layer, Fuel can function in any one of these categories. Developers can configure Fuel as-needed by switching out a few modules in the client.
The Ethereum community has suggested many implementation improvements to improve EVM performance. Unfortunately, many of these improvement proposals haven’t been implemented because they would break backward compatibility.
Execution layers built on Ethereum give us a new opportunity to build something better. Designs don’t need to be backward compatible and in fact, can do whatever is necessary to deliver global throughput and adoption for Ethereum. The FuelVM is the EVM greatly improved. Check out this non-exhaustive list of EIPs (Ethereum Improvement Proposals) implemented in the FuelVM.
The FuelVM and EVM have a lot of overlap. Here's how they're different
The FuelVM has a globally shared memory architecture instead of context-local memory
The FuelVM has a globally shared memory architecture. Instead of every contract call having its own separate memory space, call data, and return data, all contract call frames share global memory. This chunk of memory is shared amongst all call frames and is globally readable. This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize, copy from call data to memory, etc.
The FuelVM is designed for fraud-provability
The EVM is a complicated machine to construct fraud proofs for. It usually requires a second layer such as WASM or MIPS to be interpreted into a fraud provable system.
FuelVM has multiple native assets
In Ethereum, the only native asset is Ether. It’s the only one that gets first-class treatment in terms of cost and ability to be pushed and pulled through a call. In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native-level call and optimization.
Execution layers built on Ethereum give us a new opportunity to build something better. Designs don’t need to be backward compatible and in fact, can do whatever is necessary to deliver global throughput and adoption for Ethereum. The FuelVM is the EVM greatly improved. Check out this non-exhaustive list of EIPs (Ethereum Improvement Proposals) implemented in the FuelVM.
The FuelVM and EVM have a lot of overlap. Here's how they're different
The FuelVM has a globally shared memory architecture instead of context-local memory
The FuelVM has a globally shared memory architecture. Instead of every contract call having its own separate memory space, call data, and return data, all contract call frames share global memory. This chunk of memory is shared amongst all call frames and is globally readable. This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize, copy from call data to memory, etc.
The FuelVM is designed for fraud-provability
The EVM is a complicated machine to construct fraud proofs for. It usually requires a second layer such as WASM or MIPS to be interpreted into a fraud provable system.
FuelVM has multiple native assets
In Ethereum, the only native asset is Ether. It’s the only one that gets first-class treatment in terms of cost and ability to be pushed and pulled through a call. In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native-level call and optimization.
PROJECTS
ARE BUILT ON
FUEL NETWORK
Investor & Funding Rounds
Fuel Labs today announced $80M USD of support led by Blockchain Capital and Stratos, with additional support from Alameda Research, CoinFund, Bain Capital Crypto, TRGC, Maven 11 Capital, Blockwall, Spartan, Dialectic, and ZMT. This marks a major milestone for modular execution layers in the blockchain community.
Team
Nick
Dodson
Dodson
CEO, co-faunder
Nick Dodson is a co-faunder as well as the CEO of Fuel from Toronto. Previously he worked for ConsenSys, and it was he who initiated the development of Fuel v1 optimistic Rollup, with the help of Yul+.
John
Adler
Adler
Co-founder
Studied in graduate school at the University of Toronto in electrical engineering and computer science, putting formal methods at the forefront. As a student, he encountered (rather fell in love with) blockchain. Later he did research on L2 scalability at Consensys and even then developed an optimistic rollup design paradigm. John is currently working on new features in the standard Sway library and improvements to FuelVM.
Alex
Hansen
Hansen
Technical Team Lead
Hockey fan, music fan, watch restorer, and just a technical team leader. Alex is from Texas and has been programming for over 10 years. With a great passion for compilers he started writing code, then small compilers, and finally had enough experience to work on Sway. Alex is currently working on the Sway compiler, specifically: optimization, system type consistency and performance improvements.
Roadmap - coming soon
WELCOME TO
THE FUEL
AMBASSADOR PROGRAM
How to become an Ambassador
In the "How to become an ambassador" section, we outline the main aspects and qualities that an ambassador should have from our point of view
Being active is not just a simple good morning/good evening message, but being useful to the community. For example, helping new users to understand the testnet, answering simple questions from newcomers.
You can do this on Discord or in local community chats. To begin with, you need to understand the project yourself in order to help others.
You can do this on Discord or in local community chats. To begin with, you need to understand the project yourself in order to help others.
On the one hand, it may seem like a trivial thing, but it is still necessary. In our point of view, it is necessary to create useful and high-quality content that will actually be useful to the community. The formula is as follows: just go to the #random section and analyze 50-100 works, set a goal to make it a little better, a little more qualitative, a little more understandable, and these "little things" will make up a big gap between your work and dozens of others. Quality is always more important than quantity, and the team pays attention to this. You can also use your creativity and do something out of the box, like this website or create a local community in your country and tell people about Fuel there. This is how you can stand out among other participants and actually benefit the project, so this is our main idea.
Most people think that by doing dozens of similar works they will get the green light to join the ambassador program, but this is not enough now. Being involved is about making a real difference to the project, about what you can offer to change for the better. Test the project, get to know the Discord server well, and suggest something that will improve the experience of other users. The team is interested in such people, and if you prove yourself well, you will have a certain advantage in joining the ambassador program.
Other pages
Sitemap
Social media