Memory management : pari_init

[omershlo]

At the moment, pari_init is called with constant 1Mb of stack memory for each function that requires the binding to class group function.

optimize 1: remove pari_init when unnecessary
optimize 2: minimize allocated stack size
optimize 3: Make the stack size dynamic based on inputs.

[0xmountaintop]

I test Wes19 VDF using https://github.com/KZen-networks/class/blob/2a8fa3bb58a2c177ccb1a429887d680988580b68/src/primitives/vdf.rs#L158

When changing t to >257, it seems memory overflows. It will be necessary to support big t if we want to make the codes sufficing real-world need.

[omershlo]

What is the error you get?

[0xmountaintop]

What is the error you get?

by running

cargo test --lib vdf

I get

running 2 tests
  ***   bug in PARI/GP (Segmentation Fault), please report.  ***   Error in the PARI system. End of program.
error: test failed, to rerun pass '--lib'

sometimes I get

running 2 tests
  ***   impossible inverse in dvmdii: 0.  ***   Error in the PARI system. End of program.
error: test failed, to rerun pass '--lib'

and sometimes

running 2 tests
  ***   sorry, negative definite t_QFI is not yet implemented.  ***   Error in the PARI system. End of program.
error: test failed, to rerun pass '--lib'

so it seems it's not because of using 10 for t. Because rerunning it with 10 these errors may still occur.

[0xmountaintop]

gmp_classgroup in https://github.com/poanetwork/vdf works quites stably.
But their Wes19 implementation is quite complex.

I am thinking following the simplicity in https://github.com/KZen-networks/class/blob/master/src/primitives/vdf.rs, but switch to their gmp_classgroup for classgroup.

[0xmountaintop]

gmp_classgroup in https://github.com/poanetwork/vdf works quites stably.
But their Wes19 implementation is quite complex.

I am thinking following the simplicity in https://github.com/KZen-networks/class/blob/master/src/primitives/vdf.rs, but switch to their gmp_classgroup for classgroup.

or maybe https://github.com/cambrian/accumulator/blob/master/src/group/class.rs

[omershlo]

1. about the errors, you should run with one thread, see: https://github.com/KZen-networks/class#test
2. using Cambrian/POA class group implementation is actually a nice idea! I think it will be a bit complex to pull off but worth a try. I would go for Cambrian first.

[0xmountaintop]

2. using Cambrian/POA class group implementation is actually a nice idea!  I think it will be a bit complex to pull off but worth a try. I would go for Cambrian first.

TBH, POA's seems more modular and easier to pull out. Besides, POA's should be more efficient: they use GMP whereas Cambrian uses rug::Integer.

[omershlo]

ok, lets go with POA first !