Ethereum May Skip Casper FFG And Go Straight to Sharding with Proof of Stake – Trustnodes

Ethereum May Skip Casper FFG And Go Straight to Sharding with Proof of Stake


Ethereum apparently is moving at such great speed that something they have been working on for a long time may now be effectively outdated in its current form.

This is not confirmed, and there remains some confusion, but from what sense we can make it seems that new developments have made Casper FFG, with 1,500 eth staking requirements, effectively redundant.

That new development is some significant advances in sharding, which now appears to have reached a stage where one can fully see how it would work.

“We are considering changing the Ethereum 2.0 roadmap to skip Casper FFG with 1500 ETH deposits. Instead Casper and sharding validators would be unified from the get-go in the beacon chain, and deposits would be 32 ETH,” Justin Drake, an ethereum developer, says.

He further clarifies that this approach would have a number of advantages, including simplicity, with Drake stating:

“Classes of issues go away, such as dealing with gas and writing code in Solidity. While withdrawals are disabled the manager contract on the beacon chain will be “unhackable”, and much easier to write and deploy.”

The reason for this seems to be due to the appearance of a beacon chain. This is a relatively new development first mentioned merely a month or two ago.

“The new roadmap should significantly accelerate the advent of full Casper because Casper FFG would run on top of a pure proof-of-stake heartbeat from the get-go,” Drake says.

Heartbeat wouldn’t be our description, but a lighthouse. The beacon is basically a random number generator that tells stakers something like: you, go to shard 32, you head to shard 64, and so on.

Casper FFG itself doesn’t need the beacon, sharding does. Instead of having Casper FFG first on a somewhat different design, however, they are apparently thinking of simply going straight to sharding and so launch the wholistic system all at once, or at least have it designed in a unified manner even if deployment of one is earlier than the other.

Vitalik Buterin, ethereum’s inventor, said at the beginning of the year that sharding is number one priority. This simplified approach, therefore, does make sense, but it does also mean that ethereum may not see a significant upgrade until next year at best, although as stated they do appear to be moving quite fast.

That’s because ethereum is in desperate need of some higher capacity, which sharding will increase by around 100x, allowing ethereum to handle some 100 million or more transactions a day.

In a presentation, Buterin gave a high level view of sharding with Casper where he laid out the responsibilities of stakers or validators.

He further confirmed that around 100 shards are expected, with each one of them having ethereum’s current capacity of around 15 transactions a second.

With stakers so having a number of responsibilities, whereby all stakers validate the main-chain, which is really the beacon or the lighthouse, and then each of them has their own shard to validate.

It is unclear what role Proof of Work (PoW) plays here, if any. Buterin doesn’t mention that term even once during the entire presentation.

The shards, of course, are linked together through the main chain, which here is the lighthouse, or the town square if you like where everything else revolves around it.

If validators are proposing blocks, then it does seem miners have now disappeared. We tried to gain some more clarity, but have received no response in time for publishing.

That’s the many responsibilities of stakers. In contrast, under Casper FFG or with miners, they only validate the main chain and propose blocks.

This is, below, perhaps a hint of why they may be thinking of going to Sharding with Casper straight away or the Casper with 32 eth, skipping the one requiring 1,500 eth for staking.

On the one hand, if you’re a “little” guy with 32 eth, you’ll need just a laptop with enough resources to validate one shard. But if you’re a big pool with thousands of eth, you’ll end up validating all shards, so will need a lot more resources and will have a lot more costs, making pools somewhat uncompetitive and thus promoting decentralization.

Finally, below is what we can call the “be unique” approach of ethereum staking. If you can find some obscure operating system, which nonetheless is safe, while others are “normies” staking on Windows and there is some glitch somewhere with Windows OS, you’re not affected, while the not unique gray bots may be crying.

All of that is in a way what looks like a pretty simple wholistic system that can be made even more complicated by each shard itself being sharded, and then so on, for super quadratic or even exponential scaling.

That’s of course not being planned now because the focus is on getting 100 million transactions first and because it is quite complex to achieve, yet it is envisionable.

When all this? Well, we have imposed a deadline on them by 2020, somewhat in jest. At the beginning of the year we said dapp devs have about two years to get all their ideas ironed out, tested, and so on, with ethereum then ready to handle much of it by 2020.

Dates on these things, however, are more in jest than a strict deadline. You just can’t speed up what is in many ways a breakthrough, but as it can be explained in a very simple and understandable way, then we’d hope it would be out sometime next year.

That may be disappointing to some who may have though Casper FFG with 1,500 eth staking would be out this summer, but such significant requirement would have necessitated pools which would be holding other’s money and therefore may have been required to comply with all sorts of requirements.

So if sharding is merely months away, then it does seem to make sense to go straight to it with staking rather than incentivize a potentially undesirable infrastructure first.

However, it is not confirmed that this is the approach that will be taken, but it does look likely.



Leave a 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>