Skip to content

Commit e268bfc

Browse files
mmagicianmmagician
authored
Compliant privacy application (#2521)
1 parent 7260c94 commit e268bfc

File tree

1 file changed

+225
-0
lines changed

1 file changed

+225
-0
lines changed

‎applications/np-compliant_and_programmable_privacy.md‎

Lines changed: 225 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,225 @@
1+
# Nullifier Prime: Compliant and Programmable Privacy
2+
3+
- **Team Name:** NP Labs
4+
- **Payment Details:**
5+
- **DOT**: 15mXzKEjNF8mMQA7hprb7MaFRu9iWNsTsr3CsXsG5iryBkbo
6+
- **Payment**: Fiat, details to be shared upon approval
7+
- **Level:** 3
8+
9+
## Project Overview :page_facing_up:
10+
11+
### Overview
12+
13+
Nullifier Prime is a pragmatic approach to programmable and compliant privacy for blockchain applications. Our solution combines features of the Ethereum Virtual Machine (EVM) with a Zcash-like middleware for protecting assets at rest, automatically shielding and unshielding assets before and after smart contract interactions.
14+
15+
While private transfers on blockchains have been solved through solutions like ZCash since 2016, programmable privacy (maintaining anonymity while using smart contracts) remains a challenge. Current solutions face trade-offs between privacy and composability, with complex technical implementations that are difficult for developers to work with.
16+
17+
Current shielding pools implemented as smart contracts are prohibitively expensive, as they must emulate complex cryptographic primitives through EVM opcodes. More critically, these solutions demand specialized technical expertise from users to maintain privacy guarantees. Users must navigate a cumbersome process of key generation, management, and manual shielding/unshielding of assets, while carefully splitting funds to avoid information leakage.
18+
19+
We're developing the first-ever "no-click privacy" solution, where users can seamlessly interact with smart contracts without managing privacy operations themselves. Our wallet automatically handles the entire privacy lifecycle—shielding assets, unshielding when needed, and implementing randomized fund splitting strategies—all without requiring user intervention or technical knowledge.
20+
21+
Our project integrates with the Polkadot/Substrate ecosystem by forking the Frontier framework to deploy a Substrate-compatible EVM+ parachain. The privacy features will enhance the functionality of Substrate-based chains which can natively interact with Nullifier Prime.
22+
23+
Our team is interested in creating this project because we believe programmable privacy is one of the largest untapped markets in the blockchain space. It enables not only consumer adoption but also opens the door to institutional players for whom compliant privacy is a fundamental requirement.
24+
25+
While we believe that fully permissionless privacy is the future, we believe that the current market is ready for a pragmatic approach that protects the user's activity from the broad public, while revealing it to the relevant authorities. Our goal is not to advocate for any particular authority, but rather build the tooling that enables various use cases, including 1) a single authority (e.g. a KYC provider) that can monitor the activity of its citizens, 2) offchain consortium of regulators that can collectively deanonymize transactions via a multisig, 3) onchain governance of privacy parameters. Long term, we believe that tools like verifiable AML (using zkML) will become a standard part of the blockchain stack, allowing for permissionless privacy for the entire ecosystem.
26+
27+
### Project Details
28+
29+
Our project involves creating an EVM+ chain with customizable middleware enforcing privacy-compliance trade-offs at the middleware layer. The key components include:
30+
31+
- **Enhanced EVM Engine**: A fork of [Frontier](https://github.com/polkadot-evm/frontier) (including pallet-evm and pallet-ethereum) and its underlying execution engine [SputnikVM](https://github.com/rust-ethereum/evm/) with additional data structures and transaction types specifically for privacy operations:
32+
- Merkle trees for deposits using Poseidon hash (SNARK-friendly)
33+
- Nullifier sets for withdrawals using a trie structure
34+
- New transaction types: "Shield" and "Unshield"
35+
36+
- **Zero-Knowledge Proof System**: Integration of ZK proof generation and verification:
37+
- Initially based on Zcash cryptographic primitives
38+
- Precompiles for verification functions
39+
- Possible transition to zkSTARKs (using Plonky3) if time permits
40+
41+
- **User Interface**: CLI tools in Rust for:
42+
- Key management (generation and storage)
43+
- Creating deposits (commitments) and withdrawals (nullifiers)
44+
- Automating proof generation
45+
- Transaction management
46+
- Viewing account balances (both shielded and public)
47+
48+
- **Token Support**:
49+
- Native support for the chain's currency
50+
- ERC-20 token integration with special account logic
51+
52+
- **Technology Stack**:
53+
- Rust for the node implementation and CLI tools
54+
- Modified EVM (SputnikVM) for smart contract execution
55+
- Zero-knowledge cryptography libraries
56+
57+
The system will automatically shield assets after interactions with smart contracts and unshield them before making transactions. This design abstracts away the complexity of privacy operations from both users and developers.
58+
59+
Our project will not:
60+
- Implement its own consensus mechanism (will use existing Substrate consensus)
61+
- Create a new programming language for privacy applications
62+
- Implement a separate private state within smart contracts
63+
- Compromise on EVM compatibility for existing applications
64+
65+
### Ecosystem Fit
66+
67+
Our project fits into the Polkadot/Substrate ecosystem as an enhanced privacy layer for EVM-compatible parachains and applications. It addresses the lack of privacy features in current implementations while maintaining full compatibility with existing EVM smart contracts, which is becoming a core part of the Polkadot ecosystem.
68+
69+
**Target Audience:**
70+
- Users seeking privacy for their blockchain interactions
71+
- Institutional players requiring compliant privacy solutions
72+
73+
**Needs Met:**
74+
- Enables programmable privacy without requiring developers to learn new languages or paradigms
75+
- Preserves the composability of DeFi applications while adding privacy
76+
- Offers customizable middleware solutions with different privacy-compliance trade-offs
77+
- Provides a pragmatic approach that covers most use cases with a simpler design
78+
79+
**Need Identification:**
80+
The limitations of current privacy solutions are well-documented in academic literature and industry research. Current "programmable privacy" chains like Aleo, Aztec, or Polygon Miden use a private-public state model with significant limitations:
81+
- Private state is owned by a single data owner, making composable apps with shared private state impossible
82+
- The paradigm is unnatural and error-prone even for cryptography engineers
83+
- Developers must navigate complex privacy vs. compliance trade-offs
84+
85+
**Similar Projects in Polkadot/Substrate:**
86+
There are currently no projects in the Polkadot ecosystem offering equivalent programmable privacy features with EVM compatibility.
87+
88+
**Similar Projects in Other Ecosystems:**
89+
- Aztec, Aleo, and Polygon Miden offer programmable privacy but use the private-public state model we aim to improve upon
90+
- Penumbra provides app-specific privacy features but with limited programmability
91+
- Tornado Cash and similar privacy pools offer some privacy features as smart contracts but lack the protocol-level integration we propose
92+
93+
Our solution differentiates itself by providing a more pragmatic approach with better developer and user experience, built directly into the protocol while maintaining full EVM compatibility.
94+
95+
## Team :busts_in_silhouette:
96+
97+
### Team members
98+
99+
- Marcin - CEO & Lead Engineer
100+
- Antonio - Senior Cryptography Engineer
101+
- César - Cryptography Engineer
102+
- Parsa - Cryptography Engineering intern
103+
104+
### Contact
105+
106+
- **Contact Name:** Marcin Górny
107+
- **Contact Email:** marcin@np.engineering
108+
- **Website:** np.engineering
109+
110+
### Legal Structure
111+
112+
- **Registered Address:** Zug, Switzerland
113+
- **Registered Legal Entity:** Hungry Cats Studio AG
114+
115+
### Team's experience
116+
117+
Our team brings extensive experience in cryptography engineering, zero-knowledge systems, and privacy-focused blockchain applications:
118+
119+
**Marcin** participated in the a16z Crypto Startup Accelerator (London '24) and is a core contributor & maintainer for [Arkworks](https://github.com/arkworks-rs/algebra/commits?author=mmagician). Previously worked on the Grants & Research Team at Polkadot, build a GKR-based zkML verifier in halo2, and received a zkGit grant from Ethereum Foundation for [zkGit](https://github.com/NP-Eng/zkGit/blob/main/zkGit.pdf). He has writted about [programmable privacy](https://open.substack.com/pub/nplabs/p/programmable-privacy).
120+
121+
**Antonio** is a Senior Cryptography Engineer with a PhD in Number Theory. He has made multiple arkworks contributions, including 3 Polynomial Commitment Schemes ([Ligero, Brakedown](https://github.com/arkworks-rs/poly-commit/tree/master/poly-commit/src/linear_codes), [Hyrax](https://github.com/arkworks-rs/poly-commit/tree/master/poly-commit/src/hyrax)). His work includes zkML, implementing [STIR in Plonky3](https://github.com/Plonky3/Plonky3/pull/674), Naysayer Proofs implementation, and designing [compliant privacy solutions](https://np.engineering/posts/tornado-anonymity-revoker-design/) like Tornado Cash.
122+
123+
**César** specializes in Cryptography & ML Engineering, with notable work on [zkML](https://np.engineering/posts/zkml-tradeoffs/) and [arithmetic circuits](https://np.engineering/posts/arithmetic-circuits/) and Naysayer Proofs. His recent work includes adding [STIR to Plonky3](https://github.com/Plonky3/Plonky3/pull/674), Naysayer Proofs, and a [compliant Tornado Cash implementation](https://np.engineering/posts/tornado-anonymity-revoker-implementation/).
124+
125+
**Parsa** is a Cryptography Engineering intern who has studied probabilistic proofs at EPFL.
126+
127+
### Team Code Repos
128+
129+
- https://github.com/mmagician
130+
- https://github.com/Antonio95
131+
- https://github.com/Cesar199999
132+
133+
## Development Roadmap :nut_and_bolt:
134+
135+
### Overview
136+
137+
- **Total Estimated Duration:** 5 months
138+
- **Full-Time Equivalent (FTE):** 2
139+
- **Total Costs:** 100,000 USD
140+
- **DOT %:** 50%
141+
142+
### Milestone 1 — EVM+ Chain with Native Data Structures
143+
144+
- **Estimated duration:** 2 months
145+
- **FTE:** 2
146+
- **Costs:** 40,000 USD
147+
148+
| Number | Deliverable | Specification |
149+
| -----: | ----------- | ------------- |
150+
| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
151+
| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial explaining how to set up and use the shielding features |
152+
| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests, including performance metrics for the new data structures |
153+
| **0d.** | Docker | We will provide a Dockerfile for testing the functionality delivered with this milestone |
154+
| 1. | Merkle tree implementation | We will implement Merkle trees for deposits using a Poseidon hash function (or similar SNARK-friendly hash function) with fixed size (e.g. depth 20) |
155+
| 2. | Shield transaction type | We will create a new transaction type "Shield" alongside existing EVM transaction types (Legacy, EIP-1559, etc.), containing a new field for commitments, and no destination address |
156+
| 3. | Block header modification | We will modify the block header to include the commitment root, and add validation logic for this header extension |
157+
| 4. | Modified EVM engine | We will deliver a fork of the EVM engine (SputnikVM) with the above-mentioned structures |
158+
| 5. | Benchmarks | We will provide performance metrics for modifying the new data structures and compare them to relevant existing EVM opcodes |
159+
| 6. | Node template | We will provide a node template that integrates the Frontier framework which calls into the underlying SputnikVM engine |
160+
| 7. | Tests | Add tests which check the functionality of the new transaction types and the Merkle tree implementation. Note, that full shield-unshield lifecycle cannot be tested yet |
161+
162+
### Milestone 2 — Unshield Transaction Type and ZKP Verification
163+
164+
- **Estimated duration:** 1.5 months
165+
- **FTE:** 2
166+
- **Costs:** 30,000 USD
167+
168+
| Number | Deliverable | Specification |
169+
| -----: | ----------- | ------------- |
170+
| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
171+
| **0b.** | Documentation | We will provide inline documentation and extend the tutorial to cover unshielding functionality |
172+
| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests with performance metrics for ZKP verification |
173+
| **0d.** | Docker | We will provide a Dockerfile for testing the functionality delivered with this milestone |
174+
| 1. | Unshield transaction type | We will implement a new transaction type "Unshield" that includes a destination (withdrawal) address and a field containing the ZK withdrawal proof |
175+
| 2. | Nullifier set implementation | We will implement a nullifier set for withdrawals using a trie data structure for efficient (non-)membership checks |
176+
| 3. | ZKP verification precompile | We will implement precompiles for ZKP verification based on Zcash (or similar) cryptographic primitives |
177+
| 4. | Integration with EVM | We will ensure backwards compatibility, i.e. CALLs to EVM smart contracts work as expected with the new transaction types |
178+
| 5. | ZKP performance metrics | We will provide detailed performance metrics for the nullifier set updates & ZKP verification algorithms |
179+
| 6. | Security analysis | We will document the information-theoretic guarantees of the zkSNARK system |
180+
181+
### Milestone 3 — Key Management and CLI Tools
182+
183+
- **Estimated duration:** 1.5 months
184+
- **FTE:** 2
185+
- **Costs:** 30,000 USD
186+
187+
| Number | Deliverable | Specification |
188+
| -----: | ----------- | ------------- |
189+
| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
190+
| **0b.** | Documentation | We will provide inline documentation and a comprehensive guide for using the CLI tools |
191+
| **0c.** | Testing and Testing Guide | Core functions will be fully covered by unit tests and we will provide end-to-end testing examples |
192+
| **0d.** | Docker | We will provide a Dockerfile for testing the functionality delivered with this milestone |
193+
| **0e.** | Article | We will publish an article explaining the key management system and how users can interact with the privacy features |
194+
| 1. | Key management | We will implement generation and storage of user keys/secrets based on Zcash (or similar) key derivation algorithms |
195+
| 2. | Shielding functions | We will create CLI commands to facilitate creating deposits (commitments) |
196+
| 3. | Unshielding functions | We will create CLI commands to facilitate withdrawals (nullifier management) and automating proof generation |
197+
| 4. | Account management | We will implement functionality to view account balances (both shielded and public)
198+
| 5. | Transaction management | We will implement functionality to interact with a node and send transactions for deposit/withdraw actions |
199+
| 6. | Performance metrics | We will provide metrics for proof generation time and resources used |
200+
201+
## Future Plans
202+
203+
**Short-term plans:**
204+
- Develop additional middleware solutions offering different privacy-compliance trade-offs. Specifically, our team has already written about a compliant privacy pool solution in [this article](https://np.engineering/posts/tornado-anonymity-revoker-design/). The work done as part of this grant will be a foundation for this solution. We want to allow multiple parallel pools to be deployed on the same chain.
205+
- Create developer documentation and tooling to facilitate adoption
206+
- Collaborate with existing DeFi projects to demonstrate the seamless integration of privacy features
207+
- Launch a testnet to allow developers to experiment with the technology
208+
209+
**Long-term plans:**
210+
- Implement dynamic Merkle structures to support an ever-growing state (e.g. [Merkle Mountain Ranges](https://docs.grin.mw/wiki/chain-state/merkle-mountain-range/) or [Merkle Mountain Belts](https://hackmd.io/@MerkleMountainBelts/MMB-Funding-Proposal-V2#MMB-overview))
211+
- Implement a zkSTARKs-based proof system based on [Plonky3](https://github.com/Plonky3/Plonky3)
212+
- Create an ecosystem of privacy-preserving applications
213+
- Work with regulatory bodies to ensure compliance while maintaining privacy guarantees
214+
215+
**Maintenance and development:**
216+
We plan to finance the project's long-term maintenance and development through:
217+
- This initial grant as a first step towards building a privacy solution for Kusama
218+
- The recently approved Kusama vision initiative ([Referendum #498](https://kusama.subsquare.io/referenda/498)) which aims to support advanced technologies like ZK innovation and position Kusama as an experiment-centric network, which will be our main focus for funding.
219+
220+
In the future, we aim to provide our work as a public good that can be deployed as a common good parachain in the Polkadot ecosystem, making privacy features accessible to the entire network without requiring a token-based economic model.
221+
222+
## Additional Information :heavy_plus_sign:
223+
224+
**How did you hear about the Grants Program?**
225+
Recommendation 😃

0 commit comments

Comments
 (0)