In our last post, we presented the vision of Fairblock, a core component of which is providing a slate of different cryptographic tools to developers. These include threshold identity-based encryption, threshold fully homomorphic encryption, and witness encryption, each of which enables unique functionality in decentralized applications. Here we’ll be taking a deeper look into all three schemes, their unique properties, and what benefits they offer.

Cryptographic tools are just that–tools. And when you’re building applications, you want to have a whole toolbox, so you aren’t trying to nail things with a screwdriver. We’ve seen how zero-knowledge cryptography (ZK) is excelling at scaling blockchains, for instance, by compressing many transactions into lightweight cryptographic proofs. Meanwhile, other cryptographic tools are more versatile and more efficient for enabling on-chain privacy.

From protecting the contents of financial transactions against malicious actors to enabling private voting, Fairblock’s encryption tools provide privacy in distinct ways, enabling a variety of applications. Let’s dive in!

Identity-Based Encryption

Often abbreviated as IBE, identity-based encryption allows for encrypting and decrypting information based on far more parameters than was previously possible. With traditional public key cryptography, one actor encrypts information using the public key of another party (who is the only one able to decrypt that information by using their private key). In IBE you can encrypt information using things like someone’s email or IP address–hence “identity” in the name.

This is incredibly freeing because it means encryption is no longer just between two sets of preexisting cryptographic keys. It can take into account someone’s unique attributes. With Fairblock, we’re finding ways to make it even more broadly useful than that.

Fairblock leverages IBE in a novel manner. Instead of encrypting for someone using an identity attribute, it encrypts for some conditions, so that transactions are decrypted once those conditions are met. These conditions for decryption and execution can take many forms; for instance, the decryption can be triggered with a block number, deadline, price, on-chain events, or even zk proofs.

Notably, by setting a particular block height as the “identity” for decrypting a blockchain transaction, you can use Fairblock to encrypt the contents of a transaction before they’re posted on-chain all the way up until their execution. Only once the desired block height is reached are the contents of the transaction decrypted and executed on-chain.

Additionally, Fairblock provides IBE in a decentralized fashion. Instead of relying on a centralized private key generator, Fairblock leverages distributed key generation, and a decentralized network of independent actors (the validators of the Fairblock blockchain) assembles the decryption key to reveal the contents of one or more transactions. This means there’s no reliance on a trusted party to deliver pre-execution privacy.

DeFi applications can use IBE through Fairblock to encrypt transactions that will only be revealed when certain market conditions are met. This allows apps like decentralized exchanges (DEXes) to protect users’ trades from malicious actors who would otherwise use their visibility into the exchange’s order flow to perform value-extractive strategies like frontrunning and sandwiching.

Likewise, in the context of on-chain governance, a community can make the end of a voting period be the condition for decrypting votes. This allows for private voting, which protects individuals from coercion, counteracts voter apathy, and more.

In the context of on-chain MEV auctions, recent research by Gauntlet indicates that pre-execution privacy and revealing individual bids only at the conclusion of those auctions (as with IBE) enables fairer auctions that are much less susceptible to manipulation than alternative approaches.

Delving a little deeper, Fairblock’s conditional decryption system works through a threshold IBE model. Applications, blockchains, or end users encrypt the contents of transactions using the Fairblock master public key as well as a condition for decryption. When the condition is reached, all transactions whose encryption is tied to it are decrypted by Fairblock’s decentralized validator set. For more information on Fairblock’s architecture, please refer to this post.

Fully Homomorphic Encryption

To enable even greater flexibility when it comes to conditional decryption, we are also working on an implementation of threshold fully homomorphic encryption (TFHE), a kind of cryptography that allows for computation on encrypted data.

With FHE, Fairblock allows for executing transactions without revealing their contents at all. This enables use cases such as governance where individual votes remain private even once the final tally is revealed.

In DeFi it allows for protecting traders’ strategies. With FHE, the contents of all users’ trades can remain private even as they’re executed. This encourages active traders on the DEX by protecting them from having their alpha stolen or undercut.

In different applications or market conditions, IBE or FHE may be preferred. The IBE approach is faster during encryption, decryption, and during execution. Transactions are decrypted once it’s too late for any exploits, and computations are done safely on plaintext transactions. This approach offers pre-execution privacy and post-execution transparency which is sufficient or even preferred in many applications. However, at the expense of slower computation and higher bandwidth overhead, FHE offers privacy-preserving computation on ciphertexts, and it’s necessary for applications where only the results of computations — not individual transactions — should be decrypted.

While FHE has been elaborated in the academic literature for several decades, it is only just now becoming ready for production due to improvements in its design that make it more efficient as well as the more powerful computational resources available today. Zama, in particular, has done an amazing job designing a TFHE protocol and library. We’re excited to be among the first to deliver it in a way that’s both useful for practical applications and doesn’t rely on centralized actors controlling decryption keys.

In short, FHE needs a private key for the decryption of the final result of private computation. While in some applications you can rely on the user or a centralized party for holding the key, in applications that require an encrypted shared state, such as TFHE rollups, governance, or gaming, this private key should be generated and shared by a secure and decentralized committee.

Building upon Zama’s TFHE library, Fairblock’s architecture, in particular, the chain’s “FairyRing”, allows it to manage the private key and re-encryption of TFHE ciphertexts by a committee, which provides stronger security. The private key sharing and decryption happens without relying on any third party through decentralized key generation, and the large set of reputable validators are incentivized to act honestly due to their economic and social stake, a slashing mechanism, and Fairblock’s tokenomics.

Fairblock’s infrastructure effectively enables developers to build a wide range of FHE and IBE applications in their preferred L1 or L2 without going through the high learning curve of building in different ecosystems. Moreover, the modular design will make privacy-preserving applications available to end-users on the frontend of their favorite applications without requiring them to switch to standalone privacy chains, wallets, or passing a cryptography course. This will also allow for abstracting away the high bandwidth overhead and technical complexities of key management and the re-encryption process from validators or sequencers of application chains–Fairblock handles all of that.

Witness Encryption

Fairblock is also experimenting with witness encryption, another cutting-edge form of cryptography that will allow Fairblock to encrypt transaction content with even stronger security and decentralization.

Witness encryption takes a unique approach, wherein the encryption of information is associated with a kind of puzzle known as an NP (non-polynomial) problem rather than with a cryptographic key. Someone who knows a “witness” (solution) to the puzzle can decrypt the information.

Without diving all the way into the math, you can think of it this way: there’s a bank account with $100 in it, but the password to access the money is encrypted such that only someone who has solved a particular crossword puzzle can decrypt it. Once someone proves that they’ve solved the crossword (ie. they know a “witness” for the puzzle) they’re able to get into the bank account and claim the prize money.

Fairblock has already emulated the flexibility of conditional decryption that witness encryption provides through threshold IBE; however, we can derive additional benefits for Fairblock from witness encryption. Principally, it allows us to provide a more secure solution for decryption in which a user simply sets a condition for decrypting the contents of one or more transactions, Fairblock generates a witness encryption puzzle whose solution is that condition, and then the user only provides the witness for the contents of associated transactions to be revealed.

In contrast to the threshold IBE model where Fairblock’s decentralized validator set must assemble a majority of private key shares to decrypt the contents of transactions, the witness encryption model removes the need to rely on those validators.

Fairblock’s Cryptographic Security Assumptions

Fairblock’s initial threshold IBE offering relies on an honest majority security assumption: the solution is secure so long as a majority of validators on the network are behaving honestly. We acknowledge that these validators can theoretically coordinate a malicious attack where the majority share their secret shares and reconstruct decryption keys, defying the conditions for decryption set by users. We believe that the high difficulty of coordination and the loss of significant network stakes will act as high barriers to committing such attacks.

It is also important to note that potential attacks do not result in a loss of safety over user funds. The sole consequence would be the leakage of transaction information and the potential use of that information in ways that are not in the best interest of the user, such as for MEV attacks. Effectively, this scenario is falling back to the current situation of transactions being public prior to execution.

While we are confident that this system carries a high barrier against malicious actions, we’re also working in collaboration with other major projects on several research and engineering initiatives to further scale and improve Fairblock’s security guarantees. These include:

Pushing the Cryptography Frontier with Practical Purpose

We’re a team of cryptography experts, and naturally, we’re excited about putting cutting-edge encryption to use. But it’s also clear to us that different kinds of cryptography are suited to different purposes. They each come with certain benefits and drawbacks. As we build out Fairblock, we’re excited to see how applications and end users harness IBE for pre-execution privacy and conditional decryption, FHE for transaction privacy after execution, and witness encryption to further bolster decentralization.

Keep up with us on Twitter to be sure you hear about future posts in which we’ll explore some of these applications in greater detail.