Managed to beat the Rust implementation with a Zig implementation ⚡️
Initially it was slower, but, moving to use the same libsec256k1 C implementation for operations on SECP256k1 curve, now the Zig version is slightly faster.
113 micro seconds for the End to End BDHKE!
Zig is fast ⚡
nostr:note1xjwgawu8jnv3m9twle9f2h7hpf58txacdvasfdhpcc9hahezycks5jsdxj
Got it.
Sure, I will onboard more than one don’t worry 😉
My pleasure!
But how did you notice haha ?
Me today: write BDHKE scheme in Zig (https://github.com/AbdelStark/coconut).
Benchmark it: Oh wow it's super fast, 1 millisecond for the end to end scheme.
Find the Rust implementation (https://github.com/ngutech21/moksha) and benchmark it: it's about 10 times faster than my Zig implementation 😭
Gg Moksha folks! 🦀 is blazingly fast damn.
I suspect there might be a gap in terms of performance between the Secp256k1 implementation of the Zig std lib and the C implementation (the secp256k1 crate being a Rust wrapper library for Pieter Wuille's libsecp256k1 in C).
Zig benchmark:
Rut benchmark:
Yo #nostr fam, anyone going to Surfin Bitcoin this year ?
I will be there and giving a talk about Scaling Bitcoin using STARKs.
Bring back OP_CAT.
What about Zkfying Cashu guys ?
Implemented step 1 of the Blind Diffie-Hellmann Key Exchange (BDHKE) in Cairo.
This scheme is used in Cashu (ecash protocol for #Bitcoin).
Tested against the Nutshell reference implementation and got same results for blinding of secret messages.
Would be cool to implement the other steps to have a version of Cashu protocol that is provable with STARK proofs.
Macro is horrible, risks of escalation of war, Asian Stock Markets crashing like never, capitulation from large funds.
Nayib Bukele knows it well, Printer is coming.
That's why he was smart enough to bet the future of El Salvador on #Bitcoin, and history will prove him right.
No doubt about this.
Meanwhile somewhere in California, Robocop 1.0 enters the room.
https://video.nostr.build/2d27583d10235ef28b4ab2401f71a5043975def043d5b3386f9cff6c078d1dd3.mp4
I'd Buy That for a Dollar!
👀
Totally makes sense yes.
I will work on documentation and examples.
Yep mate you are right.
I had this in mind. The reason i did not do it yet is because for my POC the Job request kind is very specific to a single example which is the proving of a Fibonacci sequence. The parameters don't really make sense for a generic scheme.
I need to think about how to make a standard format for a Job kind that would be `ZK_GENERATE_PROOF` or something like this.
Or maybe it's better to have different kinds depending on the type of proof and implementation, so for my case it would be more: `ZK_GENERATE_CIRCLE_STARK_PROOF`.
Anyway, i am open to feedback and advise on this question.
Yes the overhead can be very big depending of the size of the computation.
Possibly it can be 2 order of magnitudes slower and more expensive.
#Nostr #FreedomOfSpeech Protocol
Webassembly directly I don’t think so.
However there are RISC Zero, SP1 or Jolt that enable to prove risc-v instructions (and so any language that can compile to risc v target, i.e directly)
Thank you.
In general I would say there are 3 options to generate a ZK proof for a specific computation:
- build custom circuits: this is a very low level task that requires deep knowledge of moon math and cryptography, super hard to maintain.
- use a general purpose ZK VM like Risc Zero and prove the execution of your existing code you want to prove. The benefit is that you don’t have to rewrite the code you can use it directly as is. However there is a big performance overhead
- rewrite the code you want to prove with a specialized high level ZK DSL like Cairo (this is the technique I am using). Maximal efficiency.
Provable Bitcoin Script VM is moving forward nicely, we implemented more than half of the opcodes in a week 🤯
https://github.com/keep-starknet-strange/shinigami
Of course in the remaining ones there are some that are much more complex to implement, but this is very promising.
