#空区块
Era区块浏览器显示空区块。这不是区块浏览器的问题，而是设计使然。

尽管这可能是短期现实，但重要的是要考虑此设计背后的基本原理。
每个 L1 批处理（包含多个 L2 区块）都在单个 VM 实例中执行。VM一个接一个地执行事务，然后执行一些与最后一个事务无关与整个批处理无关的代码。目前，从手续费中收取的 ETH 是从 bootloader 正式地址转移到区块矿工地址。此传输发出一个事件（与任何其他传输一样），该事件包含在“空”L2 区块中，因此可以通过 API 访问它。

Era可以将它添加到L1批次的最新L2区块中，但想象一下以下场景：如果一个 L2 块被关闭，但它的 L1 批次没有关闭，并且该节点在一段时间内没有收到任何新交易，那么L1 批处理必须在超时前关闭。如果将事件添加到最近关闭的区块中，它将修改区块，从而导致某种重组。
为避免这种情况，Era构建了一个仅包含事件的纯虚构块。

#检索区块号和批号
在 zkSync API 中访问区块号与您在以太坊上的访问方式类似。例如，eth_blockNumber返回最新的 L2 区块的编号，并且eth_getBlockByNumber，给定一个区块号，返回有关请求的区块的信息。
对于 L1 批次，要检索最新的批次号，请使用 zkSync API 方法zks_L1BatchNumber。此外，通过查询一个区块，您可以看到包含该区块的批次的批号。在交易收据中，该字段l1BatchNumber是包含交易的批号。该字段l1BatchTxIndex返回一个批次中包含的所有交易中的交易位置。

#哈希值
zkSync 中的区块哈希值是确定性的，并且源自以下公式：“keccak256(l2_block_number)”。具有确定性区块哈希的原因是这些哈希不可证明（请记住，L2 块不会提交给 L1）。建议项目不要使用 L2 区块哈希作为随机源。

#区块号和时间戳注意事项
然而，使用任何 SDK 通过 API 检索的区块的编号和时间戳属性将引用 L2区块，并且block.number在block.timestampEVM 中（在智能合约上），分别返回 L1 批次的编号和时间戳。

#为什么我们从 API 返回 L2区块？
在 zkSync Era 上，我们从 API 返回 L2区块，因为这是所有平台（包括 SDK、Metamask 和所有其他流行的钱包）可以感知我们的交易已处理的方式。预计交易一旦包含在区块中就会被处理。这就是为什么我们需要比 L1 批次更快地生成 L2区块。

#为什么我们在 EVM 中返回 L1 批次？
目前，我们在 VM 中返回 L1 批次的编号和时间戳，因为与 L2 区块相关的值将无法证明。与包含对链状态的某种承诺的以太坊区块不同，在 zkSync Era 上，这些区块不会有这样的承诺，因为计算 Merkle 树的成本太高，每批次只能执行一次。
一种在 EVM 中检索 L2 块编号和时间戳的方法正在开发中。