Create ZeroPool.md

[snjax]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants at the time of submission.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks for the applications. A few questions from my side (also based on some internal feedback):

• You still need to sign the Terms and conditions.
• Could you try to leverage the open grants template for the application. Specifically regarding the milestones.
• Has ZeroPool received any funding/further support from the Ethereum Foundation to develop their research?
• The application is pretty ethereum focused. "ZeroPool supports ERC20 and ERC721". Are there any adjustments planned for Polkadot?
• Has any of the ZeroPool (ethereum) code been audited so far?

[snjax]

@Noc2

You still need to sign the Terms and conditions.

Done

Could you try to leverage the open grants template for the application. Specifically regarding the milestones.

Done

Has ZeroPool received any funding/further support from the Ethereum Foundation to develop their research?

We have received a grant for improving Fawkes-Crypto (adding support of PLONK). But this is not grant for building ZeroPool protocol, dApp, etc.

The application is pretty ethereum focused. "ZeroPool supports ERC20 and ERC721". Are there any adjustments planned for Polkadot?

This application is related only to the PolkaDot blockchain. We are going to create a private pool for DOTs (and other assets later).

Has any of the ZeroPool (ethereum) code been audited so far?

Our Ethereum beta version is not audited. We are going to prepare for audit our next version, optimized for mobile apps.

[burdges]

What is the ZeroPool design? Zcash-like? Spends reference UTXOs via a Merkle tree. And nullifiers accumulate on-chain? That'd be fine.

Any cryptography could run in WASM on substrate of course, but..

We'll eventually provide native code support for BLS12-377, BW6, and their JubJubs via Arkworks. If you're interested in helping there then take a look at arkworks-rs/algebra#730 It's outside your current code base, but maybe fits your team well.

We'll probably never provide any native code support for any non-arkworks curves implementations besides our existing secp256k1 and ed25519/ristretto code.

[snjax]

@burdges,

What is the ZeroPool design? Zcash-like? Spends reference UTXOs via a Merkle tree. And nullifiers accumulate on-chain? That'd be fine.

It is like ZCash, but there are some differences for better support of account-based chains. For example, with such privacy as ZCash we publish only one nullifier per transaction. So, storage space is used more sparingly.

My talk on ZKSummit about account-based privacy
Account-based private transaction engine

Any cryptography could run in WASM on substrate of course, but.

Our current plans are building protocol at the most widespread curve and proving system (currently it is groth16 and bn256). With the current codebase, we can deploy the working solution faster and safer.

After that, we are going to switch our research to more novel protocols. 1-level recursion on BLS12-377 and BW6 is promising. But novel protocols could be better.

[burdges]

We've no timeframe for doing anything native, so yes if your code works well in WASM then that'll definitely be faster, and sure bn254 might run faster in WASM than BLS12-377 or whatever. I mentioned arkworks-rs/algebra#730 largely because it might fit your team's interest.

[burdges]

Apologies for the delay.. I'm probably okay to fund this project @Noc2 but..

@snjax I'm confused by a couple points:

• what do you mean by "optimistic rollup"?
• if I understand, users supply SNARKs for UTXOs but you'll support accounts too?

As you're doing zk, you could do you own off-chain storage likely just block contents aka UTXOs, but also you could use Poseidon integrated with substrate's storage in your own substrate fork, and then only provide SNARKs that get checked in the runtime (eventually on polkadot). I'd think either of the top contributors to https://github.com/paritytech/trie/graphs/contributors could give advise on this if you need anything like that. We're quite slow about upstreaming improvements to substrate's storage architecture, but we'd love to see exploration of such options.

[snjax]

@burdges,

what do you mean by "optimistic rollup"?

Our current beta implementation on Ethereum is working on L2 (custom optimistic rollup). In optimistic rollup, the relayer just publishes transactions and result of VM execution, but do not execute them. If the result is wrong, anybody can challenge the relayer by executing the transaction and stop the rollup. So, an expensive zkSNARK verifier is executed only if the relayer publishes damaged data.

if I understand, users supply SNARKs for UTXOs but you'll support accounts too?

Yes, the account is a special type of UTXO, containing spend interval (in the simplest case it is maximal UTXO index spendable by the user). So, when we perform the transfer, it is enough only to publish only one nullifier for an account and increase the spent interval for the updated (output) account.

you could use Poseidon integrated with substrate's storage in your own substrate fork, and then only provide SNARKs that get checked in the runtime (eventually on polkadot)

Sure, we are going to compute Poseidon only off-chain and verify Merkle root update with zkSNARKs. Poseidon is very expensive to compute it onchain.

[Noc2]

@snjax would it be possible to reduce the price. This way it will be easier to get the necessary approval.

[snjax]

@snjax would it be possible to reduce the price. This way it will be easier to get the necessary approval.

@Noc2, now we can reduce the total amount by removing the last milestone. Also, we start thinking about publishing our SDK, so other developers could implement their own dApps, based on our protocol.

[Noc2]

@snjax Thanks for updating the application. Removing the last milestone makes a lot of sense. Especially since we can always sign a follow-up grant for it, but I was more referring to the general costs of the proposal. For example Milestone 2 and 3 both currently have the same estimated duration and FTE and milestone 2 costs 40k instead of 30k. It would be appreciated if you could reduce the price of the deliveries a little bit more and would help to get the necessary approval from the rest of the committee.

[Noc2]

@snjax Any updates on this?

[snjax]

@Noc2
We very much appreciate the cooperation with you and the work we have done. I think we are able to consider 63k dai as a total grant amount for current milestones.

The costs are different because each step requires different people.

[Noc2]

@snjax Thanks for the quick response. Sounds good to me. Could you update the application?

[snjax]

@Noc2 done

[Noc2]

Thanks for the update. I’m happy to go ahead with it and I will share the application with the rest of the committee.

[mmagician]

The previous delivery was good, I'm also happy to proceed with a follow-up

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at [email protected] in case you're interested (at least two weeks notice is preferred).

[alxs]

Hey @snjax, care to share a quick status update on the project?

[snjax]

Hi, @alxs. Now we are focused on the core part of development (cryptography, zkSNARKs, and documentation). We decided to go step by step. Now we prepared zkSNARKs for the audit.
So, we could be sure, we reduce the security risks as more as we can before the release. And further development is going to be more smooth and more effective.

[alxs]

Thanks for the update. Sounds like a wise decision. If you expect M2 to still take a while, I recommend you submit an amendment and modify its duration accordingly.

[semuelle]

It sounds like it might still take some time before you can submit a milestone, @snjax. Could you submit a PR to your grant application with an updated timeline?

[alxs]

Please @snjax, submit an amendment. The duration should be updated to 5 months (which would be now) + however long you think you will still need.

[alxs]

@snjax this is a last request to please submit an amendment. Otherwise, we'll terminate the grant in the coming days.

[snjax]

@alxs, Hi. We have a lot of business trips. And due to the covid, we are not able to follow up all requests in time. We are very sorry.

Now the project is finishing the audit. We discuss details with auditors, improve our architecture, and have made all fixes.

So, milestone 2 is completely finalized (we have done more, including the work on the audit).

Now we are building milestone 3. We are planning to finalize it by the end of 2021.

What are the next steps to submit a completed milestone?

[alxs]

@snjax that's good to hear. You can submit milestone 2 the same way as previous ones. In case you need a refresher, the delivery process and instructions are outlined here.

[alxs]

@snjax a reminder to submit milestone 2 - please follow the process above.

[snjax]

@alxs Sorry for the late reply, it was LisCon and big backlog. I submitted the milestone 2 here w3f/Grant-Milestone-Delivery#316