Ethereum’s roadmap to (possible) ProgPoW switch.

You may (or may not) have heard that during the last All Core Devs Call a more precise roadmap to (possible) implementation, on Ethereum’s main chain, of a new PoW (Proof of Work) algorithm named ProgPoW. I am trying here to clarify the most common questions I’ve been asked about this matter. Please note : this article is meant for the “common people” and may contain simplifications which may horrify the high skilled developers involved into Ethereum’s ecosystem implementation. Nevertheless I’ll try

The specialization of Proof of Work(ers)

Before entering in detailed explanations about what ProgPoW is I think a brief summarization of what is PoW (without the prefix “prog”) is required. The acronym PoW stands for Proof of Work: this concept is the foundation of many (if not most) block chains (and related tokens/coins) out there. It’s the core principle of cryptographic immutability of a block-chain. Let’s make it more clear: every block (of data) which has to be inserted into the chain must be “sealed” with an unique cryptographic signature. This signature is produced by an algorithm which is ran by a computer program the most of you may recognize in the word “miner”. For most chains (or coins if you prefer) this algorithm is pretty much constant : the number and quality of basic operations (math and memory access) executed by the computer program stays pretty much the same over time and only some data may change from time to time.

This is the case of Ethereum’s algorithm which is named ethash. Its set of operations is constant in time while the memory area those operations make use of, named DAG, increases at a constant rate every 30.000 blocks inserted (sealed) into the Ethereum’s chain itself.

GPUs (or in a vulgar way graphics cards) are very good at executing those algorithms at very high speeds but, nevertheless, they retain the main feature of being “general purpose” devices : you can use them to “mine”, to run your video games, to render design projects, to see streamed films … whatever.

On the other hand the fact typical “mining” algorithms rely on a constant set of operations have favored the blooming of “specialized hardware” (ASICs) which are meant to speed up the execution of the algorithm while consuming less energy compared to the same work performed on a GPU. And indeed they do what they’re meant for: no doubt on that. Simply (very simply) speaking an ASIC implements the execution of the algorithm via hardware instead of via software.

At first glance you may say “well if an ASIC is more efficient than a GPU this has a positive impact on the matter of ecology and helps save a lot of energy”. I fully understand the point and I recognize it can be shared.

There are a few problems though. The more a process relies on “specialized” resources the less likely you’ll be able to make fast and efficient changes to the process itself. Building specialized hardware is a very expensive path leading to the production of machines which are meant to do a very specific thing and that one only. The ones investing (either they’re producers or end-users) on those machines have all the interest the process stays immutable for a period of time long enough to collect a sufficient amount of money to counterbalance the costs and, possibly, return a profit. But there’s more : whenever the process changes (for any reason) the depreciation of “specialized hardware” built on top of “previous version of the process” is 100% in a matter of seconds.

Let’s treat the question within the scope of Ethereum : a “specialized mining device for Ethereum on ethash algorithm” will have a residual value of ZERO when the algorithm changes. Those machines are not relocatable to other duties cause they were specifically designed and built to perform one specific task and that task only. When that task is no longer needed … well those machinery is no longer needed as well.

Now consider this : GPUs, as seen above, are general purpose commodity hardware you can buy in the nearest tech store. With the quick download and install of a simple software anyone can be ready to “mine” the chain thus contributing to its security. If algo changes either you download a new version of the mining software or (relying on your maths) can switch, using other software, to the mining of another chain/coin. With ASICs instead things get more complicated: you don’t find those machines on shelves of stores and you need a more robust business plan to get a profit out of them. Specifically you must foresee a reasonable amount of time during which the machines you’re going to buy (or produce) will be effective. The higher the investment the more certainties you want in your business plan. And when you’re powerful investor you have a great tool to get those certainties : lobbying !

I’ve listened to many arguments against any change in PoW algorithm which basically state “who cares. Ethereum’s aiming to PoS (Proof of Stake) so PoW will be abandoned”. In my view this is very short-sighted: migration to PoS is effectively a path to immediate total obsolescence of any specialized hardware dedicated to ether’s mining. So this is a change lobbyist won’t accept without a fight to preserve their investments. And fight, most often than not, translates into what is called a “contentious hard-fork” : block chain splits in two (or more) branches which will live with different rules and will cause loss of credibility (and value) to the original Ethereum project.

Allowing the concentration of hash power into the hands of very few hardware manufacturers creates and big buying groups creates a short circuit among hardware driven mining service and software driven block-chains which is quite tricky to disentangle.

If, instead, the making of ASICs is made uneconomically viable while still allowing a consistent part of the hashrate come from general purpose hardware, as GPUs are, the whole ethereum’s stack is less exposed at risks of being taken over and fragmented.

And here is where ProgPoW proposal comes in …

What is ProgPoW and why it gets proposed.

ProgPoW is still PoW (Proof of Work) much like ethash is but it adds a layer of programmability (thus the prefix “prog”) on top of that. Simply put it “removes” the constraint of a “constant set of operations” in the algorithm by creating a new variant of the algo at specified, very short, intervals. If you need more detailed technical explanations about how it works you can look here.

This makes the whole industrialization process behind the making of an ASIC which could implement such an algo a lot more expensive and with a marginal gain agains commodity GPUs way lowered. In an epoch where the whole Ethereum ecosystem is aiming to PoS, the chances of investors embarking on a high-cost and time-consuming venture like this are minimal thus reducing the exposure of Ethereum to lobby powers.

Note: I’m not saying (nor anyone else is) that is impossible to build such an ASIC. I’m saying ProgPoW makes this enterprise more expensive and more time consuming. And time to PoS is a crucial factor.

The proposal of ProgPoW to replace “simple ethash” is aimed expressely in that direction: make the residual time to PoS less exposed to the probability of being extended only due to lobby powers which, for economic reasons, prefer to keep the status-quo.

As a side effect ProgPoW produces also benefits to the community of GPU miners (whether they’re small hobbysts/enthusiasts or organizations) which will likely see their profits kept safe from the mounting wave of announced ASICs.

How it may happen the switch to ProgPoW ?

On the last streamed call by the Core Devs three key points have been settled:

  1. ProgPoW deserves and need an extensive audit by 3rd party auditors (at least two groups) which will focus their attention on crucial aspects like cryptographic strength, equality of effectiveness on different platforms types (mainly Nvidia vs AMD) and wether or not it’s adoption may be cause of risks for the safety of network;
  2. On behalf of the previous point development and implementation of ProgPoW within miners and node clients is encouraged to continue to provide useful data to auditors;
  3. Eventually miners will be called to a HashRate Voting session which finally will state if this change is wanted/needed or not.

The last point is, imho, the most important of all : for the first time the Ethereum network is calling miners to express a vote reducing the tangible distance among core developers and the base of users who have so deeply contributed to the history of Ethereum until now.

Timings for all points are not clearly set right now but I will do everything I can to keep a legit pressure for them to emerge quickly.

How miners will be able to vote ?

This is something new for Ethereum’s miners while other communities have already dealt with it. For this reason I feel like some clarification is needed.

Please note : at the moment of this writing no active action is yet required by miners but I highly encourage everyone to get informed as much as possible and build up their personal convincement advisedly.

The vote will be expressed on Ethereum’s block-chain. On every block of data of the chain there is a small space (let’s call it “field”) named extraData. This field can be filled by the “sealer” by writing some data in it. In that field the “sealer” will express its own vote in favor or against the adoption of ProgPoW.

Who are the “sealers” ? The most common misconception about mining is that “miners” are the “sealers”: well actually this is highly inaccurate. Yes you need to “mine” to find the right solution to ethash algorithm but also that solution, bound with the block that solution is found for, have to be “written” in the chain. The only point where this can happen is at node level. The nodes as a whole constitute the essence of the block-chain distribution. Every node holds a full copy of the entire block-chain (roughly 140Gb right now) and whenever a node wants to write a new information in the chain it must reach a “consensus” among other nodes about the legitimacy of data being written so all nodes keep sharing the same version of “truth”.

So only nodes can write data and, again, only nodes can fill that “extraData” field. As you may well already understood 95% of miners, especially GPU miners, do not have or run an own node thus they can’t write anything to the chain. Instead they mine through “pools” which have an underlying node: when a miner receives a mining job from the pool it receives a very limited set of instruction to accomplish the task and have no visibility of what is happening on the chain.

For this reason, “pool” miners can’t vote anything by their own. They have to vote indirectly through the pool they’re connected to.

Let’s put it this way:

  1. Before the opening of the “voting” session each pool will “declare” its voting intentions (pro or against) or will provide “different” connection points to express votes pro or against; This information will be publicly available;
  2. At the start of the voting session miners will be called to point their rigs to connect to the pool and/or port which represent their (of the miners) voting intention and will keep mining on that connection for the whole duration of the voting session;
  3. The pools receiving more hash power will be the ones which will seal more blocks thus expressing more votes on the “extraData” field.
  4. At the end of the voting session, the blocks of the session will be accounted and the votes pro or against will be summarized to elect the winning proposal.

Trivial example: Pool A declares he is in favor of ProgPoW while Pool B declares he is against. When the voting session starts you (the miner) if are in favour of ProgPoW will need to start mining on Pool A or, if you’re against, will need to start mining on Pool B. And you will need to keep mining on either of the two for the whole session duration.

Very Important: the voting session will be carried out while mining “Ethash” not ProgPoW.

How long will be the session duration?

This is an important aspect to take into account. The voting session must be set to a duration long enough to make un-economical every attempt to manipulate the result. Example: you’re an actor which is strongly against any change in the algorithm cause this would cause you damage (ASIC manufacturer ?). In such case, it may be viable for you to spend some extra money to “rent” extra hashpower to address to a pool which expresses votes against. The longest the duration of the session the higher the “rent” costs.

I believe the duration shouldn’t be anything below 2 weeks.

What are the dependencies of those 3 steps to a final decision?

The auditing and development phase are strictly bound together as they both can emerge any flaw being hidden in the algo. If none found then the voting phase may start.

But it’s a lot of time to wait for …

True. But, again, I’ll do anything I can (helped by others and by the community) to keep a legit pressure for the whole tasks to be completed as soon as possible. This is the best we could get.

Andrea Lanfranchi
Ethminer Developer / ProgPoW Implementer