AppliedZKP提出的Zkevm方案采用了数据总线的思想。在正确存储数据的基础上，状态证明证明数据的一致性，EVM证明计算逻辑的正确性。
众所周知，ZK rollup是L2最高安全级别的rollup方案，但ZK rollup是不可编程的，更不用说可组合的了。Zkevm使用ZK snark技术来证明evm的实现。Zkrollup支持zkevm和与zkevm兼容的智能合约。目前有几个团队正在研究zkevm的实现。其他团队除了AppliedZKP透露了一些电路设计的思路和细节，没有详细的信息。Zkevm应用ZKP的设计数据如下:
本文详细分析了基于zkp概念的zkevm的设计。本文提到的zkevm是指AppliedZKP提出的zkevm方案。
背景
为了保证事务的正确性，以太坊的每个节点都需要执行每个块中的每个事务。换句话说，每个节点都需要验证以太坊的整个交易历史，并逐一进行验证。Zkevm使用零知识证明技术(ZKSnark)来证明:
为智能合约的交易执行生成交易证书。zkrollup在L2的实现支持可编程性。
为以太坊的每个区块生成一个区块证书。
这些证明由两部分组成:州证明和EVM证明。在事务执行期间，状态包括存储器、内存和堆栈的状态。
总线映射是设计的基本思想。在一般的PC架构中，CPU通过总线访问内存(内存/硬盘)，即计算和存储分离。Zkevm采用了同样的架构思想。状态的改变与指令的执行相分离，分别用状态证明和EVM证明来证明。
状态证明负责总线映射信息的一致性和正确性。一致性是指总线映射和状态之间读写的一致性。正确性意味着总线图中的读/写状态是正确的。EVM证明正确的EVM操作代码(如果涉及状态操作代码，请确保与存储相关的操作是正确的)。
EVM执行与存储之间似乎有一条用于存储访问的总线:EVM执行通过总线映射获取或存储执行所需的相关状态。对于总线映射，需要证明总线映射、状态和EVM执行之间“总线”操作的正确性。从逻辑上讲，分为以下几个步骤:读状态、EVM执行(修改状态)、写回状态。总线图包括读和写状态。
总线映射
总线映射包括两种状态:一种是读取旧状态，另一种是写回生成新状态。无论旧状态还是新状态，总线映射都是一种“包含”关系。“包含”的映射关系可以用plookup算法证明。
存储状态(存储/内存/堆栈)用键值格式表示，键值对的绑定关系可以实现为一个序列:
def build _ mapping():keys = values = randomness = hash(keys，values) mappings = [] for key，Value in zip (keys，values): mappings。append(key+randomness * value)Return(mappings)为了证明键值对，可以在一些键值中使用三种plookup证明:
def build _ mapping():keys = values = randomness = hash(keys，values) mappings =有两种相关的操作码:内存读取和内存写入。例如，sload从内存读取数据到堆栈。与存储相关的操作码对应的读写数据在总线图中。注意，状态证书中的存储证书只是证明存储相关的读写操作是否在总线图中。读写数据的语义信息用EVM证明来证明。
记忆
从状态证明的角度来看，所有的内存操作都是按索引排序的。索引是一个内存地址。例如:
2,4 Address 0和Address 1的相关内存操作一起列出。在程序开始执行时，每个内存地址都被初始化为0。也就是说，当计数器为零时，索引0/1最初为0。从总线映射的角度来看，这些内存操作如下:
] for key , value in zip(keys,values): mappings.append(key + randomness*value) return(mappings)
为了证明键值对，可以在某些键值中使用三种plookup证明：
def build_mapping(): keys = [1,3每个地址的读写数据应该一致。这些一致性通过以下约束条件进行检查:2,4蓝色部分限制内存只能读写操作，棕色部分限制每个地址的初始内存为零，读写数据一致，橙色部分限制总线图中的相关内存操作。
堆
堆栈操作主要分为三类:推送/弹出、DUP和交换。使用1024大小的数组来模拟堆栈实现。EVM验证检查堆栈的位置信息。栈数据和总线映射的关系是通过栈验证来完成的。基本思路和记忆一致。
EVM证明
EVM证明是EVM实现相关约束的核心。EVM证明需要证明以下逻辑:
EVM执行的代码是指定事务的代码逻辑和存储相关的语义是否正确，比如栈位置管理，sload数据和栈数据是否一致以及计算相关的语义是否正确，比如算术计算等跳转逻辑是否正确，调用计算耗气量的正确程序是否正确。插槽是电路的基本单元，多个插槽可以组合实现一个操作码的语义。
算术计算
以加法为例，8位整数的计算可以用plookup证明。通过多次进行8位加法，可以实现任意长度的加法。
] for key , value in zip(keys,values): mappings.append(key + randomness*value) return(mappings)
键和值是与状态相关的键值对，Mappings是所有键值对的映射数组，由三个plookups证明：
映射键位于键中映射的值以值为单位映射在映射中并且映射和键值满足build_uuu映射的要求，映射建立了一种关系，上述证明可以证明键值对是键值映射的一部分。
基于以上，可以定义总线映射数据结构：
bus_mapping[global_counter] = { mem: [op, key, value], stack: [op, index, value], storage: [op, key, value], index: opcode, call_id: call_id, prog_counter: prog_counter }其中，global_uuucounter是插槽数。插槽是验证逻辑的最小单元。事务的验证由多条指令组成，每条指令可能由多个插槽组成。OP是一种逻辑上由读和写组成的操作类。prog_uuucounter是一台PC。映射中的所有总线读取操作都可以检测通过plookup判断是否属于当前状态，读取状态需要与旧存储状态一致，写入状态需要与更新后的存储状态一致。
在总线映射的基础上，使用状态证明和EVM证明来证明数据的读写正确，并且与操作码的语义一致。
State Proof
状态证明证明与“存储”相关的读/写与总线映射数据一致。即“总线”上读写数据的一致性。根据存储类，状态证明分为三种。
Storage
与存储相关的操作代码如下所示：
/image-2/[
比较两个数的原理类似加法。
跳转逻辑
Call_uid记录执行环境。对于绑定和跳转逻辑的关系，call_uid采用以下计算逻辑:
Call _ id-> RLC (call data _ callid，call data _ start _ addr，call data _ size，return data _ callid，return data _ start _ addr，return data _ size，origin，caller，call _ value，call _ stack _ depth)。
EVM证明的逻辑相对复杂。描述设计的细节在当前发布的文档中没有展开。Zkevm给出了整体设计思路，细节需要进一步细化。
总结:
AppliedZKP揭示了zkevm的设计思路。Zkevm采用总线映射的思想，将存储和计算分开。在通过总线映射提取正确存储数据的基础上，状态证明证明数据的一致性，EVM证明计算逻辑的正确性。
温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信(j7hr0a@163.com)，我们会及时处理和回复。
原文地址"详细分析了AppliedZKP构思的ZkEVM设计"：http://www.guoyinggangguan.com/qkl/185806.html。
微信扫描二维码关注官方微信
▲长按图片识别二维码
