TL; DR: In this article, I introduce the concept of GasToken Factories. When storage variables are deleted from the blockchain, the sender of the transaction receives a gas refund (or negative gas) which can substantially reduce the cost of a transaction. A GasToken Factory is a smart contract that allows third parties to delete some of its storage variables in exchange for receiving the gas refund. One example could be token sale contracts, which become useless after the sale is over, yet contain a lot of data. Using an example below, a token sale contract with 10,000 buyers which implements GasToken Factory methods could have an additional revenue of 5–10 ETH or have 290,000,000 gas units available for future transactions. With the Ethereum Name Service (ENS), there is currently ~567 ETH worth of available gas that could’ve been sold or donated. This is not only good for the contract’s owners, but also for those able to obtain cheaper (or free) gas and for the rest of the network since data is deleted from the chain.

Ethereum Blockchain Size

Over the last year, we have seen the size of the Ethereum blockchain increase substantially thanks to growing adoption. Many articles were written on the topic (e.g. this by Afri Schoedon, this by StopAndDecrypt and a response by Gustav Simonsson) either stating that the Ethereum blockchain is growing too quickly or that there is no reason to be concerned because of pruning and other tricks clients can use. There are also significant changes to the base protocol that could greatly reduce the bloating of the main chain, such as sharding and rent fees, however these will take a few years before being ready. Of course, doing things on-chain is not the only way and approaches like state channels, Plasma and child/side chains can take us a long way (see this great post by Josh Stark on layer 2 solutions). In this article, I want to present another approach inspired by the work of Lorenz Breidenbac, Phil Daian and Florian Tramèr on GasToken. I call it GasToken Factory and I will use a token sale contract as an example. GasToken Factory methods allow Ethereum smart contracts to give/sell available gas refunds by allowing third parties to delete their eventually unnecessary storage variables.

What are GasTokens?

Briefly, GasToken are tokens that can be consumed, where consuming a GasToken results in a gas refund. This is possible thanks to storage refund, where freeing the Ethereum blockchain from storage variables and contracts leads to a gas refund. This gas refund can pay up to 50% of a transaction’s gas, which can be very interesting for expensive transactions. With the official GasToken contract, you basically fill arrays with ones and create contracts which can later be destroyed.

Now, the gas refunded from freeing some storage space is less than the initial gas cost of storing the data on-chain in the first place, so why would someone want to do this? Well, you can create these GasTokens (filling an array with ones or creating a bunch of contracts) at a time t with a low gas price (e.g. 2 Gwei) and later consume these GasTokens in a transaction that has a higher gas price. Hence, half of your gas used for the expensive transaction effectively costs you 2 Gwei, while the other half costs 50 Gwei. Even if you don’t get back as much gas as you spent creating these GasTokens, the difference in gas price can make it worth it. The gastoken.io website has a great calculator for this. An analogy would be to buy gasoline for your car when it’s cheap and store it somewhere for when prices become higher.

Introducing GasToken Factories

GasTokens have so far been composed of useless data, where you first fill the blockchain with “junk” and then delete it later. However, there are many contracts filled with data that also become useless at one point. The most commonly known example would be token sales, where a sale contract can store many MBs in data (stay tuned for some analysis on this). For instance, some token sales keep track of who is whitelisted, how much each individual contributed to the sale thus far, how much each individual can contribute, or at what price, etc. All this data becomes effectively useless once the sale is over, since this data is almost only used for the logic of the sale. Of course, this is not the case for every sale, where some of the information can be reused. This is the case for tokens created using the Polymath platform and ST-20 Standard for example, which are security tokens and where the whitelist needs to be reused for transferring tokens. Nevertheless, the moment a contract contains some data that eventually doesn’t need to be on-chain anymore, you now have a potential GasToken Factory.

Put it simply, a GasToken Factory is an Ethereum smart contract that has some stored data that can be deleted after a certain point in time, allowing users to obtain a gas refund. This contract needs to have a function allowing the eventually useless storage variables to be cleared iteratively by third parties. One could give this gas refund for free, but one could also sell it at a fixed gas price, which could end up being appealing at a later time point when the network is congested.

Here’s an example: Alice has a smart contract filled with now useless data and decides to sell the gas refund available for 20 Gwei per gas unit. Bob is doing some complicated transactions that cost a few million gas units and wants to save some money now that the network is congested with an average gas price of 50 Gwei. Before executing his expensive transaction, Bob calls a function on Alice’s contract that frees some storage space. Bob can now effectively have ~50% of his gas paid at 20 Gwei, while the rest of the gas is paid at the current market price, i.e. 50 Gwei. Alice is happy because she is making money while selling her GasTokens; Bob is happy because he is saving some money by buying cheap gas; and the rest of the network is happy because useless data is deleted from the Ethereum blockchain.

TokenSale as GasToken Factory Implementation Example

In this following section, I will use a modified version of the IndividuallyCappedCrowdsale.sol contract by Zeppelin and turn it into a GasToken factory.

In this contract, we will be using two mapping variables;

the caps variable also acts as our whitelist. Since caps is controlled by the token sale owner, we need a function allowing the owner to set and whitelist each participant.

For efficiency reasons, we also mint a GasToken which stores the participant address. This is to make it easier to delete the stored variables later, since otherwise users would need to pass the addresses for each mapping to delete when trying to obtain a gas refund, which could lead to collision and higher gas cost. It does increase the tx cost for the buyers by about 25k gas, but this is a legitimate cost since it allows the destruction of almost all storage space on the contract at a later time point.

This function stores in an array the user address and then increases the gasTokenSupply by 1.

So let’s now imagine that 10,000 participants are registered, they contributed to the sale and the sale is now finalized. How can we sell the available GasTokens? Using a function called freeStorage . Note that to simplify this example, the GasTokens are not transferable and only the token sale contract has a balance, but anyone can consume these GasTokens when needed. Adding a transfer option could allow others to take/buy the GasTokens before actually needing to use them, guaranteeing them to have access to these GasTokens at a later point in time.

In the function above, we first make sure the sale is over, then we load the amount of GasTokens available (supply) and check if the user calling the freeStorage function provides enough ETH to buy the GasTokens. Then, the contract frees _amount of stored variables and then transfers the cost to the sale fund address. Once completed, the user will receive all the gas refund resulting from this function call.

TokenSale as GasToken Factory Example in Numbers

In this example, the optimal amount of GasTokens consumed gives a net gas refund of about 29,500 gas units. With 10,000 participants in the sale, this means we have a total of ~295,000,000 gas units that we can use, give or sell. If we decided to sell this gas at 30 Gwei per unit, then we are looking at an income of 8.85 ETH. This doesn’t seem much compared to the amount of money raised in many token sales, but it’s some “free” money that also helps the consumer and the rest of the network. You can be paid for doing a good deed with little extra work! Keeping it to yourself or donating to a project you like is also valuable, since this could pay for many expensive transactions.

The general rule of thumb to calculate how much gas refund your contract will be able to give/sell is :

(10,000 + 10,000 * number of mapping variables) * number of mappings

So in the case of a token sale contract like Polymath’s CappedSTO.sol with a single mapping variable ( investors ), we would have 20,000 gas units available per investor or, for example, 200,000,000 gas units with 10,000 investors.

When it comes to choosing how many GasToken to optimally consume per transaction, I use the following formula (specific to this contract):

N ~= G / 74520 + 0.305

where N is the optimal number of GasTokens to consume and G is the cost of the transaction if it did not call the freeStorage() function on the GasTokenFactory above. You can find a more precise breakdown of the calculation in the comments of the getOptimalGasTokenAmount() function.

You can find the complete contracts and tests on this Github Repository.

What other types of contracts can become a GasToken Factory?

Token sales are obvious ones, but there are others. The 2 main criteria for determining whether a contract is a GasToken Factory candidate would be:

Are you storing large amount of data (e.g. mapping or arrays)? Will this data be useless / un-modifiable after a certain time point t? (Note: You can always store the root hash of the state trie at time t, allowing you to use merkle proofs to prove a state variable for this specific root hash without keeping all the data actually stored on the blockchain).

With these criteria in mind, here are a few examples :

Ethereum Name Service (ENS) and Auctions. With the current .eth Registrar contract written by Nick Johnson, each NAME.eth address needs an auction where interested users can bid (using commit and reveal scheme). This contract contains two mappings ; _entries and sealedBids . sealedBids are already zeroed out once bids are revealed, but for each auction there are two variables in the associated _entries structure that could be deleted once the auction is over. According to etherscan.io, since the ENS deployment last year, there has been 755,719 auctions. With some quick estimations, this means there would be about 22,671,570,000 gas units available for refund; enough to fill ~2834 blocks. If valued at 25 Gwei, this would be worth ~567 ETH .

With the current .eth Registrar contract written by Nick Johnson, each address needs an auction where interested users can bid (using commit and reveal scheme). This contract contains two mappings ; and . are already zeroed out once bids are revealed, but for each auction there are two variables in the associated structure that could be deleted once the auction is over. According to etherscan.io, since the ENS deployment last year, there has been With some quick estimations, this means there would be about for refund; enough to fill ~2834 blocks. If valued at 25 Gwei, this would be worth . On-chain governance. Think of elections recorded on the blockchain, or Token Curated Registry votes (introduced by Mike Goldin). Once a voting result has been settled for good, it doesn’t matter that who voted for what remains accessible in the contract. This data can be flushed from the blockchain and stored off-chain (e.g. IPFS), while only keeping the result of the vote on-chain. (Note that recording every vote on-chain is probably not the best approach in the first place).

Think of elections recorded on the blockchain, or Token Curated Registry votes (introduced by Mike Goldin). Once a voting result has been settled for good, it doesn’t matter that who voted for what remains accessible in the contract. This data can be flushed from the blockchain and stored off-chain (e.g. IPFS), while only keeping the result of the vote on-chain. (Note that recording every vote on-chain is probably not the best approach in the first place). Lottery / Gambling. Imagine a lottery system with rounds that last 2 weeks. Over these two weeks, people buy tickets or deposit some amount. Once a given round is over, a new “deposit” balance is usually created. Tracking the deposit of each participant for each round takes some space, which can be freed later when consuming associated GasTokens.

Imagine a lottery system with rounds that last 2 weeks. Over these two weeks, people buy tickets or deposit some amount. Once a given round is over, a new “deposit” balance is usually created. Tracking the deposit of each participant for each round takes some space, which can be freed later when consuming associated GasTokens. Token Dust. This is probably more controversial, but some token contracts could allow balances with very small amounts of tokens (<0.001$) to be cleared out by third parties. There is a substantial amount of addresses that contain a trivial amount of tokens and allowing third parties to flush these in exchange for gas refunds could be interesting.

Concluding Remarks

While this solution is not applicable in every situation, my hope is that these kind of incentives will push developers to start thinking about designing their contracts so that their data can be flushed, either to make an extra income, to reduce the cost of their future transactions, or simply to be good to the network. Of course, developers should not add additional junk to their contract simply to try to sell more GasTokens. The reality is that GasTokens might not create significant revenue, especially if gas prices are kept low.

The contracts provided with this post were not audited nor optimized, hence please do not reuse in production without doing your due diligence. The contracts provides no share or promise of anything and contract will likely stop working with future hard forks.

Acknowledgements

Thanks to Nick Johnson for the feedback on the ENS section and Polymath for supporting me for this research. You can reach me at ph.castonguay@gmail.com or on twitter for any inquiries.

Resources

Joining Polymath

Are you interested in joining the security token revolution? Polymath is always looking for high quality talent. Check out Polymath’s careers page at https://polymath.bamboohr.com/jobs/ to apply!

Follow Polymath

Twitter: https://twitter.com/polymathnetwork

Telegram: https://t.me/polymathnews

Website: https://polymath.network