# The Big Picture
# What is the relationship between the GSN and ERC-4337 projects?
We believe that the GSN has by now successfully solved the meta-transactions and gas abstraction problems in the Ethereum ecosystem, taking it from hackathon ideas to a public infrastructure project with many years of production experience and track record.
Our team has applied this experience to solve some of the most challenging problems in Ethereum, including but not limited to Account Abstraction, Gas Abstraction, Signature Aggregation, Transaction Batching, Transaction Scheduling and MEV Adoption. All this work is coming together under the ERC-4337 (https://eips.ethereum.org/EIPS/eip-4337). You can read the documentation (https://eip4337.com/en/latest/), read some blog posts here(https://hackmd.io/@erc4337/) or see the code for yourself (https://github.com/eth-infinitism/account-abstraction/).
It is important to note that the GSN library is intended for dapp developers who want to sponsor transactions for existing Ethereum users here and now. It works with existing wallets like MetaMask and existing Externally Owned Accounts (EOAs) and allows them to make gasless decentralized meta-transactions.
ERC-4337, on the other hand, cannot support existing accounts. It's intended for "Smart Wallets" developers who will create new accounts for their users. ERC-4337 will require users to install ERC-4337 compatible wallets and use compatible dapps to take advantage of gasless features via the ERC-4337 Paymaster contracts.
ERC-4337 will supersede GSN once Ethereum deprecates EOAs completely, which is not currently on the horizon.
# Should dapp developers run their own relay server?
Running a relay server is highly recommended for most use cases. It will usually save money for dapps to run their own relays and configure them as the "preferred relay" for their clients. This way they can avoid having to pay an extra transaction fee to a third party.
Only in case the dapp's preferred relay server is unavailable, the clients will seamlessly fallback to another relayer in the network. This protects against network failures and denial of service attacks.
If a preferred relayer is not configured, all transactions will be routed through third party relay servers for an extra fee.
# Who pays for gas?
Ethereum always requires gas as payment for transactions, but when using GSN, who pays for the gas is abstracted away and replaced with arbitrary programmable logic.
Every transaction going through GSN must specify the address of a specific paymaster contract. This contract is programmed to decide under which conditions it is willing to accept a transaction and refund relay servers for gas on its behalf.
A paymaster can implement arbitrary acceptance policies. For example, one type of paymaster could be programmed to allow users to pay for gas in any token that can be exchanged for ETH. Another example would be a paymaster that accepts transactions on behalf of paying dapp subscribers.
For the use case of minimizing onboarding friction, dapp developers can roll gas costs into the cost of user acquisition by deploying a paymaster contract that subsidizes gas for transactions that invoke contract methods required to onboard new users.
More advanced use cases include ETH-less withdrawals of token deposits to stealth addresses and zk mixers, and even counterfactual smart wallet contracts paying for their own deployment in fiat or a stablecoin. The sky is the limit.
# Do dapps have to pay for their user's gas?
No, though that is an option. Dapp development can choose from basic predefined
payment strategies or construct their own. The Paymaster contract provides
for pre and post-payment hooks that can be used to verify that a contract
function and user are eligible for the transaction cost to be covered by a
relay server as well as allow users to pay relays in tokens rather than ETH.
When deciding how many payments and for how much to cover, dapp developers should consider what they expect the total cost of payment to be, and how they will identify who are their users. It is up to dapp developers to decide how they will identify who is an eligible user.
# Where is the private key?
While relay servers pay the gas cost for transactions, this does not mean they have access to user's private keys. The user's client uses its wallet private key to sign the request it sends the relayer. User private keys are never shared or exposed to any entity, neither relay servers nor on-chain contracts.
# How secure is GSN?
The GSN network and smart contracts have been audited and are considered to be safe.
The GSN Protocol (opens new window) lists several theoretical attacks against the relay network and paymasters which have been accounted for by the software implementation.
# How does a contract know who the user is?
The ERC2771Recipient contract has a utility function called _msgSender()
which returns the true address of the user making a contract call. The function
_msgSender() should be used in place of the solidity system variable
msg.sender.
The GSN network is built to be compatible with the Ethereum network in its
present state. This means that for relayed transactions, msg.sender will
return the address of the relay server signing the transaction, and not the
user requesting the transaction. Contracts that use msg.sender are not
natively compatible with the Gas Station network. It is necessary to use the
_msgSender() function from the ERC2771Recipient contract in the OpenGSN
library if your contract needs to identify the
initiator of a GSN powered transaction.
# Why are ETH deposits in RelayHub required?
Like the underlying blockchain it supports, the GSN is a trust-minimized decentralized system that does not require participants to know or trust each other. Instead their interactions are mediated by RelayHub, an audited on-chain contract.
To deter abuse, relay servers must stake in the RelayHub while Paymasters
deposit a balance. That way relay servers don't have to trust the paymaster
contracts they serve and vice versa.
The balance deposited by Paymasters is used to refund relayers for the cost
of relaying transactions plus an extra incentivization fee.
Relay providers are required to put a stake into the RelayHub to ensure good
behavior. In the event a relayer behaves badly (for example attempting to reuse
a nonce) their stake can be slashed and collected by other relayers by proving
on-chain the relayers bad behavior. This system of checks and balances is one
of the features that keep the GSN safe and ensures that some forms of attacks
against the network do not scale.
# Does my Paymaster contract need to hold ETH directly?
No. The funds which are used by a Paymaster contract to pay for a user's gas
costs are stored in the audited RelayHub contract. This contract is already
deployed on every network (testnet, mainnet, etc..) and does not
need to be managed by dapp developers.
Paymaster owners need to ensure that the balance stored on RelayHub is sufficient to cover the cost of transactions. If there is not a sufficient balance to cover the cost of relaying transactions, no transactions will be processed until the balance is increased.
# Does GSN work with other web3 providers?
GSN can work with any rpc provider - either injected (e.g. metamask) or web-based libraries (like Portis)