> For the complete documentation index, see [llms.txt](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zokyo-auditing-tutorials.gitbook.io/zokyo-tutorials/tutorial-30-inconsistent-block-lengths-across-chains.md).

# Tutorial 30: Inconsistent block lengths across chains

{% hint style="info" %}
[**Book an audit with Zokyo**](https://www.zokyo.io/)
{% endhint %}

#### Introduction to Block Number and Block Timestamp

In blockchain systems, two important metrics are frequently used to measure the passage of time and the progression of transactions: `block.number` and `block.timestamp`.

* **`block.number`** refers to the current number of blocks mined since the creation of the blockchain, essentially marking the block's sequential position. It provides a measure of the network's progression by counting how many blocks have been added since the genesis block.
* **`block.timestamp`** is a Unix timestamp that indicates when a specific block was mined. It gives the real-world time, in seconds, at which the block was created.

For Ethereum, it is generally assumed that a new block is produced roughly every **12 seconds**, a metric often used in smart contract development. However, this block time can vary, and making incorrect assumptions about it can result in serious vulnerabilities. Furthermore, the use of `block.number` and `block.timestamp` can vary across different EVM-compatible chains, making hardcoding block assumptions even more dangerous in multi-chain deployments.