Today I will discuss why the FuelVM is the EVM but greatly improved and what this means for the future of blockchain.
#EveryComputationMatters #BeyondMonolithic
👇
#EveryComputationMatters #BeyondMonolithic
👇
There are countless approaches ready for implementation to improve EVM performance. However, many of them would break backwards-compatibility of the Ethereum protocol, and a lot of dapps in the process.
There is a need to start fresh.
There is a need to start fresh.
Execution layers built on top of 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.
Execution layers provide a path forward.
Execution layers provide a path forward.
At one point, it was unimaginable any CPU architecture would be anything but x86, but as time passed, and the benefits of the alternatives surfaced, ARM is now seeing a massive amount of use in many mobile and Apple products.
We see the FuelVM in a similar light.
We see the FuelVM in a similar light.
The continued use of the EVM as a L1 or L2 will create an expensive and highly-constrained design space for blockchain applications, restricting global accessibility to only a select few who can afford it, constraining DeFi projects and shrinking growth.
Apps will be forced to move and seek better alternatives to Ethereum & EVM, as global demand increases and compute space becomes more scarce.
https://twitter.com/musalbas/status/1539736794215976960
In many ways, you can consider the FuelVM as the EVM with all the strongest ideas over the years implemented, in addition to learnings from WASM, Bitcoin, and other popular blockchain runtimes.
In a sense: the FuelVM *is* the EVM, greatly improved.
But how is it different?
In a sense: the FuelVM *is* the EVM, greatly improved.
But how is it different?
For starters, the FuelVM uses 64-bit words, not 256. While 256-bit has served us well in the EVM, there isn’t much need to keep this word size as libraries on the FuelVM can be made efficiently at the application level to handle things like big numbers.
medium.com/coinmonks/10-e…
medium.com/coinmonks/10-e…
The FuelVM is register-based instead of stack-based.
In blockchains, every operation is priced. As it turns out, this overhead is very expensive. Optimizing for reducing the number of operations needed to do the same amount of work has outsized benefits...
In blockchains, every operation is priced. As it turns out, this overhead is very expensive. Optimizing for reducing the number of operations needed to do the same amount of work has outsized benefits...
Register-based VMs typically require fewer instructions to do the same work compared to stack-based VMs.
This is why it's a nice fit for the FuelVM.
arxiv.org/abs/1611.00467
This is why it's a nice fit for the FuelVM.
arxiv.org/abs/1611.00467
The FuelVM has a new memory architecture.
In the EVM, every contract call has to serialize data that is forwarded or returned. This is wasted processing which severely limits cross-contract communication...
In the EVM, every contract call has to serialize data that is forwarded or returned. This is wasted processing which severely limits cross-contract communication...
With Fuel, making calls between contracts is as easy as just passing pointers to data, because all call frames can read anywhere from a shared memory block.
github.com/FuelLabs/fuel-…
github.com/FuelLabs/fuel-…
The FuelVM is designed for fraud-provability.
The EVM is a hard machine to construct fraud proofs for. It usually requires a secondary layer such as WASM or MIPS to even be interpreted into a fraud provable system...
The EVM is a hard machine to construct fraud proofs for. It usually requires a secondary layer such as WASM or MIPS to even be interpreted into a fraud provable system...
The FuelVM is designed to be fraud provable from the start, all operations are picked with this property in mind.
github.com/FuelLabs/fuel-…
github.com/FuelLabs/fuel-…
The FuelVM has multiple native assets.
In Ethereum, the only native asset is Ether. It’s the only one that gets first class treatment in the sense of cost and to be pushed and pulled through a call...
In Ethereum, the only native asset is Ether. It’s the only one that gets first class treatment in the sense of cost and to be pushed and pulled through a call...
In Fuel, any contract can mint its own UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native level call and optimization.
fuellabs.github.io/sway/v0.16.2/b…
fuellabs.github.io/sway/v0.16.2/b…
The FuelVM has many ops which help with resource constrained systems such as dynamic length memcopy, memequal and memclear.
Doing these ops in the EVM requires using iteration and loops, which make the task of operating over swaths of memory more expensive than they need to be.
Doing these ops in the EVM requires using iteration and loops, which make the task of operating over swaths of memory more expensive than they need to be.
The FuelVM already incorporates a kind of account abstraction called predicates.
A form of pay to script hash, inherited from Bitcoin, a user may send coin to a spending condition script hash. This allows for the use and creation of things like multi-sigs without any contract.
A form of pay to script hash, inherited from Bitcoin, a user may send coin to a spending condition script hash. This allows for the use and creation of things like multi-sigs without any contract.
The FuelVM removes the need for approve/transferFrom UX with scripts.
Unlike the EVM, the FuelVM has scripts, which allow many actions to happen from an origin sender without a contract being deployed.
Unlike the EVM, the FuelVM has scripts, which allow many actions to happen from an origin sender without a contract being deployed.
The FuelVM is built with an atomic UTXO paradigm from the start.
Unlike the accounts model, Fuel uses a system of UTXOs which enables a more efficient system of transfer and ownership of assets, where the accounts tree doesn’t have to be rebuilt every time funds are transferred.
Unlike the accounts model, Fuel uses a system of UTXOs which enables a more efficient system of transfer and ownership of assets, where the accounts tree doesn’t have to be rebuilt every time funds are transferred.
The FuelVM is designed for auditability.
Unlike the EVM, we designed the FuelVM’s ops with auditing edge-cases in mind, simplifying the potential side-effect outcomes of each opcode to ensure we don’t run into odd cases found in things like self-destruct.
Unlike the EVM, we designed the FuelVM’s ops with auditing edge-cases in mind, simplifying the potential side-effect outcomes of each opcode to ensure we don’t run into odd cases found in things like self-destruct.
The FuelVM is designed for multi-witness, multi-input, multi-output transactions.
A transaction can include many different witnesses and native assets, giving the developer far more options at the transaction level.
A transaction can include many different witnesses and native assets, giving the developer far more options at the transaction level.
https://twitter.com/fuellabs_/status/1500942977371357184
The FuelVM enables different sig-hash states.
This means things like meta-transactions can be done at the transaction level, as it can enable partially signed transactions by multiple parties.
eips.ethereum.org/EIPS/eip-2771
This means things like meta-transactions can be done at the transaction level, as it can enable partially signed transactions by multiple parties.
eips.ethereum.org/EIPS/eip-2771
The FuelVM provides the entire transaction in memory.
This enables better introspection of all transaction details during execution, which is especially important for predicate spending conditions, where restrictive logic would typically be used.
This enables better introspection of all transaction details during execution, which is especially important for predicate spending conditions, where restrictive logic would typically be used.
The FuelVM comes fully loaded with safe-math.
In Ethereum, there are countless deployments of a single library: safe-math. The FuelVM provides this at the VM level, and can be enabled or disabled at will.
github.com/OpenZeppelin/o…
In Ethereum, there are countless deployments of a single library: safe-math. The FuelVM provides this at the VM level, and can be enabled or disabled at will.
github.com/OpenZeppelin/o…
FuelVM instructions are 32-bit word aligned.
EVM bytecode is not word aligned, which makes parsing more complex than it needs to be.
All FuelVM operations are 32-bit word aligned designed for efficient parsing, fraud provability and auditability.
EVM bytecode is not word aligned, which makes parsing more complex than it needs to be.
All FuelVM operations are 32-bit word aligned designed for efficient parsing, fraud provability and auditability.
The FuelVM is designed for heap management.
Unlike the EVM, The FuelVM comes loaded with nice operations to manage heaps. Reducing the total cost to use common dynamic in-memory data structures.
github.com/FuelLabs/fuel-…
Unlike the EVM, The FuelVM comes loaded with nice operations to manage heaps. Reducing the total cost to use common dynamic in-memory data structures.
github.com/FuelLabs/fuel-…
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 @SwayLang, ensuring it has handy and efficient ops, such as getting specific parts of a tx.
Unlike EVM which was designed without a language from the start, the FuelVM is built alongside its companion language @SwayLang, ensuring it has handy and efficient ops, such as getting specific parts of a tx.
Plain-english specification.
While the Ethereum yellow paper accomplished its goals of specifying the EVM. It was not the easiest document to read and interpret.
The FuelVM is specified in plain-english in markdown for easy onboarding for devs, and auditors.
While the Ethereum yellow paper accomplished its goals of specifying the EVM. It was not the easiest document to read and interpret.
The FuelVM is specified in plain-english in markdown for easy onboarding for devs, and auditors.
Backward compatibility for hashing and signing with Ethereum.
The FuelVM features Ethereum’s keccak256 operation, which enables account management, signature creation and hashing from standardized Ethereum wallets like MetaMask or the Ethereum Ledger app.
The FuelVM features Ethereum’s keccak256 operation, which enables account management, signature creation and hashing from standardized Ethereum wallets like MetaMask or the Ethereum Ledger app.
Branch optimization.
All FuelVM operations are designed to ensure maximal opportunity to optimize for the reduction of internal branches that occur per operation.
Reducing the number of branches means operations can be priced cheaper while accomplishing the same behaviors.
All FuelVM operations are designed to ensure maximal opportunity to optimize for the reduction of internal branches that occur per operation.
Reducing the number of branches means operations can be priced cheaper while accomplishing the same behaviors.
Preference for standardized hashing: sha256.
The FuelVM uses sha256 for all major hashing operations, as it is now understood to be both very secure, more efficient and formally standardized than its keccak256 Ethereum counterpart.
The FuelVM uses sha256 for all major hashing operations, as it is now understood to be both very secure, more efficient and formally standardized than its keccak256 Ethereum counterpart.
https://twitter.com/drakefjustin/status/1110648087352090625?lang=en
Removal of constructor.
While the EVM allows for contract constructors, they add a level of security risk due to potential side-effects.
The FuelVM allows for a more simplistic storage init, which removes edge-cases but still allows a dev to set up a contract's initial state.
While the EVM allows for contract constructors, they add a level of security risk due to potential side-effects.
The FuelVM allows for a more simplistic storage init, which removes edge-cases but still allows a dev to set up a contract's initial state.
All contract IDs are deterministic.
For the EVM, deterministic contract IDs were only added after the fact with create2.
The FuelVM enables deterministic contract addresses by default. All contract IDs are the hash of a salt, contract code and initial state.
For the EVM, deterministic contract IDs were only added after the fact with create2.
The FuelVM enables deterministic contract addresses by default. All contract IDs are the hash of a salt, contract code and initial state.
The FuelVM retains similar contract and call paradigms.
Unlike other non-EVM designs, Fuel doesn’t leave behind the familiar contract and call paradigms we are used to with Ethereum, but enhances the experience with scripts.
fuellabs.github.io/sway/v0.16.2/b…
Unlike other non-EVM designs, Fuel doesn’t leave behind the familiar contract and call paradigms we are used to with Ethereum, but enhances the experience with scripts.
fuellabs.github.io/sway/v0.16.2/b…
The FuelVM has similar storage operations.
Unlike WASM runtimes, Fuel keeps Ethereum’s handy storage API, allowing a familiar key-value store model where individual accounts don’t need to be managed by the developer.
github.com/FuelLabs/fuel-…
Unlike WASM runtimes, Fuel keeps Ethereum’s handy storage API, allowing a familiar key-value store model where individual accounts don’t need to be managed by the developer.
github.com/FuelLabs/fuel-…
If you would like to see the FuelVM in action, please see SwaySwap, a Uniswap-style DEX built using the @SwayLang and the FuelVM on the Fuel devnet.
https://twitter.com/fuellabs_/status/1539987539985055744
If you would like to develop using the FuelVM, get started by reading the Sway Book and writing your first Fuel app:
fuellabs.github.io/sway/
fuellabs.github.io/sway/
If you would like to study the FuelVM, checkout the bootcamp:
The intended aim of the FuelVM is to provide the world with a blockchain virtual machine that is efficient, portable, fraud provable and accessible.
We believe the FuelVM is critical to deliver the autonomous future.
We believe the FuelVM is critical to deliver the autonomous future.
https://twitter.com/fuellabs_/status/1516054414330458117
• • •
Missing some Tweet in this thread? You can try to
force a refresh
