# A roadmap to shielded interactions

*By [Lyron Co Ting Keh](https://twitter.com/lyronctk) -- Jan 2, 2023. The thoughts presented below are heavily inspired by conversations with friends. A big shoutout to them: Dan Boneh, Wei Dai, Ying Tong Lai, Eddy Lazzarin, Ayush Gupta, Andrew Lu, Alex Evans.*

**TLDR.** Shielded state is fragmented. Data from multiple users cannot interact, i.e. be used together as inputs and outputs for a verifiable function. Seismic is addressing this limitation. We begin by deploying cryptosystems with stronger trust assumptions on shielding while maintaining purely cryptographic / PoS trust assumptions for existing blockchain properties (e.g. provenance). We relax these shielding assumptions over three phases. In Phase 1, users send providers information that must be communicated to potential counterparties. In Phase 2, trust is distributed across multiple independent providers. In Phase 3, provider trust assumptions are removed by having users to participate in the online protocols themselves. Getting to Phase 3 is good for crypto, and the world. If you're interested in learning about why, see [this](https://seismicsystems.substack.com/p/on-a-treasure-hunt-for-interactive) application-focused introduction.

### Shielded state across owners is fragmented


Suppose we had three users who want to maintain on-chain shielded state, i.e. blockchain data that cannot be seen or modified by external parties. To do so, each person keeps state in the clear off-chain and publishes a hiding commitment on-chain. Each user must then prove arbitrary transitions over their own commitments. There are a number of production systems equipped with zero knowledge (ZK) or fully homomorphic encryption (FHE) that enable exactly this.

We're interested in asking about the natural next step. The earlier statement- "proving transitions over their own commitments"- refers to each of the three users independently running a verifiable function over their piece of global shielded state. Now, **what happens when protocols require transitions that are dependent on not just one piece, but all three at the same time**? For the majority of blockchain applications today, the answer is that it can't be done. Shielded state is fragmented. Only the owner can prove transitions over a piece of shielded state. Transitions cannot depend on state across multiple owners. This is limiting. Blockchains are massively multiplayer. Shielding must be too.

### An informal definition for shielded interactions


The following definition generalizes to an arbitrary number of parties. Suppose we again have $N = 3$. Three users are participating in a protocol with transitions that are dependent on all three shielded states $\{S_1, S_2, S_3\}$. User $i$ owns state $S_i$ with on-chain commitment $\bar S_i$. There's an agent $G$ who needs to compute updated state commitments $\{\bar U_1, \bar U_2, \bar U_3\}$ such that $U_i = f_i(S_1, S_2, S_3)$ is publicly verifiable without revealing anything about any $S_i$ or $U_i$ to external parties. $G$ may or may not be in the original set of three participants. Also note that each $f_i$ is different per user because output states are asymmetrical (e.g. a buyer in a pool should end up with a different currency than a seller).

Readers may recognize functional similarities to multi-party computation (MPC). Correct, with slight tweaks that make shielded interactions completely different. Our modifications are 1) external users must be able to verify transitions regardless of their involvement, 2) we introduce an agent $G$ that may conduct the full computation, and 3) we allow shielding to be permeable such that all involved parties can partially learn about all $S_i$ and $U_i$. This is MPC that's retrofitted to be particularly useful in blockchain contexts. These changes unfortunately lead to pure MPC solutions being insufficient.

### ZK and FHE are not silver bullets for all things shielding
It isn't immediately evident why the protocols we have today cannot fulfill the above requirements. Why not just use ZK or FHE? The answer is subtle.

Suppose we had user 1 as $G$ in our three party case. Why can't $G$ submit a ZKP to attest to $U_i = f_i(S_1, S_2, S_3)$? $G$ would need the pre-images $S_2$ and $S_3$ to prove that she's abiding by the validity predicates of the protocol. She only knows $\bar S_2$ and $\bar S_3$. Thus, $G$ cannot create the ZKP.

Why can't $G$ use ciphertexts encrypted under an FHE scheme? Producing $\{U_1, U_2, U_3\}$ might seem like the perfect use case for FHE. $G$ can encrypt a value $V_i$, then set $\bar U_i = \bar S_i + \bar V_i$. One problem: who holds the decryption key? It can't be everyone as in a multi-key FHE scheme since it cannot be assumed that all parties are online to provide permeability. It can't be just the owner of $S_2$ since she also cannot be assumed online. Close, but not quite.

Pure ZK or FHE solutions are effective for commitments with singular stakeholders. **When other parties get involved- the case for most interaction types- they are insufficient**. Cryptosystems must use ZK and FHE in conjunction with other technologies.

### Defragmentation will be attained through pragmatism


It would be a mistake to ship the fully decentralized system in one go. It's not how difficult things get done. Decentralization requires UX sacrifices, hardware requirements, and engineering resources. Jumping ahead without respecting the onboarding process is the quickest way to kill this mission.

We must first make interactive shielding broadly accessible with some trust assumptions. This will open the gates to the first wave of interesting applications. These applications signal to the community that the problem space is worth looking at.

Then we weaken trust assumptions, decreasing service provider risk while maintaining a consistent flow of exciting protocols. We do this as many times as is needed until we live in a world with minimal trust assumptions and transformative applications. Pragmatism gets us there. **This comes in the form of a phased approach to fully decentralized interactive shielding.**

We lay out the three phases. For all three, state is held in the clear off-chain and committed to on-chain. These commitments are transitioned via client-side ZKPs and lightweight homomorphisms.

The main axis where the three phases vary is *where* state is held off-chain. Phase 1 begins with strong hardware-based trust assumptions on holding state. Phase 2 weakens these assumptions. Phase 3 removes them entirely.

### Phase 1: State is held with individual shielding providers

> We describe protocols in the two party case with Alice (holding state $S_A$) and Bob (holding state $S_B$). We designate Bob to be P$. We want Bob to compute updated states $\{\bar U_A, \bar U_B\}$ such that $U_i = f_i(S_A, S_B)$ is publicly verifiable. Generalizes well to $N$ parties.

<figure style="width:100%;margin:0px">
<img src="https://hackmd.io/_uploads/H1t4pUTMp.png" style="width:100%"/>
<figcaption align = "center"><i>Shielding providers share intersections between Alice and Bob. This figure depicts the general communication sequence. When it's finished, ZKPs (and sometimes homomorphic commitments) are used to transition on-chain state.</i></figcaption>
</figure>

#### PROTOCOL

Providers bridge shielded state. They help $G$ generate proofs and ciphertexts to transition both $\bar S_A$ and $\bar S_B$. The sequence is as follows:
1. Alice is about to do some action that puts her in contact with Bob's shielded state. She shares her intended state $S_A$ in the clear with her protocol's provider.
2. Alice sends the commitment $\bar S_A$, along with a ZKP and a signature from the provider, to the chain. The provider signature enforces sharing prior to sending state on-chain, similar to how data availability is attested to today.
3. A light client run on the shielding provider checks for $\bar S_A$ state confirmation.
4. The shielding provider grants Alice and Bob knowledge of the intersection. This intersection can either be all of $S_A$ or $S_B$, or some subset of each. For instance, Alice may learn that Bob wants to sell `1000 LINK` and Bob that Alice wants to buy `1000 LINK`. The rest of their respective orders aren't revealed.
5. Bob uses this information to compute the ZKP to attest to both his and Alice's updated state commitments $\{\bar U_A, \bar U_B\}$. BWhat if the transition is bad for Bob and he doesn't want to compute the ZKP? The protocol can be set up such that either 1) Bob can't continue moving until he transitions 2) Alice gains from the ZKP and is incentivized to compute it.

The aim of this sequence is to **make providers as weak as possible**. It is a delicate process. Small tweaks that seem inconsequential may accidentally grant providers with needless power. Three actions providers must never do:

1. Providers must never do any non-verifiable logic on behalf of users. On-chain truth must be based on pure cryptographic assumptions (conditioned on being on a proof of stake network). "Truth" here refers to provenance. Shielded state isn't useful without it. Your ERC20 balance is only real if everyone agrees that it is not self-certified. The only way to do this is if **provenance is established using purely cryptographic state transitions and PoS**.
2. Providers must never have open deployments without working data off-ramps. If this isn't done carefully, providers can hold state hostage, disallowing protocols from exiting relationships. **Protocols must be able to securely export data to a different provider permissionlessly**.
3. Providers must never block on knowledge reveals. If Alice asks for the intersection a split second after Bob asks, the provider should follow through with the reveal without any opinion on ordering other than FIFO. **Doing so prevents the entrance of a privileged provider into the MEV pipeline**.

#### TRUST

This sequence and set of best practices work together to preseve the properties that currently draw people to build on blockchains. Infiniteness, computational integrity, provenance, composability, self-custody, transparency, and censorship resistance remain largely untouched [^1]. Even in the catastrophic event of a malicious party gaining full control over a provider, this party cannot steal assets, invent money, hold funds hostage, erase balances, etc.

What they can do is leak information. Shielding is where strong trust assumptions come into play. Providers are tasked with shielding state on behalf of their users. This is a point of trust. If providers misbehave, they can expose data.

Shielding will thus be reputation based. Protocols integrate with providers who will not attempt to exploit their own hardware. All providers will run clusters of secure hardware modules for defensive depth, though the trust assumption remains strong due to the possibility of side-channel attacks. At the end of the day, communities reserve the right to exit relationships with malicious [^2] providers and migrate their activity over to new ones.

#### ONBOARDING
There will be **no adjustment period for end users**. Client code remains asynchronous. Alice can commit to shielded state, then Bob can modify it years later while Alice is offline. Communication complexity also doesn't depend on the number of participants in the protocol. These follow the norms of blockchain interactions today.

With this smooth introduction, the world will experience the first wave of interesting apps built with interactive shieldeding. The success of these protocols will convince enough people that there's promise here. Generated momentum will be enough to carry us into the next phase.

### Phase 2: State held with committees of shielding providers

<figure style="width:100%;margin:0px">
<img src="https://hackmd.io/_uploads/SJjrPHwWT.png" style="width:100%"/>
<figcaption align = "center"><i>Rather than trusting individual shielding providers, protocols secret share their state across committees. The communication sequence is the same as with Phase 1.</i></figcaption>
</figure>

#### PROTOCOL
Rather than keep shielded state with individual providers, applications will secret share their data across credibly neutral committees.

The committee fulfills its role of bridging knowlege via a generalized multi-party computation (MPC) protocol. Running the light client within the MPC and giving developers adequate expressivity will be the two biggest engineering lifts for this phase.

These committees can unfortunately never be permissionless due to the weak falsifiability of collusion. Though there's been some work on slashing mechanisms for improper threshold decryption, this remains an open problem with hints of impossibility results under realistic threat models.

#### TRUST
We weaken the provider trust assumption in this phase. It now takes collusion between multiple providers to break shielding. Trust is distributed across [ideally] independent parties. Since trust is still involved, reputation and the right to exit remain critical components of the system.

As with Phase 1's construction, the standard properties of blockchain-based applications will be secured by cryptographic and proof of stake based mechanisms.

#### ONBOARDING
Generalized MPC runs in quadratic communication complexity, which is acceptable given the restricted set of parties on the provider end. What's important here is that protocol communication complexity again doesn't scale with the number of end users, each of which can still remain asynchronous.

Developer onboarding will have a higher barrier due to more complex writing knowledge revelation predicates. These predicates will have to be written in bare metal multiparty computation languages until dev-friendly DSLs are developed.

By the time these cryptosystems are in production, interactive shielding will prove to be a core property of blockchain applications. Users will have access to experiences that surpass any that we've dreamed up today.

### Phase 3: State never leaves users, shielding is purely cryptographic

<figure style="width:100%;margin:0px">
<img src="https://hackmd.io/_uploads/HJX-9Hwb6.png" style="width:100%"/>
<figcaption align = "center"><i>Users keep shielded state on their personal devices. Groups of protocol users find each other via peer-to-peer search. These groups share knowledge in an MPC, then use a collaborative SNARK to generate a proof for settling transitions on-chain.</i></figcaption>
</figure>

#### PROTOCOL
Phase 3 removes all dependencies on individuals or committees by having shielded state stay on user devices. The sequence used in Phase 1 and 2 no longer applies. Users will communicate directly with other users before settling interactions to the chain.

Users are now responsible for running nodes that share knowledge with the other parties involved in the computation. This is done via a peer-to-peer network where every user participates in two party computation (2PC) with every other user.

To be candid- there exists an abundance of challenges with this trust minimized design. The most worrisome one is that communication complexity now scales quadratically with the number of end users. Doing this naively with a billion people is intractible. Small peer-to-peer networks must be orchestrated within protocols. One instance shard in a game must be in a separate 2PC network from other instance shards. One trading pair in an exchange must be separated from other trading pairs.

Note that each network is a set of 2PC connections, and is not one massive MPC based on t-of-n secret sharing. This is critical in the permissionless setting. We cannot allow t parties to collude against the rest of the participants.

Collaborative SNARKs will be used to prevent information leakage to counterparties. The MPC used for both the SNARKs and the knowledge sharing must now be built with guaranteed output delivery to prevent malicious end users from exiting unfavorable interactions.

#### TRUST
Shielding is based on purely cryptographic assumptions. Reaching this phase is non-negotiable. **It is the only solution[^3][^4] for interactive shielding that is fully aligned with the principles of crypto and the better system that we are building toward.**

#### ONBOARDING
The momentum we generate before this phase must be enough to convince people of the steep onboarding costs. Everyone needs to run an MPC agent 24/7 in their homes. In addition, application latency will be noticable if the peer-to-peer networks aren't well orchestrated.

DSLs developed in Phase 2 can be adapted to fit the peer-to-peer model. Developers will be assisted with these DSLs and the infrastructure necessary to spin up / down these 2PC networks for their users.

With the help of the experiences driven by interactive shielding, casual end-users are convinced of the utility of blockchains. They believe in decentralization and are willing to do the work necessary to participate.

### What we're working on at Seismic
Our team is tackling the many challenges associated with building out a Phase 1 pipeline. Granting devs turn-key access requires improvements in client-side proving, expressive interaction predicates, data availability, reorg resistance, load balancing, and much more.

If this is 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.

[^1]: There are many qualifications to this claim that we will outline in future posts.
[^2]: Identifying a malicious provider is difficult due to the weak falsifiability of data leakage. It's a topic that deserves its own line of articles. Many of the strategies involve some staking mechanism with whistleblower slashing or statistical analyses, both of which are suboptimal.
[^3]: Alternative paths are available if functional encryption is solved. Many on our team are rooting for this.
[^4]: Pure ZK or FHE solutions can also suffice now that we have an always online requirement, though those will likely be less computationally efficient than the 2PC network.