‘EZEE’: The final answer to the tango between private and public systems- Part A

March 20, 2023


With Web3 technology taking the wheel and driving us toward a new era of ownership-driven software, one key concern remains — Privacy. Are users comfortable being tracked with their user data by random anonymous parties? Such practices are anti-user and can hinder the mass adoption of this incredible movement. Data needs to be secure and in an ideal world only, should be accessible to people with any business to do with it. However, in practice, due to the public nature of blockchain, we post data publicly, making it widely accessible to anyone with an internet connection. This is highly insecure. There are data privacy policies in traditional companies for good reasons, and to bring traditional applications to this new internet, we need to figure out web3’s version of HTTPS. In this post, the first in a two-post series, we talk about different schematics trying to bring Privacy to blockchains and denote what’s missing, why it is essential, and why it is missing.

Why is Privacy of central importance in our life?

It is not competent to tell the whole world how much you are worth, what you earn, and how much money you spend, and this is why Cash today is private. You will not be able to tell the last ten people who touched your 10 <your currency> bill. A lack of Privacy in a system means a lack of security. In the web3 world, you are simply not dealing with money; you are dealing with various applications that record your output on-chain, which is all linked back to you. It’s like making your private-diary public.

For long-term success in developing complex systems, ensuring personal information stays private while coordinating with other network members becomes essential.

Plunge deep into a world that is anything but private — the blockchain. Operating in this new paradigm means your address serves as your identity, and every interaction you have with it can lay bare all of its data-driven activities for everyone to see.

Indeed, when left unchecked, public blockchains become open to exploitation — making privacy solutions integral if users are to maintain peace of mind on their journey through cyberspace.

Timeline of our past developments in privacy-preserving systems for blockchains:

Despite an immense amount of investment and research into achieving widespread adoption of Privacy on blockchain systems, all efforts have proven anything but elusive — it is time to evaluate the existing frameworks. That’s why we analyze the current solutions into categories for further examination to gain insights into why they have yet to be implemented effectively.

Mono-Static System — The Grand Start:

Let’s start our journey with monostatic systems. This type of framework allows a user to process computation on a pre-defined function Ø to help them update the global state of the system. This lack of flexibility to support arbitrary computations would make such schematics identify as a static system with pre-defined and known variables. Essentially, the state of the entire system stays enclosed and cursory within the set of pre-defined functions Ø.

Abstract representation of a Monostatic system

Zcash is a leading example of a Monostatic system, which has enabled the development of privacy-preserving Bitcoin-like frameworks. Its global state comprises encrypted commitments in the form of notes produced by pre-defined scripting capabilities provided within its Zerocash framework. Zk-snarks validate honesty and integrity when updating this ledger, keeping transactions secure while maintaining user anonymity.

Multi-Static Systems- Trying out new things :

Next up, we have Multi Static systems. These are systems that support the modification of the global state update layer, by allowing for the insertion of new variables into the ledger. These are frameworks that will enable a user to define arbitrary functions (β,δ,ζ,η…) and help them retain complete Privacy while operating on them.

Abstract representation of a MultiStatic system

ZEXE, a modified extension of the zerocash paper that came out in 2018, is one of the better answers to having a system built to support arbitrary computation on top of a private ledger providing users with both functional and Data Privacy. ZEXE modifies the existing instruction set provided by the zerocash paper and operates on records instead of coins based on their death and birth predicates. Mina, Aleo builds implementation of this framework.

The schemes under multistatic systems are built using the UTXO model, where the global state of the system is stored in a fragmented and encrypted format. Users never get to interface with a complete application state and can only interact with other users through individual functions in a p2p manner. Users can make inter-process calls between two processes, but only if the user has any state exposed in the end function. A user only gets to interact with a part of the application.

Sub-Socket Systems- Let us close our eyes, then others can’t see us:

Sub-Socket systems are hardware-based frameworks that draw parallel with multistatic systems in that users can modify the global state of the system where they can support any arbitrary applications Δ = {β,δ,ζ,η…} — made up of different functions as a whole. These are designed to be flexible and can support a wide range of VMs. These can support account-based models and allow users to interact with a contract as a whole compared to accessing a function to process an interaction provided by the multistatic systems.

Abstract representation of a Sub Socket system

The global state layer of such systems comprises different contracts protected by unique key pairs generated by the systems. Users can interact with individual contracts by encrypting their inputs for processing by the hardware(TEE). Users can view the output from the global state layer of the system by decrypting it with their private key. Secret Network, Phala, Etc., are various implementations of sub-socket systems.

Sub Socket Systems help users interact with the entire contract state in an aggregated format but cannot perform inter-process communication between different contracts residing within the global state update layer and essentially fragment the whole system into heterogeneous and isolated contracts running on top of the ledger.

The problem of “State Denial” in privacy preserving systems:

We successfully conveyed two kinds of Privacy: Functional and Data Privacy, from the handful of frameworks available to us in building privacy-preserving systems. We can provide users the ability to hide their data and function through multistatic systems while making a state update. We can provide users with data privacy through monostatic and sub-socket systems, where they can hide both their input and output after initiating a function in the system.

As a recap on the systems based on their properties, we have three types of classification. Starting with monostatic systems where the dimension of the global state in the system is kept constant. Users can only operate on a fixed set of instructions to carry out operations to update the system’s state. Following up with multistatic systems, which allow the user to modify the dimension of the global state of the system by defining new functions based on specific rule sets and expanding the framework’s capabilities. Finally, in sub-socket systems, users define multiple heterogeneous spaces isolated from each other defined within the global state update layer.

Apart from being able to provide Functional and Data Privacy through these frameworks irrespective of the cryptographic primitive put to use, we come across the following roadblocks.

Monostatic systems force users to operate within a narrowly-defined scope, preventing them from making arbitrary modifications. Designed primarily to preserve value, these restrictive environments only satisfy people beyond the community that prioritizes this singular goal.

Additionally, in monostatic and multistatic systems, users are prevented from accessing the entire state of the system or any particular application. This is due to a single-user state being stored in a fragmented and encrypted form within the system. Apart from the difficulties in predicate-based programming, we only envision somewhat-inter-function (process) communication between two different programs in multistatic systems, where a user can only interact with another function if the user has a state in the target program.

Apart from multistatic systems, we are also unable to provide users access to the global shared state of the entire system in sub-socket systems. We are able to provide users access to a shared state of their program but fail to give users visibility into other program states within the same global state layer — ending up precluding any inter-functional calls within this framework.

The common denominator in all our classified frameworks is our inability to provide users access to foreign states defined within the system, essentially creating Isolated environments per user in our global ledgers. This results in the need for inter-function calls between programs, impeding users’ access to an entire system’s worldwide state and thereby hindering the growth of privacy-preserving systems. This phenomenon is known as “State Denial.”

The Paradox:

If you want to create an encrypted program, be it through homomorphic encryption, MPC-based private contracts, or any other techniques utilizing any frameworks, you deal with the fact that once you make any variables in your system: private, other network members will be prohibited from interacting with your private data. In other words, your private data is a type of private island in the global state update layer that localizes and authorizes its access to only the data owner, making other network participants blind to the global content of the system until agreed upon.

Each private application, be it built on any system, provides the user the ability to make intra-function calls, allowing users to interact throughout the system with one another but inhabits the power to process inter-function calls in between multiple programs, where the call of foreign origin, concerning the target program, is unable to access the state.

The property mentioned above is critical to making a system private, however this is fundamental to the way Zero-knowledge systems work.

As a rule of thumb, whenever you make an application state private (hidden from the network), you make the state accessible to only the local user(s) of that application and guard any foreign actors from accessing your application state. This is a universal condition for all privacy-preserving systems known to us and known as State Denial.

We learned about two types of Privacy provided by the above frameworks: Functional and Data Privacy. However, there is a new type of Privacy known as Composable Privacy, where we can provide users access to the global shared state of the system and still allow them to make private state transitions. Privacy derived from such an ideal framework is known as Composable Privacy.

Among the three frameworks we have classified our existing systems only: Multistatic systems allow for somewhat-inter-function (process) communication. Multistatic systems such as ZEXE, zkVM, Dialeaktos, Etc., leverages an UTXO-based framework that does not enable any form of system-wide state aggregation. Instead, users can only interact with each other through select functions, and that too if they have already registered their application status in the program. As all user data remains encrypted and individualized, there cannot be applications such as AMMs built under this paradigm as such actions would require access to the entire ecosystem’s state — something the multistatic framework does not support, leading to more of a peer2peer focused applications under this framework.

Smart Contracts on public blockchains enable users to cross-interact with multiple programs and post-atomic calls, offering tremendous flexibility over a traditional database architecture. Transactions are securely recorded using a distributed ledger system across nodes of operators who can view an updated global state for each contract change accepted into the network. This structure allows for innovative solutions maximizing decentralization and access previously seen before.

This entire multidimensional access flow and the ability to post inter-function-calls becomes impractical if we make a part of the system state private in our global state update layer, as access to the data becomes revoked (i.e., the problem of state denial) or somewhat paradoxical if we would want to make the system have the ability to cross interoperate. Even in our sub-socket systems, where we can provide users access to the entire application state in an aggregated manner, we still need to give users access to other application states online within the same global state layer. It becomes difficult to establish an ecosystem of applications providing users with Privacy-preserving state transitions on a permissionless and decentralized smart contract-enabled account-based system if we utilize any of the private frameworks described above.

We must build a schematic and define the framework that allows composable Privacy to exist. A system where somebody can access end applications in a Privacy-preserving manner where applications can share the system’s global state with other network members. This property is what underpins current applications on Ethereum and Ethereum-like chains. Applications under this framework can perform inter-function calls, helping us expand value flow within the network rather than treating themselves as an isolated fragment.

However, to recap the problem of “State Denial, a private application or program built to encrypt an application state can’t have its state shared with another application or have the capability to interoperate or make inter-function calls among one another to its fullest extent. Thereby handicapping substantial private ecosystem growth and hindering user experience, and thereby the paradox that we are facing at this stage can be worded as:

“If we want to make an application state private, we can’t share the details of the system with the rest of the members in the network, but if we want to make an application composable, we cannot permission access to the application state.”

To realize our ideal environment, we must figure out how to put composable Privacy into practice. But how do we create a thriving private environment? How do we build a framework for a privacy-preserving and general-purpose smart contract interaction under the same availability and decentralization characteristics exhibited by public systems and most importantly where we wouldn’t need to isolate the application state?

State Denial is a severe issue, but Silent Protocol’s Economical Zero Knowledge Execution Environment (EZEE) solves all the above reprimands with remarkable simplicity. It is a novel framework that allows for composable Privacy, and we’re eager to share more details about its background and constitution soon! Stay tuned as the next post unveils all — until then, stay safe!

Are you interested in learning more or getting involved?

Please email us via ( and follow us on Twitter.

(To the Developers) If you’re interested in integrating your application with Silent protocol to gain compliant and user friendly Privacy, contact us.

Don't miss a thing

Introducing the Ghost layer- the first modular L1.5 for ethereum

Announcing chapter 1: Becoming a Silencer

Read more

Silent Protocol at DevConnect 2023

Silent Protocol at DevConnect 2023

Read more

Introducing 0dapps

Changing how people interact with web3 application

Read more

Keep me in the loop

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Keep me in the loop

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.