feat: Conditional transactions

[Brechtpd]

Describe the feature request

When a proposer submits transactions it cannot always know for sure how, or even if, that transaction is executed. In most cases that's fine, the proposer has spent its own money to take a risk to earn the transaction fees. However sometimes the transaction owner, and so either directly or indirectly the proposer as well, wants to set hard guarantees when, and only want, the transaction should be executed. This will be beneficial to support account abstraction but also many other use cases. More info here: https://notes.ethereum.org/@yoav/SkaX2lS9j

For Taiko to support this, with its current decentralization strategy, ideally it's moved to an in protocol feature, where not unlike the insufficient ETH balance check or the invalid nonce check, the transaction is skipped over if the required conditions are not met. However, if the decentralization mechanism works in a way in which conflicts are already impossible (or extremely rare at least) then just building this into the node software and leaving the protocol as is good enough.

Practically speaking, transactions will include some additional data that describes these conditions, which will then be checked in-circuit. These checks currently are a list of MPT state checks where the expected value needs to be in the latest MPT tree, but in the future may also contain things like block number or time range checks.

Note that this system, when available on L1, will also greatly help to reduce the amount of L2 block conflicts in a fully decentralized way. A proposer can include conditions like "only include execute my transaction when I'm the first new block in the L2 chain" which the Ethereum validators (who control over what gets included in a block, but also know exactly how these transactions will execute) can and should use to build the new L1 block. However on L1 this is only a soft guarantee as the Ethereum validator can still choose to ignore those rules (the rules are not enforced directly by Ethereum), but in that case people that need these conditional transactions will opt not to use this validator anymore.

Describe alternatives you've considered

Description of the alternatives you've considered here.

Additional context

Additional context here.

[dantaik]

The idea here (https://notes.ethereum.org/@yoav/SkaX2lS9j) is nice for account abstraction as all the state of the 'knownAccounts' parameter are on L1 so the sequencer/mevbuilder can check those states to decide if a block should be broadcasted. But for Taiko L2, we care about L2 state which is not available to L1 mevbuilder/validators unless they run a Taiko node side-by-side.

For our proposeBlock transaction, using the above approach, the knownAccounts should be the taikoL1 contract, but if we use taikoL1's address and storageRoot in the API request, then it means we can only propose one L2 block within a L2 block. It is not good.

I guess that's why, Brecht, you proposed above that we ask L2 proposers to express knownAccounts parameters as part of txList and in circuits we enforce some transactions to be skipped over if their preconditions checks fail. Is that correct?

But I don't think that solves our challenge which is waste of duplicate transactions in proposed blocks that lowered the proposer's transaction fee income while the data cost remains the same.

With transaction precondition support in our protocol, we can only help L2 mev builders who want their own MEV txs to be skipped over in certain situations. Most users don't care -- and as you said, users don't specify their transaction's preconditions.

Maybe I missed something.

[Brechtpd]

But for Taiko L2, we care about L2 state which is not available to L1 mevbuilder/validators unless they run a Taiko node side-by-side.

No need, the L2 proposer just shares its expected L1 values for the expected L2 state as available on L1.

For our proposeBlock transaction, using the above approach, the knownAccounts should be the taikoL1 contract, but if we use taikoL1's address and storageRoot in the API request, then it means we can only propose one L2 block within a L2 block. It is not good.

Because the block data is stored on-chain as the blocks come in there is no problem doing multiple L2 blocks per L1 block. For example, if proposer A submits block A and proposer B wants to build on top of this block with block B, the condition for block B would simply be that the contract state is the state post block A. Both block A and block B can be submitted in the same L1 block as the conditions are always checked against the latest state, not the state after the last block. You could even do more complex logic and the proposer can pick on of many different "fork" chains in the mempool as blocks can each have different dependencies on other blocks still in the mempool as well.

I guess that's why, Brecht, you proposed above that we ask L2 proposers to express knownAccounts parameters as part of txList and in circuits we enforce some transactions to be skipped over if their preconditions checks fail. Is that correct?

Yep, if because of how the protocol works it cannot be 100% guaranteed that the proposed gets included only at the expected position, the proposer can still take the risk to include the transaction without violating the transaction rules.

But I don't think that solves our challenge which is waste of duplicate transactions in proposed blocks that lowered the proposer's transaction fee income while the data cost remains the same.

For that we rely on this mechanism on L1. The things we would do in protocol are to enable the same guarantees on L2.

With transaction precondition support in our protocol, we can only help L2 mev builders who want their own MEV txs to be skipped over in certain situations. Most users don't care -- and as you said, users don't specify their transaction's preconditions.

The reason to get it in on L2 (either of the L2 node level or hard guarantees in the L2 protocol level) is the same as the reason to get it in on L1. If this a requirement for relayers to want to run their services for account abstraction than not having it will certainly impact users as well that want to make use of these services. I don't think this feature is necessarily helpful for MEV as these users/bots are willing to risk some money to gain the MEV, it's mostly to not waste gas when not necessary, and for cases like account abstraction the relayer will only get paid when doing useful work for a batch of users.

[ameya-deshmukh]

Hi @d1onys1us possible to work on this?