Making ethereum institution friendly & solving the duality of confidentiality — Part B (Cryptography behind the Silent Compliance VM)
Silent Compliance VM -part B
Read more
You can find part A of this continuation post here. We discussed different types of frameworks and learned about the condition known as “state denial” found in privacy-preserving systems. In this concluding post, you will learn about our proposed patent pending framework EZEE and how it avoids the condition known as state denial to help us build fluid privacy into practice.
We need privacy. It’s no hidden fact; we need privacy to secure our data. Web2 is private, and web3 deserves no less. We have come a long way in configuring schematics that help us provide two kinds of privacy to users: Functional and Data privacy.
Multistatic systems allow users to call arbitrary functions and change the global state machine. It enables users to bring functional privacy to life, where it keeps outside observers in the dark about which functions are instantiated and by whom. Sub-socket and monostatic systems allow users to update the global state machine by calling functions defined within the system and enjoy input-output privacy or Data privacy.
In our previous post, we systematized all the existing solutions and classified them into three frameworks, namely, monostatic, multistatic, and sub-socket systems. We also summarized that these available frameworks could support applications with certain properties, namely:
This is great and works well for certain applications. However, it does not allow for the creation of an ecosystem of privacy-preserving applications that can share their state and be interoperable.
Due to what it means to make an application state private, sharing the state with some other agent foreign to the data source becomes paradoxical. It is caused by the problem of state denial, which states that– you can either make an application private or make it composable with the rest of the ecosystem. However, in a privacy-preserving framework, allowing shared states to exist at the universal level becomes difficult, which deters the creation of interconnected applications. This is the biggest blocker to the application and adoption of privacy-preserving technologies.
In this post, we declare that alone, zk proofs aren’t enough to solve the problem of state denial. We describe our blueprint EZEE that builds under a new system and enables fluid privacy into practice. A system that can facilitate global state sharing that allows users to post state updates privately with arbitrary dimension expansion of the system state.
We have realized a few key points: to build a system that enables fluid privacy, we must avoid encrypting user data. Encrypting user data confronts state sharing at direct length and should be avoided. We need to build a framework that allows users to access aggregated state data and interact with smart contracts, which is crucial for making privacy-preserving systems user-friendly.
A few design frameworks are available today that utilize cryptographic primitives to enable privacy-preserving computation for smart contracts, such as Zether, smartFHE, PESCA, and zkHAWK. PESCA is the only one that doesn’t suffer the absolute consequences of “state denial.” Based on the preliminary design of penumbra, PESCA proposes to utilize threshold- Fully Homomorphic Encryption (FHE) to develop a solution applicable to only a subset of applications which helps them make their global state public. However, working on top of both smartFHE and PESCA will only be feasible once we figure out how to make FHE scalable and efficient for blockchains. On the other hand zkHawk, smartFHE, and zether propose an architecture that allows users operating on a confidential environment to lock/freeze assets into target smart contracts, which gets computed off-chain through an MPC protocol for zkHAWK and gets evaluated on-chain for both zether and smartFHE, through the use of homomorphic encryption. Nevertheless, indifferent to the cryptographic technique, the end contracts operated on suffer from the undeniable fate of state denial.
We choose to start designing EZEE from the framework proposed by Zether. Zether pushes for a design structure where users can store encrypted balances and interact with smart contracts that execute their computation on-chain. Zether demonstrates how users can interact with arbitrary smart contracts through its “lock method.” Users can lock their Zether account, which contains encrypted balances into arbitrary contracts to call a target function. The user passes their arguments by building up ciphertexts to interact with the end contract, which changes the state of the user’s Zether account at the end of the operation. Through the design structure proposed by Zether, users can interact with purpose-crafted contracts to provide privacy. Each of these end contracts deals with ciphertexts and computes through the help of homomorphic encryption, depending on the properties of an additive homomorphism.
However, because end contracts depend on the user’s Zether account, the contracts cannot interact with other contracts to process inter-function calls. They are limiting the scope of the computation on an individual application in this paradigm by only enabling access to its local data, resulting in the condition described as State Denial.
EZEE is a new design framework, purpose-built to avoid the condition prevalent in other privacy-preserving systems called state denial and help instantiate and enable “fluid privacy” for the first time. The problem in Zether stems from end applications needing users to lock in their encrypted Zether account to process different operations. This causes end applications to process zk-proof for various applications to update the system state. Zether can be divided into two silos: the execution silo and the encryption silo, wherein the silo contains the user data and assets in an encrypted format. In the execution silo, arbitrary purpose-crafted smart contracts allow users to execute calls confidentially. Both the execution and encryption silos are intertwined and interdependent on one another due to the lock and the unlock method proposed in Zether.
EZEE fragmentizes the encryption and execution layer in Zether through a novel protocol known as EZEE Signals. EZEE is an evolution of Zether that intends to solve the problems observed in Zether. We propose a formulation through which end contracts don’t need to rely on encrypted inputs to provide and operate on privacy while processing computations. It’s an ideal framework where encrypted data isn’t utilized for updating the target smart contract state and yet can provide its users the ability to retain data confidentiality and anonymity by splitting flows. Achieving this flexibility means being fluid with the rest of the ecosystem.
The encryption layer in EZEE allows users to maintain a primary account and keep its account state private and confidential. We build a monostatic environment with predefined instructions to update the encryption layer. One of the functions prescribed within the encryption layer lets the user’s primary account formulate secondary base layer addresses designated to operate target applications in the execution layer of the EZEE framework. Users can split their encrypted primary account balance into unencrypted secondary account balances to interact with the target application. The encryption layer defines methods to allow users to aggregate the states of their secondary accounts back into the primary account following target function computation within the execution layer.
The execution layer inhabits different end contracts that allow a user to update its state. These contracts are normal Ethereum or any base chain smart contract with public data and values. Users are allowed to post computation requests to them through secondary addresses. These secondary addresses publicly reflect the state while retaining user anonymity and allowing the user to aggregate the state back into the primary account held within the encryption layer, helping build on the technique of splitting flows. Overall this framework enables a user to keep their account state confidential and post anonymous calls, where they can access the global shared state of the entire system while making smart contract calls. The execution layer can contain many end applications. Based on the application ID, the user can utilize EZEE Signals, which lets the user establish an anonymous asset transfer channel between the encryption and the execution layer of the system. As dictated at the start of this section, we configure a technique other than traditional zk systems, where we encrypt user data and details and enable the user to access the global state of the protocol.
Through EZEE and EZEE Signals, we can provide users the ability to store confidential(encrypted) data and post anonymous calls to target smart contracts that don’t rely on encrypted inputs or any zk proofs.
EZEE Signals are signer ambiguous anonymous message passing protocol between two endpoints based on the many out of many proofs and Application identifiers. The EZEE framework fragments the encryption and the execution layer and lets the users segregate their states while carrying out operations on target applications. Instead of allowing end contracts to update the user’s primary account in the encryption layer to reflect the resulting operations, EZEE enables these end target contracts to access temporary assets through the user’s secondary accounts anonymously. EZEE Signals helps us form an anonymous asset transfer channels between the encryption and the execution layer by creating two private endpoints. We define EZEE Signals as a function ϕ:= (π, α), where π is a protocol for selecting a tuple of accounts based on the result of the operation α.
Through EZEE signals, a user can connect to any target applications from their encryption layer and execute privacy-preserving function calls. Once the resulting state has been reflected on the user’s secondary account, the user can aggregate his public yet anonymous state into the encryption layer in his primary account contained within the encryption layer. EZEE enables efficient Data privacy for a user’s account, protecting its current state from network Observers.
To summarize, EZEE builds a framework for programmable privacy that allows users to update arbitrary smart contract contracts in a privacy-preserving manner. A framework that does not suffer from the condition of state denial. Instead of allowing the protocol to make the end contracts that are arbitrary and deemed to expand the system state dependent on encrypted inputs, unlike other protocols– EZEE acquires a design framework that divides the framework into constant and expandable system states and segregates the users’ primary encrypted account state into n number of secondary account states to orchestrate target execution slios. Individual execution silos operate within the execution layer interacting with the end contracts that retain the ability to access the global shared state of the system (courtesy of non-dependency on any encrypted inputs while calling the end function). EZEE segregates the encryption and the execution layer through the use of EZEE Signals that allows for the creation of arbitrary application-dependent anonymous asset transfer channels that enable the aggregation of spatial states stored within different execution silos back into the encryption layer — building a framework capable of providing fluid data privacy.
EZEE is our patent-pending framework that enables fluid privacy, allowing users to update arbitrary smart contract contracts in a privacy-preserving manner while authorizing them to access the global shared state of the system, all the while providing users the ability to make private state transitions within the system. Silent Protocol is our implementation of EZEE, through which we allow users to interact with their favorite on-chain applications in a privacy-preserving manner while being able to interact with them in a compliant and fluid manner.
Silent protocol helps build a privacy module within existing smart contract-enabled blockchains that allow users to interact with existing applications in a privacy-preserving manner without bifurcating their network effect. EZEE, due to striking off end contracts from depending on any encrypted inputs, allows the users to interact with contracts natively through individual execution silos or 0dapps.
In Silent Protocol, 0dapps are deployed to encapsulate end applications that constitute the execution layer of the system. Users can operate from the Silent’s Encryption layer, where they can segregate and break down the state of their primary account to create secondary accounts based on the 0dapp. Silent protocol, through its 0dapps, can provide users with metadata and network-level privacy while interacting with target applications. For the first time, through these 0dapps, users can interface with the target application without creating zk proofs while retaining privacy, thereby creating an economical zero knowledge execution environment for users to execute smart contract calls anonymously. Silent Protocol allows users to operate n 0dapps running concurrently with one another and lets users aggregate their state back into Silent Protocol’s encryption layer through EZEE signals.
Silent protocol is bringing privacy to public blockchains. Generally speaking — privacy is disturbed for two reasons, one is state denial, and the second is answering the question of- “who will pay for my gas?” However, Silent protocol, through its implementation of EZEE, can solve the problem of state denial and, through its novel renode layer, brings anonymous relaying and privacy on public blockchains to life for the first time.
You can interact with applications such as Maker Dao with a secondary account, open a vault, and consolidate the $DAI into the user’s primary Silent account in a preserving manner. Most interestingly, without creating any zk proofs while interacting with Maker DAO in our above example. This is the flexibility provided by Silent Protocol. Through EZEE, Silent Protocol can give birth to complete fluid privacy, where arbitrary end contracts can be interfaced with through 0dapps, letting the end contracts access a shared state. Silent protocol can enable a wide range of applications, such as privacy-preserving cross-chain swapping, anonymous NFT trading, anonymous derivative trading, etc. Silent protocol has been live on testnet for a few months already. We are here to make your life better. Stay ready.
Reach out to us via email (info@silentdao.org) 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.
Silent Compliance VM -part B
Read more
How Silent will compliantly serve its users
Read more
Announcing chapter 1: Becoming a Silencer
Read more