Fusion is an experimental progressive Ethereum zkRollup written in Rust and focuses on performance, modularity, and applying cutting-edge Verifiable Computation proof systems.
Fusion is conceptually based on the original zkRollup. We use Zokrates for all circuits which provides high level abstractions for all algorithms and multiple backends. Currently the prover builds a Groth16 SNARK for each transaction in parallel, and there is no batching. Together with ZoKrates we are experimenting with Nova recursive proofs to enable incredibly fast transaction batching and compression.
See the end of this document for the full list of roadmap items, ideas, and concrete tasks.
This repository contains the entire Fusion tool suite:
circuits: the SNARK state and signature verification ZoKrates code.fusion-prover: the prover that takes a signed transaction and builds a SNARK of
state changes and signature.fusion-sequencer: the Fusion node. Receives L2 transactions via RPC, builds
blocks, and sends them for verification on L1.l1-verifier: the Fusion contracts deployed on L1. These contracts provide
block verification and canonical state root updates for L2 nodes.fusion-wallet: a simple CLI interface to sign/send Fusion transactions.git clone --recurse-submodules https://github.com/leonardoalt/fusion.gitIf you already cloned the repository without submodules, you can run the command below to initialize it:
git submodule update --init --recursiveFusion requires the following installed:
ZoKrates' latest release 0.8.7 is specifically required for this step.
cd circuits && make && make verifierNote: the current circuits require at least 16GB of RAM to compile.
This step requires the circuit step above.
cd l1-verifier && makeThis step requires the L1 verifier step above.
cargo build --release --bin fusion-sequencerThe easiest way to see everything running is via Rust tests with
cargo test --release -- --nocaptureFor more details see the tests in fusion-sequencer.
If you want to run it in production style, you may want to follow this list:
eth_private_key in fusion.toml to the private key that will deploy the contract and submit L2 blocks.eth_rpc_url in fusion.toml to an Ethereum RPC endpoint. Since we are using anvil here, this is usually http://localhost:8545.source ./scripts/run_anvil_and_deploy_contract which starts anvil and deploys the contract.fusion_l1_contract in fusion.toml with the address of the deployed contract../scripts/run_node to start the node../scripts/listen_to_node to check the ongoing output from the node../scripts/send_random_tx to send transactions../scripts/kill_node and ./scripts/kill_anvil.The state is a balanced Sparse Merkle Tree similar to this one. The tree has 256 levels besides the root. This implies that it has 2^256 leaves. Each leaf has an index, from 0 (left most) to 2^256 - 1 (right most). The path from the root to a leaf can be represented by the binary representation of the leaf's index: when walking down the tree, 0 means the path goes left, 1 means it goes right.
The tree also contains some optimizations, such as:
hash(hash(...(0))) (such as in the Ethereum Beacon Chain Deposit Contract).merge(0, 0) = 0merge(L, 0) = L, if L != 0merge(0, R) = R, if R != 0merge(L, R) = hash(L, R), if L != 0 and R != 0The used hash is Poseidon in order to be SNARK friendly.
Since we need to verify signatures inside zkSNARKs, we use EdDSA with the Baby Jubjub Elliptic Curve.
A public key (PK) consists of a curve point where x and y are elements of
the field used by Baby Jubjub. The PK can be compressed into 256 bits, which
does not necessarily fit in the field.
Given a public key (x, y), its Fusion address consists of poseidon(x, y).
This means that Fusion accounts are not compatible with Ethereum accounts.
There are no VM and smart contracts at the moment.
Fusion is designed to be highly modular and extensible. For example, here are a few things that can be modified quite easily:
nova)This enables fast experimental iterations on all fronts which can quickly turn into progress.