Switchboard Randomness
Welcome to the Switchboard randomness documentation!
Switchboard Randomness advances the foundational principles of Switchboard-On-Demand by offering unparalleled speed and safety in randomness for blockchain applications. It aims to counteract a broad spectrum of potential threats, ensuring robust support not only for basic applications but also for infrastructure worth billions of dollars.
Building Trust By Being Trustless
It's crucial to exercise caution when dealing with oracles or services that claim to provide randomness. While randomness itself is a simple concept, ensuring its verifiability can be highly complex.
Let us take a simple scenario:
From Alice's perspective, this solution appears satisfactory.
"I mean, it's always random looking bytes, they don't seem dangerous," she might reassure herself.
However, this line of thinking fails to adopt the critical lens of the Adversarial Mindset, which is essential in assessing the security and reliability of cryptographic systems.
Now lets reimagine the scenario:
What if Alice's wager wasn't just her lunch money, but her life's savings? In such a high-stakes scenario, Alice would undoubtedly probe deeper into the randomness mechanism.
Would Alice be content with merely the appearance of randomness, or would she demand robust assurances of its reliability and verifiability?
Different Entropy Sources and Knowing Your Adversary
Dangers of using Latest Blockhash as Randomness
Utilizing the latest blockhash as randomness does impose limitations on who can influence its value at a specific time. However in the context of Solana, each Solana Leader has the power and opportunity to determine slot ordering. Thus, at any given moment, the current slot leader becomes your adversary. Over time, your adversary encompasses every Solana slot leader in history.
Elliptic Curve Signatures As Entropy
Now that we've covered a randomness situation with no upper bound on adversaries, let's look at improvements. The next course of action then becomes:
If randomness cannot be sourced on chain, then let's grab some randomness off chain
You know what's really good at fetching off-chain information for blockchains?
![](https://docs.switchboard.xyz/~gitbook/image?url=https%3A%2F%2F1437531680-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FZUlLPjef2DsoVKi8Itkj%252Fuploads%252Fa25eHkyG7XKlpRxYtSyr%252Fspaces_Sgm72uKz5YhjYH7GcbB5_uploads_CAee9wEae0N0GAD5DNCo_giphy-1-1.webp%3Falt%3Dmedia%26token%3Df7829155-2042-4a86-8f87-837f9fa36ffc&width=768&dpr=4&quality=100&sign=49429ced&sv=1)
You guessed it: ORACLES
Oracle's are a common component in blockchain applications for not only data propagation, but for entropy.
Great, we've figured it all out right?
![](https://docs.switchboard.xyz/~gitbook/image?url=https%3A%2F%2F1437531680-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FZUlLPjef2DsoVKi8Itkj%252Fuploads%252FQiU4dwafp5UHCC3fOGzJ%252Fspaces_Sgm72uKz5YhjYH7GcbB5_uploads_CqSKZ72JHlQyumzv8pWu_giphy-2.webp%3Falt%3Dmedia%26token%3D79be7bd7-3737-4366-a1a8-d4b43721fefe&width=768&dpr=4&quality=100&sign=66a327dd&sv=1)
Oracle's don't always get this right..
Let's break it down how things can and HAVE gone wrong:
Method: Oracle chooses random value every slot
Explanation and Limitations
This is, in some ways, better than using the blockhash since you limit the adversary from ANY leader to just the oracle, but the oracle has complete control in this situation. And if you are okay with this, then why build in Web3 to begin with?
Adversaries
The Oracle has FULL control
Method: Randomness from elliptic curve signatures
A user requests randomness by submitting a unique seed, and the oracle responds by:
rand = Sha256(Ed25519Sign(oracleSigner, seed))
Explanation and Limitations
Now this method is a good improvement BUT has a baseline misunderstanding of elliptic curve signatures
The INTENTION is that no single party chooses the randomness alone;
The user chooses a seed they can guarantee has never been used before
Since the oracle cannot predict that key beforehand, it would not know the output of the signature and the signature can be verified on chain
Unfortunately,
Sha256(Ed25519Sign(oracleSigner, seed))
is non-deterministicEd25519Sign(oracleSigner, seed)
is actuallyEd25519Sign(oracleSigner, seed, NONCE)
under the hood. This nonce parameter is used to prevent exposing the elliptic curve that makes up the secret key and can be derived deterministically from the signer and message. A malicious oracle, though, can set this nonce to whatever they please and subsequently produce INFINITE valid signatures resulting in any hash/randomness they please
Adversaries
The Oracle has FULL control
Method: User Secrets
User generates unique
secret_key
Users commits wager and
Sha256(secret_key)
User reveals randomness as
Sha256(secret_key + [commit_slot+1].hash)
Explanation and Limitations
This model plays much in favor of the user, such that it is up to the user to not leak their secret key to the slot leader before commit_slot+1
Although the *user could have ultimate adversarial guarantees in this scenario, this scheme is dangerous for the protocol, where the user.
Since their is no trusted party in this setup (remember, ANYONE can be a leader), the user may offer to coerce the block leader for a favorable slothash. The user could even be the leader themselves!
Adversaries
No user adversaries, but the user has strong potential to nefariously coerce slot leaders to favor against the protocol injesting the randomness
So How Does Switchboard Do It?!?
The Switchboard Way
With all the risks on the above potential methods, Switchboard takes advantage of the already integrated TEE supported primitives to bring stronger randomness guarantees on-chain:
Method - the TEE oracle
User commits to use the latest slothash as a seed and commits an oracle to use
User awaits next slot production and requests randomness from the TEE oracle, using the unique slothash
(Even the slot leader is incapable of preempting the oracle to reveal entropy before the seed slot is finalized)
Oracle responds with entropy from the TEE and signs with a TEE secured secret
Explanation and Limitations
Using Switchboard TEEs, we can incorporate the added confidentiality security primitives SGX has to offer
The oracle will never reveal randomness seeded with the latest slothash to prevent adversaries from "peaking"
When the slothash is finalized, the commit transaction MUST have been completed and the user may request randomness from the oracle
Since the Switchboard On-Demand oracle network processes all requests in-enclave, the oracle operator could not have foreseen the randomness before responding
Adversaries
For an adversary to predict this randomness they would need all of the following:
Be the next slot leader of the chain
Access to the oracle authority
Know of an active unpatched TEE vulnerability
Future Work
Currently the randomness oracle queries the solana RPC itself to ensure it doe not reveal randomness for a still-confidential randomness slot.
Rather than relying on the oracle rpc, or creating a slothash oracle, integrating a light client (see tinydancer) would make grabbing the current slothash of the chain verifiable within the TEE
Gotchas
Protocols must be intentful on when a user "commits" to using a randomness value and when randomness is "revealed"
Since oracles rotate enclave keys about once weekly, we do not let oracles that are within an hour of rotation commit to producing a random value.
If "reveal" is not settled within an hour of commit, the randomness request will be considered as expired and protocols should register this as a manageable user flow
If you need flexibility around this deadline, please contact the Switchboard team for customizability on expiration options.
Getting the Picture
To say it again, fair and verifiable randomness is not as straightforward as you would think, but Switchboard put that footwork in for you. We hope this gives you some insight on how these technologies work and how Switchboard keeps you safe. With that, Switchboard is happy to offer TEE secured randomness today on Solana Devnet!
Last updated