zkevm-docs/7-copy.markdown

 ## 简介
-Copy类操作指的是在EVM中进行不定长的一段数据数据拷贝，例如CALLDATACOPY是一种将calldata中一段数据拷贝到memory中的操作。拷贝以byte作为数据长度单位，注意和栈的U256不同。
+copy类操作指的是在EVM中进行不定长的一段数据拷贝，例如`CALLDATACOPY`将`calldata`中的一段数据拷贝到`memory`中。拷贝以`byte`作为数据长度单位，不同于栈的`U256`。
 
-由于其长度的不定性，即无法在编写电路时就获知数据拷贝的长度，我们难以在不引入新子电路、子表格的情况下处理此类操作。
+由于拷贝的长度不定，即无法在编写电路时预先确定数据拷贝的长度，因此难以在不引入新子电路和子表格的情况下处理此类操作。
 
-我们的做法是，定义了copy子电路，对于Copy类操作，假设其长度为`len`，在此子电路中，使用`len`行来处理。每一行都要加上相应的约束来证明是从来源拷贝到去向。对于每次操作，生成的Witness就会包含`len`行的copy子电路的Row。
+为了解决这个问题，我们定义了一个`copy`子电路。对于Copy类操作，假设其长度为`len`，在此子电路中，使用`len`行来处理。每一行都加上相应的约束来证明是从来源拷贝到去向的。对于每次操作，生成的Witness会包含`len`行的`copy`子电路的Row。
 
-具体的，如下操作是Copy类操作：
+具体来说，以下操作属于Copy类操作：
 
-- CODECOPY
-- CALLDATACOPY
-- RETURN
-- RETURNDATACOPY
-- LOG
-- 调用开始（开始处理一笔交易或者CALL）时，CALLDATA要被写入STATE子电路所维持的状态中。分为两种：
-  - CALLDATA_FROMPUBLIC： 外界（交易、公开数据）的CALLDATA输入
-  - CALLDATA_FROMCALL： 合约调用另一个合约的CALLDATA输入
+- `CODECOPY`
+- `CALLDATACOPY`
+- `RETURN`
+- `RETURNDATACOPY`
+- `LOG`
+- 调用开始时，`CALLDATA`要被写入`STATE`子电路所维持的状态中。这分为两种情况：
+  - `CALLDATA_FROMPUBLIC`：外界（交易、公开数据）的`CALLDATA`输入
+  - `CALLDATA_FROMCALL`：合约调用另一个合约的`CALLDATA`输入
 
-如下图，数据的位置可能是：state子电路中的memory、calldata、returndata，bytecode子电路中的bytecode，public子电路中的calldata和log。
+下图展示了数据的位置可能是：`state`子电路中的`memory`、`calldata`、`returndata`，`bytecode`子电路中的`bytecode`，`public`子电路中的`calldata`和`log`。
 
 ![Figure 1](/image/copy-location.jpg)
 
-- CODECOPY, EXTCODECOPY：从bytecode到memory
-- CALLDATACOPY：从calldata（state中的）到memory
-- RETURN：从memory到returndata
-- RETURNDATACOPY：从returndata到memory
-- LOG：从memory到log
-- 调用开始（开始处理一笔交易或者CALL）时，CALLDATA要被写入STATE子电路所维持的状态中。分为两种：
-- CALLDATA_FROMPUBLIC： 从public的CALLDATA到state中的calldata
-- CALLDATA_FROMCALL： 从memory到state中的calldata
+- `CODECOPY`, `EXTCODECOPY`：从`bytecode`到`memory`
+- `CALLDATACOPY`：从`calldata`（state中的）到`memory`
+- `RETURN`：从`memory`到`returndata`
+- `RETURNDATACOPY`：从`returndata`到`memory`
+- `LOG`：从`memory`到`log`
+- 调用开始时，`CALLDATA`要被写入`STATE`子电路所维持的状态中。分为两种情况：
+  - `CALLDATA_FROMPUBLIC`：从`public`的`CALLDATA`到`state`中的`calldata`
+  - `CALLDATA_FROMCALL`：从`memory`到`state`中的`calldata`
 
 ## 设计
 
 ### Witness、Column设计
 
-~~共使用11列，参见代码。~~
-
-更新：共使用12列，参见代码。
+共使用12列，参见代码。
 
 ```rust
 pub struct Row {
@@ -109,64 +107,81 @@ pub enum Type {
 
 ### 门约束
 
-- 若 len-cnt-1==0 OR len==0: next cnt=0
-- 否则: next cnt=cnt+1; next src type, dst type, src xx, dst xx, len... same as cur
-- 若 len==0: 说明此行是pad行，则cur的 src type, dst type, src xx, dst xx, len 全部是nil或者默认值
-- 若 src type = Zero: 本行的src id pointer stamp byte 全为0。dst type若是Zero，dst xx同理。
-- 若 src type = Null: 本行的src id pointer stamp 全为0，byte不做约束。dst type若是Null，dst xx同理。
-- 对acc，若cnt=0， acc = byte 。
-- 对acc，若cnt!=0， acc = byte + acc_prev * 256 。acc_prev是上一行的acc值。注意，此加法是有限域的加法，因此可能会得到超出有限域的结果而取模。
+门约束是指对每一行的数据进行检查和约束，以确保数据的正确性和一致性。
+
+1. **长度约束**：
+   - 若 `len - cnt - 1 == 0` 或 `len == 0`：表示这一行是最后一行或没有数据（`len == 0`表示是填充行），因此下一行的 `cnt` 应为 `0`。
+   - 否则：`next_cnt = cnt + 1`，并且下一行的 `src_type`，`dst_type`，`src_xx`，`dst_xx`，`len` 等都和当前行相同。
+2. **填充行约束**：
+   - 若 `len == 0`：表示此行是填充行，此时 `src_type`，`dst_type`，`src_xx`，`dst_xx`，`len` 等全部是 `nil` 或者默认值。
+3. **类型约束**：
+   - 若 `src_type = Zero`：表示此行的 `src_id`，`pointer`，`stamp`，`byte` 全为0。同理，若 `dst_type` 是 `Zero`，`dst_xx` 也应全为0。
+   - 若 `src_type = Null`：表示此行的 `src_id`，`pointer`，`stamp` 全为0，但 `byte` 不做约束。同理，若 `dst_type` 是 `Null`，`dst_xx` 也应全为0。
+4. **累积值约束（acc）**：
+   - 若 `cnt = 0`，`acc = byte`。
+   - 若 `cnt != 0`，`acc = byte + acc_prev * 256`，其中 `acc_prev` 是上一行的 `acc` 值。注意此加法是有限域的加法，因此可能会得到超出有限域的结果而取模。
 
 ### Lookup
 
+Lookup的目的是确保每一行的数据拷贝操作是正确的。具体来说，每一行的数据都要进行两个查找：Lookup1和Lookup2。
+
 首先，byte这一列要使用lookup进行范围证明（小于256的范围）。
 
-然后，每一行，都要进行两个约束，向Copy的来源和Copy的去向进行查找表。查找表的来源都是此子表格的一行（的某些列），去向是“Copy的来源或Copy的去向”。我们称为Lookup1和Lookup2。
+#### Lookup1：来源验证
+
+Lookup1是为了验证数据的来源是否正确，去向为bytecode的查找表，含义是确定拷贝的数据没错。具体情况视 `src_type` 而定：
+
+1. Zero、Null：不进行lookup。
+2. Memory、Calldata、Returndata：
+   - 来源是此子表格的（`tag=常数Memory/Calldata/Returndata`, `src_id`, `src_pointer + cnt`, `src_stamp + cnt`, `byte`, `is_write=常数0`）。
+   - 去向是state table的（`tag`, `call_id`, `pointer_lo`, `stamp`, `value_lo`, `is_write`），即 `LookupEntry::State`。
+3. Bytecode：
+   - 来源是此子表格的（`src_pointer + cnt`, `src_id`, `byte`）。
+   - 去向是bytecode table的（`pc`, `addr`, `bytecode`），即 `LookupEntry::Bytecode`（并非 `BytecodeFull`）。
+4. PublicCalldata：
+   - 来源是此子表格的（`tag=常数Calldata`, `src_id`, `src_pointer + cnt`, `byte`）。
+   - 去向是public table的（`tag`, `tx_idx`, `idx`, `value`），即 `LookupEntry::Public`。注意此tag是Public的Tag。
 
-以上面为例，每一行，要进行：
-- Lookup1：去向为bytecode的查找表，含义是确定拷贝的数据没错
-- Lookup2：去向为state（具体tag为memory）的查找表，含义是确定拷贝的数据确实写进去了
+#### Lookup2：去向验证
 
-具体的，Lookup1的情况视src type而定：
-- Zero、Null：不进行lookup
-- Memory、Calldata、Returndata：来源是此子表格的（tag=常数Memory/Calldata/Returndata, src id, src pointer + cnt, src stamp + cnt, byte, is_write=常数0），去向是state table的（tag, call_id, pointer_lo, stamp, value_lo, is_write），即`LookupEntry::State`
-- Bytecode：来源是此子表格的（src pointer + cnt, src_id, byte），去向是bytecode table的（pc, addr, bytecode），即`LookupEntry::Bytecode`（并非BytecodeFull）
-- PublicCalldata：来源是此子表格的（tag=常数Calldata, src id, src pointer + cnt, byte），去向是public table的（tag, tx_idx, idx, value），即`LookupEntry::Public`。注意此tag是Public的Tag。（Public代码还未完善）
+Lookup2是为了验证数据的去向是否正确，去向为state（具体tag为memory）的查找表，含义是确定拷贝的数据确实写进去了。具体情况视 `dst_type` 而定：
 
-Lookup2的情况视dst type而定：
-- Zero、Null：不进行lookup
-- Memory、Calldata、Returndata：类似Lookup1，把is_write=常数1
-- PublicLog：来源是此子表格的（tag=常数tx_log, log_tag=常数bytes, dst id, src pointer + cnt, dst stamp (不加cnt), byte, len），去向是public table的（tag, log_tag, tx_idx, idx, log_id, value, len），即`LookupEntry::Public`。注意此tag是Public的Tag。（Public代码还未完善）
+1. Zero、Null：不进行lookup。
+2. Memory、Calldata、Returndata：
+   - 类似Lookup1，但 `is_write=常数1`。
+3. PublicLog：
+   - 来源是此子表格的（`tag=常数tx_log`, `log_tag=常数bytes`, `dst_id`, `src_pointer + cnt`, `dst_stamp` (不加cnt), `byte`, `len`）。
+   - 去向是public table的（`tag`, `log_tag`, `tx_idx`, `idx`, `log_id`, `value`, `len`），即 `LookupEntry::Public`。
 
 ## Core中的用法
-Core子电路的执行状态中，遇到和copy相关的状态，做法如下。
+在Core子电路的执行状态中，遇到与`copy`相关的状态时，处理方式如下：
 
 ### CODECOPY, EXTCODECOPY
 
-此指令遇到位数不足时，会填充0。因此，在得到 offset length dst_offset （这三个数从栈获得）后，通过Arithmetic子电路的Normallength来判断是否需要填充，向Normallength传入三个值：length,offset,data_size，会得到两个length：normal_length, zero_length(即padding的length)，通过lookup来约束normal_length和zero_length。
+对于这两条指令，当数据不足时会填充0。因此，在从栈中获取 `offset`, `length`, `dst_offset` 这三个值后，通过`Arithmetic`子电路的`Normallength`来判断是否需要填充。向`Normallength`传入 `length`, `offset`, `data_size`，会得到两个长度：`normal_length` 和 `zero_length`（即填充的长度）。然后，通过`lookup`来约束`normal_length`和`zero_length`。
 
-从core进行两个copy的lookup。一个的src type是bytecode，另一个的src type是zero。这两个copy的lookup的排布，可以在cnt=2行的前9个格子和次9个格子。对于每个copy的lookup，用门约束约束其各个位置的值，然后用lookup约束从core向copy去查找表即可。
+从`core`进行两个`copy`的`lookup`。一个的`src type`是`bytecode`，另一个的`src type`是`zero`。这两个`copy`的`lookup`可以安排在`cnt=2`行的前9个格子和次9个格子。对于每个`copy`的`lookup`，用门约束其各个位置的值，然后用`lookup`约束从`core`向`copy`去查找表即可。
 
 ### CALLDATACOPY
 
-此指令遇到位数不足时，会填充0。不过，在读取CALLDATA时，我们可以让CALLDATA的默认值为0（类似MEMORY的设计）。因此，不需要像CODECOPY一样弄。此指令只需一个copy的lookup，可以在cnt=2行的前9个格子。
+对于这条指令，当数据不足时会填充0。不过，在读取`CALLDATA`时，我们可以让`CALLDATA`的默认值为0（类似`MEMORY`的设计）。因此，不需要像`CODECOPY`一样处理。此指令只需一个`copy`的`lookup`，可以安排在`cnt=2`行的前9个格子。
 
 ### RETURN
 
-此指令遇到位数不足时，会填充0。不过，在读取MEMORY时，默认值为0。因此，不需要像CODECOPY一样弄。此指令只需一个copy的lookup。
+对于这条指令，当数据不足时会填充0。不过，在读取`MEMORY`时，默认值为0。因此，不需要像`CODECOPY`一样处理。此指令只需一个`copy`的`lookup`。
 
 ### RETURNDATACOPY
 
-此指令遇到位数不足时，会报错。因此，此指令只需一个copy的lookup。
+对于这条指令，当数据不足时会报错。因此，此指令只需一个`copy`的`lookup`。
 
 ### MLOAD
 
-此操作相当于进行了长度为32的copy，src type是memory，dst type没有，因此采用Null。注意，MLOAD往栈里写入，但是不是通过copy的形式，而是将32个byte组合成U256然后写入，因此copy子电路不处理栈的写入。acc列起到了将32个byte组合的作用。实现中，我们进行两个长度为16的copy，用acc来获得每个16-byte的U128，在cnt处使用值为16-1=15的查找表操作，用以获得最后的acc值。两个copy lookup的值记为value_hi, value_lo。于是，copy的lookup中也需要加入此acc列。在core里，通过copy的lookup获得value_hi, value_lo后，使用state的lookup写入栈。
+此操作相当于进行了长度为32的`copy`，`src type`是`memory`，`dst type`没有，因此采用`Null`。注意，`MLOAD`往栈里写入数据，但不是通过`copy`的形式，而是将32个`byte`组合成`U256`然后写入，因此`copy`子电路不处理栈的写入。`acc`列起到了将32个`byte`组合的作用。实现中，我们进行两个长度为16的`copy`，用`acc`来获得每个16`byte`的`U128`，在`cnt`处使用值为`16-1=15`的查找表操作，用以获得最后的`acc`值。两个`copy lookup`的值记为`value_hi`和`value_lo`。因此，`copy`的`lookup`中也需要加入此`acc`列。在`core`里，通过`copy`的`lookup`获得`value_hi`和`value_lo`后，使用`state`的`lookup`写入栈。
 
 ### MSTORE
 
-此操作类似MLOAD，相当于进行了长度为32的copy，src type采用Null，dst type是memory。我们进行两个长度为16的copy，用acc来获得每个16-byte的U128，记为value_hi, value_lo。在core里，使用state的lookup读取栈，栈的value的高位和地位要约束等于copy的acc（即value_hi, value_lo）。
+此操作类似`MLOAD`，相当于进行了长度为32的`copy`，`src type`采用`Null`，`dst type`是`memory`。我们进行两个长度为16的`copy`，用`acc`来获得每个16`byte`的`U128`，记为`value_hi`和`value_lo`。在`core`里，使用`state`的`lookup`读取栈，栈的`value`的高位和低位要约束等于`copy`的`acc`（即`value_hi`和`value_lo`）。
 
 ### CALLDATALOAD
 
-此操作与CALLDATACOPY不同，反而与MLOAD类似。相当于进行了长度为32的copy，src type是calldata，ds t type没有，因此采用Null。我们进行两个长度为16的copy，获得value_hi, value_lo，然后使用state的lookup写入栈。
\ No newline at end of file
+此操作与`CALLDATACOPY`不同，反而与`MLOAD`类似。相当于进行了长度为32的`copy`，`src type`是`calldata`，`dst type`没有，因此采用`Null`。我们进行两个长度为16的`copy`，获得`value_hi`和`value_lo`，然后使用`state`的`lookup`写入栈。
\ No newline at end of file