search

mattrglobal / pairing_crypto

A library for pairing based cryptography
Apache License 2.0
14 stars 7 forks source link

feat: redesign generators #82

Closed dev0x1 closed 2 years ago

dev0x1 commented 2 years ago

Closes #53

Generators are used at least thrice (in the domain , B, and other computations) in all BBS operations. So we should calculate/cached it once and use this cached result in all 3 places, this is what we do with MemoryCachedGenerators. With the intended DynamicGenerators design(where we calculate a Generator on fly for memory-constrained systems), if we calculate once and cache the result of the computation, its original purpose of it is defeated. And if we don't do it and calculate all generators thrice, it will be very costly performance-wise. So dropping the idea for now for DynamicGenerators and will see in the future when it comes to the actual use cases.

BasileiosKal commented 2 years ago

This looks really good to me. I'm just not 100% sure I'm seen the reason of separating the memory-cached and dynamic generators in this way. Wouldn't having "both" be the goal?? Meaning it would be nice IMO to have some "cached" generators, but you could also expand them if need be, using the n, v state??

dev0x1 commented 2 years ago

This looks really good to me. I'm just not 100% sure I'm seen the reason of separating the memory-cached and dynamic generators in this way. Wouldn't having "both" be the goal?? Meaning it would be nice IMO to have some "cached" generators, but you could also expand them if need be, using the n, v state??

Yeah, there could be many approaches, like pre-calculated generators stored in a file or maybe some small no. of generators present in the code as a lookup table or a hybrid of these. In this PR, I have added an interface and 2 implementations. Depending on the deployment use case, we can add more of these.