metacartel / Harbour-MVP

Building a decentralised p2p meta-tx relayer network [MVP] Codename: Harbour ## We solved this problem: https://medium.com/tabookey/1-800-ethereum-gas-stations-network-for-toll-free-transactions-4bbfc03a0a56
https://medium.com/tabookey/1-800-ethereum-gas-stations-network-for-toll-free-transactions-4bbfc03a0a56
MIT License
30 stars 15 forks source link

Clearer goals - Meta Tx Standard vs Relayer Network #22

Open ptrwtts opened 6 years ago

ptrwtts commented 6 years ago

This effort seems to encompass a few different goals. For the sake of clarity, and making progress, we should try to parse them out, and clearly define them. Here's a quick stab:

Goal 1 - Meta Tx Standard

Create a standard for meta transactions and relayers, so that any relayer can submit meta transactions from any dapp. This way, you decouple the two roles, so that not every dapp needs to run their own relayer, and a single relayer can serve many dapps.

The experience should be similar to choosing your Node to submit a regular Ethereum transaction, where you can easily switch between Infura, Etherscan, your own node, etc, and they all accept the same format.

Goal 2 - Relayer Network

A decentralized network of relayers, so that dapps do not need to explicitly choose relayers to rely on, and the load (and rewards) of relaying can be spread across many parties. This requires finding solutions to issues like collisions.

Other Goals

On the call, some other topics came up that may or may not be under the scope of this effort. For example, the idea of relayers also passing multi-sig messages between each other, and potentially sharing rewards. Let's discuss if these are included in the scope, or just related.

pet3r-pan commented 6 years ago

These two tracks are defined here! https://medium.com/@pet3rpan/harbour-mvp-update-1-35ddbbb9e288

s1na commented 6 years ago

Re Goal 1:

The roles could potentially be extended to: dapp, relay network, identity proxy. Dapps then wouldn't necessarily need to implement their own identity proxy and could use existing solutions. However, the roles could ofc be merged when for example the dapp offers their own identity solution.

The process would then look something like: Based on user's identity proxy, dapp crafts meta tx, and prompts for signature. Meta tx is sent to some relayers, who submit the tx to the specified identity proxy.

I could then for example, use my existing identity proxy in which I have ether, in a new dapp (not ideal for privacy, the user should know what they're doing in this case).