2

I have a mobile app that has users who generate transactions. Basically if a user wants to turn on their TV, they press a button in the app, and that should

1) Run code in a smart contract to verify that the user is authorized to control this TV

2) If the user is authorized, store the "turn on TV" command on the blockchain.

However, I don't want my users to have to pay for this activity. I would like for the company to be in charge of paying for the gas. This way I can just refill / send more gas to 1 source (my company's smart contract), as opposed to having to send gas to a ton of sources (a ton of user smart contracts).

Is there a way to centralize gas payment like this? I want to generate the transaction on the user side for security purposes, but I want the company to take the burden of paying gas. I'm thinking of sending the raw transaction from my mobile app to my backend server, and then sending the transaction from there? Would that work?

2

You could build your contract so that the user spends gas to call the contract, then the contract pays them back the same amount.

There is an attack on this; if the user spends a large amount of ETH on gas, it could drain the contract. To counter this, you should set a maximum gas price (maybe that you could change remotely), otherwise the transaction will revert().

But why would you put something as simple as turning on a TV on the blockchain? You could simply create a contract saying whether each user is authorized to turn on each TV. Instead of having to create a transaction to turn on the TV, the app just creates a connection with the TV, signs a message that says "Turn on TV #0000", sends that message to the TV, the TV verifies that message and verifies that the user is authorized to turn on the TV by viewing the Ethereum blockchain.

This method would require no transactions on the blockchain, and so would be completely free and almost instantaneous.

Please tell me if there is something I missed or I did not explain well.

1

One dead simple solution is to let users sign messages/txs with their keys and then put them in some sort of queue instead of sending them directly to the blockchain. After that, you can just submit those messages to the blockchain and pay tx fees.

Here's a detailed explanation of how it can be done: https://medium.com/zastrin/how-to-save-your-ethereum-dapp-users-from-paying-gas-for-transactions-abd72f15e14d.

Downsides of this solution:

  1. It uses eth_signTypedData function, which is (at the moment) still in development and implemented by Metamask only.
  2. Users have to trust you to forward their transaction. This really sucks, and I'm trying to come up with some solution for that.

UPDATE: Recently I found out about uPort's meta transactions. They kinda improve the process I've described above by introducing multiple relayers (any of them can submit signed messages to the blockchain) instead of a central "submiting entity" (i.e you/your dApp). If you want to know more, this post could be a good start: https://medium.com/uport/making-uport-smart-contracts-smarter-part-3-fixing-user-experience-with-meta-transactions-105209ed43e0.

  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review – Ismael Jun 23 '18 at 4:08
  • Thanks, you're absolutely right, I've edited the answer. :) – Mihailo Bjelic Jun 23 '18 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.