I’m sorry but I still don’t understand what data structures you expect a ECC library to have and what it has to do with Vulkan. Could you give an example?
The API I intend to expose will deal with Hashes and Points in Affine and Extended form but most of it can be treated as opaque byte arrays.
- BlazeSync is an optimization. ZecWallet is clearly optimized for sync. I guess you don’t want NightHawk and Unstoppable to participate?
- Users see the performance and don’t care if the developer has optimized or not
- Benchmarks provide a baseline for further work. You need a benchmark to measure your progress against it.
- I’m replying to your usage of the word slightly
I feel it downplays the improvement achieved when the increase is at least 2x.
WarpSync is open sourced in its own crate with only dependencies on librustzcash. This is as upstream as it should be. Users of a librustzcash don’t need to use warpsync if they don’t want it and if they want it there are no extra dependencies than what they probably already use.
Even librustzcash is moving in the direction of breaking down into smaller crates.
Whether ECC SDK, NH or U want to use WS is beyond my control. If you expected a drop-in replacement of the existing sync algorithm, I’m afraid that it is not the case. WS uses a different API because it needs to.
I think we should try to increase the size of the Zcash dev community instead. I have provided a list of suggestions during the ZOMG - What to build meeting. I’d rather not have developers use libraries without understanding how they work, because they are too busy.
It’s good to hear. Again, I’d like to have an open set of scenarios and metrics in order to objectively measure sync progress. I’d be best if they were chosen by the user community with participation from wallet owners. At this point, it is impossible to include ZecWallet or NightHawk because one has to share the seed phrase. That’s obviously not acceptable for a public study. Adding support for viewing keys would go a long way towards transparency.
That’s the goal of the first phase. I expect people to be compensated for POC work. It’s standard practice.
This project requires skills in:
- zcash protocol: to understand which part of the protocol can be improved
- software engineering: define API, integrate with platform libs, optimal data structures, parallelism, concurrency
- cryptography: knowledge of ECC, field math and the various algorithms used to speed up operations (algorithmically and mathematically)
- GPU programming: Which functions would benefit from being on GPU, how to use VRAM efficiently
I think it’s a rare combination of skills, so I provided a link to a previous project in order to give the community prior work experience in these areas.
Warp Sync was about 1-3. This adds 4.
If you want, I can give you technical specifications for phase 1. The project goal and deliverables are well defined already.
I will provide an example of integration since it will be in ZWallet as a separate crate. To be clear, it will have a different API but it will not depend on WS. It will be similar to the jubjub crate.
As it stands, I would be working by myself.
I will share the progress with the community as always.
Andre and Michelle have provided an update in a CoinPayments Integration - #10 by ml_sudo
Unfortunately, as you said, it ran into the risk mentioned as the vendor decided to go a different direction.
The ZEC/BTCPayServer was not funded.
I offered to look into reusing some of the work done in the CP integration but on top of BTCPayServer.
Once I have a proposal, I will submit it on the portal.
I’m 100% OK with that. Grant money should be used on the projects that bring the most value to cash.
On a parting note, I’d like to say that even 7 years after, secp256k1-cl is my most starred and forked repo. I think it’s because:
- there is still ongoing interest in ECC on GPU (last star was a week ago)
- it’s difficult to do.