Traditional Privacy Framework
The limitations of traditional privacy frameworks in enabling composable privacy.
An ideal privacy framework enables seamless composability across a system’s components, allowing users to interact securely with various smart contracts and applications while maintaining privacy and trust. Traditional privacy frameworks, often categorized as Monostatic, Multistatic, or SubSocket systems, struggle to achieve this due to their design constraints.
Classification
Traditional privacy frameworks provide either data privacy, focusing on transaction privacy, or functional privacy, emphasizing smart contract functionality. They are categorized into three types: Monostatic Systems, Multistatic Systems, and SubSocket Systems.
Mono-Static System
Monostatic systems allow users to process computations using a pre-defined function (Ø) to update the system’s global state. While they support arbitrary computations and maintain user anonymity, their lack of flexibility limits composability. The system’s state remains confined to the pre-defined function Ø, making it challenging to interact with external smart contracts or applications.
Example: Zcash
Zcash is a leading example of a Monostatic system, enabling privacy-preserving transactions on Bitcoin-like frameworks. Its global state ensures encrypted commitments, with ZK-SNARKs providing scripts to validate honesty and integrity during state updates. This keeps transactions secure while maintaining user anonymity. However, this design restricts interactions with external systems, limiting its composability.
Multi-Static Systems
Multistatic systems allow users to modify the global state by defining arbitrary functions (β, δ, ζ, η, ...) and inserting new variables into the ledger, ensuring privacy within the system. However, their UTXO model fragments and encrypts the global state, limiting users to interact with only a portion of the application state. While peer-to-peer (P2P) inter-process calls are possible, they require users to expose their state, compromising privacy during cross-system interactions.
Example: ZEXE
ZEXE, an extension of the Zerocash paper (2018), supports arbitrary computation on a private ledger, offering both functional and data privacy. It modifies Zerocash’s instruction set to operate on records (instead of coins) using birth and death predicates. Protocols like Mina and Aleo implement this framework, but its UTXO model restricts composability by exposing user state during external interactions.
SubSocket Systems
SubSocket systems are hardware-based frameworks, similar to Multistatic Systems, that support arbitrary applications (Δ = {β, δ, ζ, η, ...}) through various functions. Designed for flexibility, they use account-based models and support a wide range of Virtual Machines (VMs), allowing users to interact with entire contracts—unlike the function-level interactions in Multistatic Systems.
The global state comprises contracts protected by unique key pairs generated within a Trusted Execution Environment (TEE). Users encrypt inputs to interact with individual contracts and decrypt outputs using their private keys. However, SubSocket systems lack inter-process communication between contracts in the global state, fragmenting the system into isolated, heterogeneous contracts and limiting composability.
Example: Secret Network
Secret Network, along with Phala and others, implements a SubSocket framework. It uses TEEs to encrypt contract states, ensuring privacy for individual contracts. However, the lack of inter-contract communication restricts efficient composability across the ledger.
Last updated