Update Docs to Include New Definition of Block Timestamp and Number (#…

…711)

* fix: block.timestamp to updated definition

* docs: update more docs to reflect completion of migration

---------

Co-authored-by: MexicanAce <[email protected]>

docs/README.md

@@ -21,10 +21,6 @@ contributors: false
    </div>
 </div>
 
-::: warning Protocol upgrade
-In the upcoming protocol upgrade scheduled for August-September 2023, there will be modifications to how certain block properties are implemented on zkSync Era. Find more details [in the announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
-:::
-
 <section>
 
   <div class="card-container">

docs/dev/building-on-zksync/best-practices.md

@@ -9,10 +9,6 @@ head:
 
 Before diving into development on zkSync Era, it's crucial to consider the following recommendations. These best practices will help you optimize your code, ensure security, and align with the unique characteristics of zkSync Era.
 
-::: warning Upcoming changes
-In the upcoming protocol upgrade scheduled for August-September 2023, there will be modifications to how certain block properties are implemented on zkSync Era. Find more details [in the announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
-:::
-
 ## Use `call` over `.send` or `.transfer`
 
 Avoid using `payable(addr).send(x)`/`payable(addr).transfer(x)` because the 2300 gas stipend may not be enough for such calls, especially if it involves state changes that require a large amount of L2 gas for data. Instead, we recommend using `call`.

docs/dev/tutorials/aa-daily-spend-limit.md

@@ -194,7 +194,7 @@ The code below sets and removes the limit.
         require(_amount != 0, "Invalid amount");
 
         uint resetTime;
-        uint timestamp = block.timestamp; // L1 batch timestamp
+        uint timestamp = block.timestamp; // L2 block timestamp
 
         if (isValidUpdate(_token)) {
             resetTime = timestamp + ONE_DAY;
@@ -266,7 +266,7 @@ The `_checkSpendingLimit` function is internally called by the account contract
         // return if spending limit hasn't been enabled yet
         if (!limit.isEnabled) return;
 
-        uint timestamp = block.timestamp; // L1 batch timestamp
+        uint timestamp = block.timestamp; // L2 block timestamp
 
         // Renew resetTime and available amount, which is only performed
         // if a day has already passed since the last update: timestamp > resetTime
@@ -370,7 +370,7 @@ contract SpendLimit {
         require(_amount != 0, "Invalid amount");
 
         uint resetTime;
-        uint timestamp = block.timestamp; // L1 batch timestamp
+        uint timestamp = block.timestamp; // L2 block timestamp
 
         if (isValidUpdate(_token)) {
             resetTime = timestamp + ONE_DAY;
@@ -429,7 +429,7 @@ contract SpendLimit {
         // return if spending limit hasn't been enabled yet
         if (!limit.isEnabled) return;
 
-        uint timestamp = block.timestamp; // L1 batch timestamp
+        uint timestamp = block.timestamp; // L2 block timestamp
 
         // Renew resetTime and available amount, which is only performed
         // if a day has already passed since the last update: timestamp > resetTime
@@ -1044,15 +1044,7 @@ Reset time was not updated as not enough time has passed
 
 The `available` value in the `Limit` struct updates to the initial limit minus the amount we transferred.
 
-Since `ONE_DAY` is set to 1 minute for this test in the `SpendLimit.sol` contract, you should expect it to reset after 60 seconds. However, we're using `block.timestamp` so the limit is only reset after a new L1 batch is sealed (around ten minutes on testnet). To understand the reason behind this, we should know about the constraints around using `block.timestamp`.
-
-::: warning `block.timestamp` returns L1 batch value
-
-`block.timestamp` returns the time of the latest L1 batch, instead of the L2 block, and it's only updated once a new batch is sealed (~5-10 minutes on testnet). What this means is that `block.timestamp` in smart contracts on zkSync Era is currently a delayed value.
-
-To keep this tutorial as simple as possible, we've used `block.timestamp` but we don't recommend relying on this for accurate time calculations.
-
-:::
+Since `ONE_DAY` is set to 1 minute for this test in the `SpendLimit.sol` contract, you should expect it to reset after 60 seconds. However, we're using `block.timestamp` so the limit is only reset after a new L2 block is collated (around 2-3 seconds).
 
 ## Common Errors
 

docs/reference/architecture/differences-with-ethereum.md

@@ -161,13 +161,13 @@ contract Example {
 
 ### `TIMESTAMP`, `NUMBER`
 
-::: warning Upcoming changes
-In the upcoming protocol upgrade scheduled for August-September 2023, there will be modifications to how certain block properties are implemented on zkSync Era. Find more details [in the announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
-:::
-
 For more information about blocks on zkSync Era, including the differences between `block.timestamp` and `block.number`,
 check out the [blocks on zkSync Era documentation](../../reference/concepts/blocks.md#blocks-in-zksync-era).
 
+::: note Changes From the Previous Protocol Version
+Modifications were performed on how certain block properties were implemented on zkSync Era. For details on the changes performed visit the [announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
+:::
+
 ### `COINBASE`
 
 Returns the address of the `Bootloader` contract, which is `0x8001` on zkSync Era.

docs/reference/concepts/blocks.md

@@ -26,10 +26,10 @@ The following are the block properties returned when you use the `getBlock` meth
 
 | Parameter     | Description                                                                                                                               |
 | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
-| hash          | The hash of the block. null if pending                                                                                                    |
+| hash          | The hash of the L2 block. null if pending                                                                                                 |
 | parentHash    | It refers to the hash of the parent block in L2.                                                                                          |
-| number        | The number of the current block. null if pending. [More info on block.number](#block-number-and-timestamp-considerations)                 |
-| timestamp     | The UNIX timestamp for when the block was collated. [More info on block.timestamp](#block-number-and-timestamp-considerations)            |
+| number        | The number of the current L2 block. null if pending. [More info on block.number](#block-number-and-timestamp-considerations)              |
+| timestamp     | The UNIX timestamp for when the L2 block was collated. [More info on block.timestamp](#block-number-and-timestamp-considerations)         |
 | nonce         | It's the most recent transaction based on the account's counter, which maintains track of how many transactions it does. null if pending. |
 | difficulty    | The current block difficulty returns 2500000000000000 (zkSync does not have proof of work consensus).                                     |
 | gasLimit      | The maximum gas allowed in this block encoded as a hexadecimal, always returns `2^32-1`.                                                  |
@@ -90,18 +90,12 @@ Projects are advised not to use the L2 block hash as a source of randomness.
 
 ## Block number and timestamp considerations
 
-::: warning Upcoming changes
-In the upcoming protocol upgrade scheduled for August-September 2023, there will be modifications to how certain block properties are implemented on zkSync Era. Find more details [in the announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
-:::
+The `number` and `timestamp` properties of the block retrieved via the API using any of the SDKs will refer to L2 blocks, this is also the case for `block.number` and `block.timestamp` in smart contracts.
 
-The `number` and `timestamp` properties of the block retrieved via the API using any of the SDKs will refer to L2 blocks however, `block.number` and `block.timestamp` in the EVM (on smart contracts), return the number and timestamp of the L1 batch respectively.
+::: note Changes From the Previous Protocol Version
+Modifications were performed on how certain block properties were implemented on zkSync Era. For details on the changes performed visit the [announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
+:::
 
 ### Why do we return L2 blocks from API?
 
 On zkSync Era we return L2 blocks from API because this is how all platforms, which include SDKs, Metamask and all other popular wallets can perceive our transactions as processed. It is expected that a transaction is processed once it is included in a block. That's why we need to produce L2 blocks faster than L1 batches.
-
-### Why do we return L1 batches inside EVM?
-
-Currently, we return the number and timestamp of the L1 batch inside the VM, as the values related to the L2 block will be unprovable. Unlike Ethereum blocks that contain some kind of commitment to the state of the chain, on zkSync Era these blocks won't have such commitment, because calculating the Merkle tree is too expensive to be done more often than once per batch.
-
-A method to retrieve the L2 block number and timestamp inside the EVM is under development.

docs/reference/troubleshooting/changelog.md

@@ -7,10 +7,6 @@ head:
 
 # Changelog
 
-::: warning Upcoming changes
-In the upcoming protocol upgrade scheduled for August-September 2023, there will be modifications to how certain block properties are implemented on zkSync Era. Find more details [in the announcement on GitHub](https://github.com/zkSync-Community-Hub/zkync-developers/discussions/87).
-:::
-
 ## Hardhat plugins update (June 21st, 2023)
 
 - New release of `@matterlabs/hardhat-zksync-solc`: