[HN Gopher] SP1: A performant, 100% open-source, contributor-fri...
___________________________________________________________________
SP1: A performant, 100% open-source, contributor-friendly zkVM
Author : plastic3169
Score : 56 points
Date : 2024-12-08 10:38 UTC (12 hours ago)
(HTM) web link (blog.succinct.xyz)
(TXT) w3m dump (blog.succinct.xyz)
| jrmg wrote:
| Can someone explain this in lay-person's terms?
|
| I feel like I read and 'understood' the text of the blog post,
| but I'm still none the wiser about what sort of things this can
| prove and what the values of those proofs is.
| Avi-D-coder wrote:
| Think of zk proofs as an extension of asymmetric cryptography
| to arbitrary logic.
|
| A zkVM makes encoding the arbitrary logic as easy as writing a
| normal Rust program. A proof is a probabilistic statement that
| a specific program run with some public inputs and maybe some
| private inputs was executed correctly.
|
| For crypto zk proofs are mostly for their succinctness
| property, not for privacy.
|
| Outside of crypto privacy is the more important property, let's
| say a government issues a signed document, I could prove any
| arbitrary statement about that document without revealing the
| document. We could use zk proofs for anything we use canonical
| documents for today and we would gain privacy. Will we do this,
| probably not, but it would be an improvement.
| knazarov wrote:
| I'm not involved in the project in any way, but I can probably
| give an explanation.
|
| This is a risc-v virtual machine that supports rv32im
| instruction set (the bare minimum + multiplication). You can
| compile and run programs there as you would on a usual
| microcontroller.
|
| The "ZK" thing means that you can pass program code + data to
| this virtual machine, and as a result of execution get some
| output and a short sequence of bytes that allow the "other
| side" to verify that the result of program execution is correct
| without having to re-execute the program. This verification is
| computationally cheap. In order to do the verification the
| "other side" only needs that sequence of bytes and a hash of
| original code+data.
|
| Blockchains use this in context of achieving "byzantine
| consensus", especially in cases where multiple systems that
| lack mutual trust are involved. Think for example about if you
| want to relay information that's been computed on one
| blockchain to the other. If both blockchains can prove their
| state transitions with such virtual machine, then it is
| possible to make a sort of trusted "event queue" between them.
| There are of course caveats that rollbacks can happen, so it's
| not a silver bullet.
|
| Not sure how this applies to day-to-day software, but the thing
| that comes to mind is that it could serve some cases where TPM
| (hardware modules) are traditionally utilized. The TPM assumes
| you don't have means to break the hardware, and so it can
| attest to certain computation by signing the result with a
| baked-in key.
| warkdarrior wrote:
| How secure is this "ZK" thing? Can I use it for DRM? Trusted
| hardware is a pain to use.
| knazarov wrote:
| Let's put it this way. If you can break it and are willing
| to commit crime - you can earn a lot of money. I'm
| personally not equipped to judge the level of security,
| because I'm not a cryptography researcher. What I
| understand is that the overall ZK cryptography space has
| been around for a long time, and basic properties are well
| researched. I tried to read the PLONK paper for
| entertainment purposes and it's quite easy to understand.
|
| If you want to prove a program, you need to convert it to
| what is called "arithmetic circuits". This is a clever way
| of saying "a system of polynomial equations". It is as if
| you're converting the code to logic gates but instead here
| you use arithmetic: addition, raising to a certain power,
| etc. It is a process called "arithmetization".
|
| The proof calculation involves folding this system of
| equations in various ways and collecting a "witness". Not
| sure if I'm explaining this correctly, but it's probably in
| the right direction at least.
|
| The problem with all ZK proofs is that the last bit of
| calculating the witness is very computationally expensive.
| What takes milliseconds to run on the CPU can take many
| hours to prove. And a lot of research is focused on clever
| mathematical tricks that allow to speed up the proofs while
| keeping the risks of circuit compromise low enough. As you
| may guess, the more bleeding edge the research the less it
| is peer-reviewed.
|
| So I'd say that "it depends".
|
| As for DRM - probably not. At least not in a way that
| companies installing the DRM would want it to work. They
| likely want you to be unable to decrypt something at all
| outside of a particular chip, and watermark the video on
| top of that to be sure that you're not screen-capturing it.
|
| UPD: there's a decent free into course into modern ZK
| cryptography: https://zkiap.com/
| yencabulator wrote:
| Zero Knowledge cryptography overheads are _ridiculously_
| too high to use for the thing DRM is usually used for:
| video.
| notfed wrote:
| > pass program code + data to this virtual machine
|
| If you have to pass the data, then how can this possibly help
| solve, as others have said, scenarios that prove something
| about data without revealing the data?
| bibabaloo wrote:
| You don't _have_ to, I think the parent poster is just
| giving an example of how this can be used.
|
| The "Zero Knowledge" part is that you can tell me "for this
| particular program code, I know an input that gives an
| output of 'foobar'" and I can be convinced that you're
| telling me the truth without seeing what that input
| actually is.
| knazarov wrote:
| In order to verify the proof, you only need a "commitment"
| to the fact that you passed specific input data. This can
| be in the form of calculating a cryptographic hash.
|
| Imagine that you represent a program and data as a flat
| byte array (which is the typical case for risc-v). Your
| program contains a prologue at the very start (0x0) that
| calculates the hash of the rest of the memory and checks
| that the hash is equal to some value hardcoded right after
| the prologue and if it doesn't match - then it panics. Then
| if you can prove that the VM followed all steps exactly as
| the hardware architecture prescribes, it's just impossible
| for the result to be any other way. What you need now is to
| only send to other side this prologue together with the
| hash. You don't have to reveal the rest of the memory.
|
| Of course I'm simplifying a bit, but I hope the idea is
| clear.
| DennisP wrote:
| One simple application is making blockchains vastly more
| scalable.
|
| For a blockchain to be secure you have to store each
| transaction on chain, with enough information so everyone can
| verify that it's valid. Normally this means storing the
| sender's signature, which is bulky.
|
| With ZK, you can bundle up thousands of transactions, skip all
| the signatures, and include a single 256-bit proof that all the
| transactions had valid signatures.
| Philpax wrote:
| Not as inscrutable as these things usually are, but I still don't
| really know what one would use this for. This world feels like a
| parallel ecosystem to traditional software, and the paths rarely
| meet.
| latchkey wrote:
| When people are working on things like this where I don't
| understand what it is used for, I tend to run towards it and
| find out as much as I can.
|
| It is easy enough to just google zk usecase and find all sorts
| of various applications. None may apply to _you_, but that
| doesn't mean it is not meaningful for _others_.
| zb3 wrote:
| Is this useful outside the cryptocurrency crap?
| Avi-D-coder wrote:
| Yes, it could replace all government ids, while allowing you to
| prove arbitrary statements about said signed government
| documents without revealing them (not saying it will happen).
| perching_aix wrote:
| Wouldn't those "documents" need to be code for that to
| happen?
| Avi-D-coder wrote:
| Those documents would need to be cryptographically signed
| machine readable data, json, a pdf (difficult).
|
| Getting governments, banks, and other trusted third parties
| to sign documents is very difficult, but is happening in
| some cases.
| latchkey wrote:
| Let's say the usecase is to prove that you're 21+ to enter
| a bar in the US. I don't want to have to hand over my ID
| with my personal information on it.
|
| On my phone, I could have the "proof", which can be
| validated by the door guard with a simple NFC device (ie:
| another phone) that is compatible with that proof.
| notfed wrote:
| I really doubt any cryptographic primitive can solve
| this; what's stopping me from lending my "proof" to my
| little brother?
| plastic3169 wrote:
| If you have digital id signed with government keys (like
| passport) you would prove that person has ID where the
| age is above 18, attached to this photo and that all the
| info comes from a single government sanctioned id.
|
| You don't need to conceal all the data. Just the bits you
| don't want to leak.
| latchkey wrote:
| The app shows your face on it and says it is 21+.
| quesomaster9000 wrote:
| The door guard needs to validate your face matches your
| ID. In you example you provide the door guard with proof
| that you are in real-time communication with a real ID,
| not that it's yours.
|
| A challenge response would be the door guard provides you
| with a picture of yourself, and then you run their
| verification code with the picture and your ID.
|
| However, you would also want to take into account multi-
| venue barring lists, which would require you to provide
| that you're not on a list of people (that you don't have
| access to).
|
| In reality, this gets complicated very fast, and I would
| much prefer to just show the door guard my ID rather than
| involve computers in any way shape or form, let alone ZK
| systems.
| latchkey wrote:
| The app shows your face on it and says it is 21+.
| mattdesl wrote:
| It lets you to prove a program without having to execute it,
| and without needing to send the potentially private bytes over
| the wire.
|
| Privacy and identity is one example; like having a proof of
| some record of your identity that you can submit to an app (ie:
| age, citizenship, # of followers on twitter), without the need
| to share your personal details.
|
| Succinct proofs is another application. If you have a
| distributed compute environment (think folding@home), you may
| want receipts that proves a user in the network correctly
| executed a program. With ZK, the idea is that it can be cheaper
| to prove a program executed correctly, rather than re-execute
| it.
| ikiris wrote:
| It amazes me that people invest portions of their life savings
| on what amounts to a distributed IOU system with no actual
| backing.
| anon3459 wrote:
| So i could write some complex logic with nested for loops and
| ofload it to the coprocessor
| jeff_carr wrote:
| L. Ron Hubbard has entered the chat.
| ikiris wrote:
| If its not obvious what a zKVM is, it shouldn't be unexplained in
| a headline with no commmentary.
|
| edit: The fact that its actually zkVM instead is even more
| confusing.
| plastic3169 wrote:
| I wasn't sure if adding text is considered good form when
| submitting a link to a project I'm not part of. I followed the
| guidelines and did not editorialize the title. Surprisingly,
| 'zkVM' is a unique acronym, and search only returned relevant
| results.
| raykyri wrote:
| For those looking for applications outside crypto, this might
| also be interesting: https://docs.ezkl.xyz/
|
| It's similar to Succinct but for proofs of ML models instead of
| RISCV. So you could generate a proof on some private data, on
| your computer or in a trusted environment, and submit the proof
| to show that you pass a fraud check without revealing any of your
| data.
| wslh wrote:
| I cofounded a company doing also this [1] you can check the
| repositories [2].
|
| [1] https://bitvmx.org
|
| [2] https://github.com/FairgateLabs
| quesomaster9000 wrote:
| While it's commendable that you're trying to extend BitVM to
| handle RISC-V...
|
| Why though? The dispute resolution game is eminently trollable
| and can be made very expensive by an adversary.
|
| Then you try to make it N-party, which reduces all of the
| security assumptions down to one which isn't verifiable on-
| chain and doesn't inherit any of Bitcoin's security.
|
| Yes, technically it's possible, should it be done? Probably
| not... Would I trust it? No... Does it come anywhere near the
| security of SP1... Absolutely not.
___________________________________________________________________
(page generated 2024-12-08 23:01 UTC)