Agree with your points above.
Regarding this, it seems simpler to not include the sponsor’s nonce. Because the base transaction has a unique hash (protected by the signer’s nonce) the sponsor’s signature on that transaction will only ever be able to be accepted once. This removes the need to construct a more complicated dependency structure between the the signer and sponsor nonces.
For example, suppose we have the following contents in the mempool and a new incoming transaction:
Visually, it’s clear that TRANSACTION TUPLE 4 depends on TRANSACTION TUPLE 3, which in turn depends on STANDARD TX 1 – the transaction that would be replaced by 4 since they both have nonce of 1 for account A, and therefore it is invalid. This adds a lot of complexity to the existing rules in the mempool. I believe the best two approaches for validating an incoming transaction with dual nonce dependencies are to either i) do a cycle check on the dependency DAG or ii) maintain a state diff for each tx. Neither scenario seems ideal.
When the sponsor’s nonce is not included, transactions can be accepted, rejected, and substituted in a much more similar manner as they are today. The sponsor’s balance acts like an amorphous accumulator that has no ordered dependencies to maintain – just ensure it’s balance is greater than value + gas_price * gas_limit of the transaction it’s accepting and when a transaction they’re sponsoring is demoted, replenish their balance with the demoted amount.
The main casualty I see from dropping the nonce is that the sponsor won’t easily be able to cancel their transaction by issuing a new one with the same nonce and much higher gas price.
–
the validators can validate the outcome of transactions and decide if they are worth including, and if so, include them with a gas price 0
A few thoughts on this:
- validating a transaction at the consensus layer would cost O(n) since it could pay out in tokens at the very end of execution. Maintaining O(1) cost of validation should be a goal at the protocol layer. This could be remedied via a configurable parameter set by miner.
- it’s not clear what standard set of tokens will be accepted by miners – some esoteric token may only be accepted by a few miners and therefore the latency could be very high. Even if a small number of relayers accepted an esoteric token, there would be no degradation in latency.
- this seems to necessitate a lot more infrastructure for miners: rate negotiation endpoints, watch lists of tokens and conversion rates, validator logic watching the miner’s accounts on various tokens before and after execution, etc.
- dapps who want to onboard users may be willing to altruistically sponsor their users’ transactions, but this scheme seems to only cater more to a 1:1 relationship between the miner and signer
This is an interesting alternative though and it should not be overlooked. I think as we flesh out all proposals more we’ll better understand the advantages and disadvantages of each.