Fast Fairy Series: FairyRing Architecture I
In the Fast Fairy Series, we are going to publish a series of articles to cover our architecture, design, potential applications, cryptography, and our long-term vision.
To begin with, we are going to decipher the design of our Cosmos SDK application chain FairyRing which is responsible for the management of the decryption keys that power the Fairblock network.
The Fairblock network is an infrastructure for realizing “conditional decryption” and “programmable privacy” which enable more on-chain applications for all ecosystems and mitigates some of the core limitations toward a more decentralized and user-friendly infrastructure.
TL;DR: With Fairblock’s SDK, users can effortlessly encrypt transactions while also defining specific “conditions” e.g. block number for either partial or complete decryption and execution of these transactions.
Currently, this infrastructure allows validators to verify some specified conditions. Upon validation, these validators will submit key-shares, which will then be automatically aggregated on-chain, generating a decryption key for a batch of transactions once the conditions are satisfied. This new infrastructure will allow the development of a diverse set of applications such as bad-MEV protection, encrypted shared sequencing, sealed-bid auctions, private governance, encrypted on-chain limit orders, gaming, and randomness generation.
Overview:
Fairblock leverages cryptographic schemes such as distributed key generation (DKG), identity-based encryption (IBE), witness encryption and in soon homomorphic encryption (HE) to encrypt and decrypt transactions under certain conditions. These conditions can be a mix of time, the state of the blockchain, a token price, a solution, a ZK proof, and more.
Partner applications or wallets can easily integrate with Fairblock by using our SDK to encrypt a user’s transaction in-browser or client side. This will allow users to continue to enjoy the same applications that they are familiar with. Once the encrypted transactions are committed on-chain, validators of FairyRing will submit private key-shares once the conditions are met. Finally, these private key shares will be aggregated automatically and relayed to the applications to decrypt and execute the transactions respecting the previously committed ordering. It is easy to see that this mechanism solves many forms of exploits such as frontrunning and sandwiching attacks and protects the contents of the transaction before execution. Some immediate applications of this include sealed-bid auctions, private governance, encrypted/private intents, and shared sequencing of encrypted transactions.
Transaction lifecycle using Fairblock:
a. Users encrypt transactions using a master public key (which will be updated very infrequently) and “conditions for decryption” and submit them to the destination chain directly. This step happens seamlessly on the frontend of the application or in the user’s wallet.
b. Validators or (sequencers) of the destination application include the encrypted transaction in a block.
c. Once the conditions are met, FairyRing validators submit their private key-shares for the particular condition. The private key can decrypt all of the transactions that have been encrypted under certain conditions e.g. block height or price. This makes our infrastructure much more scalable due to the minimal bandwidth overhead.
d. The private key will be automatically aggregated using an honest majority of private key-shares of FairyRing validators.
e. The aggregated private key will be used to decrypt all of the previously encrypted transactions (or alternatively the result of privacy-preserving computations). Execution follows the ordering in step b.
This mechanism prevents many forms of exploits in defi such as frontrunning attacks and protects the contents of the transactions before/during execution. It also allow users to hide their bids in an auction, or prevent the manipulation of a governance vote.
It is easy to see that this mechanism prevents many forms of exploits/frontrunning attacks and protects the contents of the transaction before execution. This mechanism also allows users to hide their bids in an auction, or prevent the manipulation of a governance vote.
It is important to note that FairyRing validators have strong cryptographic commitments and economic incentives to act honestly. The contents of encrypted transactions will be secure as long as the honest majority assumption holds. In the event of the worst-case scenario partner applications will fall back to their current safety and liveness guarantees. Currently, FairyRing validators are used to provide private keys for decryption. However, this validator set can be replaced with other validator sets such as using Replicated Security of Cosmos Hub or the validators of the application chains themselves (Osmosis or Ethereum). We realize that the specific choice of validator set depends on a number of different factors such as engineering efforts for integration, size of the application chain, and the decision of the community. We plan on offering both solutions for applications that wish to integrate with us.
Thank you for reading our first article in the Fast Fairy Series. In our next articles, we will cover Fairblock’s future path for other ecosystems (modular ecosystem, rollups, and Ethereum), more details about the applications that we are enabling, cryptography innovations, and design.
Please send us a message on Twitter or send an email, especially if you are interested in learning more about Fairblock, building with us, and brainstorming new ideas. Thanks!!
