[COMPLETE] Upgrade plan for block.timestamp , block.number and blockhash

[uF4No]

As we announced a few weeks ago, we’re making important changes to how block.number, block.timestamp, and blockHash behave on zkSync Era.

Such an important change on a live protocol comes with risks and unavoidable impact on projects. We've gathered feedback from different teams and, after multiple discussions internally we've come up with a plan.

Here is what you need to know:

⚙️ About L2 blocks and L1 batches

In zkSync Era there are two notions of blocks: L2 blocks and L1 batches.

• L2 blocks, are the blocks created on the L2 (that is on the zkSync Era network), they’re produced every few seconds, and they are not included on the Ethereum chain.
• On the other hand, L1 batches are batches of consecutive L2 blocks that contain all the transactions in the same order, from the first block to the last block in the batch. L1 batches are produced every 30-90secs on zkSync Era mainnet (depending on the network activity) and as the name suggests, are submitted to Ethereum. More info in our docs.

At the time of this post, the latest L1 batch number is 148131, while the latest L2 block number is 10622404.

🔀 Scope of Changes

block.number, block.timestamp and blockHash currently return the number, timestamp and hash of the L1 batch. After the update is completed (see details below), they will return the number, timestamp and hash of the L2 block. We will also 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 few 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.

🧙‍♂️ Upgrade process

In order to maintain consistency and validity of the protocol's state and reduce the impact on existing projects, this update will not be instant. Instead of updating the number, timestamp and blockhash to return values from the current L2 block immediately after the update, which would result in a big jump from one block number to first one after the update, we'll roll out the changes during a catch-up period.

During this period we'll generate multiple "virtual blocks" for every L2 block. These "virtual blocks" will have a sequentially increased block.number (starting from the latest L1 batch number), the block.timestamp of the corresponding L2 block, and their own blockhash generated using the virtual block number.

The timestamp, number and blockchash returned from the protocol will correspond to the latest virtual block during the catch-up.

At the beginning, virtual blocks will be generated at the same rate as L1 batches, although we will increase virtual blocks production rate (e.g. generate 4 virtual blocks per L2 block). This will allow us to eventually catch up with the current L2 block number value.

🤨 Why this approach?

This approach is the one with the less impact on existing projects.

Updating the block.number immediately would generate problems on indexers and APIs as there would be a big gap between the the latest block number and the first one after the update, which would require projects to re-index all the historic data.

The virtual blocks and catch-up period approach will avoid this issue.

🚨 Impact on Projects

block.timestamp

From the moment we start the catch-up period, block.timestamp will return the timestamp of the latest virtual block. At the beginning it will return the timestamp of the L1 batch (same as now as virtual blocks will be produced at the same rate as L1 batches) but this value will be updated more frequently as we increase the speed at which virtual blocks are generated.

Once the catch-up period ends, block.timestamp will be refreshed at the rate of L2 block production (every few seconds).

block.number

The number of L2 blocks far exceeds the number of L1 batches (each batch contains a set of blocks). During the catch-up period the block.number will return the latest virtual block number. As we will start generating multiple virtual blocks per L2 block, this value will be getting closer to the actual L2 block number until eventually picking up with the latest L2 block.

Once the catch-up period ends, block.number will return the current L2 block number.

blockHash

This upgrade will change the structure of blockHash. The hash of the L1 batch is the root of the merkle tree. During the catch-up period, the blockhash returned will be generated from using the following method: keccak(virtual_block_number).

After the catch-up period, it will return the hash of the L2 block which has a different composition (a mix of timestamp block number, and potentially additional data about the L2 block).

🔍 Summary

Variable	Current value	Value returned during catch-up period	Value returned after upgrade
block.timestamp	timestamp of the L1 batch	timestamp of the latest virtual block (update speed varies during catch-up period )	timestamp of the L2 block (updated every 2-3secs)
block.number	number of the L1 batch	number of the latest virtual block (between L1 batch and L2 block, catching up)	number of the L2 block
blockhash	hash of the L1 batch	hash of the virtual block, generated from the virtual block number	hash of the L2 block

🗓️ [UPDATED] Upgrade Timeline

The changes for this update are currently being developed. We'll test the update process internally before moving to testnet and finally mainnet. The upgrade will start in the following dates:

• Testnet upgrade: On August 31st, we will start the upgrade on zkSync Era Testnet. The catch-up period will last for about 14 days.
• Mainnet upgrade: On September 7th at 10:00 UTC, we will start the upgrade on zkSync Era Mainnet. The catch-up period will last for about 40-60 days. Given that the amount of transactions/blocks/batches depend on network activity, we estimate a catch-up period of 50 days. Here is the expected rates over time we'll be using:
  • 07/09 : 1 virtual block per 60 L2 miniblocks
  • 08/09 - 10/09 : 1 virtual block per 30 L2 miniblocks
  • 11/09 - 12/09 : 1 virtual block per 15 L2 miniblocks
  • 13/09 - 14/09 : 1 virtual block per 7 L2 miniblocks
  • After 14/09 : We'll continue to gradually accelerate the speed of virtual block production until it reaches 8x-10x of the miniblock production rate

⛑ Risks and Considerations

The block production rate and timestamp refresh time will be gradually increased during the catch up period.
If your project has critical logics that rely on the values returned from block.number, block.timestamp or blockhash you might face unexpected behaviour (e.g. reduced time for governance voting, spike in rewards etc.). These logics could include (non-exhaustive):

• Relying on differences in block.number to compute rewards.
• Relying on block.number to calculate when an auction ends or calculate time.
• Relying on current block.timestamp or block.number to calculate LP rewards or loan interests.
• Relying on blockhash to generate randomness.

Please check if your project leverages any of these variables, read carefully the detailed information about the upgrade, and contact us if you have any questions.

🛫 Deploying New Projects

If your project does not rely on these variables, you can deploy today or during the catch-up period, there’s no need to wait!

If your project uses block.number, block.timestamp or blockhash, you should analyse if an increase in the block production rate, timestamp refresh period, or changes in the blockhash will impact your project. If it doesn't, you can also deploy at any time. You can ask us if you have a specific scenario and you're not sure.

If in doubt, wait until the upgrade is completed, deploy your project on testnet, and do extensive tests before deploying on mainnet. Follow the security and recommendations from our docs.

💬 Feedback

If you have any feedback or questions about these changes, reply below and we'll get back to you!

❓FAQ

We have a project on zkSync Era, how will this upgrade impact our project?

Please read carefully the "Impact on Projects" and "Risks and Considerations" sections above.

We're about to deploy a new project; should we wait after the upgrade?

Please read the "Deploying new project" section above. If you have any questions reply to this thread and we'll help.

Would we be able to query the L2 block data during the catch-up period?

Yes! We'll provide a contract getter that will return the L2 block number and timestamp (not the hash though!). The exact method signature will be provided later on.

During the catchup period, is there any temporary RPC method to get the virtual blocks information?

No. We won't have RPC methods to retrieve the virtual block info, but keep in mind that block.number, block.timestamp and blockhash will reference the virtual blocks during the catch-up period.

Is there a contract to query the virtual blocks data?

The Satis Foundation team (thanks @enochSatis 🙏) deployed getter contracts to retrieve the virtual block data. Addresses are:

• Tesnet: 0x5DB4d431E4308d8b41b804be0850B79332A2025C
• Mainnet: 0x5DB4d431E4308d8b41b804be0850B79332A2025C

Will these changes affect the responses from RPC requests?

No, responses for RPC requests already contain information related to L2 blocks.

Edit (07-09-2023): Updated planned timeline for upgrade on mainnet. Updated "NEW" and "UPDATED" tags for some sections

[wilsonSatis]

Thanks for the heads up. looking forward to the upgrade!

[siliasi]

Great

[axelcazorla]

top !!

[gauravl-tevaeralabs]

Thank you for sharing the information. We're eagerly looking forward to the changes.

[deanpress]

Thanks for the update @uF4No. Would it be possible to provide a precompile that already displays L2 block data before the catch-up period ends? Could be useful for certain contracts waiting to be deployed that want to utilize L2 block data right away.

[uF4No]

yes

[uF4No]

@deanpress We've updated the first post with the dates, please check it out

[deanpress]

@uF4No Good news! Thanks. To clarify: I understand that during the catch-up period, the EVM block methods will still not match what's being returned by the RPC? In that case we will have to build a workaround to emit block data of a transaction in an event, though it would be much better if we could somehow still get it from an RPC (so we don't waste gas and bandwidth on pushing events with data that's already known on chain).

[uF4No]

that's correct. EVM will return the information corresponding to the virtual blocks and, at the beginning of the catch-up period, virtual blocks will be produced at the same rate as L1 batches.
Although there won't be an RPC, as you mentioned you can build a workaround by emitting an event, or call the getter contract method getL2BlockNumberAndTimestamp that we mentioned earlier.

[sakib70]

ooo thanks

[enochSatis]

@uF4No thanks for your update.

During the catchup period, is there any temporary RPC method to get the virtual blocks information (just like getting L1 Batches and L2 Blocks now)?

[enochSatis]

Hmm, I cannot verify it on the block explorer, nor I can verify by hardhat either.

When I ran verify with hardhat, it somehow recompiled my contract and the deployed bytecode is no longer the same. I did not change the contract since the first deployment though. Any clues on it? When I deploy new contracts and verify it immediately, it works though.

Might need to wait for Mainnet gas price to be low again if redeployment is the only way.

[enochSatis]

Update:

The contract is verified on both testnet and mainnet.

[uF4No]

added to the main post 🤙

[uF4No]

@enochSatis We've updated the first post with the dates, please check it out.

[uF4No]

no, there won't be a regenesis

[nickwarkdev]

great update thanks!

[yawarshami]

Nice

[VeeruNFT]

Great work!

[gaganoo]

looking for the upgrade, thanks @uF4No

[tapu6090]

Thank you

[Dolzyn]

In this upgrade the stucked 900+ETH will be withdrawable?
Nice too see you are working and communicate with your community!

[uF4No]

No, but there are other updates that we're working on for that issue.

[Dolzyn]

Thanks for answer.

[0fprod]

ta bueno niño 🚀

[pj935591]

This is a highly anticipated enhancement, would be great if the build is ready on testnet by August end.

[uF4No]

@pj935591 We've updated the first post with the dates, please check it out.

[ZKEraBitcoin]

Great update, needed it to launch our contracts. Any idea when we see it on testnets / mainnet

[uF4No]

@ZKEraBitcoin We've updated the first post with the dates, please check it out 🤙

[uF4No]

We've updated the original post to include the dates and more information for projects that are planning to deploy.

Let us know if you have any questions or want to share any feedback

[isko5418]

спасибо за информацию, с нетерпением ждем перемен, процветания!!!

[MexicanAce]

📢 UPDATE 📢

🕙 Today's mainnet upgrade is planned to start at 10:00 UTC.

We'll start with roughly 1 virtual block per 60 L2 miniblocks (and also 1 virtual block per start of batch), which would translate to almost 1x-2x faster than before.

➡️ The current plan right now is the following:

• 07/09 : 1 virtual block per 60 L2 miniblocks
• 08/09 - 10/09 : 1 virtual block per 30 L2 miniblocks
• 11/09 - 12/09 : 1 virtual block per 15 L2 miniblocks
• 13/09 - 14/09 : 1 virtual block per 7 L2 miniblocks
• After 14/09 : We'll continue to gradually accelerate the speed of virtual block production until it reaches 8x-10x of the miniblock production rate

ℹ️ We might adapt the plan as we go, so we may change these parameters based on TPS and/or community feedback.

🙋 As always, please post any questions or concerns in this Discussion. We'll continue to update this Discussion as we progress through the upgrade.

[earnings4all]

Nice info,thanks.

[ThirawatChuaiklang]

Mm

[enochSatis]

Hey @uF4No @MexicanAce

Our Satis Foundation team has made a simple Grafana visualisation for the block catch-up. Would like to share with the community so one can easily check the catch-up progress!

Here is the link to the Grafana dashboard:
http://zksync-vblock.satis.foundation/public-dashboards/ee458e90d699447a9f3550f204c19ab9

Currently, the virtual block number is so close to the L1 batch number that it is not displayed (yet). Things will look better after 14 Sep I think (when zkSync produces virtual block faster than L2 blocks).

[ThirawatChuaiklang]

Bc

[MexicanAce]

📢 UPDATE 📢

➡️ Testnet catch-up period has exceeded the original 14 days, but we will most likely complete the migration by the end of this week (maybe on Friday September 22)

➡️ Mainnet catch-up is increasing steadily currently at 1 virtual block per 2 L2 miniblocks. We plan to increase this rate to 1:1 today, and then to 2 virtual blocks per 1 L2 miniblock on Friday September 22.

🙋 As always, please post any questions or concerns in this Discussion. We'll continue to update this Discussion as we progress through the upgrade.

[eastlance27]

How can i withdraw my stake in Era token

[MexicanAce]

📢 UPDATE 📢

Testnet has fully caught up, from now on block.number/block.timestamp will return miniblock information.

[wilsonSatis]

Congratulations!

[eastlance27]

Is there any chance to recover my stake

[ThirawatChuaiklang]

// กำหนดสัญญาและเวอร์ชั่น
pragma solidity ^0.8.0;

// กำหนดสัญญาสาธารณะ
contract RewardSystem {
// สิ่งที่ควรระบุ: ค่าแก๊ส, ผู้ใช้, และเหรียญรางวัล

// ค่าแก๊สที่ใช้สำหรับการทำธุรกรรม
uint256 public gasFee;

// รายการผู้ใช้ที่มีสิทธิรับรางวัล
address[] public eligibleUsers;

// เหรียญรางวัล
ERC20Token public rewardToken;

// รายการรางวัลของผู้ใช้
mapping(address => uint256) public userRewards;

// สร้างสัญญากับค่าแก๊สเริ่มต้นและเหรียญรางวัล
constructor(uint256 _gasFee, address _rewardTokenAddress) {
    gasFee = _gasFee;
    rewardToken = ERC20Token(_rewardTokenAddress);
}

// กำหนดฟังก์ชันสำหรับผู้ใช้รับรางวัล
function claimReward() public {
    require(isEligible(msg.sender), "You are not eligible for rewards.");
    uint256 rewardAmount = calculateReward(msg.sender);
    require(rewardToken.transfer(msg.sender, rewardAmount), "Reward transfer failed.");
    userRewards[msg.sender] = userRewards[msg.sender] + rewardAmount;
}

// ตรวจสอบว่าผู้ใช้มีสิทธิรับรางวัลหรือไม่
function isEligible(address user) public view returns (bool) {
    for (uint256 i = 0; i < eligibleUsers.length; i++) {
        if (eligibleUsers[i] == user) {
            return true;
        }
    }
    return false;
}

// คำนวณรางวัลสำหรับผู้ใช้
function calculateReward(address user) public view returns (uint256) {
    // คำนวณตามรากการและเงื่อนไขที่กำหนดเอง
    // ตัวอย่าง: rewardAmount = gasFee * 2
    return gasFee * 2;
}

}

// สัญญา ERC20 ในตัวอย่าง
contract ERC20Token {
// โครงสร้างสัญญา ERC20
// คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับสัญญา ERC20 ได้จากที่อื่น
}

[AlexHD79]

Хорошая работа

[sebastiantf]

How does the motivation for this upgrade consider the original motivation for the original case?: https://era.zksync.io/docs/reference/concepts/blocks.html#why-do-we-return-l1-batches-inside-evm

[MexicanAce]

📢 UPDATE 📢

➡️ Mainnet reached the max speed of virtual block production at 8 virtual block per 1 L2 miniblock

➡️ Assuming that the speed of catch-up will continue the same as it did in the last 24h, the estimate for catching up is 17 days. This is consistent with the previously planned timeline to end the migration at the late October.

🙋 As always, please post any questions or concerns in this Discussion. We'll continue to update this Discussion as we progress through the upgrade.

[siyangsihai]

Thank you , i get this

[dextfprotocol]

Has the Mainnet catch up completed? If not, is there a way to monitor the progress (webpage or something)?

[wilsonSatis]

It is 98+% completed.

Sat.is Foundation hs built a dashboard for that

http://zksync-vblock.satis.foundation/public-dashboards/ee458e90d699447a9f3550f204c19ab9?orgId=1&refresh=5m

[dextfprotocol]

Great! Thank you

[MexicanAce]

📢 UPDATE 📢

➡️ Mainnet has completed the catch-up period as of 15:00 UTC today! No issues were found and the system works as expected.

🤝 Special thanks to sat.is for their monitoring via Grafana Dashboard

➡️ As there are no further updates expected, we are closing this Announcement.

🙋 If you have any questions or concerns, please start a new GitHub Discussion.