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