C++ Light Client proposal

[vbar]

Project Abstract

This project is to create a C++ implementation of a Light Client for Substrate-based chains.

For which grant level are you applying?

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

Application Checklist

• The application template has been copied, renamed ( project_name.md) and updated.
• I have read and understood the FAQs, application guidelines and announcement guidelines.
• A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application.
• I have read and acknowledge the terms and conditions.
• 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.
• I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @_______

How Did You Hear About our grants program?

• Social Media
• Hackathon
• Personal Recommendation
• Substrate Builders Program
• Investor/VC
• Online Search
• Other: _______

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks a lot for the application. Just one quick comment from my side. Could you clarify as part of the specification of the delivery 0b. that it contains the points you mentioned at the beginning of the application (Cryptography, ​​Embedding Runtime, etc.)? The table basically lists the requirements of our contracts (according to our terms and conditions), that is why we always want to have it as detailed as possible. And maybe rename the headline of the milestone, because you won’t implement a substrate module.

[lamafab]

Please note that the Parity team is working on a redesign of the current RPC API, see w3f/PSPs#41. The currently API, which is quite noisy and messy, will probably be deprecated at some point in time.

[Noc2]

Thanks for the update. I will share the application with the rest of the team.

[laboon]

In theory I like this proposal, and alternative implementations are always a good thing. However, I'd like to see more specific milestone requirements, and some comments on how the changes of PSP 41 will be handled. If the RPC specification is not yet clear, it may make sense to hold off a bit on this until it has been.

[lamafab]

I'm not sure if the RPC API issue is a "blocker", but that sort of depends on what the requirements for this proposal are (it's currently not quite clear). Besides communicating with the remote nodes via PRC, which currently does not work for light clients respectively is work in progress, another way is to open a libp2p substream (/dot/light/2) to the nodes and send raw light client messages directly. We're about to merge this into the spec: w3f/polkadot-spec#512.

• We have more info on libp2p/substreams here: https://spec.polkadot.network/#sect-protocols-substreams
• The light client messages can also be seen in the substrate repo: https://github.com/paritytech/substrate/blob/master/client/network/light/src/schema/light.v1.proto

Depending on what problem this proposal is intended to solve, this might be sufficient (for now).

[vbar]

In theory I like this proposal, and alternative implementations are always a good thing. However, I'd like to see more specific milestone requirements, and some comments on how the changes of PSP 41 will be handled. If the RPC specification is not yet clear, it may make sense to hold off a bit on this until it has been.

Well, more specific requirements are basically the output of this proposal...

[teempai]

We included a note in the application on the RPC API being unstable and will take this into account as we specify requirements.

[Noc2]

Thanks for the update. Just a reminder that Vaclav Barta still needs to sign the CLA/Terms Conditions. Basically every GitHub account which contributed to the application.

[vbar]

Thanks for the update. Just a reminder that Vaclav Barta still needs to sign the CLA/Terms Conditions. Basically every GitHub account which contributed to the application.

That's a setup issue - I've signed as vbar, which is my account and does have my name.

[Noc2]

Thanks for the update. Just a reminder that Vaclav Barta still needs to sign the CLA/Terms Conditions. Basically every GitHub account which contributed to the application.

That's a setup issue - I've signed as vbar, which is my account and does have my name.

Could you also sign it with the other account? Just to make the bot happy ;-)

[vbar]

That's a setup issue - I've signed as vbar, which is my account and does have my name.

Could you also sign it with the other account? Just to make the bot happy ;-)

Trouble is, that's not an account - I think I've just (mis)configured vbar@mangrove.cz in my local git config and pushed a commit with it... I've squashed the commits now - did it help?

[Noc2]

Yes, it’s resolved. Thanks!

[alxs]

This seems very expensive to me - especially on an hourly rate level, but also in terms of output. Could you provide more detailed deliverables, as Bill mentioned? The specification may be the output of the proposal, but at least it'd help if you clarified its contents, the level of detail you will go into, length etc. Right now you could in theory deliver a one-page document that would meet the agreed requirements.

Also, if I understand correctly you're thinking of applying for treasury funding for the implementation. Would you be charging the same rate for that? Do you know if similar rates have been awarded via treasury before, and are you confident you could justify it to the community? It'd be unfortunate if you couldn't carry out the actual implementation after this, so some level of assurance would be great.

[ashlink11]

I'm supporting your application (just one approval so far). A high-quality C++ implementation is ideal. I think your hourly rate is fair. And I think it's very smart to start with the foundations (i.e. research & spec).

The reasons I think it's a fair rate are many.

There's a lot of work, time & risk that goes into the application process for grants and/or treasury funding, and then you would only receive payment upon the successful evaluation of milestone(s), so you have to essentially provide your own runway during this time. This means you need a certain level of financial stability to be a successful w3f grantee/treasury grantee because the process can be lengthy. This reduces the number of teams who can get to the level of expertise that you are at, and I'm grateful you've been able to make it through the gauntlet of becoming an expert open-source developer and are applying for this grant.

Also in general, to get to the level of being able to find bugs in a spec, you may have worked as bug bounty hunters in the past. I don't think the bug bounty system necessarily gives a fair trade to all developers, because there is potentially a history of unpaid work, i.e., any/all work done by devs who ultimately did not receive a bounty for a specific bug.

Given the investment you're willing to make, risk you're willing to take on, scarcity of quality team, and the general power dynamic between grants/grantees, I therefore think it's a fair rate.

However, I understand the points/concerns of my teammates who are debating what is a fair trade.

[takahser]

This is definitely something I'd be interested in. However, a daily rate of EUR 1500 seems very high to me. Would you be willing to reduce the price? Also, as already pointed out by some of my peers, it'd be helpful to add more details to the deliveries, so we can get a better understanding on what we can expect you to deliver.

[Noc2]

I’m closing the application due to inactivity. Let me know if I should reopen it. I will also share with the committee that I closed it.

[Noc2]

Reopened (see email)

[laboon]

@Noc2 What email was this?

[aphelionz]

@laboon It was my email. Sorry for not mentioning this sooner.

I let @Noc2 know that we would be open to a small discount and that we would update the grant with more details on what the spec would contain

[ashlink11]

@aphelionz Thank you for the update! Looking forward to seeing if we can find an agreement here for a very useful/core project proposal.

[aphelionz]

Thanks @cruikshankss - let us know if the new milestone table is helpful as well as the costs that I've just updated.

[ashlink11]

@aphelionz Thank you for more details and for negotiating on price. If I'm not mistaken, I've never seen Euro as the currency for a grant. I believe this should be USD. Checking with my team and plan to update you.

[aphelionz]

@cruikshankss went ahead and changed that to USD :)

[ashlink11]

Looks great. Thank you so much for reducing the price and adding more deliverable details.

[Noc2]

Thanks for the update. @aphelionz and @vbar could you sign the latest version of our terms and conditions?

[vbar]

Thanks for the update. @aphelionz and @vbar could you sign the latest version of our terms and conditions?

Done.

[aphelionz]

@Noc2 what else do you need from us with regards to this application?

[ashlink11]

@aphelionz I responded to you via email. Feel free to bring the conversation back here if you prefer. Thanks.

[alxs]

Hey @vbar @aphelionz. Thanks for the changes. I still would like to see more details, but given your reputation and that you're also working on bringing Ziggurat to Substrate, I have no doubt that you're serious about this and I'm happy to approve it at the current level of detail.

However, I think it may actually make sense to modify the scope of the grant so you can also work on improving the official Polkadot Protocol Specification with regards to light clients with some guidance from our spec team and/or Parity. It currently contains some sections relevant to light clients only, but there's no indication of what else applies and what doesn't, and it's incomplete, which means that right now smoldot is the de facto reference. However we'd like to provide a specification teams can rely on, so it would make sense to combine anything that isn't C++-specific that you work on with what we have. What do you think?

One more thing: are you sure you want to work on the JSON-RPC API spec now? Probably you'd have a much better idea of what is possible and what isn't after working on other parts of the client, and the RPC stuff should be mostly irrelevant to the core work.

[aphelionz]

@Noc2 @takahser friendly ping since you have requested changes. 🙏

[takahser]

@vbar I still think the daily rate is very high (you decreased it from EUR 1500 to USD 1360). Also, I still think that the application contains very little details, although you improved on it a bit. Nevertheless, I'm quite interested in seeing teams work on alternative host implementations. Hence, despite said reservations, I'm willing to go ahead with it.

[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 grantsPR@web3.foundation 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! 🚀

[alxs]

@aphelionz @vbar feel free to reach out to Florian from the spec team regarding the above. Teemu is already in contact with him via email and his Element handle is @florian:web3.foundation. Something he also mentioned was that at the moment it's unclear which substreams light clients are meant to support.