Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hopefully, in the near future, we can just slap a recursive SNARK on scrypt (or any memory hard hash function for that matter) and call it a day.


The status quo that SNARKs require a lot of memory is simply due to the current available constructions; optimisations and new constructions will certainly change that.


While building snark proofs is very memory intensive in itself, it is far from optimization free, which is one of the primary requirements for a PoW...


Not my point. The idea is that you can obtain a cheaply checkable proof that you computed a memory bound function, such as a scrypt hash.


I did get your point. But if the onus to produce such a proof is on the miner before they can broadcast the next block, then the PoW is no longer optimization free.


Ah I see. It's true, but there's a good chance these optimizations would be discovered independently, progressively and percolate into the ecosystem. Turning to ASIC was an "optimization" that was replicated and copied. It's true that there is a lot more secret sauce to optimizing a SNARK, but if mining drives improvement in SNARK efficiency, I would call that a win.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: