This is big for both Zcash and the emerging decentralized internet. The full details are available on our blog: Halo: Recursive Proof Composition without a Trusted Setup - Electric Coin Company
Amazing work, @ebfull, @str4d & @daira!
I thought it was interesting to see one of the code examples is a recursive proof of Bitcoinās proof of work. It isnāt mentioned explicitly in the paper, but presumably this can be used as a succinct proof of proof of work (useful for SPV)? In which case, it would also be interesting to understand the complexity of deployment within existing smart contract systems such as Ethereumās EVM, and whether or not the gas cost would be prohibitively expensive to verify a proof.
Yeah, weāre working on a PoC for that example right now. I think at the very least it seems like an interesting alternative to checkpoints (in Bitcoin) when you donāt trust most of your peers to be feeding you the correct blockchain. Unfortunately the verification costs involve at least two large multi-exponentiations so Iām not sure that our existing protocol will be ideal for Ethereum. Maybe future, improved protocols based on our ideas will though.
What are the benefits of ZCASH and how are they planned to be put into practice?
No trusted set up and scalability! Boom
Any idea how long it will take to integrate it into Zcash? It might help us determine funding levels for the next 4 years.
(It is cool but I kinda liked the trusted setup, dont @ me)
cool work. follow it !
So if Iāve understood this correctly, a new wallet wont need the blockchain, just a proof for its initial state.
No heavy download, fits on a phone, good to go almost immediatly. Holy cow!!
Edit: Hoping we get a āmuggle versionā of the paper at some point, even if its just a list of āthings it can enableā.
Could you please link me what youre reading? I am no cryptography expert but I do have a batchelors in math and a masters in cs I might be able to handle itā¦
Here yāgo, youāll know what an aneurysm feels like when youāre half way through - its heavy stuff.
Thank you very much I probably wont be able to handle it since I havent been working in my field after finishing uni and that was like a little over 10 years ago, but Im optimistic by nature.
Can someone explain the difference between Spartan and Halo please? Im not too sure.
https://eprint.iacr.org/2019/550
Okay, I am a bit better informed now. I thought this was separate work. from spartan, which I guess it kind of is. but it builds upon it. nice work.
nope read more. confused again. oh well.
Spartan is an example of a SNARK (in theory) though it has large constants so Iām unsure if it will work well in the recursive context. Halo is an attempt to take proving systems (Sonic built over the inner product argument, for example) that arenāt necessarily succinct but still achieve recursive proof composition with them.
Iāam not that euphoric yet until there is some audit and/or itās clear how security plays out with HALOā¦
ā¦
In other words, the miners will be responsible for both the proof generation and verification of the final ZK-SNARK. This resembles the case where one plays the roles of both the player and judge in the field simultaneously. It is also not clear how the subsequent protocol (if there is any) built on Halo would attempt to resolve this issue. Neither the Coda team nor any existing academic work provides any security argument to justify this action. Bitcoin can legitimately claim its blockchain resists 51% attack. Whatās the security level of the recursive proof framework when most of the miner computing power are dedicated to proof generation instead of verification? 1%? 0.1%? One cannot simply just trust the protocol developer without the support of any formal argument. I thought the whole point of blockchain is āin math we trustā?
ā¦
This post appears to misunderstand both the application of recursive validation, and the Coda blog post it is referencing. If the miners are the ones creating recursive chain proofs, then it should be obvious those proofs arenāt solely going to be verified by themselves:
- If the recursive proofs are part of the consensus rules (forcing miners to create them), then they will be verified by other full nodes as well (necessarily, otherwise the chain they have canāt be valid).
- If the recursive proofs are not part of the consensus rules (e.g. if they were only used for light client bandwidth improvements with an SPV-style security model), then thereās no difference between a miner generating these proofs, and some other entity (e.g. a wallet provider) doing so. And depending on what the recursive circuit covers, you could in fact have stronger security properties than SPV (because the proofs could themselves bundle in proofs that the block contents are valid).
Are there scheduled plans yet for an audit? If so when will this occur?
Weāre a while away from audits; we are still in the R&D process, and thereās little point in auditing something we arenāt certain will be used. Halo is still in development (in particular, there are various optimisations being implemented), and there is so much progress being made in the field at the moment that there are likely to be useful improvements made over the coming months.
Hey Iām just curious about current progress of Halo. Is there any roughly estimated timeline? I presume it would take several years at least for implementation of a totally trustless MPC in zcash main network?