Hello guys,
We’ve spent over five years pursuing blockchain privacy and have built and validated several concepts via PureFi Protocol.
Right now, we are focused on building a seamless cross-chain privacy model that balances security and compliance. We intend to achieve this by integrating advanced zero-knowledge (ZK) protocols with an architecture based on an internal ledger and an R-Bridge. Here is our vision of non-custodial self-banking protocol with pluggable privacy in Web3:
Our Solution: An Integrated Approach
Our solution is based on the insight that wallets can do more than merely sign transactions. By integrating local private state management and bridging capabilities, we provides a platform that offers:
- Robust Privacy: Ensuring that once private state data is computed locally, only a succinct, non-sensitive proof is ever transmitted.
- Cross-chain Compatibility: Bridging internal privacy-preserving operations with external blockchain transactions via a dedicated R-Bridge.
- Compliance without Exposure: Leveraging modern ZK protocols to meet regulatory compliance without exposing confidential user data.
The solution is implemented via two key technical components:
2.1 Internal Ledger (Private State Management)
At the heart of technology is a wallet-managed internal ledger that provides secure, local management of private state. Key aspects include:
-
Local Private Storage:
The wallet securely stores sensitive user data (such as KYC credentials, secret notes, digital passports) in an encrypted private state. This storage is managed on the user’s device and never directly transmitted to the blockchain. -
Pluggable Computation Circuits:
The integration of pluggable algorithms (or “circuits”) that execute computations locally. These circuits have full access to the private state data but operate in an isolated environment with no external communication until the computation is complete. -
Proof Generation:
Once a circuit completes its computation, it outputs a compact proof - a “fact” about the private state - that is the only piece of data allowed to leave the secure environment. For instance:- Example 1 – Age Verification for a Swap Protocol:
A user’s digital passport is stored privately. A circuit downloads the necessary algorithm, computes a proof that the user is over 18, and releases this proof to be attached to an on-chain transaction. The smart contract then validates the proof and processes the swap. - Example 2 – Privacy-Preserving p2p Transfers:
When users deposit tokens into a privacy-preserving pool, a “crypto note” is issued and stored privately. Designated circuits are later allowed to process these notes - computing nullifiers and proofs - thus ensuring the tokens remain confidential until spent.
- Example 1 – Age Verification for a Swap Protocol:
2.2 R-Bridge: Bridging Internal and External Ledgers
The R-Bridge is a set of smart contracts designed to create a secure interface between the internal ledger and external public blockchains. Its functions include:
-
Cross-chain Asset Transfer:
The R-Bridge facilitates the movement of assets by linking internal state proofs to on-chain transactions on external ledgers. It monitors the updated state proofs (similar to L2 rollup validators propagating state changes to L1) and validates them, enabling users to claim their assets without direct interaction with the internal chain. -
Safety Mechanism:
This approach minimizes risk by isolating sensitive internal transactions from public chain interactions. Users can provide a state-proof to the external chain, which then allows them to withdraw a corresponding portion of crypto assets, all without exposing the internal state. -
Compliance Integration:
By leveraging zero-knowledge proofs within the R-Bridge, compliance data (such as digital attestations for KYC or age verification) is verified without revealing underlying personal data, ensuring both regulatory compliance and user privacy.
Privacy-preserving Smart Contracts
We define a privacy-preserving smart contract as an executable code capable of operating with two distinct classes of data: private information, which is exclusively accessible to the user, and public information, which is universally accessible. In contrast to traditional Solidity smart contracts on EVM-based blockchains, our approach mandates that sensitive user data - referred to as the private state - remains processed and stored locally on the user’s device. This constraint is critical given that the private state may contain highly confidential information, such as KYC credentials, secret notes, or personal identities, and therefore should not be transmitted beyond the user’s secure environment. Conversely, the public state is intended for information that is designed to be shared among all network participants.
Given these dual levels of confidentiality, it becomes necessary to implement a rigorous access control system to regulate how data is accessed and manipulated across these tiers. The foundational principles for such an access control framework in state-transition systems - such as blockchains - are rooted in the work of Bell and LaPadula. This model mathematically defines the “system”, its state and transition relations so that if the initial state is considered secure, then each subsequent state is considered secure as well. Referring to the initial description, the system Σ(R,D,W,z0) ⊆ X × Y × Z is defined by (x,y,z) ∈ Σ(R,D,W,z0) if and only if (xt,yt,zt,zt,-l) ∈ W for each t ∈ T, where z0 is a specified initial state usually of the form (φ,M,f), where φ denotes the empty set. Practically, this model defines one discretionary access control (DAC) rule and two mandatory access control (MAC) rules with three security properties:
- The Simple Security Property states that a subject at a given security level may not read an object at a higher security level.
- The * (Star) Security Property states that a subject at a given security level may not write to any object at a lower security level.
- The Discretionary Security Property uses an access matrix to specify the discretionary access control.
Visually, this could be represented with the following diagram:
In our particular case, we have 2 levels of confidentiality: Private and Public, so according to the BLP model, we’ll have the following DAC matrix:
| Into/from Object in private context | Into/from Object Public context | |
|---|---|---|
| Subject in Private context can | read/write | Read |
| Subject in Public context can | append | read/write |
More complexion arise when we put the following statement into the equation:
- Public state is shared between all the users, system to keep it in consistent state
- Private state is NOT shared, meaning that user A doesn’t have access to a private state of user B, despite the fact that they are technically on the same confidentiality level according to the BLP model.
It’s easy to address item 1, because blockchain is essentially a system that was designed to solve this problem, but it’s not easy to address item 2. Unless we employ Zero Knowledge.
The problem of doing computation on the user’s side was addressed by Zexe. We will follow the same approach to do computations on the user’s private state. According to research by authors of Zexe, private state should be structured and kept in the form of UTXO with defined state transition rules, that will result in adding new state as ZK Note and nullifying previous state with appropriate Nullifier, likewise it was defined in ZCash paper. This way an execution of a function (or computation) looks like:
Given as input a list of old records [ri]1m with corresponding secret keys [aski]1m , attributes for new records, private auxiliary input aux to birth and death predicates of new and old records respectively, and an arbitrary transaction memorandum memo, DPC.Execute produces new records [rj]1n and a transaction tx. The transaction attests that the input records’ death predicates and the output records’ birth predicates are all satisfied. The user subsequently pushes tx to the ledger by invoking L.Push(tx).
On input public parameters pp and a transaction tx, and given oracle access to the ledger L, DPC.Verify outputs a bit b, denoting whether the transaction tx is valid relative to the ledger L.
This approach guarantees that private state data doesn’t leave users device, the only thing that is transferred back to the blockchain node is the proof that computations were a) performed b) completed without errors.
From the system security point of view, it breaks what BLP model defines (because proof is essentially a result of computation on Private confidentiality level, which should not be written to or accessible to a code (a subject) on a lower level of confidentiality). But, as far as this proof doesn’t explicitly contain any information stored in private state, this is considered acceptable from the security point of view.
Conclusion
The challenges of transparency, pseudo-anonymity, and regulatory compliance in today’s blockchain systems demand a fresh approach to privacy. We address these issues by combining a wallet-managed internal ledger that securely holds private state data with an R-Bridge that connects internal proofs to external chains. This architecture ensures that sensitive computations are performed locally and that only non-sensitive, verifiable proofs are shared on public ledgers. By leveraging modern zero-knowledge cryptography and a robust access control model inspired by the BLP framework, we can achieve a level of privacy that is essential for next-generation decentralized finance (DeFi).
As blockchain ecosystems continue to evolve, the offered integrated solution provides a critical enabler for secure, compliant, and user-friendly cross-chain interactions - paving the way for a future where privacy is a fundamental right rather than an afterthought.