Tux0 application

[muraca]

Project Abstract

Tux0 will be a Tuxedo piece that leverages zero-knowledge proofs to manage a private token.
To develop it, we will first conduct research to identify a zero-knowledge protocol that is suitable for use in Substrate runtimes.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel.

cc @Gorzorg @JoshOrndorff

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[muraca]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Thanks for the application @muraca just a couple of initial comments:

• You mentioned that you are confident that phase 1 will succeed. I take this to mean that you would want to go forward with M2 regardless of the results of the M1 research?
• Can you integrate more technical details into the application such as the tech stack? Especially the milestone deliverables themselves. For example what will you use to build the data visualization tool? What will the benchmarking program be written in?

[muraca]

• You mentioned that you are confident that phase 1 will succeed. I take this to mean that you would want to go forward with M2 regardless of the results of the M1 research?

From the proposal document:

We are aware that the results might not be as good as expected. If we fail to identify a protocol that can be used in a Substrate runtime, then we would still proceed with developing the final product, using custom host functions.
However, since some of these protocols are already used in other blockchains, we're confident this phase will be a success.

We think we must be conservative, but truth is we don't think this research will fail to identify a usable protocol.
However, to answer your question: yes, we would eventually determine what's the best protocol to use natively, integrate it in Substrate with host functions, and use that to develop Tux0, with the hope that in the future said host functions would be replaced by either the ones that the Polkadot Relay Chain will offer, or by another protocol that can work in the runtime.

---

• Can you integrate more technical details into the application such as the tech stack? Especially the milestone deliverables themselves. For example what will you use to build the data visualization tool? What will the benchmarking program be written in?

We've been deliberately vague with the first milestone, as we didn't want to set in stone things that are subject to change:

• For the data visualization tool, we want something web-ready, to easily embed the results in our article hosted on GitHub pages.
  We used ZingChart in previous works, but we don't want to use it in this project since it's not open source. We saw that C3.js might be a good fit, but we we postponed the research and decision.
• For the benchmarking tool, we're oriented towards Rust as it might be easier to integrate with the proving systems.

Regarding the second milestone, we have taken it for granted that the Tuxedo piece and the wallet extension will be written in Rust.

I agree that we might have been more clear on those things, but I was unsure on how to proceed. If you think we should clarify and write down these possibilities, I'll be happy to do so.

[JoshOrndorff]

Hey there 👋

I want to share a few things that may be relevant to the review of this grant.

First, @muraca has been contributing to Tuxedo as an open source volunteer pretty often the past several weeks. He started with small chores (Tuxedo#91), then moved on to overhauling ci (Tuxedo#93, Tuxedo#112, Tuxedo#113), and eventually started making significant design contributions (Tuxedo#127). He understands the design of Tuxedo and the UTXO system.

And second, I'm willing to mentor/advise a few hours a week on this grant. I could help with Rust, Tuxedo, and Substrate, but not with ZK aspects. I would not be an official part of the grant, as I'm currently busy working on another grant.

[Gorzorg]

Hi, I am the other guy who should be a developer in this project. I am by no means an expert in cryptography, but i could be the math guy of reference if you want to make quantitative questions.

[Gorzorg]

Also, @keeganquigley I saw your questions. While it is true that we were vague on most points, I think part of that is due to us being newbies in this grant application process.

* Can you integrate more technical details into the application such as the tech stack? Especially the milestone deliverables themselves. For example what will you use to build the data visualization tool? What will the benchmarking program be written in?

Even though @muraca integrated some changes in the application text to address the direct questions ("For example [...]"), I get the feeling that you probably have much more to ask. Since we are clueless about what constitutes a good application text, I would like if you made more such direct questions.

[keeganquigley]

Thanks @muraca @Gorzorg for your explanations, they are much appreciated. Thanks also @JoshOrndorff for the introduction, and nice to see you again. I apologize for the delay, we have a bit of a backlog atm with the recent changes.

• For the research phase, are you planning to research only the three zk protocols listed? I was just reading about Nova folding, which is a new high-speed recursive SNARK that also doesn't require a trusted setup.
• To make sure I understand correctly, will the research results be beneficial for using zk proofs in all substrate runtimes, and not just UTXO-based runtimes?

[muraca]

@keeganquigley no worries, thank you for your attention and take your time.

For the research phase, are you planning to research only the three zk protocols listed?

No, it's very likely that the list will be extended, but I think at one point we will have to choose which ones to compare and why. We can't test all the protocols we can find with a Google search.

I was just reading about Nova folding, which is a new high-speed recursive SNARK that also doesn't require a trusted setup.

Thanks for mentioning this, it might be very interesting for Tux0, we'll look into it.

To make sure I understand correctly, will the research results be beneficial for using zk proofs in all substrate runtimes, and not just UTXO-based runtimes?

The protocol we hope to identify is ideally good enough to be used in a Substrate Runtime in WASM without using host functions, so it must have small proofs and short execution time.
It doesn't have much to do with Tuxedo or UTXOs, and it will be usable on FRAME runtimes as well.

[keeganquigley]

Thanks for your answers @muraca it looks good to me and I'm happy to approve it. I will mark it as ready for review and ping the rest of the committee to take a look.

[takahser]

@muraca thanks, that sounds interesting. I have a few questions:

1. could you provide more details on the ZK protocols being considered in M1? In particular, which protocols are you going to compare and what will be the evaluation criteria? Please integrate this directly into the deliverables, as they act as a contraction that the evaluator will review your future delivery against.
2. do you have any code samples that you can provide? Or could you direct us to the nft chain materials that were presented at sub0 2022 that you mentioned in the proposal?
3. could you clarify the limitations of the prototype implementation in terms of production-readiness? What will be required to make it production-ready after this grant and what are the long-term plans for the project (if any)?

Edit:

• regarding the code samples, I just saw @JoshOrndorff's comment that provide some PRs. Although most are more CI and deps-related, Genesis Transactions Off-Narrative-Labs/Tuxedo#127 is a more complex one, that helps already. I'd still be interested in the nft chain materials though.

[muraca]

@keeganquigley we appreciate your support and thank you for your approval.

@takahser nice to talk again.

About NFT Chain

2. could you direct us to the nft chain materials that were presented at sub0 2022 that you mentioned in the proposal?

Grants-Program/applications/tux0.md

Line 99 in 0512ee1

Unfortunately, all the work done at NFT Chain is private, in the hands of the company owner, and cannot be shared.

We are legally obliged to not share anything.

Grants-Program/applications/tux0.md

Line 100 in 0512ee1

However, we presented some working prototypes at Sub0 2022, and the project has been accepted as part of the Substrate Builders Program.

In that regard, the most I can do is reminding you that you were one of the approvers of NFT Chain's application to Substrate Builder Program. In that occasion, I personally had a call with you and another developer of the company.

The Tux0 questions

We think some of the answers are already extensively answered in the document, I'll embed the content in this comment.
Your questions were all helpful nonetheless, because they made us reason on some things we overlooked, and we think we should clarify or extend.
Nonetheless, if among the things we don't explicitly state we will write more about there's anything you think should be written more extensively in the application doc, please point it out, as some things might be obvious for us and not for you, or vice versa.

1. could you provide more details on the ZK protocols being considered in M1? In particular, which protocols are you going to compare

Grants-Program/applications/tux0.md

Lines 30 to 33 in 0512ee1

	Some potential candidates are:
	- [Halo2](https://github.com/zcash/halo2/), used by Zcash in its orchard protocol;
	- [Plonky2](https://github.com/0xPolygonZero/plonky2), developed by Polygon Zero;
	- [Kimchi](https://github.com/o1-labs/proof-systems), by O(1) Labs, used by the Mina Protocol.

We didn't want to set in stone the protocols, as we could find other more suitable ones during the research phase, or even drop some for valid reasons. We'll try to do as much as we can.

We want to write the program in a way that it can be extended in the future with other protocols. We will write a few words on how we plan to do this, integrating some Rust code sketches.

what will be the evaluation criteria?

They are defined in the Project Details section:

Grants-Program/applications/tux0.md

Lines 35 to 39 in 0512ee1

	The zero knowledge protocol used in the second phase will be chosen based on this research's results. The factors that will be considered are, by importance:
	- verification performance and proof size;
	- proof construction performance;
	- security, if the library is production-ready;
	- ease of use, for example high level languages to write circuits.

I think we should specify that we intend to compare those results with execution time and size of extrinsics in Substrate runtimes as well.

3. could you clarify the limitations of the prototype implementation in terms of production-readiness? What will be required to make it production-ready after this grant

1. Tuxedo should be considered production-ready; this is in Joshy's hands.
2. The zero knowledge protocol we use and its library should be subject to security audits. This is part of the evaluation criteria:

   Grants-Program/applications/tux0.md

   Line 38 in 0512ee1

   - security, if the library is production-ready;

3. The Tux0 protocol should be reviewed by experts, I think cryptographers, and the Tux0 code should be subject to security audits. This can be done in the future by any entity who's interested in using Tux0 for their blockchain.

   Grants-Program/applications/tux0.md

   Line 60 in 0512ee1

   We can't guarantee for the project's security, since its purpose is to demonstrate the use of the chosen zero knowledge protocol, not to write a production-ready module. For that, the protocol should be thoroughly reviewed by experts, and the libraries and piece should be subject to security audits.

what are the long-term plans for the project (if any)?

Grants-Program/applications/tux0.md

Lines 169 to 170 in 0512ee1

	We intend to continue to maintain Tux0 at least until a proper release of Tuxedo's parachain support - which might even come before the delivery of this grant.
	We are interested in testing the zero-knowledge protocol we chose for Tux0 in a parachain environment.

@CrackTheCode016 recently suggested a Tux0 parathread on Rococo, which would be a huge step forward for Tuxedo as well.

[takahser]

@muraca thanks for the detailed replies and thanks for refreshing my memory :)

We didn't want to set in stone the protocols, as we could find other more suitable ones during the research phase, or even drop some for valid reasons. We'll try to do as much as we can.

I understand that you want to have some flexibility, but I'd still prefer to have them in the deliverables. If you want to drop or change one (or more) of the protocols, an amendment would be possible and in this case I wouldn't expect any problems with approving it, as long as you can justify the change. Another option would be to commit to a number of protocols in the deliverables without explicitly setting for the candidates yet, something along the line of "we're going to evaluate 3 or more protocols, such as x, y and z, but the choice of protocols will be made at a later stage".

Regarding the other 2 points, thanks for clarifying, sounds good to me.

[takahser]

@muraca thanks for the adjustments, happy to approve as well.

[muraca]

@takahser thank you again for your time and for supporting the project.
We look forward to receiving other reviews from the committee.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[muraca]

Thanks for giving us the opportunity to work on this project.
We are kickstarting the development of the first milestone, and we hope to be able to deliver it before Christmas.

[muraca]

Dear committee, I'm writing this comment to update you on the current situation of the project.

We started going through OpenZL, which could have been a great candidate to write circuits using a high-level language. However, looks like Manta Network got 400k USD from the Polkadot Treasury to build a tool that was left unfinished.

We spent some time on Nova, a SNARK library developed by Microsoft, failing to find any tutorials or appropriate documentation. Because of that, we tried building some understanding of how it works by code digging. We have some trouble understanding the implications of how many of the objects used or defined in that library, which in turn makes it difficult for us to form opinions on its usability.

We also tried contacting the developers by opening a discussion that didn't receive any answers. We don't exclude coming back to Nova later on.

We have currently spent 2 weeks on Halo2. Even if we didn't consider the first week we basically wasted, it's clear to us that 6 weeks are not enough to produce what we intended to do in the first milestone. 3 weeks per protocol are the bare minimum, but I'm afraid it could take longer.

We'd like to know if you would be willing to consider an amendment, with a more proper time and cost estimation. We are also thinking of splitting the first milestone in two parts, as receiving some funding earlier would be beneficial for us.
In the meantime, we're still working hard on Halo2, and we hope to be able to finish a few working test circuits by the end of this week.

Thanks for your attention.

cc @keeganquigley @Noc2 @takahser @semuelle

[keeganquigley]

Thanks for the update @muraca yes feel free to amend the original application to update the changes and submit an amendment PR. If the updated costs aren't significantly higher, it should get approved and merged fairly quickly.

On the other hand if the cost changes would be significant, I would recommend reducing the scope in this grant (such as removing the last milestone) rather than increasing the price, and then you can always apply for a follow-up grant if it still makes sense to fund the remaining work.

I hope this helps!

[muraca]

@keeganquigley thanks for the info.
I opened an Amendment PR #2137

[keeganquigley]

Hi @muraca just checking in on progress for milestone 1. Can you provide an update?

[muraca]

Hey @keeganquigley sorry for the late response.
I started a new job a couple of months ago that made it impossible for me to work on Tux0.
Alberto has taken over the full ownership of the project, please refer to him for future updates.
cc @Gorzorg

[keeganquigley]

Sounds good @muraca thanks for the update and congrats on the new job. @Gorzorg can you confirm this and also provide a quick update? Thanks!

[Gorzorg]

So, I needed to do some soul searching. I could expand on the causes, but i feel i could only continue working on the grant slowly, without being able to fix deadlines. The short version is, i had a minor burnout, and i am also starting a new job soon.

Realistically i could close milestone 1, but i would not be able to guarantee a timeline for the subsequent ones.

[semuelle]

Hi @muraca & @Gorzorg, thanks for the insights. There is currently no urgency with delivering this grant, so we have no desire to force the matter. However, at times grants become obsolete, which is why we keep tabs on all of them. My suggestion would be to set a target date of the first milestone for six months from now. We can still decide to cancel the grant then. What do you think?

[Gorzorg]

I will try putting effort into it

[keeganquigley]

thanks @Gorzorg does that mean your answer to @semuelle question about the timeline is yes?

[Gorzorg]

After assessing my new work situation, i have to abandon the project. I apologize.

[keeganquigley]

Thanks @Gorzorg we appreciate the update. Understood, we will go ahead and close it for now.