Noob question, whats different with Railgun?
Hi @zk-friendly
Railgun is a full, end-to-end product, while ERC-8086 and ERC-8085 are mainly about interface standards. They focus on what the primitives look like, not on prescribing a specific implementation.
If you’re asking how our reference implementation differs from Railgun, here’s where you can dig deeper:
-
This is an early foundational privacy layer we designed for Ethereum →
https://github.com/ZK-Protocol/Native-Privacy-Asset-Protocol-Whitepaper
ERC-8086 originated from this work. -
This is the reference implementation for ERC-8086 →
https://github.com/0xRowan/erc-8086-reference
If you’re not very code-oriented, the easiest way is to try what we’ve already deployed on testnet — anyone can experiment and verify things directly:
-
Anyone can create native privacy assets with a Zcash-style privacy model, as easily as creating an ERC-20 token:
https://testnative.zkprotocol.xyz/ -
Anyone can wrap ETH or any existing ERC-20 into a privacy asset and gain privacy features:
https://zerolayer.live/ -
Anyone can easily create dual-mode tokens (privacy + ERC-20 public mode), just like creating an ERC-20. Users can freely switch between private and public modes depending on their use case:
https://testdmt.zkprotocol.xyz/
ERC-8086, ERC-8085, and ERC-8091 are better understood as a modular privacy layer for Ethereum. They’re designed as building blocks — anyone can use them to build their own privacy products on top.
4 Likes
Your design is 100% same with railgun, shield and unshield, dual mode. but the utxo design is not good for UX
I intentionally tried out several different privacy solutions, and honestly the UX is way better than I expected.
The only downside right now is that you have to experience it on your own testnet. If wallets supported this protocol natively, it would be amazing to let users switch between privacy mode and public mode directly in the wallet with a simple toggle.
At that point, using privacy would feel just as easy as interacting with a regular ERC-20 token.
I’d strongly suggest providing an SDK so wallets can integrate this more seamlessly.
Thanks for the suggestion — we’ve been thinking along the same lines as well.
I’m about as much of an outsider to this topic as one can be, but after reading through your proposal, would it make sense to reserve+standardize an address that “owns” the private tokens? balanceOf(PRIVATE_ACCOUNT) would be equivalent to totalPrivacySupply().
I’d also recommend specifying whether a Transfer event is emitted for toPrivacy and toPublic.
Also also, toPrivacy is weird English, IMHO. toPrivate sounds more natural.