contract tx_lookup table

[barryWhiteHat]

In zkevm based zkrollup a smart contract translates the call data and some block constants into a form the zkp is able to read.

The circuit expects this data to be in the format of

a + r * b + r2 c + r3 d = x

The polynomial should be constructed in the field defined by privacy-scaling-explorations/halo2#1

So the layer1 even needs to calculate x and pass that as a public input to the zkevm proof.

The exact format of the polynomial is not exactly what i have described. @han0110 may have more info on this.

[han0110]

Naively, we build the tx_table as a 4 instance columns table for easily lookup like:

tx_index	tx_field_tag	index_or_zero	value
1	1 (Nonce)		txs[0].nonce
1	2 (Gas)		txs[0].gas
1	3 (GasTipCap)		txs[0].gas_tip_cap
1	4 (GasFeeCap)		txs[0].gas_fee_cap
1	5 (CallerAddress)		txs[0].caller_address
1	6 (CalleeAddress)		txs[0].callee_address
1	7 (IsCreate)		txs[0].is_create
1	8 (Value)		txs[0].value
1	9 (CalldataLength)		len(txs[0].calldata)
1	10 (Calldata)	0	txs[0].calldata[0]
1	11 (Calldata)	1	txs[0].calldata[1]
1	12 (Calldata)	2	txs[0].calldata[2]
...
2	1 (Nonce)		txs[1].nonce
2	2 (Gas)		txs[1].gas
2	3 (GasTipCap)		txs[1].gas_tip_cap
...

where the txs[i].calldata is split into byte to byte.

After calculate the 4 evaluations of the instance columns, the left effort should be identical to the subset argument described in halo2 book's Lookup argument.

[barryWhiteHat]

0 | 9 (Calldata) | 0 | txs[0].calldata[0]

Because empty rows are zeros shoudl the index of index_or_zero start from 1 ?

[TrapdoorHeader]

I think it's OK index_or_zero starts from 0. After all, the row can be identified by tx_index and tx_tag.

[han0110]

Because empty rows are zeros shoudl the index of index_or_zero start from 1 ?

For index_or_zero I think it's okay since we already have tag. But I think at least all the tag should start from 1, like currently tx_field_tag starts from 0, which makes the first tx's nonce could be also be 0 (tho not sure how it affects the result, but it seems bad), let me fix it.

[barryWhiteHat]

Since we are building the data in the table in the l1 evm. It might also make sense to calculate the message hash in the l1 evm and then include that in this table. This will allow us to remove the message hash calculation from the circuits for now and still have something that works relatively easily.

Calculating hte message hash in l1 evm will cost a bit more but this can be optimized out later. It seems like doing this in short term will remove alot of work and complexity from the circuits which we can add later when we have an architecture we are comfortable with.

@han0110 does this make sense to you? Do you see any issue ?

[han0110]

I think it makes sense to do the tx hashing in L1 for now, and move the effort into circuit later.

[barryWhiteHat]

I think we are also planning to add

1. call_data_gas_cost calculations. This is due to the really annoying gas fee difference for bytes of data that are 0 and nonzero bytes of data. This is hard to check in circuit and we hope will be removed soon :)
2. message hash calculation here. This is just to make things easier.

[han0110]

Closed by #484