Ruby Protocol Application

[rubyprotocol]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum (DAI) 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.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we've successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[alxs]

Excellent application and exciting project, I'm 100% willing to support this. I just have a few minor comments:

• http://rubyprotocol.com/ is currently empty. I suppose it's still under construction, but just checking that it wasn't a misspelling.
• I suppose you switched from smart contracts to a pallet at some point while you were writing your application, which is indeed much better suited to your requirements. However smart contracts are still mentioned several times in the text and listed as an objective under Open API and SDK. This section and the delivery items under Project Architecture are also almost identical and the UI is not listed in the latter.
• Deliverables 0a-d in the application template need to be included in each milestone.

[rubyprotocol]

Excellent application and exciting project, I'm 100% willing to support this.

Thanks for your support.

I just have a few minor comments:

• http://rubyprotocol.com/ is currently empty. I suppose it's still under construction, but just checking that it wasn't a misspelling.

Yes, it is still under construction.

• I suppose you switched from smart contracts to a pallet at some point while you were writing your application, which is indeed much better suited to your requirements. However smart contracts are still mentioned several times in the text and listed as an objective under Open API and SDK. This section and the delivery items under Project Architecture are also almost identical and the UI is not listed in the latter.

We have already replaced "smart contract" with "substrate module" in the proposal. UI has been included in both the Open API and SDK section and the deliverables section of Project Architecture.

• Deliverables 0a-d in the application template need to be included in each milestone.

We have already included the deliverables 0a-d in the updated proposal.

[alxs]

Thank you for the changes. I have a few follow-up questions:

• Do you have any candidates for the untrusted cloud, and who will carry the hosting expenses? Would this be something like AWS and would you consider using a decentralised solution like IPFS? This is currently partially implemented in Rust.
• Can data owners withdraw their consent to their data being processed? If they lost their private keys, not only would they not be able to do so but they would be locked out of any future returns.
• Whose is the certified signature Sig_D(FE.Enc(x))? If this is not the owner's, owner and provider will need to coordinate in order to upload the encrypted data, and if it is the owner it is superfluous. What would the provider's incentive be to play their part?
• In the current design, data owners could cheat purchasers by (passively) accepting payment for some computation but then immediately removing their data from the cloud. This could be prevented by requiring the data purchaser to retrieve the data beforehand.
• How will you ensure that data owners/providers have legal rights to monetise this data?
• What approach will you take to guarantee that the data is well-formed and real?

[rubyprotocol]

Thank you for the changes. I have a few follow-up questions:

• Do you have any candidates for the untrusted cloud, and who will carry the hosting expenses? Would this be something like AWS and would you consider using a decentralised solution like IPFS? This is currently partially implemented in Rust.

The decentralized cloud such IPFS is definitely on our radar. As for the hosting expenses, the project might pay for it initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business.

• Can data owners withdraw their consent to their data being processed? If they lost their private keys, not only would they not be able to do so but they would be locked out of any future returns.

The only FE algorithm the data owner needs to run is the encryption algorithm. There exist many revocable FE schemes in the literature to ensure the data owner can withdraw their consent without involving any of their private information, such as the revocable FE scheme proposed in this work: https://link.springer.com/chapter/10.1007/978-3-319-49890-4_14. The data owner might have a secret key for their own wallet to collect their monetization return, but this key is entirely independent of the FE scheme.

• Whose is the certified signature Sig_D(FE.Enc(x))? If this is not the owner's, owner and provider will need to coordinate in order to upload the encrypted data, and if it is the owner it is superfluous. What would the provider's incentive be to play their part?

In our current proposal, D is the data source, which the entity that generates the data for the data owner. For instance, in the genomic case, D could be the genomic testing company generating the DNA data for the data owner. It would be pretty easy for the data owner, as a client of the company, to obtain a signature on the encryption of the DNA data.

• In the current design, data owners could cheat purchasers by (passively) accepting payment for some computation but then immediately removing their data from the cloud. This could be prevented by requiring the data purchaser to retrieve the data beforehand.

Thanks for pointing that out. Will add this to the updated version.

• How will you ensure that data owners/providers have legal rights to monetise this data?

The whole monetization process will be compatible with the relevant law such as GDPR. We will consult with our legal team before we officially launch our product.

• What approach will you take to guarantee that the data is well-formed and real?

The well-formedness of the data owner's data is guaranteed in two ways in our proposal: 1. as mentioned above, a signature from the data source will guarantee it's obtained from the right source. 2. when the data purchaser receives the functional key from the key distributor, it will be attached with a zero-knowledge proof demonstrating that it corresponds to the function the data purchaser is interested in.

[alxs]

Thank you for your answers. Could you keep integrating these into the application?

I think the distinction between data owner and data source is currently not very clear in your proposal and I'm still confused as to their roles. E.g. in the application, for the genomic data example you state that

The secret key might be generated by the hospital that collects the users' genomic data or the data owner themselves.

If the data source is the one that generates the secret key, don't they effectively become the data owner?

As I see it in most cases the data sources will be the only ones with large enough and hopefully monetisable datasets anyway, but you expect each individual owner of a piece of that data to submit it individually, correct? Why not leave owner compensation in the hands of the data source and just interact with the latter? Otherwise, apart from the fact that it would be much harder to achieve critical mass, I still think data sources are not guaranteed to cooperate and even if they do, they would probably demand compensation for their curation and verification efforts. I understand that removing data owners from the process may go against the philosophy of the project if what you intend is to put control of one's data back in the hands of the owner, but if this is indeed your intention, this distinction and the mentioned incentivisation challenge need to be addressed.

Otherwise, feel free to pivot to only deal with data sources (though I think data providers would be a more appropriate term) instead. My impression is that you've correctly identified it's not possible to do without a data provider in order to guarantee the correctness of the data, but also that said provider has a more important role than what may seem from your application and hence needs to either be further involved in the process or alternatively just take on the role of data owner.

In case I've misunderstood anything, just let me know. Otherwise I'd be happy to see significant changes to the proposal regardless of which one of the two approaches you choose to follow, but let me reiterate that I think this is a strong application and I'll be happy to share it with the rest of the team as soon as it's ready.

Lastly, please double check that ZeroPool is the appropriate tool for your project. Manta Network have implemented private payments with zkSNARKs using ArkWorks, which has seen significantly more development, and it seems to work well for them. Otherwise, could you just expand on why you prefer ZeroPool and what it provides that makes you consider it in the first place?

[rubyprotocol]

Thank you for your answers. Could you keep integrating these into the application?

Sure, already integrate the update to the proposal.

I think the distinction between data owner and data source is currently not very clear in your proposal and I'm still confused as to their roles. E.g. in the application, for the genomic data example you state that

The secret key might be generated by the hospital that collects the users' genomic data or the data owner themselves.

If the data source is the one that generates the secret key, don't they effectively become the data owner?

Even though the data source (the hospital) is the one that produces the data, it doesn't mean it owns the patients' data. For instance, according to this report (https://www.forbes.com/sites/forbestechcouncil/2018/04/23/who-really-owns-your-health-data/?sh=1499f91d6d62), some states explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized.

As I see it in most cases the data sources will be the only ones with large enough and hopefully monetisable datasets anyway, but you expect each individual owner of a piece of that data to submit it individually, correct? Why not leave owner compensation in the hands of the data source and just interact with the latter? Otherwise, apart from the fact that it would be much harder to achieve critical mass, I still think data sources are not guaranteed to cooperate and even if they do, they would probably demand compensation for their curation and verification efforts. I understand that removing data owners from the process may go against the philosophy of the project if what you intend is to put control of one's data back in the hands of the owner, but if this is indeed your intention, this distinction and the mentioned incentivisation challenge need to be addressed.

The whole point of this project is to let the real data owner take back control of their own data, and you are right that it would go against the ethos of this project if there is a third party (i.e., the data source) to represent the data owner to collect the monetization gain of their private data. Since the law dictates only the patients can decide how to monetize their private data, it would also be illegal to let the data source be their representatives and decide how to monetize the data. We envision the data source could charge a certain extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test) and decides to join the monetization program.

Otherwise, feel free to pivot to only deal with data sources (though I think data providers would be a more appropriate term) instead. My impression is that you've correctly identified it's not possible to do without a data provider in order to guarantee the correctness of the data, but also that said provider has a more important role than what may seem from your application and hence needs to either be further involved in the process or alternatively just take on the role of data owner.

In case I've misunderstood anything, just let me know. Otherwise I'd be happy to see significant changes to the proposal regardless of which one of the two approaches you choose to follow, but let me reiterate that I think this is a strong application and I'll be happy to share it with the rest of the team as soon as it's ready.

Already add " The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test) and decides to join the monetization program. " to the proposal.

Lastly, please double check that ZeroPool is the appropriate tool for your project. Manta Network have implemented private payments with zkSNARKs using ArkWorks, which has seen significantly more development, and it seems to work well for them. Otherwise, could you just expand on why you prefer ZeroPool and what it provides that makes you consider it in the first place?

What we need is an implementation of groth16 scheme. As specified in the readme of groth16 of ArkWorks, it is still a poc prototype, this is why we choose Zeropool.

[alxs]

Thanks. Can I ask you to please add the answers in your last two comments to the application where appropriate?

I fully agree that it would be patently ill-advised to try to monetise health data derived from medical records, as well as illegal as pointed out in the report you link to. However, the rights to such data could have been waived or sold if they were collected in any other context, and this exemption only applies to the specific case of medical data.

But thanks for the clarification, knowing that you intend owners to always represent individuals does make the distinction clear between these and data sources. However could you in that case add the required interaction between owner and source to the UI deliverables of milestone 2? I.e. sources need to be able to register as such and to provide a signature, and owners need to be able to request a signature from a registered source which must then be verified on-chain.

I will share your application to the rest of the team for review pending the addition of your clarifications to the application.

[rubyprotocol]

Thanks. Can I ask you to please add the answers in your last two comments to the application where appropriate?

Sure, since I have already made the necessary change regarding my comments to your question posted 8 days ago, I mostly make the change regarding my comments to your question posted 4 days ago this time. Please let me know if I have missed anything in my latest change.

I fully agree that it would be patently ill-advised to try to monetise health data derived from medical records, as well as illegal as pointed out in the report you link to. However, the rights to such data could have been waived or sold if they were collected in any other context, and this exemption only applies to the specific case of medical data.

But thanks for the clarification, knowing that you intend owners to always represent individuals does make the distinction clear between these and data sources. However could you in that case add the required interaction between owner and source to the UI deliverables of milestone 2? I.e. sources need to be able to register as such and to provide a signature, and owners need to be able to request a signature from a registered source which must then be verified on-chain.

Thanks for pointing this out, and I have already made the change to the specification of milestone 2 regarding the UI for the interaction between the data owner and source.

I will share your application to the rest of the team for review pending the addition of your clarifications to the application.

Thanks a lot.

[alxs]

Thanks. I'll forward the application to the others.

One last thing I forgot to mention was that, regardless of what both ZeroPool's and ArkWorks' READMEs say, I'm not sure ZeroPool can be considered much more than a PoC either. Perhaps it'd be a good idea to check the code before choosing either of them.

[mmagician]

Top proposal. So I imagine your first step of your M1.1 is to devise a Rust library for performing functional encryption like GoFE right? Are you going to base your work off an existing Rust project that does something similar? Also, do you plan to support all of modular arithmetic, pairings and lattices primitives or just focus on one of them?

[Noc2]

Thanks for your application. Looks interesting. What’s your relationship with the Kylin network? Do you have any previous code/experience which you could share? Could you specify the programming language as part of the deliverables? Regarding the cryptographic libraries, are you aware of similar existing libraries that you might be able to reuse?

[rubyprotocol]

Top proposal. So I imagine your first step of your M1.1 is to devise a Rust library for performing functional encryption like GoFE right?

Yes.

Are you going to base your work off an existing Rust project that does something similar? Also, do you plan to support all of modular arithmetic, pairings and lattices primitives or just focus on one of them?

We plan to base our work on the CiFEr library (https://github.com/fentec-project/CiFEr) and its rust version (https://github.com/dev0x1/functional-encryption-schemes). We will mainly focus on supporting modular arithmetic and bilinear pairings.

[rubyprotocol]

Thanks for your application. Looks interesting. What’s your relationship with the Kylin network?

Thanks. Dylan Dewdney is the CEO of Kylin network and will be our marketing advisor and our two projects will collaborate on data sharing. Beni Issembert was previously the CMO of Beam and the advisor of the Kylin network.

Do you have any previous code/experience which you could share?

I am a cryptographer by training and functional encryption was the topic of my Ph.D. thesis. Here are some of my previous works: https://github.com/lornacrevelingwgo23/range_proof, https://github.com/lornacrevelingwgo23/Threshold_homomorphic_encryption_Garbled_circuit.

Could you specify the programming language as part of the deliverables?

Already add the Rust language in Milestone 1.

Regarding the cryptographic libraries, are you aware of similar existing libraries that you might be able to reuse?

Yes, we plan to base our work on the CiFEr library (https://github.com/fentec-project/CiFEr) and its rust version (https://github.com/dev0x1/functional-encryption-schemes).

[mmagician]

We plan to base our work on the CiFEr library (https://github.com/fentec-project/CiFEr) and its rust version (https://github.com/dev0x1/functional-encryption-schemes). We will mainly focus on supporting modular arithmetic and bilinear pairings.

So you're going to fork the rust version (and ideally contribute to it?). Would you mind outlining exactly the scope of changes needed to that rust library? As far as I can see, in its current form the lib supports only inner product (for pairings), so first you'd need to add quadratic polynomial FE, and then presumably do it for the two primitives you mentioned. Please correct me if I'm wrong - and otherwise, I'd appreciate if you could update the application document itself with this info. I would then be happy to support the project.

Regarding your previous work: it is not linked to your current profile in any way, and both @lornacrevelingwgo23 and @rubyprotocol profiles are quite empty. The repo you provided has been created just today. Is there any way you could perhaps provide better proof of previous experience?

[rubyprotocol]

We plan to base our work on the CiFEr library (https://github.com/fentec-project/CiFEr) and its rust version (https://github.com/dev0x1/functional-encryption-schemes). We will mainly focus on supporting modular arithmetic and bilinear pairings.

So you're going to fork the rust version (and ideally contribute to it?). Would you mind outlining exactly the scope of changes needed to that rust library? As far as I can see, in its current form the lib supports only inner product (for pairings), so first you'd need to add quadratic polynomial FE, and then presumably do it for the two primitives you mentioned. Please correct me if I'm wrong - and otherwise, I'd appreciate if you could update the application document itself with this info.

Yes, you are totally right about the scope of changes that need to be done, and I have already updated the proposal accordingly. Thanks for pointing that out.

I would then be happy to support the project.

Great to know. Really appreciate your support.

Regarding your previous work: it is not linked to your current profile in any way, and both @lornacrevelingwgo23 and @rubyprotocol profiles are quite empty. The repo you provided has been created just today. Is there any way you could perhaps provide better proof of previous experience?

The repo I updated is actually some of my recent work. I am trying to keep my identity confidential. I really hope it would be sufficient to prove my capacity. Thanks.

[mmagician]

Fair, thanks for confirming and good luck with the project!

[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 grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[rubyprotocol]

Fair, thanks for confirming and good luck with the project!

Thanks a lot for the support. You guys won't be disappointed.

[alxs]

@rubyprotocol care to share a quick status update, along with an ETA if possible? We were hoping to receive your first delivery about 2 months ago now. As long as you're still working on the project, delays aren't a big problem, but if you're no longer interested we would terminate the grant. Besides, the usage of the grants badge on your website goes against its guidelines (referred to by the bot two comments above mine) on two separate counts: it shouldn't be used on a team's landing page, and more importantly the grant shouldn't be announced publicly before your first milestone has been accepted, as clearly stated in the same comment.

I'd like to ask you to please remove the badge from your website and share some of your work with us or we'll be forced to terminate the grant due to breaching the terms and conditions.

[rubyprotocol]

@rubyprotocol care to share a quick status update, along with an ETA if possible? We were hoping to receive your first delivery about 2 months ago now. As long as you're still working on the project, delays aren't a big problem, but if you're no longer interested we would terminate the grant. Besides, the usage of the grants badge on your website goes against its guidelines (referred to by the bot two comments above mine) on two separate counts: it shouldn't be used on a team's landing page, and more importantly the grant shouldn't be announced publicly before your first milestone has been accepted, as clearly stated in the same comment.

I'd like to ask you to please remove the badge from your website and share some of your work with us or we'll be forced to terminate the grant due to breaching the terms and conditions.

We will update our progress with an ETA soon.

Really sorry about the mistake of our web designer. We forgot to send the guidelines to him. We did not or intended to announced it publicly. I have asked our website designer to remove the grants badge from all the relevant materials and this remove is completed. Apologize again for the mistake.

[lornacrevelingwgo23]

@rubyprotocol care to share a quick status update, along with an ETA if possible? We were hoping to receive your first delivery about 2 months ago now. As long as you're still working on the project, delays aren't a big problem, but if you're no longer interested we would terminate the grant. Besides, the usage of the grants badge on your website goes against its guidelines (referred to by the bot two comments above mine) on two separate counts: it shouldn't be used on a team's landing page, and more importantly the grant shouldn't be announced publicly before your first milestone has been accepted, as clearly stated in the same comment.

I'd like to ask you to please remove the badge from your website and share some of your work with us or we'll be forced to terminate the grant due to breaching the terms and conditions.

Hey Alex, sorry for the late response. We have been working on the code privately and did not update our repo in the Ruby project though. I guess we should have contact you more often. Here is our update: we have finished the coding of basic algorithms and their application on private machine learning. You can find the repo for the functional encryption in this repo: https://github.com/rubyprotocol/Functional_encryption_rust, and private machine learning in this repo: https://github.com/rubyprotocol/private_ml. We are working on the ZKP part and its integration with the Substrate pallet and expect Milestone 1 to be delivered soon. Meanwhile, we are also working on the design and development of UI in Milestone 2. 

[alxs]

@lornacrevelingwgo23 thanks for the update. It looks like your code is mostly adapted from https://github.com/dev0x1/functional-encryption-schemes. Please make sure to attribute properly at the time of delivery. Could you please amend your application with a concrete estimate as for the delivery date?

[lornacrevelingwgo23]

@lornacrevelingwgo23 thanks for the update. It looks like your code is mostly adapted from https://github.com/dev0x1/functional-encryption-schemes. Please make sure to attribute properly at the time of delivery.

Thanks for your reminder. We will certainly attribute properly at the time of the official delivery.

Could you please amend your application with a concrete estimate as for the delivery date?

It will take us some time to figure out how to import the ZKP library to the substrate module and we estimate it will probably take another two weeks to deliver milestone 1, and then another 1 month (as estimated in the original proposal) to deliver the milestone 2.

[alxs]

In that case, could you please submit an amendment to increase M1's duration by 3 months (which would be the delay if you submitted in two weeks, feel free to make it 4 if you feel you may need more time)?

[lornacrevelingwgo23]

In that case, could you please submit an amendment to increase M1's duration by 3 months (which would be the delay if you submitted in two weeks, feel free to make it 4 if you feel you may need more time)?

Hey, already change the estimated duration of M1 from 1 month to 5 months. But we'll try to deliver before that.

[alxs]

@lornacrevelingwgo23 not sure what you mean. You need to create a PR to modify your application.

[rubyprotocol]

@lornacrevelingwgo23 not sure what you mean. You need to create a PR to modify your application.

Thanks for your reminder. Already create a PR in this issue: #555.

[rubyprotocol]

@alxs Hey I have created a pr for milestone 1. Look forward to your comments on this.

[mmagician]

@rubyprotocol Do you have any updates regarding your second milestone? Are you still working on the project? Your delivery is overdue now, so if you could share your status that would be great. Otherwise, we would terminate your grant after 2 weeks unless we hear some news from you.

[lornacrevelingwgo23]

@rubyprotocol Do you have any updates regarding your second milestone? Are you still working on the project? Your delivery is overdue now, so if you could share your status that would be great. Otherwise, we would terminate your grant after 2 weeks unless we hear some news from you.

Hey @mmagician , sorry for the late response. I haven't checked this repo for a while. We are still working on the project and will update our repo in a few days. We expect to deliver milestone 2 by the end of December.

[rubyprotocol]

@rubyprotocol Do you have any updates regarding your second milestone? Are you still working on the project? Your delivery is overdue now, so if you could share your status that would be great. Otherwise, we would terminate your grant after 2 weeks unless we hear some news from you.

Hey @mmagician , I have just created a pr for milestone 2 delivery: w3f/Grant-Milestone-Delivery#332. Look forward to your comments.