Interstellar - Wallet Phase 2 (follow-up)

[nashjl]

Project Abstract

Interstellar is a new universal layer to access Web3.
Wallet Phase 1: w3f/Grants-Program#1354

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.
• A BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (aUSD/USDT) address for the payment of the milestones is provided 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. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[Noc2]

Thanks a lot for the follow-up application. I have one initial question: What are your long-term goals with this project? Did you already try to apply for treasury funding with this? If you plan to help different parachains and, if I understand you correctly, you're already talking to parachain teams, it might be the logical next step. Also, regarding the long-term funding of this project. If your long-term plans are instead to release your own parachain, then the substrate builders program might be better suited for you, see https://substrate.io/ecosystem/substrate-builders-program/

[semuelle]

Thanks for the follow-up application, @nashjl! I find it generally quite interesting, I just have trouble understanding the overall architecture of Interstellar and the relationship between its components. Perhaps you could add an architecture or sequence diagram containing Integritee, Interstellar and Polkadot and what data is exchanged and how?

[semuelle]

Can you expand on what this 'upgrade' entails?

[n-prat]

Currently, we are not handling any signature nor transactions in the app.
We will have to add:

• support for the Keystore/Keychain app-side
• implement signature verification in the pallets [probably using unsigned extrinsic with signed extension]
• add the "fancies" needed for a nice UX: retrieve dynamic value of the ETH/etc

We used the word "upgrade", but depending on how/what we deliver in milestone 1 it may be different pallets.

Practically the milestone 1 is server-side, and will probably be tested with Polkadot front-end + demo script;
and this milestone is the "full stack".
After milestone 1+2, we SHOULD NOT have any hard-coded default keys anywhere(ie //Alice etc).

[semuelle]

What exactly is being done/delivered here?

[n-prat]

This milestone would upgrade Android and iOs apps. Ideally deployed through Firebase and TestFlight.
With added features of social recovery, instant onboarding/airdrop, and MVP UX(ie no app closing at the end of the tx, proper error handling, etc).
The social recovery has two parts:

• the server-side using the substrate recovery pallet
• app part: we must offer a nice UX to recover if the user had a pallet before

The goal is to deliver MVP-grade apps, minus the garbling optimizations of the next milestone.

[semuelle]

Can you add/explain how you measure/evaluate these?

[n-prat]

That is not the easiest one to evaluate...
When you evaluated the latest milestone(5) you may have noticed that the app was running at maybe ~1 FPS and that was pretty much unreadable.
The goal of this milestone is to target at least 60FPS, and ideally 120+.
At those frame rates, it is a way more pleasant user experience.

Practically, we will have to refactor the garbling lib we are using(swanky) and add various optimizations from a white paper.

We will also probably add a "dynamic" feature(ie fading) to make the screen more readable, sacrificing a bit of security.
That should be user-configurable and/or server-configurable; eg based on the amount.

[n-prat]

Hello,
@semuelle cf the comments for details

For an overview of our architecture, you can find info here and there.
It is a bit dense, and probably not easily "discoverable". We are open to feedback!

[nashjl]

@Noc2 Thanks a lot for your question.

Our long-term goal is to launch our own parachain to help current and future Polkadot parachains.

As a small team with limited resources, we recognize that we may be too early stage to apply for the Substrate Builders Program or treasury funding.
Instead, our short-term goal is to develop the missing key features of our solution, such as an iOS version (as suggested by the grant team), Polkadot & Ethereum transaction capabilities and fix some user experience issues with our transaction screen.

Once we've developed these features, we can showcase a more complete and attractive version of our solution to both potential investors and parachain teams we are in conversations with.
By taking this step, we can secure a pre-seed funding round, which will not only enable us to further develop our solution but also facilitate team expansion and place us in a stronger position to participate in the Substrate Builders Program and secure treasury funding.

We believe that by following this roadmap, we can construct a compelling solution that will enable us to successfully launch our parachain and thereby bring full benefits to the Polkadot ecosystem.

[semuelle]

Thanks for the replies, @nathanprat & @nashjl. I would like to see this grant going forward, but there are still some details I cannot quite figure out. The book you linked helped a little, but maybe I'm too dense. For example, where/how does the "Integritee pallet" (D1.3) connect to Ethereum? Going through the diagram in the project details, what are the striped and dotted components? Mobile app, Interstellar chain and Integritee? Regarding M5, I would suggest you either specify more clearly what these optimisations will look like, or you remove the milestone as a whole and include that in a future proposal.

[nashjl]

Hi @semuelle, Thanks a lot for your message and support. Now that you mention it, it’s true that the diagram is confusing. We updated it here
Let us know if that gives you a better overview.

Where/how does the "Integritee pallet" (D1.3) connect to Ethereum?

"Integritee pallet - Ethereum signer" is only the signer.

For the architecture we have two options:

• we have no client at all app-side; and our stack publishes the transaction to the appropriate network cf M1.4 "Integritee pallet - submit transaction"
• our stack only handles the wallet(i.e. the signatures) and then returns a raw (signed) Tx to the mobile which can be send to the appropriate network with a local (light?) client

Regarding this milestone, we think that this is an implementation detail:

• the complexity is handling the keys and signing the Tx; publishing a signed Tx is a solved issue: it could be done with an already existing pallet(?), or via a basic RPC and a light or full client we could run as part of our stack, or even via a 3rd party API(at least for now for demo/MVP purposes).
  We want to keep it as flexible as possible at this stage to have the best options for the production stage.

"Regarding M5, I would suggest you either specify more clearly what these optimisations will look like, or you remove the milestone as a whole and include that in a future proposal."

To optimize our current garbled circuit implementation, we can use parallelization to speed up computation, caching to reduce computation load, and permutation-based garbling to improve garbled circuit size and security. These combined approaches should significantly improve performance while maintaining overall security, but careful consideration of trade-offs is necessary.
So, we don't think writing further about optimization implementation details up-front will help in this case; It is likely to become irrelevant after the implementation is done.

Would you be OK with:

• specifying a performance target (e.g., at least 60 fps ~ previous grant M3 performance)?

• optionally the link to the white paper related to a permutation based garbling scheme designed for performance.

The goal of M5 is to have a functional MVP. Without these optimizations, we won’t be able to deliver a proper MVP demo (we are currently at <1 FPS)

Regarding D5.2 (Master/Configuration) Display Circuit Update:
Currently, for each frame, we are displaying only one segment per digit with 1/2 probability. It can take a few seconds for the user to read the digits.
To improve readability, we can display multiple segments for each digit per frame, which reduce the cognitive load i.e. time required for the brain to process information and can make the UI significantly more comfortable with very little impact on security.

[semuelle]

Thanks for the update. Sounds good to me.

Would you be OK with:

* specifying a performance target (e.g., at least 60 fps ~ previous grant M3 performance)?
* optionally the link to the white paper related to a permutation based garbling scheme designed for performance.

Either one is fine. I just want to make sure that, when this is delivered, we have a way of actually evaluating it. Any details you can add about what will/might/could be done would help.

[nashjl]

@semuelle Thanks for your response, we have updated M5 with what you agreed on. We will also add fps in the logs.
We can assure you that regarding the evaluation of M5, you will SEE a major improvement!

[semuelle]

Thanks for the update.

[Noc2]

Sorry for the late response here, and thanks for the detailed answers. I will mark the application as ready for review. But I personally won’t approve it. I would be willing to give you a small follow-up grant to keep working on the PoC, but I think you should try to actively find other income sources. Almost 100k plus the previous grant is a lot for a small startup. Otherwise, we risk that the project won’t take off, especially since the entire grants team is not really focused on the business side of applications. The Substrate Builders Program as well as the treasury, usually don’t have huge requirements when it comes to the progress of teams and their existing work, but ideally, you also get external investors to support your project.

[nashjl]

Hi @Noc2 thanks for your feedback. We understand your concerns. For us, the main problem with treasury funding is the threshold of 5% which you need to deposit in DOT. The substrate builders program is something we are looking at, but we need to at least have some financial support anyways.
We already had early talks with investors and are in close contact with some of them.
The main reason other VCs stayed on the sidelines was the lack of understanding the project as they could not really visualize how it would work. The goal of this follow-up is to create an MVP which can address this crucial problem and demonstrate the power of Interstellar (a demo says more than 1000 words).

PS: About ERC-4337

We just received huge market confirmation from the ERC-4337 release focused on account abstraction. Ethereum based projects like Argent, Safe, Sushiswap etc. all see a lot of potential in this for their ecosystem.
Interstellar is the evolution of account abstraction. Our key advantage to those solutions is being a substrate-based chain (with native social recovery), dedicated to this problem instead of simply building on Ethereum L2s. This allows us to personalize way more in terms of accessibility, user experience and security:
Interstellar is not limited to EVM chains/smart contracts and works with any native type of current and future blockchain technology. Leveraging not only mobile secure elements, but also Trusted Execution Environments (TEE) and especially a Strong Authentication/Transaction Validation Layer which can resist state of the art malware attacks and banking trojans (that simple account abstraction cannot handle). Achieving a true cold wallet security with your mobile.

[Noc2]

Sorry for the late reply, and thanks for the detailed response. Something to be aware of: the SBP also supports projects financially, as far as I know, and helps you get in touch with VCs. Apart from this, I still recommend reducing the scope of this application or applying for treasury funding. But I will also share the application again with the rest of the team for additional feedback.

[nashjl]

Thanks for getting back @Noc2!

We are making progress with our partnerships and would really like to continue working with the Web3 Foundation. Following your recommendation, we could reduce the scope of this application to 2-3 milestones. Regarding alternative funding, we will check again with the SBP but are also currently looking at the Ethereum Support Program which could help with developing the MVP before applying for treasury funding.

Additionally, we just applied to talk at Polkadot Decoded 2023 which might be a good possibility to get more traction (if accepted).

Please let us know if this approach makes sense, so we can propose an updated scope and sync with ESP.

[keeganquigley]

Thanks for the reply @nashjl it's possible that if you reduce the scope/cost of the application it might have a better chance of getting approved. Perhaps you could focus purely on the PoC of the garbled circuits and pallets and less on the app deployment; if you lowered it to a level 2 grant you would only need 3 approvals.

[nashjl]

Thanks for the recommendation @keeganquigley!

We modified the PR into a level 2 application, focusing purely on the garbled circuits and pallets. 👍

[keeganquigley]

Thanks @nashjl I believe a contract will need to be signed in order to get paid in fiat, but I will double check with the team tomorrow. Other than that I'm happy to support it.

[nashjl]

Great. Thanks a lot @keeganquigley for your support!

[Noc2]

I'm happy to go ahead with it. For fiat payment, we don't need to sign a separate contract. See https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md

"In the case of fiat payment, please share your bank account privately with [email protected] via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here."

[dsm-w3f]

Thank you for your application. Reading the discussion, I think is a good strategy to continue working and trying to find other sources of funding. I'm happy to support the project, it seems to be a very promising one. One idea is to look for mobile phone companies (hardware ones) that could embed the technology in their products. However, I strongly advise trying to get a patent before doing that. Good luck in finding more supporters.

[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! 🚀

[nashjl]

Thanks a lot for your support @Noc2, @semuelle, @keeganquigley and @dsm-w3f!

Thank you also for your feedback, guidance, advice and ideas. Means a lot!