Iris followup milestone 2 submission

[driemworks]

Milestone Delivery Checklist

• The milestone-delivery-template.md has been copied and updated.
• The invoice form 📝 has been filled out for this milestone.
• This pull request is being made by the same account as the accepted application.
• In case of acceptance, the payment will be transferred to the BTC/ETH payment address provided in the application.
• The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application pull request: w3f/Grants-Program#1365

The delivery file has been fixed.

[dsm-w3f]

@driemworks thank you for the milestone submission. Please see the evaluation documents and provide proper answers and fixes. After that, let me know to continue with the evaluation. The main problem that I'm having is to spin up all parts of the system to test it. See details in the evaluation document.

[driemworks]

Thanks for the feedback. I'll address your comments as soon as I can. As for the EC2 access, please let me know the best way to provide you the .pem so you can ssh into those instances. I'll also look into spinning up the network (3+ validators) locally using docker-compose if you'd prefer that route.

[dsm-w3f]

@driemworks if I would spin up everything locally I'll probably test this way. If you want to send the .pem to access the servers It would be possible to send using Iris (if it is ready for production) or using matrix/element. I'll send you my contact in private by e-mail.

[driemworks]

@dsm-w3f I've resolved the test issues and the majority of the clippy issues. The only ones remaining are those that refer to types being to complex or number of parameters passed to a function are exceeded. Several of these are in our assets pallet, which is a copy of the one included in substrate with minor modifications to make it easier to use in other pallets, so we opted to leave as is for now. I've also resolved all lint issues in the ui portion of the project. The latest code has been pushed to the master branches of both repositories and docker images have been updated. I really like the idea of transferring the .pem using Iris itself. If you could potentially give me a window when you might be testing, then I can ensure that the network is running and the file is available.

In regards to running the testnet locally, the only difficulty is the need for each validator to communicate with a unique IPFS instance. Since the OCW of the node is making the call to IPFS, it seems that we would need to configure a new CLI argument to specify the IPFS port. I'm investigating this currently and will get back to you as soon as I can (If you have any documentation on that, it would be much appreciated). I think if we used kubernetes to launch the network then we might be able to avoid requiring a new argument, but I'm not sure if that would be a route we should explore.

To address the other comments in the evaluation:

front end - No automated unit tests.

That is accurate. As milestone 4 is centered entirely around building a robust and modular SDK, we opted to forgo formal automated tests for now (and intentionally didn't mention UI testing in our deliverables). The UI delivered in this iteration serves more as a testbed for interactions with our node and to make manual verification/usage easier. As the deliverables state that core functionality must be tested, we assumed that this would be fine for now, but if it would make you more comfortable we can

Just one doubt, what is currently preventing a peer collect all parts of the threshold cryptography and reconstructing the key? Is that a problem for your cryptographic scheme?

That's a valid concern. It's technically possible for a secret to be recovered if the validator nodes collude and fraudulently create capsule fragments for an unauthorized node. In the case of our small testnet, this only requires two validators to collude. The simplest way to reduce the risk of collusion is to start as a PoA network (which we have currently), though that isn't truly decentralized. Our long-term goal to offset the risk is to allow the caller to specify their desired threshold and shares value for the TPRE system. The higher these values, the lower the risk of collusion, however, the cost to get a reencryption key (for consumers) would be higher as well. We're researching potential ways to ensure that data security doesn't rely on a financial standing, but we have more to analyze before making any definitive statement on that.

You can reach me on element at @driemworks:matrix.org as well as driemworks@idealabs.network

[dsm-w3f]

@driemworks thank you for the improvements. I reevaluated the artifacts and updated the evaluation document.

Regarding spinning up the system, if it is complicated to spin up all services using docker-compose we can try to test using EC2 AWS nodes that you probably already configured. I'm available today and tomorrow for doing this evaluation. Then I'll be back on January 3rd. I'll send you a msg in the matrix then we can combine how to perform the system test.

My concern about the cryptographic scheme is to not allow all parts of the key to be shared with anyone, including the recipient, since it would be possible to get the key of the sender. Collusion is another case you should also handle for this scheme to be robust.

[dsm-w3f]

@driemworks thank you for the improvements and fixed. The milestone was approved. I updated the evaluation document and added some improvements for the next milestones. I'll forward your invoice internally and the payment should take place within two weeks (could happen before). Great work!

[RouvenP]

hi @driemworks we transferred the payment today.

[driemworks]

Thank you. Just confirming that it's received!