zama-ai / fhevm-go

fhevm-go is an open-source library used to easily integrate the fhEVM into an EVM-compatible blockchain.
Other
21 stars 15 forks source link

Add support for 1, 2, 3 and 4 bits for rand8() #41

Closed dartdart26 closed 1 week ago

dartdart26 commented 11 months ago

Implementation would be something like TFHE.randEuint8(uint8 upperBound) with valid values 2/4/8/16/...:

TFHE.randEuint8(2); // Value between 0 and 1 TFHE.randEuint8(4); // Value between 0 and 3 TFHE.randEuint8(8); // Value between 0 and 7 TFHE.randEuint8(16); // Value between 0 and 15 ...

dartdart26 commented 11 months ago

@immortal-tofu Should we pass the number of bits or the upperBalue? If it is upperBound, it would instead be 1, 3, 7, 15, 31 and so on to pass as upperBound, because 0 is always included.

The other alternative would be to pass number of bits, i.e. 1, 2, 3, 4, 5, 6, 7 and 8.

immortal-tofu commented 11 months ago

We had this discussion with @mortendahl and it seems to him more logic to have 2/4/8/16. He refers to some implementation in Rust https://rust-random.github.io/rand/rand/distributions/struct.Uniform.html

dartdart26 commented 11 months ago

Cool, I will explain the behaviour in the function doc and state it is not inclusive.

It will fail if the upper bound is not a power of 2, will explain that too.

mortendahl commented 11 months ago

It seems that non-power-of-2 uniform sampling could happen in the near future (at some performance price)

dartdart26 commented 11 months ago

@mortendahl do you think we should allow any bound for the mock? It would be easily doable now. I guess the question is if we want to expose non-power-of-2 in a separate API call to cater for an explicit higher price for the FHE version.

immortal-tofu commented 11 months ago

Good question. I'd say we should keep power of 2 and we'll see later for uniform randomness.

dartdart26 commented 11 months ago

I agree we can keep power-of-2.

Btw, I've added upperBound for 16 bit and 32 bit random generation too, maybe the FHE version becomes impractical for such types, not sure of the implementation.

dartdart26 commented 11 months ago

Implementation: