Towards a Green Model of Proof of Work: The Case of Arweave 2.6
If you are a loyal Arweave News reader, you already know about the Arweave 2.6 version and its main characteristics. If not, that is not a problem; we get you covered anyway: check this article that summarises what Arweave 2.6 is, or check this blog post if you want a more in-depth read.
Today we want to focus only on one attribute, which is somehow derived from the Arweave 2.6 mechanics: energy consumption.
Most of the criticism of blockchain networks was directed toward the power consumption of those networks, especially the ones relying on Proof of Work consensus. Arguably those networks are the most secure blockchains, but at the expense of power consumption and hardware requirements (to mine efficiently on a PoW-based blockchain like Bitcoin, one has to deploy specialised hardware nowadays; somehow in contradiction with the idea to let everyone participate in the network with consumer grade available hardware – with, let’s say a simple PC).
This criticism led to the creation of Proof of Stake consensus mechanisms. Arguably way more power efficient but less secure. Now, the topic of this article is not to compare those two consensus mechanisms, so if you want to know more about them, you can check it out here.
While in PoS systems, security is granted by the amount of staked assets (an attack could occur if somebody will stake the same amount of assets as those already staked), in PoW systems, the security is weighted in the height of hashrates.
Where does Arweave stand? It uses Proof of Work. How can Arweave be power efficient if it relies on PoW? Well, we asked DMac, one of Arweave’s core developers.
Q: If one searches for “hashrate” on google, one will find many articles about how it is an essential metric in calculating the security of a POW network. The higher, the better. Is this assumption valid? Is the value of the hashrate the single metric in evaluating security on POW?
A: Pretty much. It’s the thing that prevents sybil attacks on the network. The higher the hash rate, the more difficult it is to take over 51% of the network and start censoring transactions.
Q: Ok, but we are willingly restricting the hash rate to around 800/s/no de to stop the expensive “arms race” favouring costly machines rather than efficient machines for the task at hand: replicating Arweave’s data set. So, what’s the “catch”? How can Arweave remain viable from a security standpoint and still curve down the hashrate?
A: It’s because it’s no longer just hashing. There’s “useful work” being done for each hash. With 2.6 there’s a maximum amount of hashes a single replica of the arweave data set will generate… to get access to all those hashes, you have to store 100TB of data, and you have to get that data from the network.. taking several days. If you wanted to generate a 51% attack, you’d have to be storing 51% of the replicas on arweave.
In a simplified situation… there are 1000 replicas of the data stored by miners (And that’s just the hypothetical amount of replicas.. I’ve seen Sam quote a number in the 4000s), each one 100TB in size. That means the total amount of storage is … I don’t even know…quite a lot of PetaBytes?
Q: Ok, so basically, with 2.6 we are replacing the need for a high hashrate, which is somehow a volatile metric, dependent only on how many miners are on the network, and how high is their collective computing power, with a ratio between the size of the data set – which arguably will go only up, and the number of replicas stored by the miners. Not only are we managing to make it greener than normal PoW, but also we are composing security over time. Am I correct?
A: Assuming the number of miners stays about the same and the weavesize grows.. yes.. an attacker will have to sync and store more and more data if they want to attack the network.
Q: How much is Arweave PoW right now, and how much is something else? And what does represent this – something else?
A: Arweave today (Arweave 2.5) is PoW, but limited by the transfer speed of SSDs. With 2.6 the cryptographic clock limits the “top speed” even more so that HDDs can be used to mine. 2.6 is swapping a limit enforced by physical limits of SSD drive speeds and replacing it with a limit enforced by a verifiable delay function (cryptographic clock). So already today, since SPoRA, Arweave has been using “useful work” as opposed to pure PoW hashpower for consensus.
Q: Now, returning to the subject at hand – the green side of 2.6. can you estimate how many watts/h an optimized miner could consume?
A: Yeah, [although] I’m not a miner…at the beginning, when Arweave was pure PoW, it could be a LOT, computing billions of hashes. With SPoRA, it went to thousands…with 2.6 it went to hundreds. A laptop cpu can do millions per second, so really, the power is using some small portion of a consumer-grade CPU and then running SSDs at full speed 24h a day. SSDs are pretty efficient power wise though…because they have no moving parts, so you might say a full replica is 25 of 4TB SSDs and SPoRA (Arweave 2.5) lets you run them all at max transfer speed.. if you have enough CPUs…so.. before.. with a full replica.. and 25 4TB SSDs, all recalling chunks at 7300 MB/s you could keep a lot of CPUs busy. Now (with Arweave 2.6), even with that same hardware, you wouldn’t be able to use one CPU fully.
Q: From what I see, one can use the most power-efficient CPU, no GPU, and the most energy-hungry part will be the storage. from what I know, a 2 TB HDD (being 6x more power-hungry than a SSD, but being cheaper) consumes around 6W/h.
A: Yes, there’s further optimizations, though, in 2.6, where the data is being read in 200MB stripes, so the read heads don’t have to move as much.
The tuning is set so that if you store the full weave, you need to read at about 400Mb/s from an HDD which is roughly 1/2 its performance capability.
Q: My laptop consumes when the GPU is active around 230watts/hour. It is safe to assume that a miner that stores almost the entire Arweave data set could use the same amount of energy of basically…a consumer-grade laptop?
A: Yeah, that’s a reasonable estimate. I suspect it’s even a tad higher, depending on the hardware configuration.
As you can see, talking about power consumption in blockchain, is a rather complex endeavor that ultimately leads to the core feature of any blockchain: how the network manages to provide immutability in a decentralized and inclusive manner.
Also, it would be best to consider the exact traits a network offers in exchange for power consumption relative to your own goals.
In the case of Arweave it’s simple: do you need decentralized, immutable, permanent storage? Then there is no greener solution. Actually, in this respect, Arweave 2.6 could be considered overkill. Not only that it makes for probably the most power-efficient PoW, but it transforms almost all the power consumption into meaningful work for the network, assuring one of the highest rates of redundancy in the world.
If you want to learn more about Arweave 2.6 and how Arweave managed to arrive at this point directly from DMac, check out this vid. It will be worth your time.