Why I believe ProgPoW is the next step forward for DigiByte
It’s currently New Year’s Eve. I’m with friends and family. We have the BBQ going, fire roaring roasting marshmallows, lots of beer, laughs, and good music… and yet I find my mind wandering to think about what 2020 will hold for DigiByte, namely, in the form of Algo upgrades.
2019 was an amazing year, going from strength to strength, with countless milestones / achievements. Odocrypt is quite simply a work of genius, in my opinion. Target as close to ASICs as possible, then dial it back just a little so that they’re infeasible to build for on anything but a FPGA. This is one of the key future points for DigiByte that has not only laid the groundwork for future Algo replacements, but solidified the future of MultiAlgo.
From Odocrypt to ProgPoW
You see, having multiple algorithms supporting the same “type” of hardware, while still beneficial in many ways, is not optimal.
Having multiple FPGA-friendly algos could be used to game MultiShield, by alternating your hash-power across the algorithms. Same for if we ever had multiple GPU (Computer graphics cards) or CPU mineable algorithms, say swapping between the likes of X16R and ProgPoW (Hypothetically here).
You can obviously have multiple ASIC Algos for maximum security, but then you only have the benefit of “security” and not the other benefits you gain from FPGA / GPU / CPU mining.
The mining distribution from ASICs not only prices many people out of the market, but geographically prevents participation from those who would want to due to import / export laws amongst other things.
Odocrypt has really kick started this for DigiByte, having 5x algorithms targeting different hardware types. The focus on an algorithm for FPGAs that cannot practically be mined on an ASIC cannot be overstated, and should not be overlooked.
ProgPoW is the next extension of this, but with a focus on GPU hardware.
The DigiByte community has been longing for a GPU-focused algorithm since the initial announcement of the Baikal X10 Giant in November 2017, and ProgPoW has consistently been at the forefront of those discussions.
The brainchild of IfDefElse (although 2/3’s of whom are not public figures), the ProgPoW algorithm has been independently reviewed by multiple different groups with the goal of an eventual implementation into Ethereum. Although receiving mostly glowing reviews for it’s GPU saturation (far higher than that of Ethash), and mechanisms for minimizing any potential benefit of FPGA / ASIC mining, the minor suggestions that resulted from the investigations have been implemented in to the proposed commit for DigiByte.
At the time of writing, it’s my strong belief that ProgPoW is *the* single best possible algorithm for DigiByte to implement that supports / targets GPUs.
ProgPoW is also very flexible. Should things change in the GPU landscape, the variables within ProgPoW could be relatively easily tweaked to undo any advantage an individual manufacturer of GPU’s may have, or to refine the optimizations further as newer GPU generations come out to ensure a level playing field across hardware.
What Odocrypt has been able to do for FPGA mining of DigiByte, ProgPoW will do likewise for GPU mining, but hopefully on an even broader scale.
This is because like ASIC’s, most people don’t simply have FPGA’s lying around their home, and so there is still a decent investment required up-front in order to mine and participate in the security of the network. FPGA’s are (generally speaking) more readily available to people, and come in many shapes and sizes, rather than from just a couple of vendors who control almost the entire supply chain of ASICs.
GPU’s, although only created by AMD / nVidia, have multiple manufacturers behind them, such as MSI, EVGA, Gigabyte, Asus, and more. This helps to ensure a relatively competitive distribution, worldwide, with no single manufacturer dominating supply. ProgPoW has also been intentionally and extensively tuned to be as close to “equal” as possible, so as not to favor nVidia or AMD boards.
Speaking of worldwide, GPU’s are not geographically restricted in basically any way (Save for one or two minor exceptions), and many people have graphics cards in even mid-range computers or certain laptops (Though, laptop mining is never advisable due to heat reasons etc). This means the barrier-to-entry for many is effectively nothing, further increasing the broad participation in the network security.
Blockchain decentralization with GPU mining
In the interests of lowering the barrier-to-entry, the plan will also be to reset the DAG for the ProgPoW implementation in to DigiByte, rather than using the existing Ethereum / Ethash details. The benefit of this DAG reset is predominantly two-fold:
- It allows people on older GPU’s to contribute even if it’s less cost-effective / energy efficient, and possibly even a net loss.
- It allows more people to “try it out” even if their hardware is older, and introduce them to mining.
Keeping the DAG would effectively “force” users to utilize newer and more efficient hardware (with more GPU RAM), however those newer cards are already more cost-effective thanks to improvements in GPU computing and as such have quite the advantage as-is. However, allowing users with older hardware to participate at the start of this GPU-focused push seems the right thing to do.
When you couple the low-cost (often free) entry for many people, the supply-chain of the hardware, these all greatly benefit DigiByte for an open participation in the network
But aren’t ASICs more secure than GPUs?
Sort of! Yes, and no…
ASICs provide exponentially more hashrate compared to their CPU / GPU counterparts, that much is undeniable. The flip side of this is that there is a massive investment required to:
a) even attempt to create / manufacture a line of ASICs
b) purchase an ASIC as an end-user to begin mining
This further contributes to a more centralized but higher hashrate mining. It’s this higher hashrate that is of greatest benefit to Bitcoin when you look at the SHA256 mining, but they’re also by far the most centralized (when compared vs DigiByte’s MultiAlgo mining).
It’s a bit of a trade-off, and one that we’ve seen many other blockchains battle with:
- Do you want the highest hashrate, even if there’s fewer people protecting the network?
- Or, do you want more people contributing to the security of the network overall, even if the “green number” of hashes is lower as a result?
It’s this relatively delicate balance that we have to weigh up, and prioritize accordingly.
I believe that MultiAlgo gives us the “best of both worlds” (benefiting all aspects), coupled with our MultiShield difficulty adjustment.
DigiByte does not need to specifically choose one or the other, as we have 5x independent algorithms, so we can reap the benefit of all hardware types.
Why MultiAlgo can be so powerful
MultiAlgo, combined with MultiShield (Based upon DigiShield), can have the security of ASICs and FPGA’s, as well as the distribution and ease-of-onboarding that GPU’s and CPU’s offer.
DigiByte has recently implemented Odocrypt, an FPGA-focused algorithm that morphs itself every 10 days in order to avoid ASIC dominance (As, an ASIC that can reprogram itself is basically a FPGA, minimizing any reason to try and create an ASIC).
DigiByte still has:
- SHA256, the algorithm Bitcoin uses
- Scrypt, the algorithm Litecoin uses
- Qubit, an algorithm that DigiByte is the dominant hash-power in
- Skein, another algorithm that DigiByte is the dominant hash-power in.
Keeping in mind that each of these 5x algorithms has an equal 20% likelihood of finding the next block.
So we have the opportunity to replace one of these algorithms with a GPU-optimized algorithm. GPU’s are great for a number of reasons, as mentioned, because many people already have them (at home), they’re not really geographically restricted, and people who want to “get serious” about mining can simply purchase a second GPU to add in to their PC, or, setup a dedicated mining rig with several graphics cards.
Likewise, CPU’s are also good for participation, because even if your PC is lower-end, as opposed to a higher-end gaming PC, you can still participate in the security of the network. This again would help maximize the distribution of the blockchain, the and the mining.
This is why after ProgPoW, I would like to see RandomX implemented.
So it’s up to us now to pragmatically review the algorithms we have, and look to the future.
Why does this matter to me if I’m not a miner?
Mostly because the “infrastructure” around the blockchain needs updating.
Every time a protocol upgrade such as this occurs, once the miners have confirmed a new algorithm is locked-in, the rest of the blockchain has approx a week to ensure they are updated as well.
If they aren’t, they’ll basically stop working
If they are, then that’s great and they will carry on happily as the upgrade occurs. This should ideally happen without any end-user knowledge specifically needing to know the difference between the blocks prior to the upgrade and the blocks after the upgrade, except to say that they would know the blockchain is doing this to further increase the security. That, is obviously beneficial to them.
Alternatively if you are an end-user running a Core Wallet, you will need to upgrade as well, but if you’re using anything other than the Core Wallet then the wallet vendor will likely do all the work behind-the-scenes for you.
We need to decide which algorithm(s) will be replaced
There are obviously benefits to maintaining hash power dominance in an algorithm, it means there’s unlikely to be any amount of 3rd-party hash-power which could be used to attempt an attack on the network. This security is arguably Bitcoins biggest selling point, with SHA256.
However, SHA256 & Scrypt both have highly optimized and tuned hardware thanks to an incredibly competitive ecosystem. The landscape around Qubit / Skein is not as refined, with further hardware advancements entirely possible (or even highly likely), which could negatively impact the centralization of the mining for that algorithm
This is not something I personally have an answer for, or being completely honest that I have fully thought through myself.
However, here’s how I would like to see DigiByte in a year or two’s time:
- An ASIC mining algorithm
- Odocrypt, our FPGA focused algorithm
- ProgPoW, to focus on GPU mining
- RandomX, for CPU mining
- And a 5th algorithm of some description…
To be honest that 5th algorithm could end up being another ASIC algorithm (If we kept, say, SHA256 as one we don’t have dominance in then this one could be one we DO have dominance in such as Skein). It could be an ARM-specific CPU targeted algorithm (Which Cellphones and Raspberry Pi’s use), it could be staking… Or, it could be something else entirely, like a “Proof of Space” (Hard drive space) algorithm?
This is something that the DigiByte community will need to decide: Which algorithm do we want ProgPoW to replace?
And think further to the future, be “forward thinking”, and contemplate what you could see happening down the line too, perhaps with a CPU-focused algorithm such as RandomX or SIGMA.
Then, let’s think even further to the future and mull over what that 5th algorithm I mentioned above could be?
For now though, I ask the DigiByte community this:
