[ZK Stack] - What does block level log mean

[MRabenda]

Team or Project

No response

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.75

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Hey,

As a team we want to index similar to other EVMs available in Ethereum ecosystem, zkSync to our database. During indexing process we found a block 2225352 which does not have any transaction, receipt or trace but emitted that log

[
  {
    "jsonrpc": "2.0",
    "result": [
      {
        "address": "0x000000000000000000000000000000000000800a",
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x0000000000000000000000000000000000000000000000000000000000008001",
          "0x000000000000000000000000feee860e7aae671124e9a4e61139f3a5085dfeee"
        ],
        "data": "0x000000000000000000000000000000000000000000000000047a6df982eed8c4",
        "blockHash": "0xe72a03c5970c374dc1f66b76e629cd493a1dec626e1a97352cbe176be9585752",
        "blockNumber": "0x21f4c8",
        "l1BatchNumber": "0x4e43",
        "transactionHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "transactionIndex": "0x0",
        "logIndex": "0x0",
        "transactionLogIndex": "0x0",
        "logType": null,
        "removed": false,
        "blockTimestamp": "0x6447d357"
      }
    ],
    "id": 0
  }
] 

I understand that:

• 0x0000000000000000000000000000000000008001 is bootloader contract (transfer was from that address)
• 0000000000000000000000000000000000008001 is L2BaseToken, this mean ETH as transferred

But could you help me understand why this event was emitted? How received that ETH and why?

Expected Behavior

Current Behavior

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

In the context of ZKsync, a "block level log" typically refers to logs that are generated by system contracts within a block, even if there are no explicit user transactions within that block. These logs are crucial for maintaining the state and operations of the system contracts on the ZKsync network.

From the log data you provided, it appears that the log was emitted by the bootloader contract (0x0000000000000000000000000000000000008001). This contract is responsible for various system-level functions, including handling transfers of the base layer token (L2BaseToken, which in this case is ETH).

The log indicates a transfer event (0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef), which is a standard ERC-20 Transfer event. The data field shows the amount transferred, and the topics indicate the involved addresses.

The recipient of the ETH (0xfeee860e7aae671124e9a4e61139f3a5085dfeee) and the amount transferred can be decoded from the data and topics fields. This event might have been triggered by a system operation or maintenance activity that required the transfer of ETH, possibly related to fee distributions or internal system adjustments.

For more detailed insights into how these system contracts operate and manage such logs, you can refer to the ZKsync documentation on System Contracts and the specific mechanisms they use for logging and handling transactions.

For further technical discussions or to delve deeper into specific implementation details, I recommend visiting the ZKsync developers discussions on Github.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[cytadela8]

@MRabenda All transactions in ZK Stack blockchains emit transfer events for the transaction fee. This fee (and transfer events) transfers happen between fee payer (from address or paymaster) and 0x8001 (the bootloader).

However, the bootloader does not hold these fees. All fees are transferred to the current fee collection address. This was previously 0xfeee860e7aae671124e9a4e61139f3a5085dfeee, now it is 0xA9232040BF0E0aEA2578a5B2243F2916DBfc0A69. These transfers happen only at the end of the batch. Not during every block. (One batch contains multiple blocks.)

Block 2225352 is the last block in a batch. It happens not to contain any transactions, but the transfer of collected fees from bootloader to fee collection address is attached to it.