Specs for invalid transaction filter.

[smtmfft]

Checking if a TX is invalid by adding a few auxiliary columns to the TX table. So far the balance, nonce and intrinsic gas checking is ready. The access list gas cost checking is in fact a TODO because the specs does not enable the access list tx type (neither the circuit), so this part is more like a draft design for future use, and could be separated out if necessary.

Try addressing https://github.com/privacy-scaling-explorations/zkevm-circuits/pull/872#discussion_r1022863932

[ChihChengLiang]

Hi @Brechtpd, can you assign a reviewer for this PR?

[Brechtpd]

I'll do the review.

[ed255]

I think this is not considered in this PR but I'm wondering the following: for Taiko, have you consider the possibility to include a tx with invalid signature in the block? Or do you consider the signature verification a pre-check to reject transactions before they are considered to be included in a block?

[Brechtpd]

It is indeed not part of this PR, but if needed I think we can add support for that in another PR if others are interested.

We will be handling blocks containing invalid transactions (except insufficient ETH/incorrect nonce transactions as they depend on the latest state) as completely invalid (a block with transactions like that won't have any state changes). In our system the proposer has full control over the included transactions so can make sure the transaction data/signature/etc... is valid, only the parts depending on the latest state (nonce, ETH balance) may be invalid because that's out of the proposer's control sometimes, so we want to be able to skip over individual transactions for that.

But we also still have to be able to prove blocks containing any kind of transaction data. But instead of having to handle all invalid cases in the circuit, we'll have a smart contract on L2 that will be usable to prove that the block contains invalid transactions, and so a proof for an invalid block is simply a normal proof with a single tx that calls this smart contract function with the block transaction data and shows a tx in the block is indeed invalid somehow (e.g. its signature is invalid, wrong RLP encoding etc...). This way the circuits remain simpler and we reuse the EVM itself with easier to write solidity code to handle these error cases (which normally will never be used because a proposer will always lose money by submitting blocks that contain these transactions that are always invalid).

[smtmfft]

Anyone know why I got this error??

==================================== ERRORS ==================================== __________________ ERROR collecting tests/evm/test_end_tx.py ___________________ tests/evm/test_end_tx.py::test_end_tx: in "parametrize" the number of names (6): ['tx', 'gas_left', 'refund', 'is_last_tx', 'current_cumulative_gas_used', 'success'] must be equal to the number of values (5): (<zkevm_specs.evm.typing.Transaction object at 0x7fe9028b8190>, 60000, 0, False, 0) =========================== short test summary info ============================

There is no "success" parameter in test_end_tx.py. https://github.com/privacy-scaling-explorations/zkevm-specs/blob/2c7067605eb2dc5406bb50d0abe0962fd0feafec/tests/evm/test_end_tx.py#L82-L85

[CPerezz]

zkevm_specs.evm.typing.Transaction object at 0x7fe9028b8190>,

That's really weird... The parametrize seems to match perfectly the Testing Data passed.. Maybe @han0110 or @ChihChengLiang can bring some light here

[ChihChengLiang]

Hey @smtmfft and @CPerezz, it looks like the test error is triggered when the PR is merged with the master branch. If you rebase the branch, the error can be reproduced.

[smtmfft]

Hey @smtmfft and @CPerezz, it looks like the test error is triggered when the PR is merged with the master branch. If you rebase the branch, the error can be reproduced.

Thanks @ChihChengLiang , The pytest is fixed after rebase :)

[ChihChengLiang]

Hi @Brechtpd, I noticed you still need to approve the PR. Anything you'd like to add to the review?