ProvableHQ / leo

🦁 The Leo Programming Language. A Programming Language for Formally Verified, Zero-Knowledge Applications
https://leo-lang.org/
GNU General Public License v3.0
4.79k stars 634 forks source link

[Feature] Adding a pseudorandom number generator function to ChaCha that takes in Aleo Address and a uint64 as parameters to generate extremely unrepeatable unique IDs #27968

Open harshnambiar opened 1 month ago

harshnambiar commented 1 month ago

🚀 Feature

As discussed with Pranav on the dev hour call, the function should work similar to the normal ChaCha rand function, but take three arguments:

  1. The address of the caller
  2. The address of the recipient
  3. A count value that is an integer

Using these a pseudorandom Field will be generated that is so unlikely to be repeated that the probability of it repeating never exceeds 10^(-29)

Motivation

The reason this is important to us is because we want to map something to both the recipient and the sender in the form of Aleo mappings, and such unique unrepeatable IDs would help us achieve that. Each transaction in our Aleo program would lead to one of these IDs being created, hence it is better to do this inside the Leo code itself.

Implementation

Assuming the implementation used is similar to what we have so far used at the javascript layer, the following code just needs to be converted to Rust in the base library for this to work.

Are you willing to open a pull request? No!

d0cd commented 1 month ago

The Aleo Virtual Machine (snarkVM) allows users to seed the ChaCha::rand function with user-defined data. This functionality needs to be added to Leo.

Note that the AVM seeds the default implementation with the transition ID, which is a field element. The probability of repetition is approximately 2^(-253) which is already lower than the above threshold.

harshnambiar commented 1 month ago

The Aleo Virtual Machine (snarkVM) allows users to seed the ChaCha::rand function with user-defined data. This functionality needs to be added to Leo.

Note that the AVM seeds the default implementation with the transition ID, which is a field element. The probability of repetition is approximately 2^(-253) which is already lower than the above threshold.

That might be true but assuming the same contract is used over the entire lifetime of the dapp, then the probability of repeats will keep stacking. We could avoid this by having the first 16 digits of the ID as the timestamp, and the remaining digits as the random number generated using ChaCha::rand. This could be implementable if we can make another rand function in the ChaCha library that takes the timestamp into account.