More info to be added....

Hey everyone,

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.

We require an icon to indicate the implementation of meta-txs and universal login solutions.

Similar to walletconnect's logo https://walletconnect.org/

Hey everyone, this is a challenge we were exploring with @Perseverance for one of the possible solutions (read more about the general solution here) for the collision problem. Would love to hear whether you think something like this could work, or a more complex PRNG is required.

Introduction

One of the directions under consideration for the collision problem is to have relayers register on-chain, put a stake, and have the protocol randomly select a relayer every epoch to submit a batch of meta txes to a smart contract. Selecting a relayer on-chain requires a source of randomness that can't be predicted ahead of time or manipulated in a way to increase a relayer's chance of getting selected.

Problem Statement

Given a list of relayers R = [R_1, R_2, ..., R_n], and function isTurnOf(R_i) which returns true if R_i can produce a block during this block (B), we'd like to discuss employing the parent's block hash (P_h) as a source of entropy in isTurnOf, e.g. by checking if R[uint256(P_h) % n] == R_i. Using P_h is usually not a good practice, due to the following reasons:

1. Miners could withhold a block, if the block hash is disadvantageous for them.
2. During B, P_h is known, and therefore, users (and specially miners) can make transactions to influence the decision in isTurnOf.

Discussion

In the case of selecting a relayer:

1. The reward a miner would forego by withholding a block, is probably significantly than the reward of a batch of meta txes (also depends on the number of meta txes in a batch).

2. In the simple isTurnOf mentioned above, if R is mutable, the miner could create the transactions and add them to the beginning of the block to influence the decision (if it's their turn to propose block). This might seem like a very unlikely case to assume such collaboration between a relayer and a miner, but, I think a considerable percent of relayers could also be miners (as miners are running a full node anyway and the marginal cost of running a relayer is low).

Possible Improvements

Two general approaches could help with problem 2.:

• Fix R, for at least one block before B, e.g. if a new relayer calls register, or an existing relayer calls withdraw, they are put on a queue, that is processed the next block.
• Modify isTurnOf to make it unpredictable for everyone but the relayer who should submit batch now. For example, have each relayer commit to a random value (e.g. keccak256(S)) on register, and on every execTransactions, and pass that to isTurnOf(R_i, S). This limits miners to only knowing whether it's their turn this block or not, so it becomes harder for them to influence the decision by front-running. However, because nobody but the relayer knows whose turn it is, it becomes hard to punish relayers for not submitting blocks, if this is required by the protocol.

Extension

The simple protocol outlined above can be further extended in various ways. One particular extension, is to select a shuffled subset of R (D for dynasty) every M=32 blocks, in which, isTurnOf(D_i) == true in block B_i where 0 <= i < M.

As mentioned in #23, the research being done on account abstraction could be quite relevant to meta transactions. This issue tracks the resources on the topic. Please feel free to add stuff :)

Roughly in chronological order:

• EIP-86
• Tradeoffs in Account Abstraction Proposals
• EIP-859
• A recap of where we are at on account abstraction
• Account Abstraction Radically Simplified

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.

This may be controversial, but is it possible to have regular Ethereum miners act as the relayers? All that should be required is updating popular clients (Parity, Geth, etc) to understand meta transactions, and take the rewards into account when deciding which transactions to include in a block (ie which give them the most rewards). The gas price would technically be zero, but they include it because they will get paid once it's mined.

You probably don't even need to get all clients on board. As long as at least one client does it, then meta transactions would get processed as soon as a block is produced by a miner using that client. But obviously for the sake of getting transactions processed quickly, you would want wide adoption.

Am I missing something?

One of the differences I have seen among projects is how they transmit the signature of the meta tx, with some sending v, r, s fields separately, and some using an encoded version.

What are the arguments for each? For an encoded signature, which EIP does it adhere to (EIP-191 or EIP-712)?

// Just adding in notes from our community call. Will need to split these up into more defined discussions / topics with proper context & documentation.

Initial list of detected problems & topics to discuss

• Glossary (relayer vs gasProvider)
• standard of
  • the signature
  • contract interfaces / execute function
  • calls & messages (what are the different calls / messages used, common, differences -> specifics, down to the granular details)
    • sending tokens ( mentioned by Mark Pereira > is this part or not of the calls & messages?)
• signaling & collision
• cryptoeconomic mechanisms
  • to ensure execution
  • to avoid collisions
• sybill attacks (3 kinds)
• increased cost (gas + fee)
  (possible solution Dapp based relayers who waive the cost)
• signaling accepted Tokens (single relayer or relayer-network wide)

Introduction

The goal of this issue is to be a facilitator of the conversation over securing the relayer network. It will outline an approach proposed by me and @s1na and hopefully we can improve it.

Problem statement

An attacker can drain the capital ETH of the relayers in the relayers network by submitting one transaction to be relayed to multiple relayers.

An example of such attack would be, malicious attacker sending one and the same request for relayed execution of a transaction to multiple relayers. Normally all relayers will check the execution of this transaction and decide that this transaction will legitimately go through successfully.
However, only one of the relayers will successfully execute this relayed transaction, due to the nature of the blockchain and anti replay attack mechanisms, the other relayers will lose ETH due to the reverting of the already executed transaction.

Discussion

General overview

By nature, this problem is a synchronisation problem. In general, if all the relayers in the network are synchronised, they will be able to tell who is processing which transaction. Such synchronisation, in real time would be exponentially harder with each new relayer.
Approaching this problem from another angle we've reached the conclusion that this problem can be solved through ordering.

Ordering

Another way to solve the problem is to remove the chaos of every relayer executing transactions all the time. Instead we can allow for one relayer to relay transactions per block(The proposed mechanism of finding the relayer allowed to relay will be found in the following Proposed Solution section). This requires some additional capabilities of the relayers in addition to the plain relaying:

Gossiping received transactions

In order for the network to work as fast as possible, the relayers would need to gossip each other the relayed transactions they receive from the dapps. This will allow for the relayer of the next transactions to include these transactions in the next block ensuring high responsiveness.

Maintaining list of transactions to be executed

All relayers will need to be able to maintain list of transactions to include in the next block. In addition the relayers would need to watch for submitted relayed transactions, in order to guard against resubmitting transactions.

Proposed solution

The proposed solution is based on pseudo-random round robin way of choosing the next relayer. Randomness of the round robin will be ensured by the block-hash of the previous block. Although this can still be manipulated, it becomes very impractical for a miner to collude with relayer as the economical incentive of producing a block would generally much higher than the economical incentive of relaying transactions. Read more here #13.

In addition a staking smart contract needs to be created. This smart contract will have several important functions. Firstly, it will allow for relayers to register as such, via placing a stake. Secondly, this contract is going to be the verifier of which relayer is the current eligible relayer. The identity smart contracts would need to additionally poll this contract verifying the current msg.sender against the eligible relayer.

Possible improvements

There is a need to figure out a way to punish dishonest relayers that are withholding transactions (not gossiping) until it's their time to submit into a block.

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.

Hey everyone,

Note: I didn't know any other place to put this to discussion. If it doesn't belong in this repository please let me know and I'll delete it. The goal is to discuss some of the proposed solutions, put forth new ideas, etc.

Challenge

When a user publishes a meta transaction to a decentralized relay network, there'll be a competition among the relayers to submit the transaction first, and thus get the reward. As only the first submitter gets a reward, everyone else's transaction reverts and they lose gas, and this inefficiency would cause the relayers to demand a higher price.

Possible solutions

Stake by users and relayers

• User publishes intent for a meta transaction to a pubsub channel
• Relayers would respond that they're interested in submitting this tx to network
• User acknowledges the request of one relayer, who in turn submits the tx and is rewarded
• To prevent relayers from showing interest, but not submitting the tx, they put a stake, that would be slashed in case of misbehaviour (not submitting within a time frame).
• To prevent users from acknowledging the request of multiple relayers, the user is also required to put a stake.

Considerations
There are however some edge cases to consider in this approach. For example, how to require a newly registered user to put a stake, and doesn't that affect UX? Can the user grief relayers by responding late so the relayers don't have enough time to submit the tx? Can user be caught when doing this? Generally, it seems to me somewhat difficult to distinguish between malicious act and network delays.

PoW

• User publishes meta transaction to a pubsub channel.
• Relayers try to solve a PoW challenge, and the first one who solves the challenge gets to submit the transaction. This acts as a kind of rate-control mechanism.

Considerations
This approach would probably need a dynamic PoW difficulty. Cost of energy needs to be factored in, which results in relayers asking a higher price. Requires on-chain validation of the proof, which means it requires modifications to the existing identity proxies.

Simplified PoS

Relayers register as such on-chain, and a psuedo-random number generator selects a relayer or a committee of relayers to submit transactions in a timeframe. I'm still doing research on this.

What are the other standards that we need to be aware of?

From our discussion, we mentioned identity standards, ERC191 etc.

If you are reading this and somehow is a graphic designer, please please help us make a logo. We are in dire strife.

Tenzorum's definitions

Meta-tx (Meta transaction): Tx with additional meta data fields eg. reward details

Relay: Act of sending meta-tx away to offchain 2nd layer / service node

Relayer: The user / dapp that is sending the tx away to the 2nd layer service node

Delegation: The act of relaying a meta-tx and relaying the reponsibility of executing the tx to a third party

Delegated-tx (Delegated transaction): Meta-tx that has been relayed to a service node to be executed

Service node: A server that recieves meta-txs and executes valid meta-txs

Tx-pool: Pending layer of meta-txs that are ready to be executed

Gasless transaction: And event that happens from the user's point of view