zkevm-docs/6-bytecode.markdown

@@ -208,3 +208,53 @@ Lookup keccak table，<pc+1（即length）, rlc_acc, hash_hi, hash_lo> 去往Kec
 
 Lookup Public table，addr和hash新增的往public table的lookup。<tag=CodeHash, addr, hash_hi, hash_lo>。此lookup只在下一行的addr change==0时进行。
 
+
+
+## 2024-07-01更新
+
+### 需求
+
+bytecode可能存在一种情况，在bytecode末尾的PUSH可能存在push字节码不足的情况，如：
+
+```shell
+./evm --code 6f2f --json run
+{"pc":0,"op":111,"gas":"0x2540be400","gasCost":"0x3","memSize":0,"stack":[],"depth":1,"refund":0,"opName":"PUSH16"}
+{"pc":17,"op":0,"gas":"0x2540be3fd","gasCost":"0x0","memSize":0,"stack":["0x2f000000000000000000000000000000"],"depth":1,"refund":0,"opName":"STOP"}
+{"output":"","gasUsed":"0x3"}
+```
+
+如上`6f`是`PUSH16`但是PUSH指令后面不足16个byte，会将PUSH指令后面的值右边填充0，如上`0x2f000000000000000000000000000000`
+
+### 实际trace中遇到的原因
+
+原因是合约字节码后面都会有一段`metadata`，这段`metadata`描述了一些编译器相关的信息，并不再有效的(p c可以跳转到的)bytecode之内
+
+按照正常流程，pc跳转执行bytecode，并不会执行到这部分代码，但是zkevm在解析bytecode是从前向后按照顺序解析，就会出现将metadata的数据解析为无效OPCODE的情况
+
+查看议题：https://git.code.tencent.com/chainmaker-zk/zkevm/issues/72
+
+### 方案
+
+生成bytecode witness时，对bytecode进行处理，当PUSHX后面的字节数量不够X个，用`0` padding到X个，这些padding行使用` is_padding`进行标识，如果是padding行，则`is_padding`的值为1。并新增一个`length`，用来记录有效code的长度(除了padding行的有效行)，这种情况下的最后一个有效行就是`addr != 0 &&addr_nochange_next && is_padding == 0 && is_padding_next == 0 `
+
+但是有时并不会遇到`当PUSHX后面的字节数量不够X个`的情况，这种情况下的，最后一个有效行就是`addr != 0 && addr_change_next && is_padding ==0`
+
+因需要区分两种情况，为简化，所以不管会不会出现`PUSHX字节不够X`的情况都进行padding，总的padding数量32, 即`最终长度(带有padding的长度)-有效长度(无padding的长度) == 32`
+
+ keccak计算hash时不算这部分padding的值
+
+
+
+### 新加约束
+
+length:  `length_cur == length_prev`
+
+最后一个有效行：
+  `addr != 0 &&addr_nochange_next && is_padding==0 && is_padding_next == 1`---> `pc == length -1`
+  即 pc == length -1为最后一个有效行
+
+Padding:
+
+​    padding的位置如果是PUSH的byte，则按照PUSH的约束执行
+
+   如果padding的位置不是PUSH的byte，则除addr, pc, length外的所有值都为0