Public inputs in appliedzkp zkevm (13)

1. introduction

The following is the Ethereum client for calculation block All of the public inputs data ：

• 1） At present block
• 2） Previous 256 individual block：Previous Blocks
• 3） Global information
• 4） transaction
• 5） Other requirements public data ：【 Not with verification circuit Medium public inputs Equivalent , Because of every circuit public input value There is verification overhead , The verification overhead should be kept as small as possible .】
  • 5.1） For synchronization State Trie The data of
  • 5.2） Used to calculate new block The data of
  • 5.3） Used to verify synchronized data

2. For current block Of public inputs And circuits

For current block Of public inputs Yes ：

• Hash: 256 bits
• Block Fields used in RLP:
  • ParentHash: 256 bits
  • UncleHash: 256 bits
  • Coinbase: 160 bits
  • Root: 256 bits (State Trie Root)
  • TxHash: 256 bits (Txs Trie Root)
  • ReceiptHash: 256 bits (Receipts Trie Root)
  • Bloom: 256 bytes
  • Difficulty: 256 bits
  • Number: 64 bits
  • GasLimit: 64 bits
  • GasUsed: 64 bits
  • Time: 64 bits
  • Extra: 0 bytes
  • MixDigest: 256 bits
  • Nonce: 64 bits
  • BaseFee: 256 bits (BaseFee was added by EIP-1559 and is ignored in legacy headers.)

For current block The circuit of is ：

• 1）Block Hash verifier
  • All fields
• 2）EVM Circuit Block Table
  • Coinbase
  • GasLimit
  • Number
  • Time
  • Difficulty
  • BaseFee
• 3）State Circuit
  • Block.Root

3. Used before 256 Block public inputs And circuits

Used before 256 Block public inputs Yes ：

• block[-1].Root: 256 bits
• block[-1…-257].Hash: 256 x 256 bits

Used before 256 The circuits of blocks have ：

• 1）EVM Circuit Block Table
  • block[-1…-257].Hash
• 2）State Circuit
  • block[-1].Root

4. Global information and circuit

The global information is ：

• ChainID: 64 bits

The corresponding circuits are ：

• 1）EVM Circuit Block Table
  • ChainID
• 2）TxCircuit
  • ChainID

5. For trading public inputs And circuits

At present, we only consider the definition in EIP-1559 Medium legacy transaction, Corresponding public inputs Yes ：

• Nonce: 64 bits
• GasPrice: 256 bits
• Gas: 64 bits
• CallerAddress: 160 bits
• CalleeAddress: 160 bits
• IsCreate: 1 bit
• Value: 256 bits
• CallDataLength: 64 bits
• CallData: CallDataLength bytes
• TxSignHash: 256 bits
• Signature
  • v: 256 bits
  • r: 256 bits
  • s: 256 bits

among ,TxSignHash RLP The fields used in are ：

• Nonce
• GasPrice
• Gas
• CalleeAddress
• Value
• CallData
• ChainID

TxHash RLP The fields used in are ：

• Nonce
• GasPrice
• Gas
• CalleeAddress
• Value
• CallData
• ChainID
• Signature.v
• Signature.r
• Signature.s

The circuits corresponding to the transaction are ：

• TxCircuit
  • All Fields

6. Other public data required

Some data in the previous sections will be submitted for verification proof Attach . In order to verify a proof, Strictly speaking, more data is needed to synchronize State Trie.

6.1 Sync State Trie Data needed

In order to synchronize the new block State Trie（ Suppose there is already state）, At least the following data is required ：

• For each tx
  • GasPrice: 256 bits
  • Gas: 64 bits
  • CallerAddress: 160 bits
  • CalleeAddress: 160 bits
  • Value: 256 bits
  • CallData: CallDataLength bytes
• Block fields that affect EVM execution
  • Coinbase: 160 bits
  • Difficulty: 256 bits
  • Number: 64 bits
  • GasLimit: 64 bits
  • Time: 64 bits
  • BaseFee: 256 bits
• Extra fields that affect EVM execution
  • block[-1…-257].Hash
  • ChainID: 64 bits

Sync State Trie when , No signature is required , And nonce The value can be from the previous block State Trie derived .

6.2 Calculate the data required by the new block

In order to calculate the new block （ Suppose there is already state）, The following data is needed ：

• A way to prove that block[-1].Root (calculated from the known State Trie) is
  included in block[-1].Hash
  • A simple way to resolve this is by publishing the StateRoot with each proof (liked via public input)
  • Another way to resolve this is by publishing all block fields, so that a verifier can calculate the block hash in the circuit proving that it uses the expected StateRoot.

6.3 Verify the data required for synchronization

Even if a node has enough data to synchronize State Trie, The node still cannot verify its calculated State Trie Whether it is right （ And proof identical ）, The following data is also required ：

• StateRoot

7. Public Input Method

The required public Data is not equal to verification circuit Of public inputs, Because of every circuit public input value There is verification overhead , The verification overhead should be kept as small as possible .

In order to reduce ciruit public inputs Of size, Introduced PublicInputs Circuit Thought , stay PublicInputs Circit in , Will verify circuit What is needed in public inputs（ As witness） Corresponding these public inputs Previous commitment, At the same time, these data are established in the expected shape of the residual circuit （ As lookup table perhaps public input values）.

PublicInputs Circuit From the top aggregation circuit verification , Only a small part is needed public inputs（ That is to say ,a challenge to validate the commitment of the necessary public data）.

To start with ：
Yes a list of raw public inputs （ Contains the required public data） Must be able to give aggregation circuit. Want to reduce public inputs To reduce verification overhead , For this reason, I hope we can “ Compress ”.

There are many different kinds of “ Compress ” The way , The most advanced one is EIP-4844, Support the generation of cheap data commitment Send to Ethereum , Then the contract “ decompression ”（opened）.

EIP-4844 As defined in commitment The adoption is different from circuit In the domain , Make in circuit Inside open The commitment It's very expensive , We must resort to PublicInputs circuit To prove （circuits In addition to the ）committed raw public inputs And （circuit Within ）witnessed raw public inputs Equivalent .

The detailed processing flow is ：

1. Send raw_public_inputs to Ethereum as a blob following EIP-4844
2. Get commitment_bls=kzg_commitment(raw_public_inputs)
3. Prove that commitment_bls has committed to the same values as the ones found in the raw_public_inputs advice column in the public_inputs_circuit. See here for a possible approach.
4. public_inputs_circuit lays out the advice column raw_public_inputs into the tx_table, block_table, etc.
5. When Aggregation0 circuit verifies public_inputs_circuit proof, it has access to commitments of advice columns corresponding to tx_table, block_table, etc. We call these table commitments.
6. Aggregation0 circuit passes these table commitments around (to other aggregation circuits) until they reach the circuit that uses them
7. aggregation circuit that verifies a circuit that uses a table, uses the table commitment in the verification of the proof.

Can be 1/2/3 Simplified as ：

1. Calculate raw_public_inputs from the necessary public inputs passed via calldata in the tx where we call the zkEVM verification function
2. p = RLC(raw_public_inputs, rand)
   – rand = hash(raw_public_inputs, polynomial_commitment(public_inputs_circuit:advice_raw_public_inputs))

Among them the first 2 Point needs ：

• A. Aggregation0 must have rand and polynomial_commitment(public_inputs_circuit:advice_raw_public_inputs) as public input
• B. public_inputs_circuit must have rand as public input

Be careful ：

• Aggregation0 circuit For the top aggregation circuit, Will be in L1 Verification in the contract .
• Once through Aggregation0 circuit, Every proof The verification cost of will be independent of “ Actual ”public inputs Number （ That is, the number of transactions ,call data size, Number of block fields, etc ）.
• Calculate the contract value Of RLC yes cheap Of （ Only required MULMOD and ADDMOD）.

Here's how to use RLC Shortcut flow chart ：

7.1 stay circuit Internal validation KZG BLS commitment

The following is the proof based on BLS curve （ Such as EIP-4844 As defined in ） Of KZG commitment Corresponding to circuit in advice column Same value in Proposal for ：

1. Pick random x
2. Evaluate the polynomial used in commitment_bls at x and get y. So
   verify_kzg_bls_proof(commitment_bls, x, y, quotient_kzg) == True, where
   y is in modulus of BLS
3. Pass (x, y) into the aggregation circuit (as public inputs)
4. Pass (x, y) into the public_inputs_circuit (as public inputs)
5. public_inputs_circuit contains a column with raw_public_inputs
6. Inside the circuit, evaluate the polynomial defined with raw_public_inputs as its Lagrange coefficients in the BLS modulus at x and verify that the result is y.
   We use the barycentric formula to evaluate the polynomial using its Lagrange coefficients efficiently.

How to choose random challenge x Well ？

• x = hash(commitment_bls(raw_public_inputs) || poly_commitment(PublicInputsCircuit:raw_public_inputs))

The reason lies in ：

• The prover shouldn’t know x before the commitment_bls is calculated
• The prover shouldn’t know x before the witness PublicInputsCircuit:raw_public_inputs is committed
• In summary: the prover shouldn’t be able to change any of the commitments after it learns about x, otherwise the prover is able to construct a polynomial with values different than raw_public_inputs that evaluates to y on x.

8. PublicInputs Circuit

8.1 Setup

All the necessary public data is arranged in a single array of elements (called raw_public_inputs), following the layout of the block_tablevalue column, tx_table { tx_id, index, value} columns, and extra fields in between.

8.2 Public Inputs

• rand_rpi: Randomness used to “compress” the raw public inputs
• rpi_rlc: Random Linear Combination of the raw public inputs (using rand_rpi as randomness)
• chain_id: Chain ID, used to match the Chain ID public input used in the Tx Circuit
• state_root: State Root of current block, used to match the State Root of current block public input used in the State Circuit
• state_root_prev: State Root of previous block, used to match the State Root of previous block public input used in the State Circuit

8.3 Behaviour

• 1） First ,the circuit calculates the Random Linear Combination of a column containing the raw public inputs array, and verifies that the result matches the rpi_rlc passed via public inputs using rand_rpi as randomness.
• 2） secondly ,the circuit proves that the contained block_table -> value and tx_table -> {tx_id, index, value} columns correspond to the correct sections of the raw public inputs column.
• 3） Last ,the circuit proves that the chain_id, state_root and state_root_prev in the public inputs are found in the correct offset in the raw public inputs column.

Reference material

[1] Public Inputs