ZK-COUNTERS TABLE

Dynamic zk-counters

In the following doc, we calculate the cost of processing the opcode. It's important to also add the cost of calculating the cost

EXP

Inputs:
1- a: integer base.
2- exponent: integer exponent.

dynamic_gas = 50 * exponent_byte_size
We need to calculate the exponent byte size to get the gas cost. The counters cost is dynamic but we can't calculate the cost without consuming counters in a dynamic way. We need to find a way to get the size of the exponent in a constant manner or handle the counters limitations from the zkasm.
Maximum setted: Maxmimun byte syze = 256 bytes. Max counters = 256 * (2A + 4B) + 1B = 512A + 1025B

SHA3

L = input length
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0

cnt_arith = 2 + B6
cnt_binary = 2 + A + B9
cnt_keccak = 1

CALLDATALOAD

L = byte offset in the calldata.
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0

counters = divARITH + B*(SHLarith + SHRarith)

CALLDATACOPY

L = Length to copy.
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0

counters = A(divARITH + SHLarith + SHRarith + MSTORE32) + SHLarith2 + SHRarith + MSTOREX

CODESIZE

counters = SLOAD

CODECOPY

L = bytes to copy.
if is createContract -> counters = CALLDATACOPY
else -> counters = LT + L*(LT + MEM_ALIGN_WR8)

EXTCODESIZE

counters = SLOAD

EXTCODECOPY

L = bytes to copy.
if is createContract -> counters = CALLDATACOPY
else -> counters = LT + L*(LT + MEM_ALIGN_WR8)

RETURNDATACOPY

L = Length to copy.
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0
counters = 2EQ + LT + divARITH + mulARITH + A(MLOAD32 + MSTORE32) + B*(MLOADX + MSTOREX)

EXTCODEHASH

counters = SLOAD

SELFBALANCE

counters = SLOAD

MLOAD

counters = MLOAD32

MSTORE

counters = MSTORE32

SLOAD

counters = SLOAD

SSTORE

Cant calculate

JUMPI

isCreateContract ? true -> A = 1, false -> A = 0
isCreate ? true -> B = 1, false -> B = 0

counters = EQ + A(B(MLOADX + SHRarith) + (1-B)(EQ)) + (1-A)(EQ)

JUMP

isCreateContract ? true -> A = 1, false -> A = 0
isCreate ? true -> B = 1, false -> B = 0

counters = EQ + A(B(MLOADX + SHRarith) + (1-B)(EQ)) + (1-A)(EQ)

LOG

L = byte size to copy.
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0
counters = AMLOAD32 + BMLOADX

CREATE

counters = computeGasSendCall + copySP + SLOAD + SSTORE + getLenBytes

CALL

argsLengthCall + retLength == 0 ? true -> A = 1, false -> A = 0
argsOffsetCall > memLength ? true -> B = 1, false -> B = 0
counters = addARITH + EQ + (1-A)(LT +BsaveMem ) + LT + isEmptyAccount + computeGasSendCall + copySP

CALLCODE

counters = 2EQ + LT2 + computeGasSendCall + copySP

DELEGATECALL

counters = 2EQ + LT2 + computeGasSendCall + copySP

CREATE2

counters = computeGasSendCall + copySP + SLOAD + SSTORE + getLenBytes

STATICCALL

counters = 2EQ + LT2 + computeGasSendCall + copySP

REGS TABLE

Dynamic regs

SSTORE

SLOAD

Should check how SLOAD is implemented

Functions TABLE

Dynamic functions

copySP

It depends on the stack size.
L = stack length
L/32 = A
L % 32 > 0 ? true -> B = 1, false -> B = 0
counters = MLOAD32 * (A + B)

MLOAD32

MSTORE32

MSTOREX

MLOADX

L = bytes length
L > 0 ? true -> A = 1, false -> A = 0
isMSTOREX ? true -> B = 1, false -> B = 0
counters = LT + B(2SHRarith + 2SHLarith) + (1-B)(C(2SHLarith + 4SHRarith) + (1-C)(2SHRarith + 2SHLarith) + MEM_ALIGN_WR)
MAX:
counters = 192A + 193B + 2MA

SHRarith

SHLarith

A -> bytes to shift
D -> times to shift (A << D)
E -> D > 256? true = 1, false = 0
counters= ARITH + EQ + (1-E) (D(LT + ARITH)) = 1A + 1B + (1-E)(D(1A + 1B)
MAX:
counters = 32A + 32B

isEmptyAccount

isNotPrecompiled ? true -> A = 1, false -> A = 0
zeroBalance ? true -> B = 1, false -> B = 0
zeroNonce ? true -> C = 1, false -> C = 0

counters = LT + A(SLOAD + LT + B(SLOAD + LT + C*(SLOAD + LT)))

https://github.com/0xPolygonHermez/zkevm-rom/blob/main/docs/opcode-cost-zk-counters.md

区块会经过两个步骤
eth_blockNumber->zkevm_isBlockVirtualized->zkevm_isBlockConsolidated

zkevm_isBlockVirtualized 到达该阶段说明数据已提交到L1层，当到达后，出现不一致概率极低，比如版本升级异常等，才会出现数据不一致
zkevm_isBlockConsolidated zkp 证明已生成，不会再发生数据不一致

每个阶段具体时间隔间，要看具体节点配置，比如当前测试环境
zkevm_isBlockVirtualized：15s
zkevm_isBlockConsolidated：10-20分 （算力充足情况下）

查询RPC
https://www.quicknode.com/docs/polygon-zkevm/zkevm_isBlockVirtualized
https://www.quicknode.com/docs/polygon-zkevm/zkevm_isBlockConsolidated

跨链交易发起：0x0bbbcf153f17ec0e1f12d698bbc64f9d242bc1cd1312dd5f34febf0e6cb6601a

1. 根据tx_hash查看表l2_to_l1_logs，得到所在的miniblock_number为15841
2. 根据上面的miniblock_number，根据number查看表miniblocks

   select * from miniblocks where number=15841;

3. 得到当前跨链交易所在l1_batch_number为7670
4. 根据l1_batch_number，以number查看l1_batches表

   select number,is_finished,eth_commit_tx_id,eth_prove_tx_id,eth_execute_tx_id from l1_batches where number=7670;

   得到

   number | is_finished | eth_commit_tx_id | eth_prove_tx_id | eth_execute_tx_id 
   --------+-------------+------------------+-----------------+-------------------
   7670 | t           |            41073 |           41148 |             41151

5. 根据eth_commit_tx_id查询eth_txs，得到CommitBlocks对应交易信息

   select nonce,contract_address,tx_type,has_failed,sent_at_block,tx_status,confirmed_eth_tx_history_id from eth_txs where id=41073 ORDER BY updated_at DESC limit 1;

   nonce |              contract_address              |   tx_type    | has_failed | sent_at_block | tx_status | confirmed_eth_tx_history_id 
    -------+--------------------------------------------+--------------+------------+---------------+-----------+-----------------------------
     41091 | 0x5e3e5f6ef0e21f0cf5b4c3acd3cf29740b1cbbd8 | CommitBlocks | f          |               | Done      |                       43194

6. 根据confirmed_eth_tx_history_id得到CommitBlocks对应交易hash

   select eth_tx_id,tx_hash,confirmed_at from eth_txs_history where id=43194  ORDER BY updated_at DESC limit 10;

   eth_tx_id |                              tx_hash                               |        confirmed_at        
    -----------+--------------------------------------------------------------------+----------------------------
         41073 | 0x0b01e199877faef52b95477119f53bf546a2915bc903132331f41542e58da53d | 2023-09-18 03:50:19.059576

7. 同理查询eth_prove_tx_id和eth_execute_tx_id得到对应的交易hash

问题背景

从一些外部消息得知

9月12日消息，据zkSync Era区块链浏览器显示，zkSync Era主网疑似出现宕机情况，zkSync Era提交给以太坊的最新批次为#208455，时间为14:14，区块高度已暂停于#13641404，已暂停出块37分钟。

跟进缘由

由于现有部分项目基于zkSync Era，所以需要确认下问题起因是什么，是否存在官方新版修复，目前现有版本会不会同样存在问题

确认问题

先从浏览器数据，确认下，是否存在消息描述问题，以及分析下问题位置（区块浏览器/链节点）

确认下Batch高度时间

208455 与 208456 相差时间符合预期

确认下Block高度时间

确认下Batch Commit时间

分析结果

从节点Batch和Block生成时间，以及Batch Commit，对比消息中的#208455前后时间差，综合来看，链方面数据无宕机，
大概率是当时区块浏览器服务方面，或者连接的某些提供数据RPC节点，出现了区块同步不及时问题。

如何避免

浏览器和提供查询的RPC节点做多个主备灾备, 实时高度状态检查和线路自动切换

所在服务器安装对应的显卡驱动（一般都有了），需要使用对应的 cuda image与其对应

对外prover docker统一使用ubuntu 20.04

• base:从 CUDA 9.0 开始，包含部署预构建 CUDA 应用程序的最低限度（libcudart）。如果您想手动选择要安装的 CUDA 软件包，请使用此映像。
• runtime:通过添加 CUDA 工具包中的所有共享库来扩展基础映像。如果您有使用多个 CUDA 库的预构建应用程序，请使用此映像。
• devel:通过添加编译器工具链、调试工具、标头和静态库来扩展运行时映像。使用此映像从源代码编译 CUDA 应用程序

数据来源：https://hub.docker.com/r/nvidia/cuda/tags