# On a treasure hunt for interactive shielding

*By [Lyron Co Ting Keh](https://twitter.com/lyronctk) -- Nov 6, 2023. The thoughts presented below are heavily inspired by conversations with friends. A big shoutout to them: Small Brain, Jack Lu, Andrew Lu, Justin Gilbert, Tarrence van As, John Guibas, Ayush Gupta, Kydo, Ibrahim Yusufali, Bobby Beniers, Henry Harder, Danny Aranda, Colin Roberts.*

### Setting up booby traps isn't as easy as you'd imagine

> **Shielding** is a term used to describe the process of maintaining and modifying blockchain state such that is not available to the general public. For instance, you could have a shielded number $3$ on-chain. No one can see this number except you and whoever you allow. You can add $4$ to this number to make it $7$ without revealing any information to the public.


We go through a contrived situation to provide a gentle introduction to an important problem. If you hate hypotheticals, we recommend skipping directly to the next section, *The booby trap limitation generalizes*, for the real-world use cases.

Indiana Jones was a beloved franchise that won over millions of devoted fans. Suppose you were one of these fans who learned about the adventurer way of life through the original films. Now you want to revitalize the story through a contemporary medium, an on-chain game.

You want this game to capture the most iconic part of the series- the booby traps. In your game, players are dropped into a dense jungle. Their job is to lay booby traps to eliminate the other players. The last one standing claims the treasure. Players can set up [cursed artifacts that unblock rolling boulders](https://youtu.be/c6XHLe94SJA?si=AX94lO3qgIAl7n8f&t=101), [invisible wires that trigger spikes from above](https://youtu.be/3W42cVP4evI?si=WHVDvQtO1dIqyX3z&t=237), and [false floors over pits filled with vipers](https://youtu.be/a3gf_ne6oQs?si=4vspt27R04TLBzEi&t=36).

You start coding, but you run into a problem. It quickly became apparent that booby traps and players need to be shielded. Players shouldn't be able to query the chain for all traps, or else they'd be easy to avoid. Players themselves should also be shielded, or else trivial mechanics would arise with players spamming rivals with traps.

You already know how to implement shielding using familiar technology. Solutions based on zero knowledge (ZK) or fully homomorphic encryption (FHE) suffice. Where you run into problems is in triggering the traps.


Each trap is shielded, so how does a player hit a trap they don't know about? Each player is shielded, so how does a trap activate on a player it doesn't know about? **This is due to fragmentation in shielded state.** Applications are restricted because it isn't easy to have shielded state from multiple users to interact. Doing this with pure ZK or FHE constructions quickly becomes intractable as the number of players in the jungle grows.

### The booby trap limitation generalizes

Creating traps for your Indiana Jones game unearths a common problem for blockchain developers. Suppose that, in conjunction with your game, you wanted to spin up a black market to sell loot, poisons, materials, and other assets that exist in the jungle world. The orders in this black market must be shielded, else a player's intentions are leaked as they gather materials for traps.

A standard swap in this black market would start with a player placing an order- e.g. `buy SNAKE`- and an accompanying trigger- e.g. `swap IF price > 100G`. When someone comes along and places a crossing order- e.g. `sell SNAKE @ 105G`- they trigger the swap. Abstractly, it's the same mechanic as triggering booby trap. **Placing an order is setting the trap, and filling the order is falling into it.**


There's more. Suppose you wanted to pair your game with team-specific social feeds (yes, Indiana can be a team player too). Team members can share everything from strategic outlines, to useful heuristics, to uplifting memes. Since there's an abundance of alpha in this feed, only the team members should be able to see and modify it.

A thread would begin with a player publishing the first post- e.g. `let's talk strategy`- and an accompanying trigger- e.g. `attach to thread IF member replies`. Someone can come along and activate the trigger via `join group` and `reply` actions. There's some nuance here because now there's an explicit separation between *seeing* someone's shielded state when you join the group and *modifying* it when you reply, so the trigger has multiple parts. It's broadly the same case as the booby trap yet again. **Starting the thread is setting the trap, and replying to the post is falling into it.**


The generic problem is consistent across all the above scenarios and generalizes to groups greater than size 2. They need interactive shielding- **a primitive that allows shielded state from multiple owners to interact inside some function and produce new shielded state for each owner.**

### Interactivity opens up entirely new classes of DeFi / Gaming / Social apps

The ability to have shielded state interact opens up a rich design space that's largely unexplored. **There's an abundance of low hanging fruit**:

1. Gamers can explore labyrinths with hidden treasures from previous civilizations, raise fortresses that feign strength with facades of banners, or enter into bountiful trade agreements with underground merchants. Developers can provide entirely novel gameplay.
2. Traders can fill orders through different dark pool variants, insure proprietary trading strategies through RFQ pools with bespoke triggers, or assume leveraged positions without risk of being stop hunted.
3. Creators can generate pre-release content with distributed production studios, maintain exclusive feeds for core influencers, or spin up special purpose DAOs with internal proposals for competitive environments.

All of the ideas here are uniquely enabled by interactive shielding, and they barely scratch the surface.

It's surprising that we've lived in a world dominated by applications with fragmented shielding for so long. It is, however, understandable why. If you build projects through a tech-first lens, then of course you end up designing the single player protocols that lend themselves to pure ZK or FHE constructions.

These single player protocols form a vanishingly small subset of all interesting shielding applications that could exist. Just look at what's happened in the public blockchain world. We started in the single player land with the `ERC20` and `ERC721` unlocks, where you'd create state and hand it off. Most on-chain activity here consisted of `mint()` and `transfer()` calls. Then, when we began collaborating on state, **we witnessed an explosion of function call variety in the mempool**. We started seeing `swap()`, `follow()`, `summon()`, `borrow()`, `cast()`, `move()`, `fill()`, `stake()`, `bet()`, `race()`, `capture()`, `post()`, and many more. There's no reason to believe that shielding isn't the same. To put succinctly, **most of shielding *is* interactive shielding.**


We must tap into the green zone the same way the public world tapped into multi-player functions. **During a time when success of the space is so dependent on the creation of novel experiences, doing so is not optional.**

The first wave of ZK applications gave us a glimpse of the wondrous abilities advanced cryptography could grant in the application layer. Continuing their work does not mean building "more of the same"- new protocols that are variants of seminal works. Instead, we need to use the knowledge they shared and tools they developed to tap into new sources.

### Shielding is a superset of privacy

None of the ideas we've mentioned here have to do with privacy, the subset of shielding that adds the additional property of anonymity. The two are commonly conflated. Why? Because the first big entrant of ZK into the space was in a mixer. It's reasonable to jump to the conclusion that hiding properties in cryptography are best used as tools for anonymity.

This is incorrect. The work being done in privacy is absolutely critical, but **we must realize that applications of shielding extend far beyond**. Opening up the conversation for shielding actions, not actors, puts us on an entirely different vector of creativity.

### Fragmentation on both ends of the function


The standard tech stack today allows you to initialize shielded state that you own, operate on shielded state that you own, and produce shielded state that you own. This is fragmentation on both inputs and outputs.

**You can't have state from multiple owners as input.** In our Indiana Jones example: you can't implement a function that takes in one player in the jungle and another player's trap.

**You similarly can't have state for multiple owners as output.** In our Indiana Jones example: you can't produce new state commitments for the player who's taken health damage and the player whose trap was spent.

### Seismic is building interactive shielding directly into leading chains

> The figure below is shown preemptively so readers can get a rough idea of what interactive shielding entails. It does, however, leave room for questions. What does it mean to compute this function? Why are there dotted lines when merging state? What's G? These are answered in the precise definition provided in the upcoming technical roadmap.


Fragmentation is a significant blocker. Prior to coming together for Seismic, we were application developers who experienced this first hand. Having to re-design our previous protocols around fragmentation is what prompted us to build Seismic in the first place.

Our cryptosystem is currently in alpha, where we're testing out integrations with partners who have upcoming mainnet launches. We use ZK proofs and lightweight homomorphisms in order to have state provenance that's based on pure cryptographic assumptions. For the shielding property in the short term, we use secure hardware modules. In the long term, we have systems in place for transitioning to trust-minimized MPC networks.

**Seismic's protocol ships as a set of sequencers that plug into any chain**. Developers can communicate with our nodes using an SDK in their client-side code. On the contract side, **developers can access interactive shielding in the language native to their chosen VMs**. Seismic takes care of parsing and compiling native contracts to generate bytecode for the paired deployments to the target chains and our sequencers. Our system comes with the many prerequisites needed for interactive shielding: **fast client-side proving, expressive interaction predicates, data availability, reorg resistance**, and load balancing to name a few.

We won't go into more product detail in this post. It's better to maintain focus on what's important- introducing the problem and the accompanying design space. We will release the outline of our protocol shortly for technical readers. Product announcements and designs will follow.

With each announcement, **we aim to maintain complete accountability**. We'll be clear about what we've built and what we haven't. We'll be clear about what trust assumptions we're imposing and how we're dealing with them. We'll be clear about our contributions on top of other OSS work and its implications to the ecosystem.

In the following months, we will demonstrate just how rich this design space is. We'll do so by shipping secure systems to production. Ideas are cheap. Sustained transaction flow isn't.

### Get involved with the creation of interactive shielding

If any of the thoughts presented in this post are interesting to you, whether you're a cryptographer, engineer, or creative, please reach out to `L [ at_] seismic.systems`.

### Acknowledgements

We are not the first to experiment with interactive shielding. Many incredible projects have achieved this under specific trust / liveness assumptions and interaction types. We've learned a great deal from their work and would like to credit them here: [[Anoma](https://anoma.net/), [Aztec](https://aztec.network/), [Curio](https://www.curio.gg/), [Dark Forest](https://zkga.me/), [Penumbra](https://penumbra.zone/), [Renegade](https://renegade.fi/), [Secret Network](https://scrt.network/), [Zama](https://www.zama.ai/), [ZKHunt](https://0xparc.org/blog/zk-hunt)]. This is by no means a comprehensive list.