PowMachina

Documentation

A proposal: a DAG from real data (Proof of Archive)

Status: research only. No code. It was written in answer to the question of what would give PowMachina something groundbreaking without breaking the properties of PoW.

This is not a decision. It is material that is also meant to say why it should not be done.

1. Where the question comes from

Lane G already forces a miner to hold 1–8 GiB and to read 1 MiB per hash randomly from it. That dataset is noise today — derived deterministically from the epoch number, so everyone generates it in 31 ms on a card and it is of no use to anybody.

The question is: what if it contained real data? Mining would then enforce their replication.

2. Why NOT “AI inference as PoW”

This is the industry’s most common idea and it does not work. That is not an opinion, it is a property of the problem — PoW needs work that is hard to do and trivial to verify:

the PoW requirement AI inference
verification much cheaper than the computation ✗ verification = repeating the inference
a ZK proof as a substitute ✗ an overhead of 10³–10⁶×, the “useful” part is a fraction of a percent
smoothly tunable difficulty ✗ an inference cannot be made 3 % harder
no trusted task-setter ✗ somebody has to choose the tasks

Whoever sells it either has a trusted task-setter (centralization), or the “AI” is a marketing layer over an ordinary hash. Copying it means putting a claim into your white paper that cannot be measured — exactly what the F3 gate taught us not to do.

3. What those who solved it do

Arweave — SPoRA and packing (the closest to us)

On every attempt a miner has to read a 256 KiB chunk of real historical data plus the Merkle path to it. Whoever does not have the data has nothing to present.

Arweave 2.6 tightened this with packing: the key SHA256(offset ‖ tx_root ‖ the miner's address) goes through RandomX, a 2 MB scratchpad is produced and its first 256 KB encrypt the chunk with a Feistel cipher. The result is that every miner’s copy is different — somebody else’s packed copy cannot be downloaded, you have to download the original and pack it yourself.

On top of that there is the recall range: one offset unlocks 400 challenges over a contiguous 100 MiB range, and a second, global range can only be used when you have a solution in the first one too — which forces holding the whole replica, not the convenient pieces. A VDF limits the number of recall ranges per second, so that the brake is the size of the storage, not the read speed.

The state: a weave of 353.5 TiB (July 2026), partitions of 3.6 TB.

Chia — Proof of Space

The plots contain no useful data. It is a pure commitment of space. Elegant, but it creates nothing.

Filecoin — Proof of Replication

It stores real client data and proves a unique copy, but the “sealing” is heavy and the whole thing is a separate market, not the consensus of a single chain.

The conclusion of the research: there is exactly one class of solution that is useful, verifiable and free of a trusted third party at the same time — random access into a real archive. And our B-core is structurally almost the same thing, only with random filling.

4. What it would look like for us

The change is a single sentence: an epoch’s DAG would not be derived from the epoch number but from a committed archive.

today:        DAG[i] = f(cache(epoch), i)         ← noise, everyone makes it themselves
the proposal: DAG[i] = pack(archive_chunk(i), epoch)  ← you have to have the archive

What stays untouched:

the PoW property does it stay? why
cheap verification ✅ a Merkle proof of the chunk, like light verification today
smooth difficulty ✅ the target does not change at all
no trusted task-setter ✅ if the archive’s root is in the genesis
it cannot be precomputed ✅ the data has to be had, not computed
lane C, finality, MESS, the rotation rule ✅ untouched

5. The numbers that decide

How much data we can carry at all

With the parameters of the time (a 256 kB block / 120 s; today it is 96 kB / 30 s):

share of a block for data the archive’s growth
5 % 3.2 GiB/year
10 % 6.4 GiB/year
25 % 16.0 GiB/year

And the DAG grows like this:

the DAG’s size
after 1 year 1.20 GiB
after 5 years 2.03 GiB
after 10 years 3.06 GiB
after 34 years 8.00 GiB (the cap)

Here is the first problem. If the DAG is to be the whole archive, the archive can grow at most as fast as the DAG, that is ~210 MiB/year — 3 % of what 256 kB blocks could carry. Either the DAG is untied from the 8 GiB cap (and we retire small cards), or the DAG is only a window into a larger archive.

Arweave solves this with partitions of 3.6 TB — a miner holds as much as they want and their chances grow with the number of partitions. That is a different model from our “everybody has the same thing”.

For comparison

Our 8 GiB cap is 0.0023 % of today’s Arweave weave. We will not be a competitor to Arweave and there is no point in building it that way.

6. What we would have to solve

Which corpus. The chain’s own history is the cleanest (it grows with us, nobody has to commit it, and keeping it is a value for the chain in itself). An external corpus (Wikipedia, arXiv, scientific data) sounds better in a pitch, but somebody has to commit its Merkle root — and that is a governance decision, exactly the thing this project avoids.

The bootstrap. Today a new miner produces the DAG in 31 ms. With real data they have to download it. That turns 31 ms into hours and it is a barrier to entry — that is, exactly the opposite of what we want (“a coin miners will not be afraid to mine”).

Availability at the start. Until the archive is replicated, a new miner has nobody to pull it from. The classic chicken-and-egg problem Arweave solved with years of growth.

Packing or not. Without it a pool can hold one copy and serve chunks. For us bandwidth prevents that for now (1 MiB per hash), but with a larger archive and smaller reads that would stop holding. With packing through RandomX (which we already link) every miner would have their own copy — but a downloaded copy has to be repacked, which lengthens the bootstrap further.

Another gate. It is a change to lane G, so it means measuring again and the right to say no again.

7. The recommendation

Do not do it now. The reasons, in order:

  1. The chain has never run. Adding a new layer to something that has not mined a single block from a stranger is building on sand. The testnet first.
  2. The bootstrap goes against the main goal. “Download a binary and mine” becomes “download a binary, then X hours of archive, then repack it”. That puts off exactly the small miners this coin is for.
  3. The sizes do not work out. The 8 GiB cap allows ~210 MiB of archive a year. That is interesting for the chain’s own history, not as a “public archive”.

What to do instead — the cheap version of the same idea:

Fill the DAG with the chain’s own history, once there is enough of it. No governance, no external corpus, no question of “who chooses the data”. Mining would enforce that every miner holds the history — a value Bitcoin does not have (there it is held by whoever wants to).

The pitch would be: “you cannot mine without holding the chain’s history.” Measurable, true, and it does not add a gram of trust in a third party.

But even that only after the chain has run for a year and has that history at all.

8. Sources