Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Make smart contracts (e.g. dapps) accessible to non-ether users by allowing contracts to accept "collect-calls", paying for incoming calls.
Communicating with dapps currently requires paying ETH for gas, which limits dapp adoption to ether users.
The gas stations network is an EIP-1077 compliant effort to solve the problem by creating an incentive for nodes to run gas stations, where gasless transactions can be "fueled up".
The network consists of a single public contract trusted by all participating dapp contracts, and a decentralized network of relay nodes (gas stations) incentivized to listen on non-ether interfaces such as web or whisper,
The system consists of a
Roles of the
Roles of a
Glossary of terms used in the processes below:
The process of registering/refreshing a
The process of sending a relayed transaction:
The process of winding a
Removal of stale/invalid relays:
The rationale for the gas stations network design is a combination of two sets of requirements: Easy adoption, and robustness.
For easy adoption, the design goals are:
The robustness requirement translates to decentralization and attack resistance. The gas stations network is decentralized, and we have to assume that any entity may attack other entities in the system.
Specifically we've considered the following types of attacks:
Attacks and mitigations
Attack: Relay attempts to censor a transaction by not signing it, or otherwise ignoring a user request.
Relay is expected to return the signed transaction to the sender, immediately.
Therefore, the maximal damage a relay can cause with such attack, is a one-time delay of a couple of seconds. After a while, senders will avoid it altogether.
Attack: Relay attempts to censor a transaction by signing it, returning it to the sender, but never putting it on the blockchain.
This attack will backfire and not censor the transaction.
Attack: Relay attempts to censor a transaction by signing it, but publishing a different transaction with the same nonce.
Reusing the nonce is the only DoS performed by a Relay, that cannot be detected within a couple of seconds during the http request.
Sender has a signed transaction from Relay with nonce N, and also gets a mined transaction from the blockchain with nonce N, also signed by Relay.
The result of such attack is a delay of a few blocks in sending the transaction (until the attack is detected) but the relay gets removed and loses its entire stake.
Attack: Dapp attempts to burn relays funds by implementing an inconsistent may_relay() and using multiple sender addresses to generate expensive transactions, thus performing a DoS attack on relays and reducing their profitability.
In this attack, a contract sets an inconsistent may_relay (e.g. return true for even blocks, false for odd blocks), and uses it to exhaust relay resources through unpaid transactions.
Relays may also look at recipients' history on the blockchain, looking for past unpaid transactions (reverted by RelayHub without pay), and denying service to contracts with a high failure rate.
This attack doesn't scale because the cost of creating a malicious contract is in the same order of magnitude as the damage it can cause to the network.
The attack can be made even more impractical by setting RelayHub to require a stake from dapps before they can be served, and enforcing an unstaking delay,
Attack: User attempts to rob dapps by registering its own relay and sending expensive transactions to dapps.
If a malicious sender repeatedly abuses a recipient by sending meaningless/reverted transactions and causing the recipient to pay a relay for nothing,
A simple method that mitigates such Sybil attack, is that the dapp lets users buy credit with a credit card, and credit their account in the dapp contract,
A variation of this method, for free dapps (that don't charge the user, and prefer to pay for their users transactions) is to require a captcha during user creation in their web interface,
Attack: Attacker attempts to reduce network availability by registering many unreliable relays.
Registering a relay requires placing a stake in RelayHub, and the stake can only be withdrawn after the relay is unregistered and a long cooldown period has passed, e.g. a month.
Each unreliable relay can only cause a couple of seconds delay to senders, once, and then it gets blacklisted by them, as described in the first attack above.
Attack: Relay attempts to unregister other relays.
Removal of stale relays is trustless. RelayHub verifies whether the removed relay has performed any action recently, and would revert any transaction that tries to remove an active relay.
Attack: Attacker attempts to replay a relayed transaction.
Transactions include a nonce. RelayHub maintains a nonce (counter) for each sender. Transactions with bad nonces get reverted by RelayHub. Each transaction can only be relayed once.
The gas stations network is implemented as smart contracts and external entities, and does not require any network changes.
Dapps adding gas station network support remain backwards compatible with their existing apps/users. The added methods apply on top of the existing ones, so no changes are required for existing apps.
A working implementation of the gas stations network is being developed by TabooKey and will be released for public benefit soon. It consists of
Copyright and related rights waived via CC0.
from reddit, comment of @vbuterin https://www.reddit.com/r/ethereum/comments/cmrqsl/gsn_gas_station_network_the_ultimate_ethereum/ew5rold/
IMO we do just need to bite the bullet and accept that using many kinds of dapps is a some-setup-required proposition.
We designed GSN to be used in different ways, not necessarily paying for CAC.
Consider, for example, the case where users own and use an ERC-20 token, but don't have ETH. Maybe they paid Fiat for a service, and it minted an ERC-20 token. Or maybe they were airdropped the token as a limited form of CAC.
In this use-case, a malicious user can only burn his own funds, not the company's (or the DAO's). The user acquires tokens. The contract then accepts GSN calls and compensates relays, only for users that have sufficient token balance. At the end of the transaction, the contract gets the actual cost of the transaction and charges the user for it, in tokens.
At no time, could the user burn company money. The user can generate transactions as long as the token balance is sufficient. Once the balance is too low, the contract's view function, acceptRelayedCall(), starts rejecting transactions. Relays will know they're not getting paid, so they won't relay the transactions.
Another use-case that came up at ethereum-magicians, is mixers. Consider a mixer, where a user wishes to withdraw his mixed ETH from a new address. The mixer accepts and pays for GSN transactions, only of they include a proof of ownership of enough funds to pay for the transaction. The mixer then charges the user for whatever the GSN transaction cost was, then sends the rest of the funds to the new address. The mixer doesn't take any risk here. It always gets reimbursed during withdrawal.
That would keep Ethereum confined to a relatively small group of users, determined enough to jump through the hoops. GSN is about making Ethereum as large as the Web, by making onboarding as easy as the Web.
@vbuterin , I think we briefly talked about it, back in Cape Town, regarding financial inclusion. Consider the dapp built at the ETHCapeTown hackathon, that implemented a land registrar for South African townships. They need such dapp since the state's registrar not really functional for them, but most township residents don't have a bank account, cannot pass KYC of any exchange, so they have no practical way to acquire ETH and use Ethereum. GSN would be their gateway to Ethereum. We can't expect them to go through a setup process that involves the international banking system.
In this land registrar use-case, the contract is a DAO and there's no company. First-time users would have to get "gas tokens" from someone in their community who already has them and probably exchanges them with Rand cash, creating an allowance for the new user to register or transfer a house. There's no risk for the DAO, as the user pre-paid someone for the gas (or at least someone in the community has vouched for them). The initial "gas tokens" would be minted by investors who do have a bank account and a way to acquire ETH, so they deposit it for the contract's GSN allowance in exchange for gas tokens, which they can sell to local users for cash, at some profit. Investors have no risk, since gas is always paid upfront, cash.
I can describe more models we've encountered when discussing GSN with the community, but you probably get the picture. GSN is about much more than just CAC. It's a way to bring everyone on board.