If you are a developer or a network user, you have probably already encountered the issue of stuck transactions. It could be described as an endless waiting for processing.

Including a transaction in a block can give a headache. As the blocks’ size is limited, miners will prioritize transactions with the highest gas price.

How do we end up in this situation, and why, by a chain reaction, does this obstruct every new transaction sent with the same account? What can a transaction relayer bring to prevent that? 

Quick reminder: transactions on Ethereum are scheduled by a number associated with the transaction called a "nonce". Each account on the chain has a "nonce" which is incremented with each transaction. Thus, the first transaction done by an account will have the nonce 1, and the third will have the nonce 3.

Transactions must be executed in the right order of nonces: the third transaction made by an account cannot be included in a block and executed before the second transaction. 

If several accounts compete to execute their transaction as soon as possible, the gas price will suddenly increase. Imagine a scenario where an account has submitted a transaction with a gas price too low, the transaction will then be stuck by the inflow of more profitable transactions for minors.

To get out of this situation within a reasonable time, you must either cancel or replace the stuck transaction with a new one using the same nonce and a higher gas price. The operation must be repeated while increasing the gas price until the transaction is included in a block.

Finally, except if you can force a sequential use of the account (which is impossible if the transactions are issued from a user's wallet for example), you will have to manage all the pending transactions of the account with a gas price potentially decorrelated from the new market price. 

Made famous by Cryptokitty and the ICOs, this challenge has now to be faced by the decentralized finance protocols. Fortunately, these problems remain occasional on Ethereum.

On the user side, the frustration is similar to what you feel when a payment does not work on an e-commerce website. On the application side, in addition to the support it generates, this generally results in a loss of income.

Users and developers have inherited an inextricable problem on Ethereum 1.x. This probably contributed to tarnishing the image of the protocol. It also showed that the community can gather to propose improvements,  such as the use of meta-transactions.

Photo by Brett Jordan on Unsplash

The meta-transaction concept allows users to interact with the blockchain with only a pair of public/private keys.

On the user side, sending a meta-transaction is similar to sending a standard transaction (from, to, value ... and signature) except that instead of sending it directly to the Blockchain, it sends the meta-transaction to a third party who will take care of the gas.

This third party builds a new transaction that contains the meta-transaction and sends it to a smart contract proxy (it can also be a proxy function in a contract).

The contract checks the validity of the meta-transaction (thanks to its signature) before executing it.

This mechanism is more and more used by applications to improve users’ onboarding. It allows them to sponsor the gas for their users while keeping the benefits of a decentralized system (non-corruptibility, non-repudiation, etc.).

You might wonder: if the application can relay the transactions by itself for its users, when and why do we need a relayer?

The dilemma between “do it yourself” or “buy a solution” is well known to developers and the answer always depends on the context.

Well as it is the case for food delivery, build and maintain relay infrastructures is very complex and costly. Indeed, more and more applications choose to integrate APIs to relay their transactions instead of doing everything by themselves. 

To keep its promise, and in addition to improving the path of transactions in the blockchain, relayers can facilitate the implementation of gasless transactions.

As explained above, for a given account, transactions must be ordered and validated sequentially. For example, if you want to send 3 transactions, transaction #3 will remain pending until number 1 and number 2 have been processed. The number of pending transactions for an account is limited by the node (on Geth, the default limit is 64 for instance). Beyond this limit, the node can arbitrarily delete transactions from its queue.

To avoid these limitations, a relayer can dispatch its meta-transactions and send them from multiple accounts. Indeed, if you have three accounts, the number of transactions that can be pending on a node goes from 64 to 192 when using Geth. In addition, when a transaction is stuck on one of the accounts, the relayer can displace it to one of the two remaining accounts and thus keep sending its transactions.

Another thing to consider is the nonce system used by the relayer smart contract. The nonce system is used to avoid a replay attack. The chosen nonce system solution will impact the way transactions are processed. For instance, if you wish to anchor certificates, you want to be able to send a large number of transactions simultaneously and the order doesn’t matter. 

Indeed, some applications might require to send transactions sequentially and others simultaneously. Depending on the usage, and the volume of transactions, some cases might require to optimize the cost of storing a replay attack protection system, where others might not need such complex implementations. Relayers allow developers to get rid of these complex issues by providing simple and ready-to-use services.

It is necessary to have Ether on your account if you want to change a smart contract or send a transaction or do anything on Ethereum. This makes user onboarding and user experience painful. There is no way to have a high conversion rate when the users have to buy Ether before being able to use the application. 

To overcome that, some applications simply offer to pay gas on behalf of their users. This approach is often disregarded by developers as it is far from the philosophy of the protocol, which aims to guarantee independence in the network. In such a traditional model, the application considers gas as an infrastructure cost, just like CPU consumption on AWS for instance. Since income generation is generally correlated to the use of smart contracts, it is an economically viable model in most cases.

The application and the users might also agree with each other on-chain for an automatic reimbursement of gas costs implied. With the emergence of DeFi's services, more and more users own tokens without Ether. And some systems allow their users to pay for their transactions with an ERC20 token.

The application can also distribute its own tokens to its users at the time of registration. This mechanism is comparable to the distribution of free coupons that can only be used on application contracts.

A relayer will help to put in place the right gas reimbursement strategy without requiring heavy investments in research and development.

Ideally, all of these services should work transparently for the developer, that is to say without modifying their smart contracts or the code of their application.

Relay services are usually exposed via a classic web API. They can also be available as a proxy in front of a "web3 provider" between the application and the node to facilitate their use with libraries like web3js.

Finally, the design of the solution must allow its users to verify that the relayer can neither replay, nor modify the meta-transaction data.

Actually, the relayer function is quite similar to a node waitlist, but it adds several essential features for live applications on the Mainnet. 

Photo by Daniel Jensen on Unsplash

Decentralization, privacy, security, simplicity, etc. Choosing how to relay a transaction on Ethereum implies taking into account a lot of criteria and again, depending on the context, different choices have to be made. 

GSN (Gas Station Network) is one of the most visible initiatives in this area. This solution allowed the construction of a network of decentralized relayers. When using a relayer hub, the players that are ready to process transactions for a commission can compete against one another. GSN requires significant integration efforts. It is a very suitable solution when the use of a P2P relay network is a prerequisite. 

To understand why there is no consensus around a standard, let's compare two wallets: MetaMask and Argent.xyz. The first manages the identity of its users with an EOA, while the second uses smart contracts. 

Naively implementing a “relay proxy” on transactions sent from MetaMask is more complex than what it looks like. The use of msg.sender in the contracts used by the application would be banned because it would contain the address of the relayer instead of the user’s public address. 

On the other hand, Argent.xyz uses an account contract that must be deployed for each user. This is an additional cost for Argent.xyz but the verification and relay of transactions are done directly in this contract, without the need for any modification on the destination contracts. 

Application contracts can also directly verify and execute the signature of meta-transactions by implementing two functions. One to protect against replay attacks and the other to verify and execute the transaction. This solution has many advantages but remains unusable for already deployed contracts. 

To go further on the different relay philosophies on Ethereum, @wighawag recently proposed the idea of a “Minimal And Extensible Meta Transaction Forwarder” # 2585. This EIP shows how huge this topic is and how much the debate is active in the community.

Applications that require large transaction volumes systematically pay way too expensive network commissions. And this extra cost does not prevent them from having to intervene when a transaction is stuck. For smaller and under construction applications, building and maintaining a relay infrastructure requires too much investment. PSPs (Payment Service Providers) like Paypal or Stripe have made it easier for developers to accept payments on the Internet. And even if Ethereum allows you to remove or limit the power of third parties, this protocol must acquire gateways to simplify its usage. The power of relayers is limited “by design” by meta-transactions, thus they perfectly meet the current challenges of developers on Ethereum.

At Rockside.io, we decided eight months ago to build the best relayer on Ethereum. We already process hundreds of transactions daily for startups and large accounts and thus we know that the need is real among developers. The increasing use of relayers also shows that the relationship between companies and the blockchain is evolving. We have moved from a desire to understand to a desire to actually use the technology.