Upcoming changes to block.number, block.timestamp & blockHash

[uF4No]

UPDATE
All details and upgrade plan have been shared in this new thread.

Original message below

We’re making important changes to how block.number, block.timestamp, and blockHash behave on zkSync Era. Here is what you need to know:

🔀 Scope of Changes

block.number, block.timestamp and blockHash currently return the number, timestamp and hash of the L1 batch. After these changes they will return the number, timestamp and hash of the L2 block. We will introduce a new set of methods for accessing values in the L1 batch.

⏱️ Background & Motivation

Many applications require a higher fidelity of time that can be achieved by referencing L1 batches. With these changes, contracts will be able to measure time at the level of L2 blocks (produced ≈ every 1 - 2 seconds!). This information is already available on the API but with the upcoming changes, developers will be able to access it directly in the smart contracts. For consistency, block.number and blockHash should also correspond to the L2 block.

🚨 Impact on Projects

block.number

The number of L2 blocks far exceeds the number of L1 batches (each batch contains a set of blocks). This means that immediately after the changes have been applied there will be one-time jump in the value returned by block.number. For example: if the changes were applied in this batch — it could change from 74126 → 652929. After this jump, block.number will only return values from the L2 block.

block.timestamp

The timestamp of L1 batches is roughly equivalent to the timestamp for L2 batches. So while block.timestamp will also jump from batches to L2 blocks, the change will be less significant. After this point, block.timestamp will be updated at the rate of L2 block production (≈ every 1 -2 seconds).

blockHash

This upgrade will change the structure of blockHash. The hash of the L1 batch is the root of the merkle tree. The hash of the L2 block, however, has a different composition (a mix of timestamp block number, and potentially additional data about the L2 block).

🗓️ Upgrade Timeline

Instead of providing a specific date right away, we would like to involve the developer community in gathering feedback first. However, as a rough estimate, we anticipate implementing these changes sometime between July and August.

💬 Feedback

If you have any feedback on these changes we would love to hear from you!

[deanpress]

Thank you for working on this. I (as I'm sure many developers) are happy to hear timestamps and blockhashes will be more in key with what we expect.

For current development I had to build an L2 block data oracle just so we could get our contracts working with zkSync. I would much prefer to use on-chain data for this rather than having to build completely separate versions of each contract I'm working on just to get it working with zkSync.

Regarding blockhash, can we expect it to offer similar PRNG to L1 blockhash? I noticed you said "potentially additional data about the L2 block". Preferably this is as much data of the L2 block as possible.

Also, what will the history limit be for blockhashes? On L1 it's 256 but some L2 networks have it infinitely available.

[uF4No]

The blockhash will include number, timestamp and hashes of the transactions. Unlike Ethereum, it will not include the state root. We would not encourage the use of blockhash as a source for randomness. You can use it but keep in mind it might not be secure.

what will the history limit be for blockhashes?

It will be 256

[KonScanner]

Suppose I wanted to say to initialize a contract_address and call balanceOf for a specific block. Will it be that before a certain point, I need to use the L1 block number and then use the L2 block number?

[githubdoramon]

@KonScanner in this case you mean calling it from the API, not on solidity right? If this is the case, the API already works with L2 number and timestamp, so nothing changes there.

[nishuzumi]

Hello sir, this block number modification is nothing but a heavy blow to some DEFI applications, can I know the exact timing otherwise some protocols that distribute rewards as per block number may have huge problems.

[uF4No]

@nishuzumi We wanted to create this thread to gather feedback from projects (thanks!) and understand potential issues and how these changes might affect different projects across the ecosystem.

We understand these changes might impact some projects so we won't make the update without a proper notice period.

[uF4No]

We've just shared all the details of the upgrade plan in this new thread

[333david]

Zksync is the best layer 2 product

[jmwhangjin]

This is the best

[mnuww]

keep going