tromp



Offline



Activity: 662

Merit: 568







Hero MemberActivity: 662Merit: 568

Musings on Proof of Disk Space September 30, 2019, 02:00:05 PM Merited by odolvlobo (1) #1 I'd like to explore some simple-minded proof of disk space (PoD) design based on

the idea of separate PoD and tx chains, a characteristic shared by Burst and Chia.

I want to keep things as simple as possible. In particular,

- no proof of time

- no need to process more than a few disk blocks per second



The PoD chain will be as deterministic as possible, to prevent the possibility

of grinding attacks. It will not commit to any transaction data.

Each PoD block will just have the following fields

- height

- previous block hash

- timestamp

- farmer public key

- PoW solution.



A PoD block is valid if its timestamp is larger than the previous block's, and



hash(prePoW) <= hash(PoW solution) < hash(prePoW) + 1 / difficulty



where prePoW consists of all fields apart from the PoW solution, and hashes are

interpreted as fractions in [0,1). The underlying PoW can be anything, either

hashcash or some memory hard asymmetric PoW with instant verification. We need

each PoW instance to commit to the farmer public key though, so that no

grinding is possible over the public key. Valid PoD blocks with timestamps in

the future are not considered until the local time catches up.



The separate tx chain will have blocks of tx data, each of which links to a

same-height PoD block and is signed with the public key in the latter.



The farming process

=============

I.e. how to extend the PoD chain.



Each farmer computes prePow hashes at increasingly larger timestamps and

looks for a close enough stored PoW solution hash on its hard disk.

On success, it regenerates the PoW instance and solves it to complete the new PoD block.



Storage of PoW hashes

===============



Let a PoW record be a pair (index, hash) where the 64-bit index allows us to

reconstruct the PoW instance, and hash is the most significant 64-bits of the

hash of the PoW solution.



A typical 4TB hard disk costs $100. Let's use up to $100 worth of leased mining

hardware and electricity to fill the disk with bucket sorted 12-byte PoW

records, where the most significant 32 bits of hash are used as bucket

selector. Each of the 2^32 buckets will have on average 4*10^12/2^32/12 ~ 78

hash-sorted records, taking up under 1KB, or 2 512-byte disk blocks.



Work per PoW record

==============



If we optimistically assume that electricity costs $0.04 per KWh and that we

spend $10 on electricity, then that gives us (10 / 0.04) * 3600J = 0.9 MJ of energy.

Dividing that over the 10^12/3 PoW records gives 2.7 uJ (microJoule) per PoW

solution. With memory access costs measured in picoJoules per bit, that could

involve on the order of a million bit accesses.



PoW solution rate

============



If we want to fill the disk in about one month, or 30 days, than the mining

hardware will use 250KWh / (30*24h) ~ 350W, and will need to produce 10^12/3 /

(30*24*3600) = 128600 solutions per second.



PoD as PoW amplification

================



Although this scheme aims to substitute disk space for work, it still involves a

large amount of work in filling the disk. This is mostly due to PoW records

being so compact. One would like to force them to take more space, but I do

not see any way to do so. Perhaps this is the real reason that Chia needs

to use proof of time.

This scheme can also be seen as a PoW amplifier. A 30 day run of a mining rig

is captured on disk so that it can be re-used for many years.



Questions

=========



- Is there some big error in my calculations?

- Or in the logic of this scheme?

- Is there anything left to grind?

- Is anything to be gained by not storing PoW records?

- Is anything to be gained by storing PoW records differently?

- Can we force larger PoW records?

- Is the assumed mining hardware within the realm of feasibility?

- Will the hard disk manufacturer have to prepare disks, presumably in a place with very cheap electricity?



-John