Deliverable: Research Feasibility of a Java Host

[Daniel-K-Ivanov]

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#1353

[semuelle]

Thanks for the delivery, @Daniel-K-Ivanov. I will look into it as soon as possible.

[bhargavbh]

Overall Evaluation:
The feasibility research has been performed in sufficient detail with clear findings (positive/negative) for each of the subcomponents. The report is well structured and is a good starting point for teams to build a Java node implementation, and nicely complements the spec.
As mentioned in the grant application, a PoC for testing the performance and compatibility of a Wasm Runtime within Java has been delivered. The performance on small-scale benchmarks are promising. Milestones outlined in the application have been satisfactorily delivered.

I have looked into the light client design in details and here are a few comments.
Evaluation of Java Light Client Design:

• Network: Are there any optimisations/ tunings planned for peer discovery of light-clients in comparison to Full nodes. The requirements and settings are different, and I would assume implementing the same peer discovery for both cases would lose out on intent-specific optimisations. By design, light-clients peer with fewer nodes in comparison to full nodes. In optimal cases, syncing with a single honest node is sufficient. However, it usually has to sync with at least a few when initially joining the network (due to weak subjectivity).

• Database: could you please add more details on how you plan to use the persistence layer to store checkpoints and reliable nodes to sync with? This might be a potential attack surface. Our current light-client architecture does not provide a channel to report equivocation back to the network, which means the full nodes can attempt to mislead the light-client without being reported.

• Host Configuration: The Diagram in the document has a sub-component called Host Configuration. What are the parameters of this configuration? Why does it sit between the network and core layers? I was unable to find any details in the text.

[vikinatora]

Hi @bhargavbh, thanks for the feedback and the comments. I'll try to address them here:

1. The primary focus of the research was the feasibility part of the host as well as providing a high-level design of the different host types. Algorithm optimizations weren’t research topics we devoted time to. That’s not to say we don’t intend to deliver on a high-performing client, we intend to modularize the light client in such a way that it’s going to be easy to change implementation details if required for optimization or other reasons.

2. I assume the attack you’re talking about is the long-range attack mentioned in the specification. Our understanding is that this attack is high-risk, high-investment and as such we believe the chance of happening is low and the impact would be low as well since the light client is a passive participant of the network. As you said the punishment for this is reporting the equivocations and light clients don’t have a way to do that.

   We couldn’t find suggestions neither in the spec nor in the existing node implementations for approaches for guaranteed protection against such an attack or selecting a reliable full node when warp syncing. That’s why we think it’s best to safe guard the code in terms of failure-resistant logic if this attack was to happen.

   An approach we thought of is to sync with a node until it gives us a reason not to by detecting equivocations using the justification message definition. We can then move to a new node and persist the old one to a “black list” of nodes that we’d avoid syncing with anymore and the new one’s address to the “reliable list”. This approach might seem naive but it's aligned with the goal to sync with as few nodes as possible while keeping the complexity low and allows to incrementally improve the functionality.

3. The Host Configuration is small component that is to store host specific information such as the client parameters that it can launch with, chain specifications and other information that may be host specific. The positioning of the component between the network and core layers, doesn’t have to do so much with it’s functionality, rather that it’s the place where we decided is most suitable for that module when talking about diagram symmetry, although you can make the case the configurations will have some implications on the neighbouring layers. It didn’t deserve a full row like the network and core layers because it should be much smaller in terms of logic, but also we had to include it as it’s going to be a light client module after all.

We're open to suggestion for any of these points. Even though we've conducted a thorough research into the inner workings of the host, we're still far from the knowledge that people at Parity or the host's core developers have. Our team hopes that one day we'll be at the tip of the knowledge in the Polkadot community as well.

[vikinatora]

Hey @bhargavbh, @semuelle. Have you managed to take a look at our reply to your comments? Do we need to update the reasearch outcome documents or the discussion will be kept here?

[bhargavbh]

hi @vikinatora thank your for the replies. Of course, comments-1&2 were exploratory, however, i would suggest integrating your clarification on Host Config in the research doc. My colleague @FlorianFranzen is evaluating the PoC WASM environment deliverable, and will reply here soon.

Cheers

[vikinatora]

Thanks for the info @bhargavbh, I updated the Light Client design document to have information about the Host Configuration module. Looking forward to hearing from you.

[Noc2]

Sorry for the delay here. I'm finally happy to tell you that the milestone is approved and I will forward your invoice internally. See our notes here

[github-actions]

Congratulations on completing the first milestone of this grant! As part of the Grants Program, we want to help grant recipients acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully deliver their first milestone. Please use the badge only in reference to the work that has been completed as part of this grant, so please do not display it on your team or project's homepage unless accompanied by a short description of the grant. Furthermore, you're now welcome to announce the grant publicly. Please remember to observe the foundation’s guidelines in doing so. If you haven't already, reach out to grantsPR@web3.foundation for feedback on your announcement and cross-promotion.

Thank you for your contribution, and good luck! If you have any remaining milestone, let us know if you encounter any delays by leaving a comment on the application PR or submitting an amendment.

[github-actions]

We noticed that this is the last milestone of your project. Congratulations on completing your grant!

So, where to from here? The main goal of the W3F grants program is to support research as well as early-stage technical projects. So, if your project still falls under one of those categories, you might want to apply for a follow-up grant. Depending on your goals and project status, there are other support programs in our ecosystem that might be better suited as the next step, for example:

Project with a Business Case/Token: Substrate Builders Program or VC Funding

Common Good Projects: Treasury Funding

For a more comprehensive list, see our Alternative Funding page.
Let us know if you have any questions regarding the above. We are more than happy to point you to additional resources and help you determine the best course of action.

[fededubbi]

Hi @vikinatora,

Can you please let us know in which currency you want to be paid in?

Many thanks,
Federica

[vikinatora]

Hi @fededubbi,

Address is eth:0x1F7683228Ee9Bc65335374eA5c92B81C74131404 (USDC/USDT/DAI).

Thank you,
Viktor

[fededubbi]

Hi @vikinatora,

Yes, but which of these 3 currencies you prefer to be paid in?

Many thanks,
Federica

[vikinatora]

Hey @fededubbi,

DAI is preferred.

Thanks,
Viktor

[RouvenP]

hi @vikinatora we transferred the payment today. we had to do the transfer in USDC due to liquidity constraints. thanks!