零知识证明 - zkEVM源代码分析(EVM Circuit)

这篇文章将详细讲解EVM Circuit各个Column的设计,每种Opcode如何约束以及多个Opcode之间是如何约束以及组合。

zkEVM是零知识证明相对复杂的零知识证明应用,源代码值得反复阅读和学习。

https://github.com/appliedzkp/zkevm-circuits.git

本文中采用的源代码对应的最后一个提交信息如下:

commit 1ec38f207f150733a90081d3825b4de9c3a0a724 (HEAD -> main)
Author: z2trillion <z2trillion@users.noreply.github.com>
Date:   Thu Mar 24 15:42:09 2022 -0400

zkEVM的电路主要由两部分电路组成:EVM Circuit和State Circuit。本文先讲解EVM Circuit的电路相关的源代码。其他部分在后续的文章中介绍。这篇文章将详细讲解EVM Circuit各个Column的设计,每种Opcode如何约束以及多个Opcode之间是如何约束以及组合。

整体电路结构

EVM Circuit的整体的电路结构如下图所示:

1.png

从Column的角度来看,EVM Circuit分为三部分:1/ Step选择子(包括当前Step,第一个Step,最后一个Step等等)2/ Step电路 3/ Fixed Table(固定的查找表)。Step电路逻辑是核心部分。所谓的Step是指从电路约束角度的执行的一步。这一部分又分为两部分:a/ execution state (Step状态选择子) b/ 各种执行状态的约束逻辑。图中用虚线画出了大体的约束逻辑模块。

理解EVM Circuit从Configure和Assign入手。

EVM Circuit Configure

EVM Circuit电路实现在zkevm-circuits/src/evm_circuit.rs。从它的configure函数看起:

pub fn configure<TxTable, RwTable, BytecodeTable, BlockTable>(
  meta: &mut ConstraintSystem<F>,
  power_of_randomness: [Expression<F>; 31],
  tx_table: TxTable,
  rw_table: RwTable,
  bytecode_table: BytecodeTable,
  block_table: BlockTable,
) -> Self
where
  TxTable: LookupTable<F, 4>,
  RwTable: LookupTable<F, 11>,
  BytecodeTable: LookupTable<F, 4>,
  BlockTable: LookupTable<F, 3>,

EVM Circuit的电路约束由两部分组成:1/ fixed_table 2/ Execution 部分。fixed_table是一些固定的表信息,占用4个column,分别对应tag/value1/value2/结果。

2.png

tag的种类为10种,定义在zkevm-circuits/src/evm_circuit/table.rs:

pub enum FixedTableTag {
  Range5 = 1,
  Range16,
  Range32,
  Range256,
  Range512,
  SignByte,
  BitwiseAnd,
  BitwiseOr,
  BitwiseXor,
  ResponsibleOpcode,
}

接着查看Execution的部分。ExecutionConfig的configure函数定义了电路的其他约束:

pub(crate) fn configure<TxTable, RwTable, BytecodeTable, BlockTable>(
  meta: &mut ConstraintSystem<F>,
  power_of_randomness: [Expression<F>; 31],
  fixed_table: [Column<Fixed>; 4],
  tx_table: TxTable,
  rw_table: RwTable,
  bytecode_table: BytecodeTable,
  block_table: BlockTable,
 ) -> Self
 where
    TxTable: LookupTable<F, 4>,
    RwTable: LookupTable<F, 11>,
    BytecodeTable: LookupTable<F, 4>,
    BlockTable: LookupTable<F, 3>,
 {

q_step - Step的选择子(selector)

q_step_first - 第一个Step的选择子

q_step_last - 最后一个Step的选择子

qs_byte_lookup - byte范围检查的选择子

对于一个Step,采用32个Column的数据进行约束。

   let q_step = meta.complex_selector();
   let q_step_first = meta.complex_selector();
   let q_step_last = meta.complex_selector();
   let qs_byte_lookup = meta.advice_column();
   let advices = [(); STEP_WIDTH].map(|_| meta.advice_column());

什么是Step?

从功能角度看,Step是“一步”执行。从电路角度看,Step是一个由32列16行的电路构成。Step的参数信息定义在zkevm-circuits/src/evm_circuit/param.rs:

const STEP_WIDTH: usize = 32;
const STEP_HEIGHT: usize = 16;

Step定义在zkevm-circuits/src/evm_circuit/step.rs中:

pub(crate) struct Step<F> {
  pub(crate) state: StepState<F>,
  pub(crate) rows: Vec<StepRow<F>>,
}

Step由StepState和16个StepRow组成。先说StepRow,Step Row包含了一个Step中某个Row涉及的所有信息:

pub(crate) struct StepRow<F> {
  pub(crate) qs_byte_lookup: Cell<F>,
  pub(crate) cells: [Cell<F>; STEP_WIDTH],
}

对于一个Step中的某个Row来说,除了cell的数据外(cells),还有该Row对应的qs_byte_lookup,是否该Row的Cell中的数据被Range256进行约束(qs_byte_lookup后续会详细讲解)。

StepState数据结构包括了一个Step对应的状态信息:

pub(crate) struct StepState<F> {
  /// The execution state for the step
  pub(crate) execution_state: Vec<Cell<F>>,
  /// The Read/Write counter
  pub(crate) rw_counter: Cell<F>,
  /// The unique identifier of call in the whole proof, using the
  /// `rw_counter` at the call step.
  pub(crate) call_id: Cell<F>,
  /// Whether the call is root call
  pub(crate) is_root: Cell<F>,
  /// Whether the call is a create call
  pub(crate) is_create: Cell<F>,
  // This is the identifier of current executed bytecode, which is used to
  // lookup current executed code and used to do code copy. In most time,
  // it would be bytecode_hash, but when it comes to root creation call, the
  // executed bytecode is actually from transaction calldata, so it might be
  // tx_id if we decide to lookup different table.
  // However, how to handle root creation call is yet to be determined, see
  // issue https://github.com/appliedzkp/zkevm-specs/issues/73 for more
  // discussion.
  pub(crate) code_source: Cell<F>,
  /// The program counter
  pub(crate) program_counter: Cell<F>,
  /// The stack pointer
  pub(crate) stack_pointer: Cell<F>,
  /// The amount of gas left
  pub(crate) gas_left: Cell<F>,
  /// Memory size in words (32 bytes)
  pub(crate) memory_word_size: Cell<F>,
  /// The counter for state writes
  pub(crate) state_write_counter: Cell<F>,
}

先详细介绍一下StepState的各个变量的含义。

  • execution_state - 表明当前Step的执行状态。一个Step的执行状态定义在step.rs中:
pub enum ExecutionState {
  // Internal state
  BeginTx,
  EndTx,
  EndBlock,
  CopyToMemory,
  // Opcode successful cases
  STOP,
  ADD, // ADD, SUB
  ...
  // Error cases
  ErrorInvalidOpcode,
  ErrorStackOverflow,
  ErrorStackUnderflow,
  ...
}

一个Step的执行状态,包括了内部的状态(一个区块中的交易,通过BeginTx, EndTx隔离),Opcode的成功执行状态以及错误状态。有关Opcode的成功执行状态,表示的是一个约束能表示的情况下的执行状态。也就是说,多个Opcode,如果是采用的同一个约束,可以用一个执行状态表示。举个例子,ADD/SUB Opcode采用的是一个约束,对于这两个Opcode,可以采用同一个执行状态进行约束。

  • rw_counter - Stack/Memory访问时采用rw_counter区分开同一个地址的访问
  • call_id - 每一个函数调用赋予一个id,用于区分不同的程序
  • is_root - 是否是根
  • is_create - 是否是create调用
  • code_source - 调用程序的标示(一般是个程序的hash结果)
  • program_counter - PC
  • stack_point - 栈指针
  • gas_left - 剩下的gas数量
  • memory_word_size - memory的大小(以word(32字节)为单位)
  • state_write_counter - 状态写入的计数器

仔细查看Step的创建函数(new),发现在创建Step的时候分别创建StepState和StepRow。

pub(crate) fn new(
      meta: &mut ConstraintSystem<F>,
      qs_byte_lookup: Column<Advice>,
      advices: [Column<Advice>; STEP_WIDTH],
      is_next_step: bool,
 ) -> Self {

创建StepState的逻辑如下:

let num_state_cells = ExecutionState::amount() + N_CELLS_STEP_STATE;

let mut cells = VecDeque::with_capacity(num_state_cells);
      meta.create_gate("Query state for step", |meta| {
        for idx in 0..num_state_cells {
           let column_idx = idx % STEP_WIDTH;
           let rotation = idx / STEP_WIDTH + if is_next_step { STEP_HEIGHT } else { 0 
};
           cells.push_back(Cell::new(meta, advices[column_idx], rotation));
        }

        vec![0.expr()]
      });

      StepState {
         execution_state: cells.drain(..ExecutionState::amount()).collect(),
         rw_counter: cells.pop_front().unwrap(),
         call_id: cells.pop_front().unwrap(),
         is_root: cells.pop_front().unwrap(),
         is_create: cells.pop_front().unwrap(),
         code_source: cells.pop_front().unwrap(),
         program_counter: cells.pop_front().unwrap(),
         stack_pointer: cells.pop_front().unwrap(),
         gas_left: cells.pop_front().unwrap(),
         memory_word_size: cells.pop_front().unwrap(),
         state_write_counter: cells.pop_front().unwrap(),
       }

N_CELLS_STEP_STATE=10是StepState中除了execution_state外的其他Cell的个数。

按照16行*32列,创建出对应于advices这些Column的Cell。重点要理解好Cell的表示,在同一个Column中的不同的Cell,采用Rotation(偏移)进行区分。在编写电路业务的时候,特别注意对Cell的抽象和描述,这些模块化的电路可能会应用多个实例。再观察这些StepState对应的Cell,这些Cell再配合上q_step相应的选择子,就可以精确的描述一个Step的电路约束逻辑。简单的说,q_step选择子约束行,Step中的Cell采用Rotation(相对偏移)定位。

创建StepRow的逻辑如下:

let mut rows = Vec::with_capacity(STEP_HEIGHT - rotation_offset);
  meta.create_gate("Query rows for step", |meta| {
   for rotation in rotation_offset..STEP_HEIGHT {
      let rotation = rotation + if is_next_step { STEP_HEIGHT } else { 0 };
      rows.push(StepRow {
        qs_byte_lookup: Cell::new(meta, qs_byte_lookup, rotation),
        cells: advices.map(|column| Cell::new(meta, column, rotation)),
      });
    }

    vec![0.expr()]
 });

从StepState下面的第一个行开始是一个个的StepRow。

3.png

Custom Gate约束

Custom Gate的约束相对来说最复杂。Custom Gate的约束包括:

a. 每一个Step中的execution_state只有一个有效状态:

let sum_to_one = (
   "Only one of execution_state should be enabled",
    step_curr
      .state
      .execution_state
      .iter()
      .fold(1u64.expr(), |acc, cell| acc - cell.expr()), // expression -> 1 - sum(state's cells)
 );

实现的方法是将所有的状态的Cell的数值累加起来。sum_to_one是1-sum的表达式(expression)。

b. 每一个Step中execution_state是布尔值:

let bool_checks = step_curr.state.execution_state.iter().map(|cell| {
    (
        "Representation for execution_state should be bool",
         cell.expr() * (1u64.expr() - cell.expr()),
     )
 });

检查的方法就是采用x*(1-x)。

c. 相邻的两个Step中的ExecuteState满足约定的条件:比如说,EndTx状态后,只能是BeginTx或者EndBlock。

                      [
                          (
                              "EndTx can only transit to BeginTx or EndBlock",
                              ExecutionState::EndTx,
                              vec![ExecutionState::BeginTx, ExecutionState::EndBlock],
                          ),
                          (
                              "EndBlock can only transit to EndBlock",
                              ExecutionState::EndBlock,
                              vec![ExecutionState::EndBlock],
                          ),
                      ]
                      .map(|(name, from, to)| {
                          (
                              name,
                              step_curr.execution_state_selector([from])
                                  * (1.expr() - step_next.execution_state_selector(to)),
                          )
                      }),

注意,这些相邻的约束,对于最后一个Step不需要满足:

.map(move |(name, poly)| (name, (1.expr() - q_step_last.clone()) * poly))

d. 第一个Step的状态必须是BeginTx,最后一个Step的状态必须是EndBlock:

         let _first_step_check = {
              let begin_tx_selector =
                  step_curr.execution_state_selector([ExecutionState::BeginTx]);
              iter::once((
                  "First step should be BeginTx",
                  q_step_first * (1.expr() - begin_tx_selector),
              ))
          };

          let _last_step_check = {
              let end_block_selector =
                  step_curr.execution_state_selector([ExecutionState::EndBlock]);
              iter::once((
                  "Last step should be EndBlock",
                  q_step_last * (1.expr() - end_block_selector),
              ))
          };

特别注意的是,如上的这些custom gate的约束都是相对于某个Step而已的,所以所有的约束必须加上q_step的限制:

          iter::once(sum_to_one)
              .chain(bool_checks)
              .chain(execution_state_transition)
              .map(move |(name, poly)| (name, q_step.clone() * poly))
              // TODO: Enable these after test of CALLDATACOPY is complete.
              // .chain(first_step_check)
              // .chain(last_step_check)

当前的代码不是最终的代码,first_step_check以及last_step_check都被注释掉了。从TODO可以看出,这些约束在CALLDATACOPY的约束实现测试完成后会加上。

Advice Column的数据范围约束

约束每个advice都是byte(也就是Range256)的范围内。因为范围(Range)的约束实现在fixed_table中,由4个fixed column组成。所以Range256的范围约束由tag/value等四部分对应。

     for advice in advices {
          meta.lookup_any("Qs byte", |meta| {
              let advice = meta.query_advice(advice, Rotation::cur());
              let qs_byte_lookup = meta.query_advice(qs_byte_lookup, Rotation::cur());

              vec![
                  qs_byte_lookup.clone() * FixedTableTag::Range256.expr(), //tag约束
                  qs_byte_lookup * advice, //值约束
                  0u64.expr(), //ignore
                  0u64.expr(), //ignore
              ]
              .into_iter()
              .zip(fixed_table.table_exprs(meta).to_vec().into_iter())
              .collect::<Vec<_>>()
          });
      }

到目前为止,整个电路的大致的样子有了,划分了Column的类型,定义了每个Step的电路范围。并且约束了每个Step中的状态以及相邻两个Step的状态关系。

Gadget约束

对于每一种类型的操作(Opcode),创建对应的Gadget约束。具体的逻辑实现在configure_gadget函数中:

fn configure_gadget<G: ExecutionGadget<F>>(
      meta: &mut ConstraintSystem<F>,
      q_step: Selector,
      q_step_first: Selector,
      power_of_randomness: &[Expression<F>; 31],
      step_curr: &Step<F>,
      step_next: &Step<F>,
      independent_lookups: &mut Vec<Vec<Lookup<F>>>,
      presets_map: &mut HashMap<ExecutionState, Vec<Preset<F>>>,
  ) -> G {

对于Gadget的约束,抽象出ConstraintBuilder:

     let mut cb = ConstraintBuilder::new(
          step_curr,
          step_next,
          power_of_randomness,
          G::EXECUTION_STATE,
      );

      let gadget = G::configure(&mut cb);

      let (constraints, constraints_first_step, lookups, presets) = cb.build();
      debug_assert!(
          presets_map.insert(G::EXECUTION_STATE, presets).is_none(),
          "execution state already configured"
      );

通过ConstraintBuilder::new创建ConstraintBuilder。对于每一种Gadget,调用相应的configure函数。最终调用ConstraintBuilder的build函数完成约束配置。

先从ConstraintBuilder的定义讲起。ConstraintBuilder定义在zkevm-circuits/src/evm_circuit/util/constraint_builder.rs中:

pub(crate) struct ConstraintBuilder<'a, F> {
  pub(crate) curr: &'a Step<F>, //current Step
  pub(crate) next: &'a Step<F>, //next Step
  power_of_randomness: &'a [Expression<F>; 31],
  execution_state: ExecutionState, //execution state
  cb: BaseConstraintBuilder<F>, //base builder
  constraints_first_step: Vec<(&'static str, Expression<F>)>,
  lookups: Vec<(&'static str, Lookup<F>)>,
  curr_row_usages: Vec<StepRowUsage>, //当前StepRow的使用情况
  next_row_usages: Vec<StepRowUsage>, //下一个StepRow的使用情况
  rw_counter_offset: Expression<F>, //
  program_counter_offset: usize, //PC
  stack_pointer_offset: i32, //栈指针
  in_next_step: bool, //
  condition: Option<Expression<F>>,
}

a. ConstraintBuilder::new

创建了ConstraintBuilder对象。

b. G::configure

所有的Opcode相关的Gadget相关的代码在zkevm-circuits/src/evm_circuit/execution/目录下。目前已经支持三十多种Gadget,也就是说,支持三十多种execution_state。以比较简单的AddGadget介绍相关的约束实现:

pub(crate) struct AddGadget<F> {
  same_context: SameContextGadget<F>,
  add_words: AddWordsGadget<F, 2, false>,
  is_sub: PairSelectGadget<F>,
}

AddGadget依赖于其他三个Gadget: SameContextGadget (约束Context),AddWordsGadget(Words相加)和PairSelectGadget(选边,选择a或者b)。通过AddGadget的configure函数可以查看相关的约束。

1/ 约定opcode,a/b/c(操作字)的Cell(通过cb.query_cell)

let opcode = cb.query_cell();
let a = cb.query_word();
let b = cb.query_word();
let c = cb.query_word();

2/ 构建加法约束(减法也转化为加法)

let add_words = AddWordsGadget::construct(cb, [a.clone(), b.clone()], c.clone());

3/ 确定是加法还是减法操作,查看opcode是ADD还是SUB

let is_sub = PairSelectGadget::construct(
  cb,
  opcode.expr(),
  OpcodeId::SUB.expr(),
  OpcodeId::ADD.expr(),
);

4/ 约束对应的Stack的变化

cb.stack_pop(select::expr(is_sub.expr().0, c.expr(), a.expr()));
cb.stack_pop(b.expr());
cb.stack_push(select::expr(is_sub.expr().0, a.expr(), c.expr()));

5/ 约束Context的变化

let step_state_transition = StepStateTransition {
  rw_counter: Delta(3.expr()),
  program_counter: Delta(1.expr()),
  stack_pointer: Delta(1.expr()),
  gas_left: Delta(-OpcodeId::ADD.constant_gas_cost().expr()),
  ..StepStateTransition::default()
};
let same_context = SameContextGadget::construct(cb, opcode, step_state_transition);

注意所有的约束最后都是保存在cb.constraints变量。

c. cb.build

cb.build就是对于每个Gadget的约束进行修正和补充。对于当前Step的所有的Row:

1/ 如果没有用到的Cell,需要限制为0

2/ 如果需要检查范围的,检查qs_byte_lookup

     for (row, usage) in self.curr.rows.iter().zip(self.curr_row_usages.iter()) {
          if usage.is_byte_lookup_enabled {
              constraints.push(("Enable byte lookup", row.qs_byte_lookup.expr() - 1.expr()));
          }

          presets.extend(
              row.cells[usage.next_idx..]
                  .iter()
                  .map(|cell| (cell.clone(), F::zero())),
          );
          presets.push((
              row.qs_byte_lookup.clone(),
              if usage.is_byte_lookup_enabled {
                  F::one()
              } else {
                  F::zero()
              },
          ));
      }

对于当前Step的约束或者查找表,加上execution_state的选择子。

    let execution_state_selector = self.curr.execution_state_selector([self.execution_state]);

      (
          constraints
              .into_iter()
              .map(|(name, constraint)| (name, execution_state_selector.clone() * constraint))
              .collect(),
          self.constraints_first_step
              .into_iter()
              .map(|(name, constraint)| (name, execution_state_selector.clone() * constraint))
              .collect(),
          self.lookups
              .into_iter()
              .map(|(name, lookup)| (name, lookup.conditional(execution_state_selector.clone())))
              .collect(),
          presets,
      )

到此,Step的约束框架浮现出来了。ExecuteState是可能的执行状态,相对于qs_step来说,execute_state的相对位置固定。并且execute_state的每个Cell的值必须是布尔类型,有且只有一个执行状态有效。针对每个执行状态,存在相应的Gadget电路。所有的Gadget电路在cb.build的阶段都必须加上execution_state_selector选择子。也就是说,整个EVM Circuit电路逻辑上包括了所有执行状态的约束。

在讲最后一部分,其他Lookup约束之前,介绍一下Stack约束和Context约束。

Stack约束

回头再看Add电路约束,利用cb.stack_pop和cb.stack_push函数实现相应的Stack的约束。

pub(crate) fn stack_pop(&mut self, value: Expression<F>) {
      self.stack_lookup(false.expr(), self.stack_pointer_offset.expr(), value);
      self.stack_pointer_offset += 1;
 }

  pub(crate) fn stack_push(&mut self, value: Expression<F>) {
      self.stack_pointer_offset -= 1;
      self.stack_lookup(true.expr(), self.stack_pointer_offset.expr(), value);
 }

stack_pop和stack_push的实现类似,都是调整stack_pointer_offset偏移,并通过stack_lookup约束Stack上stack_pointer_offset对应的值。

pub(crate) fn stack_lookup(
      &mut self,
      is_write: Expression<F>, //是否是写操作?
      stack_pointer_offset: Expression<F>, //Stack偏移
      value: Expression<F>, //Stack的值
  ) {
      self.rw_lookup(
          "Stack lookup",
          is_write,
          RwTableTag::Stack,
          [
              self.curr.state.call_id.expr(),
              0.expr(),
              self.curr.state.stack_pointer.expr() + stack_pointer_offset,
              0.expr(),
              value,
              0.expr(),
              0.expr(),
              0.expr(),
          ],
      );
  }

核心逻辑是rw_loopup,rw_loopup实现又是基于rw_lookup_with_counter。Stack的访问细化为call_id, Stack的偏移以及rw的次数。在同一个Step State中,对同一个Stack的偏移存在多次读写的可能性,这些可能性的约束需要加上读写的次数。

rw_loopup_with_counter的实现就是将lookup(查找表)通过add_lookup记录在ConstraintBuilder的lookups变量中,为后面的查找表的Configure做准备。

fn rw_lookup_with_counter(
      &mut self,
      name: &'static str,
      counter: Expression<F>,
      is_write: Expression<F>,
      tag: RwTableTag,
      values: [Expression<F>; 8],
  ) {
      self.add_lookup(
          name,
          Lookup::Rw {
              counter,
              is_write,
              tag: tag.expr(),
              values,
          },
      );
  }

除了RW(可读可写的)查找表外,目前还支持其他一些查找表类型。Lookup枚举类型定义在zkevm-circuits/src/evm_circuit/table.rs:

pub(crate) enum Lookup<F> {
  /// Lookup to fixed table, which contains serveral pre-built tables such as
  /// range tables or bitwise tables.
  Fixed {
...
  },
  Tx {
  ...
  },
  Rw {
  ...
  },
  Bytecode {
  ...
  },
  Block {
  ...
  },
  Conditional {
  ...
  }

Tx查找表约束交易数据,RW查找表约束可读可写的数据访问(Stack/Memory),Bytecode约束执行的程序,Block约束的是区块相关的数据。

4.png

再重头看一下Stack的约束实现。对于每一种Step,可能存在Stack或者Memory的操作。为了约束这些操作,除了申请和这些操作数据相关的Cell外,还需要指定Stack Pointer。在Stack Pointer锚定的情况下,某个Step内部的Stack的操作可以独立约束。并且,Stack Pointer对应的Cell在Step中的位置可以通过q_step进行锚定。也就是说,从单个Step的角度来说,约束可以独立表达和实现。当然,Stack的约束除了单个Step的约束外,多个Step之间也存在Stack数据一致性和正确性的约束。这些约束由后续“Lookup约束”进行约束(请查看Lookup约束章节)。

Context约束

之前的重点是单个Execution State的约束实现。SameContextGadget约束的是多个Execution State之间约束实现。

pub(crate) struct SameContextGadget<F> {
  opcode: Cell<F>,
  sufficient_gas_left: RangeCheckGadget<F, N_BYTES_GAS>,
}

具体的约束逻辑实现在contruct函数中:

pub(crate) fn construct(
  cb: &mut ConstraintBuilder<F>,
  opcode: Cell<F>,
  step_state_transition: StepStateTransition<F>,
) -> Self {
  cb.opcode_lookup(opcode.expr(), 1.expr());
  cb.add_lookup(
      "Responsible opcode lookup",
      Lookup::Fixed {
          tag: FixedTableTag::ResponsibleOpcode.expr(),
          values: [
              cb.execution_state().as_u64().expr(),
              opcode.expr(),
              0.expr(),
          ],
      },
  );

  // Check gas_left is sufficient
  let sufficient_gas_left = RangeCheckGadget::construct(cb, cb.next.state.gas_left.expr());

  // State transition
  cb.require_step_state_transition(step_state_transition);

  Self {
      opcode,
      sufficient_gas_left,
  }
}

逻辑简单清晰,实现了如下的约束:

1/ opcode_lookup - 约束PC对应的op code一致

2/ add_lookup - 约束opcode和Step中的execution state的一致性

3/ 查看gas是否足够

4/ require_step_state_transition - 约束状态的转换是否一致(涉及到两个Step之间的约束)。比如说PC的关系,Stack Pointer的关系,Call id的关系等等。

具体的代码,感兴趣的小伙伴可以自行查看。

Lookup约束

在每个Execution State的约束准备就绪后,开始处理所有的Lookup的约束。

     Self::configure_lookup(
          meta,
          q_step,
          fixed_table,
          tx_table,
          rw_table,
          bytecode_table,
          block_table,
          independent_lookups,
      );

实现的逻辑相对简单,每个Lookup的约束需要额外加上q_step约束外,建立不同的表的约束关系。其中independent_lookups就是某个Step约束中除去常见表外的查找表约束。

EVM Circuit Assign

EVM Circuit通过assign_block对一个Block中的所有的交易进行证明。

pub fn assign_block(
      &self,
      layouter: &mut impl Layouter<F>,
      block: &Block<F>,
  ) -> Result<(), Error> {
      self.execution.assign_block(layouter, block)
  }

ExecutionState的assign_block,除了设置q_step_first以及q_step_last外,对Block中的每一笔交易Tx进行约束。

            self.q_step_first.enable(&mut region, offset)?;

              for transaction in &block.txs {
                  for step in &transaction.steps {
                      let call = &transaction.calls[step.call_index];

                      self.q_step.enable(&mut region, offset)?;
                      self.assign_exec_step(&mut region, offset, block, transaction, call, step)?;

                      offset += STEP_HEIGHT;
                  }
              }

              self.q_step_last.enable(&mut region, offset - STEP_HEIGHT)?;

一笔交易Tx的一个个步骤(step)存储在steps变量中。针对每个Step,调用assign_exec_step进行assign。在理解Configure的逻辑的基础上,这些逻辑相对简单。感兴趣的小伙伴可以自行深入查看相应源代码。

EVM Circuit的电路实现先介绍到这里,后续的文章接着介绍State Circuit和Bytecode Circuit。

本文首发于:https://mp.weixin.qq.com/s/-sUsId_555hzBRhR7O93Lw

  • 发表于 2022-04-25 17:17
  • 阅读 ( 494 )
  • 学分 ( 0 )
  • 分类:零知识

0 条评论

请先 登录 后评论
Star Li
Star Li

80 篇文章, 6159 学分