Skip to content
This repository has been archived by the owner on May 25, 2019. It is now read-only.

Dynamic Gas Rewards #4

Open
austintgriffith opened this issue Sep 14, 2018 · 6 comments
Open

Dynamic Gas Rewards #4

austintgriffith opened this issue Sep 14, 2018 · 6 comments

Comments

@austintgriffith
Copy link
Collaborator

Challenge

As gas prices change and rewards remain constant it will be hard to balance the crypto-economics of incentivizing relayers to submit meta transactions.

Possible solutions

Detect Gas Used

Can we detect the amount of gas used for the full transaction on-chain and let the publisher pay this back exactly up to some limit?

Gas Price Oracles

Oracles could provide gas informations and reward according to current gas prices.
(this is my least favorite option)

Dynamic Gas Token

Could a token be pinned to gas prices and used to pay the relayer back just the right amount to make it worth it to them to submit. Could a GasToken.io be unwrapped on-chain to pay for it?

  • disclaimer: There are a lot smarter people in the space so this will change quickly as better solutions arise. Just wanted to get a dialog going. I bet @avsa or Gnosis or uPort already have this solved.
@pet3r-pan
Copy link
Member

pet3r-pan commented Sep 15, 2018

Just fleshing out this problem...

A service node (SN) is rewarded X amount of tokens to execute an meta-tx with a gas cost of Y.

X reward > Y cost ~ At the very least for SNs to be incentivised to execute the transaction. This may be measured in fiat $ value or the utility in respective to the individual/org running the SN (as it is all dependant on the perception of what is more valuable).

We can potentially assume that the SN will always price the reward of their service to an amount that outweighs the cost of gas. As cost of gas fluctuates, absolute cost of reward will change along with it.

@pet3r-pan
Copy link
Member

Relevant video from Chronologic that talks about how to price the execution of the meta-txs: https://www.youtube.com/watch?v=jf64HVgrh6I

FIXED GAS PRICE Set by the scheduler at the time of scheduling

• Pros • Simple • Protects from TimeNode withholding • Cons • Fails on spikes • Gas price guessing

RANGE GAS PRICE Minimum and maximum gas price.

• Pros • Incentivizes TimeNodes to pick correct price within bounds • Protects from TimeNode withholding • Cons • Given the front-running, the equilibrium is max • Requires a decently high max in order to cover the spikes

MINIMUM (FLOATING) GAS PRICE Minimum gas price is set, higher prices covered by the TimeNode.

• Pros • Allows the TimeNode to decide where the equilibrium is • Protects from TimeNode withholding • Cons • Covers spikes up to minimum reimbursement + reward

@pet3r-pan
Copy link
Member

@jamesray1
Copy link

jamesray1 commented Oct 12, 2018

I have been discussing this issue with Pocket Network.

You want the payout to ideally equal or approximate as close as possible the true utility provided as per mechanism design. This is hard to do with a volatile token or gas price, and the solutions proposed here look suboptimal. If the token or gas price is stable, like a stable coin like DAI or HAVVEN. (I think I prefer the latter model where a token is issued against a distributed pool of assets, rather than using on-chain governance and collaterilized loans), you can have a relatively stable reward.) (Note that a stable coin can still fluctuate in value, e.g. DAI and HAVVEN are pegged to USD, which is still volatile, just a lot less than volatile cryptocurrencies. The more widely the pool of assets is that the token is issued against, the better the diversification and Sharpe ratio of the pool/token.)

Pegging a token to the gas price also in particular seems to warrant further investigation, but you will need to use an oracle like Etherscan and probably use the median gas price, given that at any instant you could have very high gas price transactions and very low ones and everything in between. Implementing a decentralized oracle then becomes important. And using a gas token like with gastoken.io to arbitrage the price by creating junk transactions to fill and unfill storage is not an ideal solution for storage pricing economics, but it is probably better than the status quo.

@jamesray1
Copy link

@jamesray1
Copy link

And also:

https://research.pokt.network/t/using-price-oracles-to-set-the-stake-per-relay-rate/35/9?u=jray

As has been recognized, there are risks of manipulation with oracles, whether centralized or decentralized (obviously with the former it is extremely hard / impractical to avoid manipulation). If you censor/omit data, then you can manipulate the price. So any kind of decentralized oracle (as would be the case here) either needs to be extremely carefully designed and thoroughly tested for security and anti-manipulation proofness, or not use a decentralized oracle at all!

Further reading on oracles are e.g. here (I just read the first three threads):

https://ethresear.ch/search?q=decentralized%20oracle

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants