Usually when I go and read the github and zulip threads the reason for paused work comes down to the fact that no one has come up with a design that maintains every existing promise the compiler has made. The most common ones I see are the feature conflicts with safety, semver/encapsulation, interacts weirdly with object safety, causes post post-monomorphization errors, breaks perfect type class coherence (see haskells unsound specialization).
Too many promises have been made.
Rust needs more unsafe opt outs. Ironically simd has this so it does not bother me.
When I read these sorta of articles I ask if I would invest today if given the opportunity. Currently the answer is still yes.
They have barely even monetized users. I think it's possible the bubble pops and openai still continues to win.
So much of this article is copium pretending the world is not radically changing. Even if progress stops today massive numbers of jobs will be and are being replaced. I wish it wasn't true but what I wish has no bearing on reality.
At some point self driving cars will need their own loser driving laws.
Perhaps allowing them to drive around school buses is not a good idea, although personally I have felt far safer biking or walking in front of a Waymo than a human. But rules few humans follow, like rolling stops, and allowing them to go 5 over seems like a no-brainer. We have a real opportunity here to br more sensible with road rules; let’s not mess it up by limiting robots to our human laws.
Corporations gain control of public spaces by allowing corporations to cast other road users as incompetent. Much the same as GM, etc., did with jay walking laws in the US.
Distinguishing between human and robot drivers in this way benefits only corporations and the politicians they pay.
This is a discussion about why autonomous vehicles should have different rules than human drivers, not about the energy efficiency of stop signs. Don't be a dick, dick.
Indeed, the memory model has a decent impact.
Unfortunately it's difficult to isolate in measurement.
Only Apple has support for weak memory order and TSO in the same hardware.
Oh there’s an interesting idea. Given that Linux runs on the M1 and M2 Macs, would it be possible to do some kind of benchmark there where you could turn it on and off at will for your test program?
The solution is strong compile time and runtime guarantees about code behavior.
The author is right there's no way an individual can audit all that code. Currently all that code can run arbitrary build code at compile time on the devs machine, it can also run arbitrary unsafe code at runtime, make system calls, etc..
Software is not getting simpler, the abundance of high quality libraries is great for Rust, but there are bound to be supply chain attacks.
AI and cooperative auditing can help, but ultimately the compiler must provide more guarantees. A future addition of Rust should come with an inescapable effect system. Work on effects in Rust has already started, I am not sure if security is a goal, but it needs to be.
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).
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.
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.
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.
If you're going with a "digital id signed with government keys", then we don't need a ZKP, we can just use digital signatures. A certificate from the government that says "the holder of this id is 18+" is all the information that needs to be contained in the certificate.
That is a moving target. I could be 17 today and 18 tomorrow. Also it is not feasable to make all the different variations of ID but they do give out single one with all the info.
Part of the problem is that "normal" digital signatures create correlation factors that can be used to track/profile users, whereas a zero knowledge proof (over knowledge of a valid signature) could prevent this.
How is this different from showing a non-digital driver's license that says you're 21+? Underage kids borrow each others' driver's licenses, so they can borrow each others' phones.
I'm failing to parse your argument here. We're talking about an example usecase of zkProofs as a way to better explain the technology. We're not trying to solve the problem with every different random way to sneak into a club that you can think of.
I actually was a club owner in San Francisco at one point in time. Even went through the ABC training. Got sued at one point by the ABC cause they snuck someone in under age. No system is perfect.
But, I'll tell you that having someone show me a cell phone with my picture on it, nicely large and backlit and saying I'm 21, is a great solution to requiring people to present an ID that could come from one of 1000 places.
> But, I'll tell you that having someone show me a cell phone with my picture on it, nicely large and backlit and saying I'm 21, is a great solution to requiring people to present an ID that could come from one of 1000 places.
I agree, but I already have a California DMV app that does this. It doesn't need a ZKP.
> I'm failing to parse your argument here. We're talking about an example usecase of zkProofs as a way to better explain the technology.
Indeed my argument is that ZKP seems unnecessary in this example, and yes it's extremely hard for me to appreciate the usefulness of a ZKP with an example where it seems useless.
> I agree, but I already have a California DMV app that does this. It doesn't need a ZKP.
What happens when you aren't in California? Or what happens when someone from outside of California comes to a bar.
> Indeed my argument is that ZKP seems unnecessary in this example, and yes it's extremely hard for me to appreciate the usefulness of a ZKP with an example where it seems useless.
Then go find better examples if you're this interested.
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.
Too many promises have been made.
Rust needs more unsafe opt outs. Ironically simd has this so it does not bother me.
reply