Skip to content

Commit

Permalink
update contract function
Browse files Browse the repository at this point in the history
  • Loading branch information
isabellewei committed Aug 6, 2024
1 parent 67e38c7 commit 421dfbc
Showing 1 changed file with 7 additions and 6 deletions.
13 changes: 7 additions & 6 deletions src/content/docs/en/technology/chain/rollup.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -52,18 +52,19 @@ The rollup process can be broken down into three phases: transaction execution,

## Commit Transaction

The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 messages. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise, the transaction will be reverted. See the `commitBatch` function signature below.
The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 messages. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise, the transaction will be reverted. See the `commitBatchWithBlobProof` function signature below.

```solidity
function commitBatch(
function commitBatchWithBlobProof(
uint8 version,
bytes calldata parentBatchHeader,
bytes[] memory chunks,
bytes calldata skippedL1MessageBitmap
) external override OnlySequencer
bytes calldata skippedL1MessageBitmap,
bytes calldata blobDataProof
) external;
```

After the `commitBatch` function verifies the parent batch is committed before, it constructs the batch header of the batch and stores the hash of the batch header in the `ScrollChain` contract.
After the `commitBatchWithBlobProof` function verifies the parent batch is committed before, it constructs the batch header of the batch and stores the hash of the batch header in the `ScrollChain` contract.

```solidity
mapping(uint256 => bytes32) public committedBatches;
Expand All @@ -85,7 +86,7 @@ chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] ||

, where `block.l1TxHashes` are the concatenated transaction hashes of the L1 transactions in this block and `block.l2TxHashes` are the concatenated transaction hashes of the L2 transactions in this block. Note that the transaction hashes of L1 transactions are not uploaded by the rollup node, but instead directly loaded from the `L1MessageQueue` contract given the index range of included L1 messages in this block. The L2 transaction hashes are calculated from the RLP-encoded bytes in the `l2Transactions` field in the [`Chunk`](#Chunk-Codec).

In addition, the `commitBatch` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to an L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system.
In addition, the `commitBatchWithBlobProof` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to an L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system.

## Finalize Transaction

Expand Down

0 comments on commit 421dfbc

Please sign in to comment.