Random Number Generators

Project Psiens

The Psiens Random Challenge

technology-hacker-background

As the core concept of the Psiens.IO solution evolves around resolving a guess against a future random number, the concept around generating this random number should ideally follow the following requirements:

  • Must create sufficiently random numbers for the player-guess scenario.
  • Must be unknown by the player by the time the player submits a guess.
  • Must be unknown by the Psiens.IO server until time of resolving player guesses.
  • Must be immutable so the Psiens.IO server cannot modify results prior to guess resolution.
  • Must be verifiable so that the Psiens.IO server guess resolutions can be independently verified.

There are a number of blockchain and off chain random number services available (Ginar, Random.Org, DRAND.) but they are all primarily focused on the ‘randomness’ of the generated number. A few also try to tackle the trust issue (RanDAO, Provable/Random.org,ChainLink) but these are mostly hard to integrate in the Psiens.IO guess-result schema. A number of promising VRF solutions are going live and maybe in the future some of these could be incorporated into the Psiens.IO ecosystem.

Project Psiens has created two random number generator solutions which fullfill the requirements above: The “Collaborative Random Number Generator” and the “Crypto Trade Random Generator”.     During Beta phase only the first option will be deployed whereas the second will be introduced once we are out of Beta.

 

The Collaborative Random Solution

blockchain5

The first Psiens.IO solution for accomplishing the above is to introduce a concept based on a (patent pending) Collaborative  Random Number Generator solution.

  1. The  “Two Party Collaborative Random Generator” solution works as follows:
    1. Upon Player login the Server creates and saves for that Player:
      1. A series of Random Numbers, one for each required Range. 
      2. A Random Key.
      3. Encrypt the Random Number series (from 9.i) using the Random Key to create an Encrypted Object.  For the Nerds among you, the Encrypted Object is an encrypted base64 converted byte array of rnds.
      4. Sends the Encrypted Object to the Player.   The Random Key is NOT sent at this time.
    2. The Player receives and stores this Initial Encrypted Object.
    3. At a later time, the Player  sends a Guess Request to the Server.  The Guess Request contains:
      1. The requested Range
      2. The Guess (within Range)
    4. Once the Server receives the Guess Request from a given Player it will:
      1. Find the Random Number in this Player’s saved Random Numbers series, based on the requested Range.
      2. Use the formula Result = (Server Random + Player Guess) % Range.
      3. The Result stemming from above calculation IS the collaborative Random Result for the given Guess cycle.
      4. The Server now generates and saves a NEW sequences for the given Player :
        1. A series of NEW Random Numbers, one for each required Range. 
        2. A NEW Random Key.
        3. Encrypt the NEW Random Number series (from 9.i) using the Random Key to create a new Encrypted Object.  
      5. The Server now send the Response back to the Player with the following:
        1. The Result (9.d.iii)
        2. The NEW Encrypted Object (9.d.iv.3)
        3. The PREVIOUS Random Key (9.a.ii), meaning the Random Key used to Encrypt the last Encrypted Object sent to the Client.
      6. The Player Receives the Server Response and:
        1. Validate the returned Result:
          1. Use the returned Random Key to DECRYPT the previously supplied Encrypted Object, which was previously stored by Player.
          2. Find the Random Number which corresponds to the used Range, in the DECRYPTED series of Random Numbers.   COMPARE found Random Number to the returned Result.  
            1. If there is NO MATCH then the Result cannot be Validated by Player .
        2. Store the Server supplied NEW (Random Numbers) Encrypted Object on the Player , to be used for the NEXT Guess cycle.
      7. Repeat steps 9.b to 9.d for every new Guess cycle.
To learn more about how this  solution works check out the Psiens Client wrapper (Unity3D, C#) which can be found HERE.
 
This solution is fast and secure and will generate nice random Results for Guess resolutions.   In the second solution NEITHER the Server NOR the Player knows what Result will be as it comes from a 3rd party.   You can more info on this alternative solution below.

 

The Crypto Trade Random Solution

blockchain2

The second Psiens.IO solution for accomplishing the above is to introduce a concept based on a (patent pending) Crypto Trading Random Number Generator.

The idea is to use a public source of random data as input for a random number generator. The data should be changing 24/7 and with frequent updates. This makes crypto currency trading ideal for this purpose. There exist a number of APIs for fetching the crypto-trade ticks. Some APIs are in connection with the crypto-trading platforms themselves while others are aggregate data from multiple platforms. Several of the crypto-trade APIs include publish-subscribe models often using WebSockets. These are ideal for our purpose since :

  • Crypto trading is open 24/7.
  • They public public trade tickets to ALL subscribers at the same time and with very frequent updates.
  • A crypto-trade pair ticker includes a number of parameters which will often have large variations and only minor intercorrelation between parameters.
  • We can now use a publicly known algorithm to convert the specific ticker object data into a random number. The algorithm logic is not that important as long as it can reliably convert the selected ticker object data into a random number.
  • The currently used algorithm is visible in the PsiensRNDVerifier code (see below)
  • By making the used algorithm public it will allow 3rd parties to use the algorithm on the same API and thus produce the same random numbers (since ALL subscribers will get the same ticker objects) as those used by the Psiens.IO server to resolve guesses.
  • Using the ticker data directly to create a random number can in some cases cause too non-random results in the case of very low trading or rapid increases/decreases. Furthermore ticker-objects are not published with a fixed sequence but rather when certain internal delta thresholds are exceeded. To get around this we use a novel assignment system:
    • Use a series of predefined crypto-pairs and a given pub-sub API
    • Limit possible guess ranges to a series of ranges (for instance 2-9)
    • Every Publish event will include one or more crypto-pair ticker objects.
    • Use a round-robin solution to iterate through the ranges and with a given range in mind pick the next unused ticker object in the last Publish Event.
    • With the picked crypto-pair ticker object in hand, use it to create a random number using a known algorithm AND the given range.
    • So for instance if a Public Event includes 3 ticker objects (from our list of predefined ticker objects), we now use the first ticker object to calculate (using the public algorithm) a range 2 and assign this to the range 2 slot. Similarly use ticker object 2 and 3 to calculate and assign range 3 and 4 random numbers to ranges 3 and 4 respectively. When the next Publish Event comes in with say 2 ticker objects, we use these to to calculate and assign to ranges 4 and 5. When we get past the last defined range, we start over with the lowest range (hence the round-robin notion).
    • This solution will create a constantly updating list of random numbers, one for each range. And when a creator makes a guess for a given range, the Psiens Guess solution will WAIT until the used range is updated AFTER the time the guess is placed.
    • The wait time from a guess is submitted to the Psiens.IO server and until the guess is resolved will depend on:
      • When the guess with a given range was submitted in relation to the current spot in the round-robin range queue.
      • The amount of crypto-pair ticker objects coming with each API publish event
      • The frequency of API Publish events.
      • Every guess made to the Psiens.IO platform will result in a guess response. The guess response includes the result AND the RndID which is given as “timestamp + ticker symbol”. Players could use the RndID to do runtime validation of the random results however to make this verification simpler we have included a project (see below) which does the random validation but using a Ticker Report available anytime from the Psiens.IO server.
This solution will also include a public PsiensRNDVerifer project to do ad hoc validation of Results created by this solution:
  • The PsiensRNDVerifer project will be publicly available on github at a later time once the Crypto Random option is live.
  • Open the Project in Visual Studio and run the application. On the Swagger UI web page Start the monitoring to do a verification Run. The report will take about 2 minutes to run and when done the user can fetch the report using the ‘get-report’ endpoint.
  • The verification run should result in an output where the last 72 random results from Psiens.IO are validated against the random results calculated by the application itself using the same crypto ticker results as was used by the Psiens.IO server. Hopefully all the values are coming back with a ‘VERIFIED’ tag, meaning that each result from the Psiens.IO server was validated against the locally calculated values.  This report can be run ad hoc.

  • Currently the Crypto Random Number Generator (beta) uses the Binance Spot WebSocket (pub/sub) services. Mainly because it is one of the big boys in the room..and it is even free to use.  Later we will expand the Crypto Random Number Generator to use additional public crypto trade ticker APIs

  • The PsiensRNDVerifier project also includes a functionality to attempt to answer the question of HOW random the numbers generated by the Crypto Random Number Generator really are.

 

After Beta phase we will introduce a Guess solution which ALTERNATES between the two options described above.   More info to come.