draft specs of invalid tx

[smtmfft]

According to https://github.com/taikochain/internal/issues/22, I made this draft specs.

Signed-off-by: smtmfft [email protected]

[Brechtpd]

We can probably depend on privacy-scaling-explorations#313 when it's available for the ETH balance case. I didn't think this case could be seen as a similar error case as when it happens in a smart contract execution.

Also because the PSE team wants it (privacy-scaling-explorations/zkevm-circuits#872 (comment)), please add support for the insufficient intrinsic gas when you can (if a future PR makes more sense that's okay).

[Brechtpd]

LGTM! But don't merge this in just yet because it does seem like everything we will do will end up in the shared repo so mentions of taiko specific stuff should be removed and should be put into a separate folder or something to reduce potential conflicts.

[Brechtpd]

Suggested change

	instruction.call_context_lookup(CallContextFieldTag.TxId), total_txs
	instruction.call_context_lookup(CallContextFieldTag.TxId), total_valid_txs

As the comment above says?

[smtmfft]

no, the comments is replaced by mistake, here still using total_txs.
That is part of the reason why I wanted to use another new table in front of the existed tx table (if possible/necessary), as we need to carefully deal with existed tx table log now, and later circuit writers need to keep the invalid skip logic in mind once this flag is added. Not sure if it add extra burden to others, however, so far these changes seems workable and acceptable I guess?? What's your opinion?

[Brechtpd]

Oh okay. Is the only difficulty recovering the "real" tx id (counting up using only the valid transactions)? If so seems easy enough to keep track of that (and perhaps even put it in the tx table).

[smtmfft]

Yes, I now think adding more flags (auxiliary table columns) to tx table if necessary is a better approach, although those who query tx table need to keep them in mind and adjust the way how to use the values accordingly.

[Brechtpd]

Hmm shouldn't this be enforced elsewhere, or maybe just be something like

gas_used = is_tx_invalid * gas_used;
effective_refund = is_tx_invalid * effective_refund;

Both gas_used and effective_refund seem to be calculated directly from other data sources so I don't know how this check helps. Either it's already always 0 because of some other checks in begin_tx or something, or this check is useless because gas_used and effective_refund still have their normal values when is_tx_invalid is true?

[smtmfft]

Could be I think, let me check if they are inherited from begin_tx or not.

[smtmfft]

Could be merged into gas handling logic in begin_tx, which makes gas_left equal tx.gas if tx is invalid, so that here gas_used == 0.
but refund is checked here only, left one enforcement here I think is OK??

[Brechtpd]

Hmmm yes seems like refund is read from the tx table but not checked anywhere else. If that's the case the new code makes sense to me.

[smtmfft]

Add access list logic, but current specs supports legacy tx type only, so the real access list is still a TODO.