Kumquat: The First-Ever Fork on Citrea
The first-ever fork on Citrea, named Kumquat, will soon go live on the internal devnet. We expect Kumquat to arrive on Citrea testnet within the following weeks.
Kumquat brings a host of significant upgrades, including new EVM opcodes, enhanced proving mechanisms, and improved data availability.
TL;DR: The Citrea testnet is now cheaper, more robust, and smaller (yay, Light Client Proofs!). Keep reading for a detailed breakdown of the updates introduced with Kumquat.
What are forks?
Forks allow systems to upgrade (or sometimes downgrade) to a different set of rules. In the context of Citrea, the maintainers and community will perform a series of forks over the testnet and mainnet to keep improving the protocol. Every system upgrades differently, most popularly via hard forks or soft forks. Kumquat is an example of a hard fork.
What’s Inside the Kumquat Fork?
The Kumquat fork includes a wide range of upgrades to the Citrea testnet, including major refactoring in some parts of the codebase, proving improvements, cycle reductions, light client proofs, DA types, and more. Below, the changes and their benefits are detailed.
Light Client Proofs
The Citrea codebase is now able to generate light client proofs! These proofs will primarily be used in Clementine to verify the Citrea state in BitVM.
Light client proofs are generated by (simplified steps):
- Start from the L1 block number.
- Check batch proofs’ given inclusion and completeness proofs for an L1 header in an ordered way.
- Recursively verify batch proofs and ensure their initial and latest states are consecutive.
- Finalize the circuit by outputting the latest scanned L2 block number, block hash, and Citrea state root.
Thanks to Citrea’s light client proofs, you can trustlessly verify the Citrea state root as long as you can access the given Bitcoin block hash at the specified height, as does BitVM!
As part of these improvements, recursion has been implemented in the guest to enable the cheap verification of a proof inside another proof.
Header Chain Circuit
One of the key enablers of Light Client Proofs is the Header Chain Circuit. The Header Chain Circuit is a Rust codebase designed to run in Risc0, generating a recursive ZK proof of Bitcoin’s full header chain. Thanks to recursion, the prover can start from where the last proof ended, avoiding unnecessary time spent on proving the older blocks.
The Header Chain Circuit is now part of the BitVM repository, making it widely accessible to all teams using BitVM!
Cancun Compatibility
Cancun is Ethereum’s latest hard fork. It is mainly known as the upgrade that brought blobs to Ethereum. For Citrea, the maintainers decided not to include blob logic into the rollup, as Citrea is a rollup on Bitcoin and applications cannot benefit from blobs. Currently, Citrea block headers include blob-related fields; however, the sequencer doesn’t allow any type 3 (blob) transactions, and the VM doesn’t activate the KZG precompile.
The Citrea codebase implements the rest of the Cancun changes:
- EIP-1153: Transient storage opcodes
- EIP-5656: MCOPY - Memory copying instruction
- EIP-6780: SELFDESTRUCT only in the same transaction
- EIP-7516: BLOBBASEFEE opcode (always returns 1, as there are no blobs supported)
Full Proving (with Fake Receipts!)
Pre-Kumquat, the Citrea codebase was implemented in a way where the sequencer always committed the batches, but the prover only selected a few batches daily to test the prover in the cheapest way possible.
With the Kumquat upgrade, the system now takes advantage of the Fake Receipts feature of Risc0, which enables running the full proving execution but generates a fake receipt instead of a real one. This allows the full proving of batches without incurring high costs. This improvement is strictly for testnet as it is not secure for any production circuit.
New ELF Compilation and Read System
As part of Citrea’s multi-prover strategy (an adapter to prove Citrea’s guest program in SP1 alongside Risc0 has been implemented), changes were made to how guest code is compiled and versioned. This update simplifies the maintainers’ tasks, making it easier to iterate on new versions of the codebase and provers.
Dependency Upgrades
The Citrea codebase uses dependencies from various codebases, including revm, Reth, and Risc0. In this fork, all dependencies have been upgraded to their latest stable versions.
ECDSA Accelerator for Risc0
Risc0’s recently released ECDSA accelerator, which is three times faster than its predecessor, is being considered to be activated. This enhancement will significantly improve prover performance.
Cycle Reductions
The Citrea STF has been refactored to reduce cycles during ZK execution. By simplifying operations and removing redundant or unnecessary checks, the prover can now generate proofs more cheaply and efficiently.
Off-Chain Contracts
In pre-Kumquat Citrea, every contract deployed into Citrea was sent to Bitcoin DA as part of the state diff. However, Citrea researchers realized this was unnecessary from a trust assumption perspective. Full nodes and provers can still reach the same state using the code_hash field instead of the code field. Users interacting with contracts would already have the code, as they rely on trustless verification.
The Citrea codebase now supports off-chain contracts, where only the code hash is stored on-chain, while the full bytecode is relayed off-chain. This change makes contract deployments as cheap as regular transactions from a DA perspective.
More!
Besides the major updates mentioned above, Kumquat includes several smaller improvements. You can check the release notes if you’re interested in learning more!
When Will Kumquat Be Activated on Testnet?
The maintainers have been working diligently on Kumquat since the testnet launch. As of last week, all tests were passing, and the internal devnet was successfully forked. The community and developers can expect Kumquat to arrive on the testnet within the next couple of weeks.
Please join our Discord to stay updated!