The Internet Needed HTTPS—Blockchains Need an Encryption Layer

It might be difficult to imagine now, but the success of the Internet was not always guaranteed. In the early days, there was email, blogs, and websites, but the vision of the Internet espoused by early visionaries was a long way off being realized. 

Today, we take things like online shopping, banking, and the sharing of sensitive data for granted, but the early Internet had none of these use cases. It was missing a key component: security. 

That changed with the invention of HTTPS. First introduced in 1994 by Netscape, HTTPS is an extension of HTTP (Hypertext Transfer Protocol) and uses encryption protocols such as SSL (Secure Sockets Layer) and TLS (Transport Layer Security) to secure data transfers between a user's browser and the server. When a user connects to a website, the server sends a digital certificate to verify its identity, and both the browser and server create a shared encryption key. This ensures that any data sent between them is encrypted, helping protect it from interception or tampering. 

Before HTTPS, users were reluctant to enter their bank details into a website for fear they might be leaked to a third party. Today, this isn’t something we have to think about. With secure banking, ecommerce, and communication—all powered by HTTPS and its associated protocols—the adoption and use of the Internet grew exponentially. 

There’s a similar challenge at play today. Blockchains have added a trustless, decentralized value layer to the Internet, enabling users to transact without third parties and offering a universal, shared backend for the global economy. However, more than a decade after their introduction, there are still many use cases that have yet to be realized, and many members of the wider public—along with global institutions—have been reluctant to adopt the technology despite its clear promise. 

One of the key reasons for this is the lack of confidentiality. Public blockchains provide transparent ledgers that enable trust and verification among participants, but to combine these qualities with the utility of the centralized Internet, they require an upgrade. Users need to be able to send tokens without their transactions being visible to the entire network—companies won’t begin to pay their employees onchain in large numbers if anyone can see how much each team member is getting paid. And large-scale adoption by financial institutions requires the ability for them to offer confidentiality—an investment bank would be unlikely to issue a bond onchain if the amount held by each investor was transparent to the public. 

Just as HTTPS made the internet a trusted environment for sensitive interactions like banking and e-commerce, FHE could similarly transform blockchains by enabling secure, private transactions without sacrificing the transparency and decentralization that make blockchains unique. HTTPS allowed the internet to move from a space of public, read-only data to a platform for secure, interactive transactions. FHE, bolstered by complimentary encryption technologies like Trusted Execution Environments (TEEs) and Multi-Party Computation (MPC), has the potential to do the same for blockchains, protecting sensitive information without disrupting the decentralized trust that powers them.

The Confidentiality Revolution

Traditionally, efforts to introduce confidentiality to blockchains have focused on secure enclaves or TEEs, such as Intel SGX (Software Guard Extensions), and zero-knowledge cryptography. These technologies address different aspects of confidentiality: TEEs provide hardware-based isolation for secure data processing, while zero-knowledge cryptography enables proving information without revealing it.

These solutions are compatible with select onchain use cases. TEEs are fast due to hardware acceleration, making them a good fit for applications prioritizing speed, such as advanced gaming or real-time analytics. 

Zero-knowledge cryptography provides advanced privacy, making it ideal for use cases such as private peer-to-peer transactions. However, it faces challenges with composability due to its commitment-based approach.

While these approaches can be valuable components of blockchain privacy, alone they are insufficient to create an encryption stack that enables a fully decentralized, onchain counterpart to HTTPS/SSL. 

So, is there a mode of encryption that would meet these requirements and serve the same function HTTPS does for blockchains? 

FHE: The Holy Grail of Cryptography

Historically, it has been a core assumption that data must be decrypted in order to be computed upon. This creates a foundational limitation for processing data, as security and confidentiality risks are introduced whenever data requires processing. Data is most often computed on secure servers, but data leaks and security vulnerabilities are common. But what if decryption wasn’t necessary in order to compute upon data? While this might sound impossible, it has recently become a reality.

In 1978, Ronald Rivest, Leonard Adeleman, and Michael Dertouzos introduced the concept of privacy homomorphisms, which could enable computations on encrypted data without revealing information about the underlying plaintext. While this idea was revolutionary, their initial schemes could only support a restricted set of operations on encrypted data—for example, you could do addition or multiplication, but not both—rendering them impractical for most real-world use cases. 

After decades of continued research, in 2009, cryptographer Craig Gentry made a breakthrough by solving a major issue in homomorphic encryption. Previously, computations on encrypted data would gradually accumulate errors, much like how a photocopy of a photocopy becomes less clear with each copy. Gentry's solution, called 'bootstrapping,' allowed the system to reset itself and reduce these errors, making it possible to perform unlimited computations on encrypted data without losing accuracy. 

Subsequent work by the cryptographic community has addressed efficiency and performance issues, resulting in a current manifestation that can solve many of the security and confidentiality challenges previously thought inherent to online activity.

FHE: The Foundation of the Blockchain Encryption Layer

Things get really exciting when we combine FHE with blockchain technology. On a public blockchain like Ethereum, FHE would mean that data could be added to the network in ciphertext form, opaque to the public, but still be computed upon, with developers able to run functions on it and build apps using it. It’s a magic bullet, combining features that were, until now, impossible to achieve at the same time: decentralization, utility, and confidentiality.

A wide range of use cases becomes possible by combining these features. For example, in healthcare, FHE could allow patient data to be securely shared and analyzed by multiple institutions without exposing sensitive medical records. In supply chains, companies could track shipments and verify product authenticity without revealing confidential business data to competitors. Just as HTTPS enabled secure transactions in e-commerce and banking, FHE could power a wave of blockchain adoption in industries that require both transparency and confidentiality.

Simply put, FHE enables the native, unique benefits of decentralized computing to exist in harmony with confidentiality.

Where Inco Fits In

So how do we combine FHE and blockchains in practice? We have the encryption standard and we have public blockchains, but how do we implement FHE to be a blockchain standard just as HTTPS/SSL became the standard for the Internet?

That’s where Inco comes in. Inco is a modular computing network that combines FHE with Zero-Knowledge Proofs (ZKPs) and MPC to enable confidential computation for any blockchain.

Inco is designed to make the integration of FHE as seamless as possible for developers. By providing an FHE-enabled version of the Ethereum Virtual Machine (fhEVM), developers can immediately begin building confidential blockchain applications using the same tools they’re already familiar with, like Solidity, MetaMask, Remix, and Hardhat. This means there's no need to learn new languages or frameworks—developers can focus on building the future of private, decentralized applications using the tools they know best.

A developer looking to build an onchain poker game on Ethereum could store the core game logic on the Ethereum network and offload features that require confidentiality, such as each player’s hand of cards, to the Inco network, enabling this data to be computed and used to run the game while ensuring it isn’t exposed to other players. 

FHE, along with other encryption-based approaches, provides the missing piece blockchains have been lacking: confidentiality. With confidentiality available to any developer on existing blockchains through the tools they’re already comfortable with, we’re about to see a plethora of new use cases be brought onchain, with a wave of adoption similar to the post-HTTPS wave of adoption seen by the centralized Internet in the 1990s. 

To learn more about Inco and the use cases you can build by leveraging the confidentiality it provides, check out the Inco documentation.