Ethereum 2.0, Getting to a Billion Transactions a Day – Trustnodes

Ethereum 2.0, Getting to a Billion Transactions a Day


“The ethereum killer is ethereum, the ethereum of China is ethereum, the ethereum of Taiwan is ethereum… 2.0.”

So said Vitalik Buterin, ethereum’s co-founder, in November 2017. Since then, developers have been working for months to launch the real ethereum killer, ethereum 2.0, and the aim may well be getting to a billion transactions a day while maintaining a decentralized and secure public blockchain.

By comparison, the current top ranked coin, bitcoin, can only handle 300,000 transactions a day. Ethereum does a bit better with maximum capacity of 1.4 million. Bitcoin Cash reached 2.2 million during a stress test.

To increase capacity, there are somewhat easy optimizations that can be done by sort of tinkering at the edges. Block propagation, for example, can be a lot more efficient. Easy compression of data can reduce orphan rates. Things like Turbo Geth can make nodes more lean.

These efficiency gains can increase capacity to perhaps 5 million or maybe 10 million, but to get to real scale, to a billion, a breakthrough is needed called sharding.

Sharding breaks up nodes into groups so that instead of all nodes validating the same transaction, a group of nodes validates say 10,000 transactions with all these groups then combining to provide roughly the same security guarantees as currently.

According to one analysis, there would be 1024 shards which sounds very high. At current node numbers, that would mean just 20 nodes per shard, something which might be a bit low.

However, nodes are currently not incentivized so at a technical level no one currently needs to run an eth node unless they’re a miner or an exchange and similar businesses. Arguably even those can delegate the node running to Infura.

This will change when Ethereum 2.0 launches as that will pay node operators through staking. All one would need would be 32 eth, currently worth just $7,800, to receive about 5% interest a year, or 1.6 eth a year.

For such passive income, one has to run a node because stakers are effectively miners which use eth to prove they’re not fake nodes rather than the Proof of Work calculation of useless math equations.

Moreover, it is best for such stakers to run their own node because the design rewards unique set-ups, like the node running on an obscure Linux operating system, and punishes heard behavior, like joining a big pool, due to the way the penalties are set-up.

Node numbers therefore would increase considerably. In addition, as a node would actually matter in Ethereum 2.0, there would be a good reason to run one besides the financial incentives, that being really supporting the network.

So if nodes increase 10x to 200,000, there would be 200 nodes per shard, which sounds reasonable. If ethereum is really handling a billion transactions a day, however, node numbers may also increase 100x, giving a very healthy 2,000 nodes per shard.

In Ethereum 3.0, these 2,000 nodes can then be sharded again through mind-boggling maths to reach 10 billion or even 100 billion transactions a day.

With inflation devaluing our money every day, a billion is no longer cool. Now what’s cool is a trillion. That could be achieved by utilizing a new layer two method that was introduced today, in a very research form, by Buterin. He says:

“We can actually scale asset transfer transactions on ethereum by a huge amount, without using layer 2’s that introduce liveness assumptions (eg. channels, plasma), by using ZK-SNARKs to mass-validate transactions. Here is how we do it.

There are two classes of user: (i) transactor, and (ii) relayer. A relayer takes a set of operations from transactors, and combines them all into a transaction and makes a ZK-SNARK to prove the validity, and publishes the ZK-SNARK and the transaction data in a highly compressed form to the blockchain. A relayer gets rewarded for this by transaction fees from transactors.”

The current proposed layer 2 solutions, like the Lightning Network (LN) or its eth equivalent Raiden, like Plasma or like state/payment channels, have their own, but different, capacity problem.

The way they work is by compressing transactions through exchanging balances on the second layer, then settling on the base layer.

This works fine for small amounts, and is ideal for many use cases like micro-payments, but for real usage it requires far too much capital with Emin Gün Sirer, Cornell Professor, stating this March:

“An exchange needs to have funds on hand tied into channels that are proportional to the float per person, time the number of people they want to support.

So, suppose somebody could receive up to $10,000 from Coinbase, and Coinbase has, I don’t know, ten million users. So ten million times $10,000… $100 billion dollars get’s tied up.”

You can replace an exchange with a dapp and change the numbers as you like, but the capacity limits here are clear, albeit limits of a different nature.

That’s because in these sort of layer two solutions, you can have millions of transactions a second in theory, but you’ll need to lock up the amount you want to transact as a collateral of sorts until it is settled. So a dapp would have to put down say 100,000 eth for 100,000 eth to be transacted on its dapp through LN like solutions.

That explains to a great extent the reason why such second layers have not found much adoption as a full solution, but they do have niche use-cases which can increase capacity in combination with other solutions.

What Buterin is proposing with ZK-SNARKs is different from the above. If we can simplify it and if we understand it well, he seems to suggest snarks can be utilized to prove the validity of say 1,000 transactions which are compressed into 1 on-chain transaction.

There wouldn’t be any locking of funds here, with the second layer aspect being more technical than frontend facing like LN.

This, Buterin says, would allow for 500 transactions a second, with sharding then on top adding some zeros to it, increasing capacity to the point where it is practically unlimited as it can meet all the foreseeable demand.

How snarks would work exactly in this set-up, however, is currently unclear with it not even at the fetus stage, but sharding and staking have been conceptualized with the specification almost done.

That will now probably be fleshed out more at Devcon next month where the ethereum ecosystem is put on display.

We may therefore learn how much they have progressed so far and what is the rough time-line moving forward.

We have given them, in jest, a deadline of 2020, but we do know how difficult this is so we wouldn’t really shout at them if they go over a bit because a billion transactions a day is very much something worth waiting for and very much something worthy of getting right.

There are plenty of easy trade-offs that can get this to a billion transactions even tomorrow, but that wouldn’t be cool at all. What is cool is a billion transactions a day on a decentralized, trustless, secure, global, permissionless, programmable, public blockchain.

You take any of them out, and you might as well take all of them out. Which is why this is taking time, but it will get there. Some of the brightest minds are hitting it with all they can, so it will eventually bend.

Once it does, then this will be ready for mainstream usage, including potentially entire countries running on the blockchain.



Comments (3)

  1. Great article

  2. 1 B per Day is 11,574 Transactions per Second. So what you are saying is Ethereum 2.0 will start off as a shitcoin. Even with Ethereum 3.0 with 10B, it will be outdated. There’s projects already doing way more than that.

  3. Just say 11,500 transaction per seconds,

    You put a billion transaction per day so it will look huge and mislead the public,

    They are projects doing way better than that is doing 1 million transaction per seconds and it’s confirmed already,

    This advertisement is deceptive,

Leave a Reply to Tim Mayeur Cancel Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>