Transactions

Transactions in Wischain

A transaction within the Wischain ecosystem is defined as a cryptographically signed message that initiates a state transition in the blockchain. This can range from a simple balance transfer to invoking a smart contract, which executes a program to modify the current state of the network.

Transaction Types

Wischain currently supports three distinct types of transactions:

1. Pre-EIP-155 Transaction: This type is designed to accommodate the Singleton Factory contract.

2. Legacy Transaction: This refers to transactions compliant with the original Ethereum EIP-155 standards.

3. L1MessageTx Typed Transaction (Type: 0x7E): This new transaction type, introduced in Wischain and detailed in EIP-2718, is specifically for transactions initiated on Layer 1 (L1). It is important to note that Wischain does not currently support EIP-2930 and EIP-1559 transaction types, though plans to reintegrate these in the future are in place.

L1 Message Transaction

The L1MessageTx is a novel transaction type for those initiated on L1. It operates through the L1 bridge contract. Each time a new message is added to the L1MessageQueue contract, the L2 sequencer generates a corresponding L1MessageTx transaction to be included in the L2 blocks. Since the signature is implicitly verified during the L1 submission, L1MessageTx transactions do not require a signature.

The structure of the L1MessageTx transaction is defined as follows:

type L1MessageTx struct {
  QueueIndex uint64          // The queue index of the message in the L1 contract
  Gas        uint64          // Gas limit
  To         *common.Address // Target address; contract creation from L1 is not permitted
  Value      *big.Int        // Amount of Ether to transfer
  Data       []byte          // Encoded data for the transaction
  Sender     common.Address   // Address initiating the transaction
}

The RLP encoding for L1MessageTx transactions follows the EIP-2718 format: TransactionType || TransactionPayload, where the TransactionType is 0x7E and the TransactionPayload is the RLP encoding of L1MessageTx.

Two key characteristics of L1MessageTx transactions include:

1. The QueueIndex indicates the position within the L1 message queue, which is distinct from the nonce of the sender's account. However, the sender’s nonce will still increment by 1 after this transaction.

2. L1MessageTx transactions do not incur L2 or L1 fees. The L2 fee is already covered when users submit their transactions on L1, and no L1 fee is charged since the data for L1MessageTx transactions is readily available in the L1 bridge contract.

Transaction Life Cycle

The life cycle of a transaction in Wischain comprises three main phases:

1. Confirmed: A transaction is submitted to either the L1 bridge contract or the L2 sequencer. It achieves a Confirmed status once it is executed and included in an L2 block.

2. Committed: Transactions are batched together, and a commit transaction containing this batch's data is submitted to L1. Once the commit transaction is finalized within an L1 block, the transactions in this batch are marked as Committed.

3. Finalized: After generating the validity proof for the batch, it is verified on L1. Once the finalize transaction is confirmed in an L1 block, the status of the transactions in the batch is upgraded to Finalized, becoming a canonical part of the Wischain L2 chain.

Submitting Transactions

Users can submit transactions to Wischain through two main pathways:

1. Direct Submission to L2 Sequencers: Users can connect their wallets to the Wischain RPC endpoint and directly submit transactions to the L2 sequencers. The sequencer will validate the transaction and store it in its local transaction pool.

2. Transactions Originating from L1: The Wischain L1 bridge contract offers three entry points for users and smart contracts to send transactions from L1, which are then added to the L1MessageQueue contract:

   • WischainGatewayRouter Contract: Allows the deposit of standard tokens to L2.

   • L1ScrollMessenger Contract: Facilitates the sending of arbitrary messages to L2.

   • EnforcedTxGateway Contract: Enables Externally Owned Accounts (EOAs) to initiate enforced transactions, such as withdrawing tokens or calling contracts on L2.

The Wischain sequencer regularly initiates new mining jobs by pulling L1 messages from the L1MessageQueue contract along with transactions from the L2 mempool to seal a block. Once a transaction is included in an L2 block, its status transitions to Confirmed.

Commit Transaction Data

The rollup node collects new L2 blocks, packaging them into chunks and batches (see more on Transaction Batching). Periodically, it submits a Commit Transaction that posts the batch of transaction data to the L1 WischainChain contract. After this Commit Transaction is finalized in an L1 block, the status of the transactions within that batch shifts to Committed. At this stage, users can independently reconstruct the L2 state based on the committed data from the L1 contract.

Finalize Transactions

Following the generation of the validity proof, the rollup node sends a Finalize Transaction that includes the validity proof and the new state root for on-chain verification. Once the Finalize Transaction succeeds and is confirmed in an L1 block, the status of the L2 transactions within that batch changes to Finalized. The new state root can then be utilized by third parties in a trustless manner.

Transaction Batching

In Wischain, transactions are organized into a multi-tier batching system:

1. Blocks: A collection of ordered transactions packed into a block.

2. Chunks: A series of contiguous blocks grouped together. Each chunk serves as the foundational unit for proof generation within the zkEVM circuit.

3. Batches: Multiple contiguous chunks are combined into a batch, which serves as the base unit for data commitment and proof verification on L1. The proof for a batch, referred to as a batch proof, is an aggregated proof of the chunk proofs contained within that batch.

This multi-layer batching schema aims to reduce the gas costs associated with on-chain data commitment and proof verification. It enhances the granularity of rollup units on L1 while considering the fixed capacity of the proving circuit. Consequently, batching minimizes the amount of data stored in the contract and spreads the proof verification costs across multiple L2 transactions.

When a chunk is created, a corresponding proving task is generated and assigned to a zkEVM prover. Following the creation of a new batch, two primary actions occur: (a) the rollup node commits the transaction data and block information from the batch to the L1 contract, and (b) a batch proving task to aggregate the chunk proofs is dispatched to an aggregator prover. Detailed standards for proposing chunks and batches can be found in the Rollup Node documentation.