back
Exploring IP Privacy with Fully Homomorphic Encryption
Story
01 May 2025
How confidential IP interactions can work
So far, Story’s Proof-of-Creativity (PoC) protocol has been public and permissionless, meaning anyone can view all intellectual property (IP) assets, metadata, interactions, and lineage on the Story Network. While this transparency serves many use cases well, it falls short for scenarios requiring privacy, such as:
- Individual creators who want to protect their work from unauthorized exploitation, e.g., unauthorized AI training, or during private licensing negotiations
- Institutions that invest heavily in R&D or manage high-profile IPs require controlled, private access
To support these use cases, we're exploring different solutions for enabling Privacy-Preserving Programmable IP. This post explores how Fully Homomorphic Encryption (FHE) could enable private licensing and confidential IP interactions within the Story’s Proof-of-Creativity Protocol.
Part I: Defining Privacy Requirements for IPs on Story
Traditionally, security-related privacy consists of two main pillars, anonymity and confidentiality:
| Concept | Explanation |
|---|---|
| Anonymity | Who initiates actions |
| Confidentiality | What actions contain |
To understand how these privacy needs map onto Story’s PoC protocol, think of the protocol in terms of nouns and verbs:
- Nouns: IP assets, each with metadata (e.g., media files, descriptions), license terms, and ownership
- Verbs: Actions performed on IP, such as registering derivatives, grouping IPs, or claiming royalties—each tied to modules in the protocol (e.g., Derivative Module, Royalty Module, Grouping Module)
If you're not familiar with Story’s PoC protocol, here’s a quick primer: https://docs.story.foundation/concepts/overview
When you put privacy together with these nouns and verbs, the implications cascade across the IP lifecycle:
| Action | Anonymity | Confidentiality |
|---|---|---|
| IP Registration | Who registered/owns the IP | What’s the content (metadata) of the IP |
| License Attachment | Who owns/attached the license to the IP | Contents of the license (revenue share, licensing fee, etc.) |
| Derivative Registration | Who registered/owns the IP; who/which IP receives licensing fees | Contents of the license linking the derivative to parents; ancestor info; licensing fees paid |
| IP Group Formation | Who owns the group IPA | Which IPs are in the group; what reward pool it's using; what license governs the group |
| Royalty Claiming | Which IP royalties are claimed from; who receives them | How much royalty is being claimed |
In most IP use cases, anonymity is about hiding the identity of the owner or revenue recipient. We don’t explore that aspect in depth here due to its regulatory and compliance implications. Instead, we focus on confidentiality.
Static data, such as IP metadata, can already be encrypted on the client side before uploading it to IPFS via services like Filebase or Pinata. The hard part is license confidentiality, as these terms govern actions across the protocol: who can create derivatives, how royalties are shared, what permissions exist, and more. Keeping this data private means supporting confidential computation, not just encrypted storage.
Part II: Fully Homomorphic Encryption as a potential solution
On a high level, Homomorphic Encryption (HE) allows encrypted data to be processed without decrypting it. This is very powerful; it means private license terms can influence on-chain behavior without being revealed, not even to the nodes performing the computation. “Fully” means the scheme supports arbitrary (Turing-complete) computations.
Incorporating FHE into an on-chain protocol like Story’s PoC introduces several challenges:
- Key Management: FHE requires protocol-wide public/private key pairs. To avoid centralization, we need threshold key generation and sharing, where a subset of parties can authorize decryption in the protocol.
- Access Control: The protocol must dynamically manage who can access encrypted data and initiate decryption.
- Performance: FHE operations are computationally intensive and may not be completed within typical block times.
- Security: Malformed ciphertexts from malicious users can pose security risks, such as chosen-ciphertext attacks.
- Client Integration: Users need tools that enable them to encrypt inputs and generate proofs of validity using the same encryption scheme.
These challenges aren't unique; similar problems have been encountered and tackled across other systems. A typical architecture includes the following components:
| Problem | Technical Component | Function |
|---|---|---|
| Who can decrypt the data? | Access Control List (ACL) Smart Contract | Defines who can access encrypted data. Verifies permissions before allowing decryption or re-encryption actions. |
| Who manages keys and handles decryption? | Key Management Service (KMS) | Generates and manages FHE keys using threshold cryptography. Multiple nodes jointly perform decryption to avoid centralization. |
| How to meet on-chain latency constraints? | On-chain Symbolic Execution Modules | Simulates logic on-chain without performing FHE computation. Emits events for off-chain execution while preserving protocol behavior. |
| Who performs FHE computation? | Off-chain FHE Co-Processor | Listens for events, runs encrypted computations off-chain, and stores results back on-chain via callbacks. Keeps computation off the critical path. |
| How do users encrypt and prove input validity? | Custom Client | Encrypts inputs and generates proofs that the data is well-formed. Ensures integrity and prevents attack vectors like malformed ciphertexts. |
To make this concrete, here’s a simplified end-to-end example of how private IP interactions could work using these technical components:
Example Flow 1: Attaching Private License Terms
- The user requests to attach private license terms to an IP.
- The client encrypts the license terms and generates an associated proof to demonstrate that the user knows the underlying license terms (to prevent chosen-ciphertext attacks).
- The client submits the transaction to a contract (let’s call it
PrivateLicenseRegistry) with the encrypted license terms and proof as parameters. - The contract verifies the proof and evaluates the operation symbolically. Once finalized, it emits an event.
- During execution, the protocol ACL manages and verifies that the relevant contract and addresses have access to the ciphertext.
- The event triggers the FHE co-processor to run the actual FHE computation, registers the license, links it to the IP, and stores the new state in the contract via a callback function.
Example Flow 2: Retrieving Attached Private License Terms
- An authorized user requests to view the private license terms attached to an IP.
- The
PrivateLicenseRegistrycontract receives the request and verifies the user’s access through the ACL. The ACL generates a Merkle inclusion proof for the user and the encrypted license ciphertext. - An event with the ciphertext, user’s public key, and ACL inclusion proof is then emitted after contract execution. This triggers a decryption action by the KMS nodes, which verify the proof and re-encrypt the data using the user’s public key.
- Once re-encryption is done, the KMS triggers a callback on-chain. The callback emits an event containing the re-encrypted ciphertext for the private license terms.
- The client receives the event and decrypts the ciphertext locally using the user’s private key.
Evaluating Existing Solutions
Several mature open-source libraries support Fully Homomorphic Encryption (FHE), including OpenFHE, Microsoft SEAL, and HElib. These libraries provide core functionality for building encrypted computation systems, although most are not specifically tailored for blockchain environments.
For blockchain applications, the most notable tool today is Zama’s fhEVM. It offers a Solidity-compatible smart contract framework based on TFHE (a fast gate-level FHE scheme), enabling encrypted execution and access control. fhEVM also includes an integrated suite of on-chain and off-chain infrastructure, making it one of the most promising FHE platforms for confidential smart contract development.
Performance and Costs
Despite its potential, FHE remains a resource-intensive technology. Performance and cost are the two primary challenges to using FHE in production environments.
Take Zama’s TFHE-rs library as a reference. CPU benchmarks were run on an AWS hpc7a.96xlarge instance. GPU benchmarks used H100 GPUs. On this high-end data center hardware, it achieved the following performance for 64-bit encrypted integer operations:
| Operations (over 64-bit encrypted integer) | CPU | GPU |
|---|---|---|
| Negation (-) | 106 ms | 23.5 ms |
| Add / Sub (+, -) | 105 ms | 23.5 ms |
| Mul (x) | 401 ms | 254 ms |
| Equal / Not Equal (eq, ne) | 81.2 ms | 16.1 ms |
| Comparisons (ge, gt, le, lt) | 102 ms | 23.9 ms |
| Max / Min (max, min) | 145 ms | 40.6 ms |
| Bitwise operations ( &, |, ^) | 20.7 ms | 5.79 ms |
| Div / Rem (/, %) | 8.22 ms | 1.88 ms |
| Left / Right Shifts (<<. >>) | 134 ms | 83.3 ms |
| Select | 32.6 ms | 16.9 ms |
Although FHE has seen orders of magnitude improvements over the years, its performance is still a limiting factor today. Even with high-end data center hardware, the performance of FHE operations remains limited. A single 64-bit encrypted integer operation typically takes tens to hundreds of milliseconds. This means that for a simple encrypted ERC20 transfer (involving one addition, one subtraction, one comparison, and one select), throughput would be in the low single-digit transactions per second. More complex protocol interactions would perform even slower.
Achieving comparable performance also requires significant cost. A single hpc7a.96xlarge CPU instance costs over $5,000 per month (source), while a comparable GPU setup using AWS’s p4d.24xlarge instance can exceed $20,000 per month (source).
In short, as of today, FHE is only practical for high-value use cases where the need for privacy justifies both the latency and the infrastructure cost.
Future Outlook
Although FHE still faces performance and cost challenges, the pace of progress has been remarkable. Advances are happening on multiple fronts, from specialized hardware accelerators (e.g., the development of ASICs) to breakthroughs in cryptographic foundations (e.g., exploring Multivariate Quadratic (MQ) based schemes as alternative foundations). These innovations are rapidly improving both the performance and affordability of encrypted computation.
We’re actively tracking these developments and exploring FHE as a potential solution to support privacy-preserving IP use cases at scale.
