Conditional execution

[s1na]

Hey everyone,

Meta txes are supposed to be submitted to the network immediately by relayers. It'd be however possible to delay their execution, and make it conditional, e.g. on time, state or events. This could allow "automating" actions like revealing votes and bids, or claiming rewards, etc.

There are two main questions however:

• Whether they can be added to the meta tx standard, with an acceptable complexity overhead. It'd be amazing to have insight from @kosecki123 or @lsaether on this.
• Whether it's desirable to add them to this standard, or they should rather be a different standard.

[Kyrrui]

In addition to this -- I have seen a contract add a execute by date so that a relayer cannot execute a transaction after a certain date. https://github.com/dreamteam-gg/smart-contracts/blob/master/contracts/token/DreamTeamToken.sol#L175

[pet3r-pan]

https://ethresear.ch/t/scheduling-transactions-with-arbitrary-bytecode-on-the-ethereum-network/3647

[s1na]

TL;DR We discuss adding (uint conditionType, bytes condition) to executable signed messages, and employing these fields to enable meta txes conditioned on EVM events.

Note: Conditional execution is costlier in terms of gas, but this shouldn't add much overhead to non-conditional txes.

Modifications to executable signed messages

As there are multiple ways to make transactions conditional, including by time, by checking state or by occurence of events, in addition to the data necessary for specifying the condition, we could add a condition type, which specifies how to parse the condition data.

Condition type

ConditionType	Purpose
0x0	Not conditional (default)
0x1	Time-based condition
0x2	EventLog occurence

Condition data

For EventLogs, the condition could be the RLP-encoded concatenation of (address emitter, bytes32 eventTopic).

Relayer

Relayers would store conditional meta txes, and when the event specified by one of the meta txes is emitted, they compute a proof for the receipt that contains the event log, and send it along with the block header and index of log in receipt to the smart contract.

On-chain verification

For an incoming meta transaction which has a conditionType == 0x2:

• Block header sent by relayer is parsed to get block number and receiptHash.
• Hash of block header should be equal to blockhash(blockNumber).
• Proof sent by relayer for receipt should be verified against receiptHash.
• Log is extracted from receipt (according to logIndex).
• emitter and eventTopic should match those of extracted log.
• Smart contract executes meta transactions.

Example for verifying proof.

Challenges

Meta transactions pre-specify the data field, which determines which function should be called, and what parameters should be used. This means, the arguments of the event can't be used for the transaction as they will be determined in future, and user can't sign it. This severely limits the flexibility of event conditions.

Ideally, users (or dapps) should be able to specify conditions on the event values, and use them in the transaction. E.g. whenever a Transfer(address from, address to, uint256 amount) was emitted, if from == SOME_ADDR compensate them with the same amount.

This could be solved by expecting the callback function to accept bytes eventData parameter, in addition to the fields specified in data, and modifying the identity proxy to append eventData to the parameters, when calling the callback function, if conditionType == 0x2.

[jamesray1]

This means, the arguments of the event can't be used for the transaction as they will be determined in future, and user can't sign it. This severely limits the flexibility of event conditions.

In Rust you can use asynchronous futures with the Futures and Tokio crates.

Tokio uses the futures crate and has documentation for both here: https://tokio.rs/.

Because conditional execution is costlier, DDOS attacks come to mind, however it could conversely be used to prevent DDOS attacks. For instance, if a relay reward is below some limit that will be acceptable by a relayer, the relayer can choose not to execute that transaction and not relay it, and only do so for txs above this limit. And DDOS attacks on relayers are a poignant problem since meta-txs can be submitted at no cost, so many could be submitted. If a relayer is pseudorandomly assigned to a meta-tx at a given rate, this problem is compounded. An alternative solution to this problem is to make sure that a random beacon conditionally assigns a relayer to a meta-tx, iff the reward is >= the relayer's threshold reward amount. The implementation for the latter should be simpler, although conditional execution still seems generally useful.