Rent, Pruning, 10x Scaling and Six Stages, Ethereum 1.0 Might be the Biggest Upgrade Yet

Ethereum is transforming from a dumb blockchain which does not scale to one that might allow our grandchildren to still run a node while performing millions or billions of transactions.

A closed door call meeting of 43 core developers out of perhaps 60 appears to have concluded, according to Lane Rettig of eWASM:

“While rent is a stick that would have clear UX impacts, a ~10x increase in tx throughput is a carrot that’s incredibly valuable, and is a tradeoff that the community may be willing to accept.

There are a *lot* of unsolved challenges around data availability, if we break the existing invariant (*not* specified in the yellow paper, however!) that all block headers, bodies, receipts, and logs are always available within the existing P2P network.”

Currently, the ethereum blockchain can scale by making certain optimizations, but at a great cost and perhaps to the point where the system literally no longer works even with one node if we are to look at it from the time frame of decades or centuries.

That’s because a full node has all history. As more transactions are made, that history grows and grows, meaning that the node’s resources grow and grow to the point where, in a long enough time frame, even if all current bitcoin asics are used and all the energy of Belgium, you still wouldn’t be able to synch one node.

There may of course be break throughs, perhaps in part due to their need by the public blockchain, but Péter Szilágyi says it currently takes 4-5 days to synch a full node.

That’s the giabyte one, rather than the archive nodes, and that’s only after three years of ethereum up and running with only one year of it processing above 500,000 transactions a day.

If in the current state, and if we just extrapolate, in another three years it will take 10 days. In a decade it will be about 20 days or close to a month.

That doesn’t take into account Moore’s Law, but if capacity increases 10x and there are 10x more transactions – which is probable – then in just three years, it will take 50 days or two months to synch a node.

That’s obviously not sustainable, with another interesting point made by Szilágyi in a fairly accessible proposal to prune the chain.

As you may know, sharding is coming and what that does is it takes the current network and basically it replicates it 1,024 times in a way that all these 1,000 networks are still just one network but that one network now can handle 1,000 x current capacity or so while maintaining resource requirements for node at the same level as the current network.

It’s a marvelous beauty, conceptually, and it will be the biggest breakthrough since the blockchain’s invention once it does come out. Szilágyi, however, points out that even under sharding, each node will still require the current resources – that being the 5 days synching time which continues to increase effectively indefinitely save for what Moore’s Law might mitigate.

Obviously under sharding there would be stupendously more capacity and that can be doubled further or more through the sharding of shards.

Then there will be Proof of Stake, which will pay ethereans to run a node so there will be an incentive which can cover the resource usage costs.

If however we look at a long enough time-line and if we assume Moore’s Law at some point reaches a limit, then perhaps we can’t escape the conclusion that if history grows indefinitely, even if it is very slowly, then at some point this will break because there will be too much history.

So the same concerns apply even with sharding, but they apply more if capacity is increased 10x before the 1,000 networks.

So there are two probably controversial proposals for which there will probably need to be some general consensus.

One of them is by Alexey Akhunov, a former Software Developer at Goldman Sachs and other banks who is now independently developing for eth.

He has put forward the idea of storage rent. In simple terms, this is basically deleting contracts that are not used while having a method to restore the contract if one wants to use it.

Why not just delete them and restore them without requiring rent is not very clear, but one obvious answer might be that without some sort of cost, people would just restore them for the lulz.

Would they really, one can ask, wouldn’t the spammers eventually get bored or maybe – if this network does become globally important – wouldn’t they just be sent to prison?

Plus, the restoration would be only temporary as the contract would become inactive again, but one can also ask why shouldn’t they pay rent?

This is at a pre Ethereum Improvement Proposal (EIP) stage, but it looks like the way it would be implemented would be by taking the rent from transactions and sort of storing it into the contract. So a popular contract would have enough funds to run effectively indefinitely.

Meaning that although Akhunov says there is a trade-off in UX – if it is implemented as stated above, then it isn’t very clear what exactly the trade-off is from a user’s perspective.

One such UX degradation might be that in addition to gas, users might have to enter a rent fee as well, but can’t the contract deal with the rent fee by itself without involving the users?

As in, end users are left alone and not bothered, transacting as they do now, but the contract takes a bit of their eth or token for transacting with it and stores it to pay rent. Making the experience no different from now as far as say Trustnode’s dapps testruns are concerned, except that we might be a penny poorer each time we transact with a dapp.

Now how exactly this will work in practice is not clear. Akhunov has promised a Proof of Concept (PoC), but we’d want to “touch” it and “feel” it so we can see for ourself how it works perhaps on the testnet.

Beyond scalability, the other carrot as far as rent is concerned is inflation, or rather less need for it. That’s because all this rent will go to stakers, as in everyone and anyone with a laptop that wants to “deposit” their eth and hodl to get back some interest at perhaps 5%-8% a year for securing the network in “voting” whether a transaction is valid and should be processed.

So if this went to a vote and if it is implemented well and deleted smart contracts can be restored, then from a realpolitics perspective, hodlers would probably greenlight it because they don’t tend to like inflation and they do tend to like a cap on the supply.

A cap on the supply has not yet been proposed, with it too a somewhat difficult decision because one would need to consider what sort of economic implications that has, especially if this does become the future of money – at least for machines.

Some do like a very small level of inflation which tends to go towards zero as the new supply is fixed while the general supply keeps growing, making the fixed new supply be less and less of a percentage of the general supply.

On the other hand, if inflation is close to zero, then why not just cap it? One reason might be because then it would be only those transacting that pay for the network’s security while hodlers pay nothing.

Anyway, there are enough difficult decisions on the table, so to cap or not to cap has seemingly been left for another day.

One such decision is that of a proposal by Szilágyi which might be even more controversial than rent. Szilágyi emphasizes he has practical considerations in putting forward this proposal and to simply describe it, he is basically saying that rather than the history growing indefinitely, we just put a cap on the history.

That being, nodes keep or need only say the last three years to get up and running. All history is then kept on IPFS or wherever so that if you really want it all, you can have it.

The main question here is whether this can be implemented in a way that doesn’t affect security, as in old transactions can’t be double spent or do not become unspendable or are not created out of thin air and we can be sure of it because of whatever.

Szilágyi doesn’t really talk much about security on his proposal, but obviously if he is putting this forward we can assume that there is a way to make sure you can’t double spend and so on by keeping all the block headers and they’re thinking ways of keeping sort of skeletons of history so that you can reconstruct it if you wish.

Now what bitcoiners would say is that all of it sounds fine, but someone has to archive that old history. Why should we trust that someone?

The answer to it would be – and if it can be done – that you technically don’t need to because you can reconstruct it from the skeleton which you keep in the running node, but whether that’s really possible isn’t very clear.

Most end-users probably wouldn’t care one bit whether to prune or not as they don’t even run a full node, but we’d say there needs to be a lot more detail on how this would work as far as the general public is concerned. As in, do we have to trust the archiver and so on.

We remain neutral on both proposals as both need more flesh, but we do kind of like rent and the network pruning provided their implementation is what we’ll just describe as “considerate.” That being that we don’t have to trust the archiver and that the smart contract can indeed be revived.

If we have to trust the archiver, then that makes it a very complex question and a decision that perhaps shouldn’t be made now but when/if history grows to the point where it is a fairly immediate concern.

Likewise we wouldn’t want contracts to be deleted if they can’t be revived and who pays the rent is a consideration because for end users, even having to enter a gas fee is arguably too much, let alone rent. You’d think rent, however, would be fixed so can automatically be taken off the address, but again these proposals are at a very early stage.

These will apparently be implemented in six stages rather than in just one big upgrade. No dev has dissented yet, perhaps because it is a bit too early, but there are tradeoffs for both of these proposals and those tradeoffs need to be made a bit more clear because if eth devs don’t, then we’re sure bitcoiners will. Especially for pruning.

On the other hand, most ethereans probably don’t have the technical knowledge to form an informed opinion, but the question of say whether you want to trust the archiver or not isn’t very technical if trust is involved. In which case, it will need to be made more clear to what extent that trust has to apply.

Meaning there will probably be more information on these two topics and on what the foreseen six stages of implementation are, but it is now becoming very clear that ethereum is indeed scaling and bigly with some difficult decisions needed to be made on the way.

Copyrights Trustnodes.com