> For the complete documentation index, see [llms.txt](https://ibvm.gitbook.io/ibvm-doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ibvm.gitbook.io/ibvm-doc/rollup-architecture.md).

# Rollup Architecture

IBVM uses an optimistic rollup architecture with ZK proofs for more efficient verification.

## Transaction Flow

1. Users submit transactions to the sequencer network
2. Sequencers order and execute transactions in batches
3. The state update is published off-chain
4. ZK-SNARKs prove the correctness of state transitions
5. Proofs and state commitments are submitted to Bitcoin

### **Batch Processing**

Each batch of transactions follows this process:

1. Collect transactions $T = {T\_1, T\_2, ..., T\_n}$
2. Order transactions according to gas price priority
3. Apply transactions to the current state $S\_t$
4. Compute the new state $S\_{t+1}$
5. Generate ZK proof $\pi$ of the state transition
6. Publish the batch metadata and state commitment to Bitcoin

Mathematical representation:

1. Initial state: $S\_t$ with root hash $H\_t$
2. Transactions: $T = {T\_1, T\_2, ..., T\_n}$
3. Execute: $S\_{t+1} = Apply(S\_t, T)$
4. New state root: $H\_{t+1} = Hash(S\_{t+1})$
5. Generate proof: $\pi = Prove(pk, H\_t, H\_{t+1}, T)$
6. Publish to Bitcoin: $Commit(H\_{t+1}, \pi)$

## Data Availability

To ensure data availability, IBVM uses a hybrid approach:

1. On-chain Data: Minimal commitment data published to Bitcoin
   1. Batch ID, state root, and proof hash
2. Off-chain Data: Full transaction data stored in a distributed network
   1. Complete transaction data
   2. Contract code and storage
   3. Intermediate state roots

The data availability layer guarantees that:

1. All data needed to reconstruct the state is available
2. Data can be verified against on-chain commitments
3. Anyone can download and verify the full state

### **Data Availability Sampling**

To verify data availability without downloading the entire dataset:

1. Data is erasure-coded using a Reed-Solomon code with parameters $(n, k)$
2. The encoded data is split into $n$ chunks
3. Verifiers randomly sample $s$ chunks
4. If all sampled chunks are available, with high probability all data is available

The probability of detecting unavailable data with $m$ missing chunks: $P\_{detect} = 1 - \binom{n-m}{s} / \binom{n}{s}$

## Fraud Proofs vs. Validity Proofs

IBVM combines elements of both optimistic rollups and ZK-rollups:

1. Optimistic Component:
   1. Transactions are assumed valid initially
   2. A challenge period allows for fraud proofs
   3. Reduces the computational overhead for normal operation
2. ZK Component:
   1. ZK-SNARKs provide cryptographic guarantees of correctness
   2. Eliminates the need for long challenge periods
   3. Enables faster finality

The challenge period duration is determined by: $T\_{challenge} = \frac{L\_{max} \times C\_{safety}}{R\_{block}}$

Where:

* $L\_{max}$ is the maximum Bitcoin reorganization length considered
* $C\_{safety}$ is a safety factor (typically 2)
* $R\_{block}$ is the average Bitcoin block rate