Introducing the Concept of Storage Taxes in the Ethereum Ecosystem

While cryptocurrencies witness breakthroughs with each passing day, some of the challenges being faced by the underlying blockchain technology cannot be overlooked. One such major obstacle is the issue of scalability.

The lack of scalability in the major crypto blockchains, i.e., Bitcoin and Ethereum vastly limit the maximum number of transactions that can be processed by a blockchain at a given time.

This problem can be substantiated with the help of an example. Comparing a blockchain’s scalability with a multi-national payment gateway like VISA shows the urgency of a scaling solution. The famous credit card provider VISA can process up to 2000 transactions per second, which dwarfs some 15 transactions processed per second by the Ethereum blockchain.

However, all is not lost as scaling solutions such as Sharding and Plasma are expected to raze down the scalability concerns of the distributed ledger technology (DLT).

Arguably the cryptosphere’s most recognizable face and the co-founder of Ethereum, Vitalik Buterin, recently stated that the smart contracts based DLT platform is en route to a million transactions per second, courtesy of the aforementioned scaling solutions. If the ambitious target does materialize, it could completely disrupt the financial payments infrastructure as we know it today.

While you can find hundreds of articles on sharding and plasma on the internet, one not-so-popular scaling solution seems to be making its way steadily into the limelight. Storage Taxes is one of the most ambitious scalability solutions after sharding and plasma.

The purpose of this article is to cast some much-required light on the developments going on with Storage Taxes – including their benefits, and the associated challenges. The write-up draws information and findings exquisitely put together by the user “jvluso” here.

How do Storage Taxes Address Scalability in Ethereum?

Looking broadly, storage taxes exhibit similar characteristics as sharding. The protocol, at its most basic level, involves creating smaller parts from a larger one.

In the context of databases, sharding results in the creation of smaller partitions in the ledger. These partitions are thus referred to as shards. This means that with the help of sharding, participants in the consensus protocol need not execute the entire code themselves – instead, they can execute a part of the code in a block and mitigate the stress borne by the underlying network.

Storage taxes differ slightly from sharding in the sense that participants in the consensus protocol need not store the piece of data themselves. Participants only need to agree to the integrity of the data being stored. Once the consensus is achieved, the data is stored off the chain.

Storage taxes offer enough tools and incentives for users to save the data off the grid and prove its authenticity whenever required. The motivating factor for users in this scenario is the option to pay for storage that they force on consensus protocol participants to store the data.

One of the major upsides to storage taxes is the reduced memory requirement for nodes – much like the minimal CPU and bandwidth requirement for nodes in case of sharding.

Retrieving Lost Contracts via Sleep/Awaken Function

Storage taxes offer a slew of features that address some of the most critical challenges the DLT is facing today. One of the features offered is the sleep/awaken function.

At times, contracts may get deleted due to storage rent. The sleep/awaken function helps in keeping track of the dormant contracts, saving them from getting lost forever. Technical details about this functionality can be read over here.

Given the technically heavy process of sleep/awaken function; we will focus more on the challenges being faced by this functionality and ways to overcome them.

One of the prime obstacles with sleep/awaken is that to get a contract up from its “sleep” or awakening it mandates a proof that the contract was not awakened from the last time it was put to sleep. As is the case with any emerging technology, arranging for this proof is rather expensive. To mitigate the expense involved, the “Awaken Bloom” technique has been conceptualized.

The Awaken Boom technique entails that at regular intervals (maybe every block or a fixed number of blocks)   a bloom filter of the non-dormant or “awoken” blocks will be published, in addition to the head of a Merkle tree of the live blocks being published.

For the uninitiated, a Merkle tree is a data structure where every non-leaf node is a hash of its child nodes. Evident from the image below, the leaf nodes are the lowest tier of nodes in the Merkle tree.

(Source: Wikipedia)

Coming back to the Awaken Bloom, the published bloom filter will be available like any other data piece in the blockhead. Subsequently, the opcode could use the awaken bloom to establish that the contract has been dormant or not awoken for a large number of blocks – in exchange for a minimal per-block gas cost.

By now, you might be wondering what exactly is the use of publishing Merkle tree of the blocks. Well, sometimes bloom filters can generate false positive matches. However, by including the Merkle tree head for every match made, false matches can be easily identified and singled out.

Costs Associated with Creating a new Account

It is estimated that creating a new account will be more costly than awakening an existing account. The Ethereum blockchain mechanism requires that before an account can be interacted with under any capacity, it must prove that it has never existed in the entire blockchain’s history.

While it may not be expensive at first, the process of creating a new account will eventually become cost-intensive in the future. To circumvent this problem, a new type of private key/public key account can be created.

This type of account can make use of the combination of the private key and the block hash of the most recent block published.  Once the account address is determined, before the address is truncated, the recent block hash can be hashed with the public key. This will ensure that when you later interact with the newly created address for the very first time, the required proof will only need to go back to the block specified.

Circumventing the Tax Payment to Save the Gas

For obvious reasons, users would never want to see their ETH balance going down due to the tax charges. To overcome this fuss, users will be required to deal with single ETH wrapped contracts which can’t be awoken without being put back to a dormant state immediately.

To achieve this limitation for a contract, the aforementioned awaken function will need to be replaced by a more sophisticated awaken + call function. This new function will enable the wrapped ETH smart contracts always to go back to the sleep state if interacted with by an account which doesn’t put it back to the dormant state on its own. This will further facilitate the developers to create more complex mechanisms and conditions to keep the contracts in awaken state.

Final Thoughts

While the concept of Storage Taxes looks promising, there is still a lot of work left to be done to bring it to the forefront of the things in the DLT world. Thankfully, challenges are what the crypto and blockchain enthusiasts strive for, and it won’t be long before we observe positive changes in the new and exciting domain of emerging technologies.