Update future research & technical specs

README.md

@@ -25,20 +25,32 @@ Citrea uses BTC as its native token. **There is no Citrea token**. Please beware
 
 Citrea is the first rollup that enhances the capabilities of Bitcoin blockspace with zero-knowledge technology, making it possible to **build everything on Bitcoin**. This requires **no changes to the network's consensus rules**.
 
-## Citrea is a [Type 2 zkEVM](technical-specs/characteristics/execution-environment.md)
+### Citrea is a [Type 2 zkEVM](technical-specs/characteristics/execution-environment.md)
 
-Citrea processes a large number of zkEVM transaction batches and submits a succinct zero-knowledge proof that allows **easy verification** of the batch validity in an inscription-like envelope to Bitcoin. The zero-knowledge proofs generated by the prover output the state difference resulting from that batch, with these proofs then being published to Bitcoin regularly.
+Citrea processes a large number of zkEVM transactions in batches and generates a succinct zkSNARK proof from them. These proofs are then published to Bitcoin directly. This allows for easy verification of the batch validity in an inscription-like envelope.
 
-## Citrea proofs are inscribed in Bitcoin and optimistically verified via BitVM
+### Citrea is a **rollup on Bitcoin**
 
-Anyone running a Bitcoin node can both verify Citrea and access its full state. This method ensures that the data needed to transact on Citrea or verify Citrea becomes permissionlessly available for every single node in the Bitcoin network. The proof inscribed in Bitcoin by prover(s) is optimistically verified in Bitcoin as well, thanks to BitVM.
+Citrea **batch proofs** also includes the **state differences** for each batch, meaning that any changes from block A to block B in a batch are also available for anyone who's reading Bitcoin. This allows a Citrea full node to **directly read the state from Bitcoin permissionlessly** and reconstruct the state - which is the key of Citrea being a rollup on Bitcoin, rather than a sidechain.
 
-## Citrea supports Light Nodes
+Citrea uses **Bitcoin as a Data Availability layer**, and it's the only source of truth for the system. As long as Bitcoin is secure, nodes always continue to function.
 
-Taking advantage of a recursive zero-knowledge proof system - STARKs specifically - Citrea allows easy verification of the blockchain by light nodes. By recursively verifying batch proofs within light client proofs, the full Citrea dataset shrinks into a small zero-knowledge proof and lives inside Bitcoin. Anyone running a Bitcoin Light Node (SPV) can trustlessly verify Citrea and access its state root.
+### Citrea has a native trust-minimized two-way peg: Clementine
 
-## Citrea has the first universal trust-minimized two-way peg
+Clementine is the BitVM-based trust-minimized two-way peg mechanism implemented by Citrea Team. BTC pegging mechanism uses the idea of BitVM at it's core, and it utilizes Light Client Proofs that includes recursively proven batch proofs. 
 
-Citrea light client proofs are natively verified on Bitcoin via BitVM, enabling the first layer 2 verification in Bitcoin and trust-minimized two-way peg mechanism. Pegged BTC is held in the BitVM contract (leveraging Taproot) on the Bitcoin network. Withdrawals are only authorized with valid ZK proofs, meaning no party can steal the pegged BTC from the bridge.
+Clementine has a 1-of-N trust assumption, which means that as long as one single entity in the bridge multisig is honest, no party can steal the pegged BTC from the bridge. 
+
+You can read more about Clementine [here](https://www.blog.citrea.xyz/unveiling-clementine/).
+
+### Citrea is fully open-source
+
+You can find the source code of [Citrea](https://github.com/chainwayxyz/citrea) and [Clementine](https://github.com/chainwayxyz/clementine) here. It's been built in public from day one. 
+
+You can also check many other projects and other relevant open-sourced components from our organization page on Github, [Chainway Labs](https://github.com/chainwayxyz).
+
+-----
 
 Citrea uses $BTC as its native token. To avoid confusion and improve on/off-ramp UX; Citrea native $BTC is referred to as $cBTC in Citrea.
+
+In the following pages of this documentation, you can find much more details on how Citrea works and what does each component do in its architecture.

SUMMARY.md

@@ -7,12 +7,14 @@
 ## ⛓ Technical Specs
 
 * [TL;DR](README.md)
-* [Technical Introduction](technical-specs/introduction.md)
+<!-- Edit introduction.md -->
+* [Technical Introduction](technical-specs/introduction.md) 
+<!-- Edit characteristics.md -->
 * [Characteristics](technical-specs/characteristics/README.md)
   * [Execution Environment](technical-specs/characteristics/execution-environment.md)
   * [Block Production](technical-specs/characteristics/block-production/README.md)
-    * [Pre-Confirmations](technical-specs/characteristics/block-production/pre-confirmations.md)
-    * [Decentralized Sequencer Network](technical-specs/characteristics/block-production/decentralized-sequencer-network.md)
+    * [Sequencer](technical-specs/characteristics/block-production/sequencer.md)
+    * [Sequencer Commitments](technical-specs/characteristics/block-production/sequencer-commitments.md)
   * [Proof Generation](technical-specs/characteristics/proof-generation.md)
   * [Nodes](technical-specs/characteristics/nodes.md)
   * [Bitcoin Settlement: Trust-minimized BTC Bridge](technical-specs/characteristics/bitcoin-settlement-trust-minimized-btc-bridge/README.md)
@@ -54,12 +56,13 @@
 
 ## 🔎 Future Research
 
-* [Multi VM Approach](future-research/multi-vm-approach.md)
-* [Volition Model](future-research/volition-model.md)
 * [Decentralized Sequencer Network](future-research/decentralized-sequencer-network.md)
-* [Trustless Atomic Swaps](future-research/trustless-atomic-swaps.md)
 * [Lightning Integration](future-research/lightning-integration.md)
+* [Multi Prover](future-research/multi-prover.md)
+* [Multi VM Approach](future-research/multi-vm-approach.md)
+* [Trustless Atomic Swaps](future-research/trustless-atomic-swaps.md)
 * [Trustless Settlement](future-research/trustless-settlement.md)
+* [Volition Model](future-research/volition-model.md)
 
 ## 🌐 Community
 * [Citrea Meetups](/community/README.md)

future-research/decentralized-sequencer-network.md

@@ -1,5 +1,22 @@
 # Decentralized Sequencer Network
 
-Citrea contributors are exploring solutions to support multiple sequencers in consensus without affecting latency and finality. One possible approach is to implement a PoS-like layer but for only sequencing blocks. The source of truth for users will always be zero-knowledge proofs in Bitcoin. The decentralized sequencing layer will reduce the short term trust in sequencers to protect the ordering, as the ordering will be finalized on the sequencing layer in a single slot.
+<!-- TODO: Link sequencer.md in this text -->
+<!-- TODO: Include force_transaction.md in this text -->
+<!-- TODO: Possibly link prover.md -->
 
-There are several consensus mechanisms that are being experimented such as CometBFT, Hotstuff, and MonadBFT.
+Almost all rollups today have a single sequencer in the Web3 ecosystem, so does Citrea. While it is sufficient for security (safety) and being non-custodial, liveness failures may still occur. To prevent this, a promising idea is to implement a decentralized sequencer network. We aim to launch Citrea mainnet with a force transaction mechanism, which greatly provides censorship resistance, and decentralized sequencers also benefit this topic.
+
+The main considerations are:
+- **Architecture**: Deciding the sequencer set, making it permissionless or not, modifying the architecture, determining the best consensus (CometBFT, Hotstuff, MonadBFT), and making further adjustments are all crucial properties, each with tradeoffs.
+- **Latency**: Achieving consensus among multiple sequencers is not easy, it bring some latency to the system and it should not impact responsiveness of the rollup hugely.
+- **Economic Incentives**: There are interesting ideas stemming from an economic perspective and a game theory perspective on the decentralized networks. It's important to ensure the safety in theory, just like in practice.
+
+Currently, potential approaches that can fit with Citrea and Bitcoin are:
+- **PoS-like layer for sequencing blocks**: For users, the source of truth will always be zero-knowledge proofs in Bitcoin. The decentralized sequencing layer will reduce short-term trust in sequencers to protect ordering, as ordering will be finalized on the sequencing layer in a single slot.
+- **Shared Sequencing**: We're following the state-of-art solutions emerging in other ecosystems. Once they're proven to be secure and battle-tested throughly, a good approach could be adapting them into Citrea.
+
+In case you were wondering, based sequencing is not a good idea for Citrea, as it uses Bitcoin as a DA layer. Unfortunately, Bitcoin script is not expressive enough for this purpose.
+
+-----
+
+Upon mainnet launch, we will start diving deep into this topic and will work on it with full focus.

future-research/lightning-integration.md

@@ -1,3 +1,15 @@
 # Lightning Integration
 
-Trustless atomic swaps between Citrea and Lightning Network are being researched at the moment. This could allow users of Citrea to pay Lightning invoices directly from the Citrea network or on- and off-ramp from Citrea without needing to leverage the Bitcoin base layer.
+<!-- TODO: Add diagram -->
+
+Trustless atomic swaps between Citrea and Lightning Network are being actively implemented at the moment. This will allow users of Citrea to pay Lightning invoices directly from the Citrea network or on- and off-ramp from Citrea without needing to leverage the Bitcoin base layer.
+
+More technically, for both ways of the swap the smart contract on Citrea simply emulates the Lightning's HTLC. An LSP (Lightning Service Provider) behaves as a proxy on Lightning and it is responsible for all cross-network interactions - with liquidity maintained on both sides.
+
+For the path from Lightning to Citrea, here's a basic explanation:
+- Citrea user generates a hash from a preimage and sends it to Lightning user.
+- A route to LSP from the Lightning user is formed.
+- Regular Lightning payment procedure applies from the user to LSP.
+- LSP then locks the amount that is send in CBTC to the smart contract on Citrea. This can only be unlocked with the preimage of that has that's been sent along the route.
+- When Citrea user withdraws the CBTC, the preimage is revealed publicly. Everyone uses the preimage to spend their UTXO, and the swap is complete.
+

future-research/multi-prover.md

@@ -0,0 +1,12 @@
+# Multi Prover Implementation
+
+<!-- TODO: Link Clementine -->
+
+ZK-proofs are the backbone of Citrea. They are used to prove the correctness of the state transitions and the validity of the transactions by the full nodes via batch proofs. Along with that, they are used to generate Light Client Proofs, which is used in our BitVM-based bridge design Clementine.
+
+A common problem with ZK-proofs is that, even though they're super efficient and easy to verify, they are very hard to generate. Citrea uses Risc0 for proving, and at the moment our prover is efficient enough to make the system continue. However, we can speed up the proving process a lot as the state-of-art continues to evolve rapidly. Day by day new algorithms and techniques are being developed, and several companies have made enormous progress both in terms of software and hardware. We believe this acceleration will continue even faster in the future, and we can easily adapt them into Citrea since our architecture is designed with this in mind.
+
+While these improvements are going on, another feasible yet much more efficient idea is having a multi-prover system. The goal is to make the proof generation process faster and resistant to the proof system & circuit bugs by distributing it across multiple independent provers. There are a couple of ways to achieve this theoretically:
+
+<!-- TODO: Revisit here. -->
+<!-- Discuss: SGX, multiple zkEVM, multiple zkVM, horizontal scaling, vertical scaling, prover coordination, impacts, dependencies -->

future-research/multi-vm-approach.md

@@ -1,5 +1,17 @@
 # Multi VM Approach
 
-Citrea is designed to be compatible and interoperable with multiple virtual machines. It runs inside a generic STARK zkVM, meaning any virtual machine can be implemented and will produce execution proof.
+Citrea is designed to be compatible and interoperable with multiple virtual machines. It runs inside a generic STARK zkVM, meaning any virtual machine can be implemented and will produce execution proof. Currently on the path to mainnet, Citrea implements EVM and it will be launched that way. 
 
-Initially, Citrea implements EVM, however implementing different VMs like WASM or SVM is possible thanks to its future-proof design.
+Implementing different VMs like SVM or integrating WASM-based smart contracts to Citrea is also possible thanks to its future-proof design. The objective in this approach is to build an environment where contracts can be written in multiple languages like Solidity (EVM) or Rust, C++ (WASM) and run & interact on the same blockchain, natively. 
+
+Two main methods that fits into this approach are:
+- Integrating Arbitrum Stylus-like* solutions to Citrea's EVM module: Essentially bringing a WASM execution model into the system.
+- Building a Wasm-based sovereign module from scratch: A dedicated WASM execution environment needs to be built and integrated with custom precompiles.
+
+<!-- TODO: Is there any other "easy" method that I miss? -->
+
+-----
+
+The idea is quite experimental and it is something team can consider some steps after the mainnet launch. It's not a high-priority idea, but can be a great feature in the future, both for the ecosystem and the developers.
+
+* Arbitrum Stylus is under the BUSL License, and it is currently allowed for specific use cases in the Arbitrum Ecosystem. As cypherpunks writing code, we deeply value their work and respect their license. This will also continue with honesty & transparency when we start to implement the ideas in this document.

future-research/trustless-atomic-swaps.md

@@ -1,3 +1,5 @@
-# Trustless Atomic Swaps
+# Trustless Atomic Swaps with Bitcoin
 
-Trustless atomic swaps between Citrea and Bitcoin are being researched at the moment. These swaps would allow users to on- and off-ramp from Citrea without using the peg mechanism.
+Trustless atomic swaps between Citrea and Bitcoin are being actively implemented at the moment. These swaps would allow users to on- and off-ramp from Citrea without using the peg mechanism.
+
+<!-- TODO: Add more explanation here. -->

future-research/volition-model.md

@@ -1,5 +1,22 @@
 # Volition Model
 
-Volition is a special type of data availability solution that combines off-chain and on-chain data. Very briefly, volitions allow users or apps to choose where to save their data for each transaction. The model allows applications with different data locations to be interoperable in a single blockchain. For example users may choose off-chain data availability for low fees with less security or they may choose Bitcoin data availability for regular fees with full security. No matter the data availability choice, every transaction continues to get proven with ZK proofs.
+Volition is a special type of data availability solution that combines off-chain and on-chain data storage. Traditionally, there are two categories of rollups regarding the data storage:
 
-In short, the volition model provides Bitcoin equivalent validity, censorship resistance, and re-org resistance but leaves the data availability option to users or apps.
+- **On-chain Data Availability** (e.g. Citrea): All transaction data / state diffs are stored on the L1 chain. Full nodes can simply scan L1 blocks to sync with the network. This is the most secure and trustless* way to provide data for the network; however, not the cheapest.
+    - `Trustless` here is in the context of data only and it indicates that chain data is always available as long as the L1 chain is secure. This is pretty much the standard & correct definition in this context.
+
+- **Off-chain Data Availability** (i.e. Validiums): All transaction data / state diffs are stored off-chain. Validiums are mostly cheaper than pure rollups; however, they rely on some other DA solutions and DACs. It is arguably less secure than using Bitcoin directly for our case and it introduces more trust assumptions to the system.
+
+Volition, compared to two categories above, offers a hybrid approach - it allows users to choose where to publish transactions (+ relevant data), and choose the security of on-chain data availability or the cost efficiency of off-chain data availability.  Essentially there will be two states for two DA branches, and latest Citrea state will be the combination of these two branches.
+
+It's important to note that regardless of the DA preference, all transactions would still be process by the STF (State Transition Function), and will be verified via ZK proofs. 
+
+There are two major challenges in this direction:
+
+a) Complexity: It's definitely not trivial to implement a volition model (none exist in production as of October 2024). It also requires modifications to the Citrea STF and overall architecture, particularly in terms of sequencing, proving, and running full nodes.
+
+b) Guarantees: For users who prefer to use an alternative DA branch, trust assumptions will be different. It is essential to have a very secure off-chain DA solution for volition purposes, as well as to work on attack scenarios, bugs, and other potential issues and scenarios.
+
+-----
+
+We're closely following the recent ideas & research regarding volition models. We plan to initiate the research & development process after the Citrea mainnet launch, and will continue to share the findings & progress with the community as usual.