Randomness Contract

Provision of verifiably fair randomness is core to the ecosystem.

On-chain randomness might sound easy to implement, but it's quite the opposite. If implemented incorrectly, dishonest developers could exploit players, or savvy players could game the system and drain liquidity providers of their funds.

The deterministic nature of the blockchain means that certain aspects of randomness must be sourced from off-chain. Achieving this in a way that is secure and verifiable is crucial.

Zeebit’s solution involves leveraging the same zero-knowledge cryptographic verification that is used by Solana’s runtime - a solution core to the whole blockchain, and one which has been entrusted with over $10 billion at its peak.

There are four ingredients to Zeebit’s verifiable randomness, each playing an important role:

• Client seed - a value provided by the player when placing their bet, which can be changed at any time (it could be changed for every single bet, for example) prior to a bet being placed;

• Request nonce - an ever monotonically increasing number incremented each time a request was made - providing entropy and ensuring that it is impossible that an identical set of seeds could ever occur;

• Future blockhash - at the time the request is created, the contract will specify that a particular future blockhash must be used. The earlier blockhash that can be used (for instant bet requests) relates to the block of the current request transaction. This blockhash, along with any future blockhash is by definition unknowable to anyone at the time it is requested.

• Provider’s secret key - the hidden off-chain ingredient. A randomness provider node has an address on the blockchain and maintains a secret key to operate this address (the same way any Solana wallet does). When the provider node receives these ingredient seeds, it concatenates them into a byte array of fixed length and signs the message with its secret key, producing an unpredictable outcome - the randomness.

The off-chain provider submits a transaction to the randomness smart contract, which in turn invokes a callback to the relevant game contract once the response has been validated against the request.

Using the same cryptographic toolkit leveraged by Solana’s runtime (Ed21559 Signature Algorithm), anyone can independently prove or verify that randomness provided by a given provider was produced without the seeds having been tampered with.

• Players can validate that the client seed used was indeed the seed which they provided;

• The monotonic increasing of the randomness contracts request nonce is visible all-times on Solana’s immutable ledger;

• The blockhash corresponding to the pre-specified slot number in the request can be retrieved from Solana’s immutable ledger;

• An implementation of the Ed25519 verify method in any programming language can be used to provide a zero knowledge proof (i.e. without revealing the secret key) that these seeds, and only these seeds, were signed by the secret key corresponding to the stated provider’s public key - without any tampering whatsoever.

The platform interface will facilitate ease of verification of this and all of the elements of randomness generation are published to Solana’s immutable ledger, for anyone to validate at any time.