As far as I understand Ethereum always needs gas in each transaction. I think that this is limiting ethereum use cases. I am thinking that it would be very useful having an additional way of broadcasting transactions. In this new form the signed transaction does not include gas and it is being added by a second client.
Basically the first client sends a transaction without any gas and a second client wraps the data in the previous transaction, adding the gas for the current and the previous transaction.
This would increase the use cases and simplify some of them. Examples:
- Multi-signature: All the owners sign the transaction but one of them is paying the gas for all of them.
- Service provider: The service subscriber creates the transactions (invoking contracts) but the service provider pays the gas of them (the user supposedly paid to the provider via a different payment channel).
This would allow invocation of smart contracts from accounts without ether, as the service provider would be paying for it.
I can imagine that finding a good approach for broadcasting the initial transactions to the network might be risky if not thought properly (they might flood the network, as there is no gas involved). However an initial version could be implemented in this way:
- Alice creates a transaction T from her account (example: invokes a smart contract method). The transaction is flagged with "no-gas".
- Alice exports the raw transaction and sends it via mail/HTTP/etc to a third party P: service provider, friend, etc.
- P calculates the required gas for T and wraps it into the data field of a new transaction, covering the gas expenses from T.
- P signs the new transaction and broadcasts it to the network.
Eventually a miner will include the transaction in a new block as the gas has been provided.
With this idea we can think of nesting transactions one inside of each other and being the outer transaction the one paying for the gas. None of the transaction will be processed if there is not enough gas.
I see this system very flexible and not too difficult to implement. In the future we could think for ways to broadcasting the source transactions in a way that do not flood the network and which can be wrapped. Or maybe the other way around, the wrapper has a time-limit to accept a wrapping a transaction from an specified origin... etc.
Please let me know what you think about this concept.