Block do not provide the actual receiptsRoot, transactionsRoot

[ab697d53cb5378b44dbd84e1fb14721d]

Environment

Mainnet

Provide a brief description of the functionality you're trying to implement and the issue you are running into.

Why are the receiptsRoot and transactionsRoot values not computed for a block? These values are specific to the transactions in the block and would be useful for verifying the block.

How can I programmatically verify that a transaction was included in a particular block and batch?
Reference to Ethereum JSON-RPC API differences:
https://docs.zksync.io/build/api-reference/ethereum-rpc

Repo Link (Optional)

No response

Additional Details

No response

[gleenai[bot]]

In ZKsync Era, the receiptsRoot and transactionsRoot values are not computed for a block like they are in Ethereum. This is because ZKsync's Layer 2 (L2) blocks do not include the concept of a state root; only Layer 1 (L1) batches have this concept. Therefore, fields such as receiptsRoot, transactionsRoot, and stateRoot contain zero values in the block data.

To programmatically verify that a transaction was included in a particular block and batch, you can use methods like eth_getBlockByHash or eth_getBlockByNumber to retrieve block details. Although these methods do not provide the actual receiptsRoot and transactionsRoot, they still list the transactions included in the block. For batch-related verifications, you might need to refer to specific L1 batch numbers associated with the block, if available.

For more detailed information on how these methods work and their limitations in ZKsync, you can refer to the Ethereum JSON-RPC API documentation for ZKsync.

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.

[bxpana]

@ab697d53cb5378b44dbd84e1fb14721d looks like this was not the answer you were expecting?

[ab697d53cb5378b44dbd84e1fb14721d]

Hey @bxpana,
Is there is a reason why those roots can't be computed they don't rely on the stateRoot to exist.

[bxpana]

This is what I got back from the team:

If they want to do offchain verificaitons, then It all boils down to who you trust. For instance, in case of an L1 if you want to programmatically "verify" that a transaction is a part of a block you would check the merkle proof of a receipt root, yes. On the other hand, the question is: where do you get the root from? From some Infura API/your node? If so, can't you just query the same source of root? I.e. just ask your Infura/your node since you anysway trust them.

Okay, let's say that the task is a bit different: if you have some trusted source of block hashes (e.g. the blockhash command in Solidity). Now you want to users to be able to verify on their own against this trusted source. If this is the sort of question we are trying to solve, then the hash of our L2 block is https://github.com/matter-labs/era-contracts/blob/f4ae6a1b90e2c269542848ada44de669a5009290/system-contracts/contracts/SystemContext.sol#L231. The last part is _blockTxsRollingHash. It is a rolling hash of all the txs in a block: https://github.com/matter-labs/era-contracts/blob/f4ae6a1b90e2c269542848ada44de669a5009290/system-contracts/contracts/SystemContext.sol#L407. The verification is not O(logn), but O(n), but this n is usually small, so should be fine. Unfortunately there is nothing better atm

[ab697d53cb5378b44dbd84e1fb14721d]

Thanks for the reply @bxpana , yes it is the second task we are trying to solve.
I have implemented the block hash calculation and this works although I'm still curious why something like:
keccak256(abi.encode(_blockNumber, _blockTimestamp, _prevL2BlockHash, _receiptsRoot, _transactionsRoot)); is not preferred. I guess there might be some trade-off versus proving overhead to consider.
In any case the feedback is appreciated.

[bxpana]

Checking on this

[bxpana]

Unfortunately it is expensive to calculate the receipts root inside our system, i.e. it is obviously easy to be done on the server side, but if we wanted to include it into the L2 block hash, it would have to be validated within zk circuits and this part is expensive

[ab697d53cb5378b44dbd84e1fb14721d]

Understood, thanks a lot for the feedback much appreciated. 🙏