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

Home

Jump to bottom
Pet3rpan edited this page Nov 2, 2018 · 2 revisions

Research

Current focus: Understanding the implications of EIP859 (currently in-progress with S1na) https://github.com/ethereum/EIPs/issues/859

  • What are the implications of 859 on the development of the relayer network?
  • Can Ethereum fullnodes be used for a relay service?
  • Assuming 859 solves the collision problem, can we push it foward? actually implement it ourselves? Engineering trade between the time we solve the reseaarch problem vs. implementation of ETH 2.0

Research problems

Technical requirements documentation

What outcome do we want this network to have? Technical specifications (as well as product requirements from teams) ~ + What behaviours are needed for this to exist between a p2p network of nodes? What behaviours and actions do we want to incentivise, what do we need to penalise?

Node execution collision

Part of the network incentivisation problem. How do we fairly propagate rewards of executing meta-txs to the whole network? (Further work needs to be done on identifying the various aspects of p2p node behaviour that needs to be incentivised as well as penalised).

Relayer collision problem: https://github.com/Meta-tx/Harbour-MVP/issues/3 Source of randomness: https://github.com/Meta-tx/Harbour-MVP/issues/13 Round robin staking design: https://github.com/Meta-tx/Harbour-MVP/issues/14

Conditional execution

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.

Conditional execution: https://github.com/Meta-tx/Harbour-MVP/issues/11

  • Karl F. Suggested we read the truebit paper

Relayer rewards

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

  • 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?

  • Oracles could provide gas informations and reward according to current gas prices.

  • 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.

Clone this wiki locally