CanonicalTransactionChain. To do so, the sequencer must process transactions instantly, without delay. This process must follow the constraints imposed by
appendSequencerBatch(). Also, the sequencer must add transactions from the CTC queue during the so-called "Force On Period".
enqueue()transactions directly into the L1 queue. This will force the sequencer to include transactions in the L2 queue within the
FORCE_INCLUSION_PERIODtransaction. If any transaction in the queue is older than
FORCE_INCLUSION_PERIODblocks, that transaction must be added to the chain before the protocol allows the sequencer to add other transactions. If the sequencer stops sending transactions completely, the protocol allows users to add transactions to the CTC by calling
CanonicalTransactionChaincontract, where all Optimistic Rollup blocks are stored. At the next stage, the sequencer reads the batch of the user-published transactions in the
CanonicalTransactionChaincontract to process them and produce a State Batch. Then, it appends the generated Merkle root: it is an important part of the process as verifiers (other smart contracts) can use Merkle tree proofs it to verify the validity of the batch that occurred recently.
Canonical Transaction Chain, and then the resulting state is committed by writing it to the
State Commit Chain. Proposers must pay a bond to obtain privilege for this role.
Canonical Transaction Chainto determine the resulting state root after each transaction.
Canonical Transaction Chain. They process transactions and verify that the state roots in the state commit chain are correct. If the state root is invalid, the verifier initiates and completes a fraud-proof task. There is a convenient cross-chain communication contract
L1CrossDomainMessenger, which can verify these proofs on behalf of other contracts.