Zcash Node and lightwalletd Running PoC Proposal

What is your price for this package of services?

1 Like

Thanks for the feedback. Maintenance relates to work required to keep the services running. Support relates to helping people connect to and use the services.

We’re glad to run more nodes for a longer term. This grant application is for a proof-of-concept (PoC).

From the grant application -

If this PoC project is successful, we would apply for a larger, longer-term grant to continue running these nodes.

… a large number of light clients …

We should avoid this kind of centralization - especially since this is critical infrastructure.
Provide the means such that it’s easy for people to run lightwalletd services. Ideally zcashd would provide lightwalletd services by default.

1 Like

Seriously? This is the size of one game by today standards.

2 Likes

Thanks you for your offer. Honestly I don’t need it at this moment, and I see it as my little contrib to Zcash.

1 Like

I think it’s not a problem of size but of easy to use. It’s not easy for “normal people” to run and use a full node. And full node are slow to sync and not compatible with light client.
If we can abstract this part it will be better to Zcash adoption.

3 Likes

For clarification, I didn’t make a direct offer, I don’t have the authority to speak for ZOMG. I simply stated that I would support (as a voter on ZOMG) Zcashers who help the ecosystem.

It’s up to you, and others, if they feel the need to apply for a grant.

1 Like

I don’t know I didn’t think about it, because I’m not ready to guarantee SLA on this kind of services.
I can set it up and maintain it but I will not be available 24/7 to fix issue ASAP. Even if issue happen once a year, it’s always when you’re not available to fix it :sweat_smile:

But if someone need some help to set up nodes at different geographical places I can help without problem, just DM me.

3 Likes

I think that all the same, a service for 3 months cannot cost 13,000, as an option to hire a company for detailed instructions on how to make a node, and look for companies that will be able to offer this service for much less money on their equipment.
In the meantime, develop existing nodes.

3 Likes

There are actually some serious disadvantages to this from a privacy and security standpoint. Light clients are still very vulnerable to a malicious lightwalletd. You can see a rundown on these vulnerabilities here:

https://zcash.readthedocs.io/en/latest/rtd_pages/wallet_threat_model.html

Having lots of lightwalletd’s mitigates some of these issues, like the ability to analyze the transaction graph based on who is fetching memos, but as you add more lightwalletd’s, the chances of connecting to a malicious lightwalletd approach 1.

A few ideas on how to address the budget question to make sure that everything’s fair, that I’ll bring up on today’s meeting:

  1. We can ask for transparency about hourly rate, and server costs estimates up front.
  2. We can ask for an accounting of hours spent and actual server costs at each funding milestone. (Perhaps, if it’s easier than the applicant expects, the project will come in under budget in terms of hours and server costs.)
  3. We can invite (and are inviting) competing or complimentary proposals, which lets the market determine the fair price, over time.

As far as inviting competing proposals goes, we are already doing this, just by having put out the call for proposals and having published this to the ZOMG “What we fund” document. And this discussion itself, happening in a public forum, underlines the fact that we may be interested in funding this sort of thing, inviting competing proposals.

Also, the fact that this proposal is for a three month proof of concept gives us some protection against wasting community funds by overspending. If we do award this grant to this applicant, at the end of three months we’ll have another opportunity to review competing proposals.

4 Likes

And thanks everyone for taking the time to kick the tires on this proposal. This kind of attention from different perspectives is exactly what the process needs to make the ZOMG work well!!!

2 Likes

Regarding #1, this spreadsheet is linked in the proposal. It’s a detailed cost breakdown of the proposal.

I am not at all convinced by this proposal. I don’t think it’s going to improve Zcash adoption.
If @chris-remus wants to convince us, I think he should think about self-managing and self-financing his PoC. If there is added value, as he thinks, we could consider funding.
I’m not keen on paying to see …

2 Likes

I doubt that running centralized nodes is more private or more secure.
It’s fragile, technically and politically.
You should fund work to solve privacy and security issues of lightwalletd instead.

@NighthawkApps uses ECC’s stock lightwalletd and has considerably less users(although steadily growing) than @adityapk00’s ZecWallet.

1 Like

While I agree on this point, here are a some points why I think this proposal is not a good idea in its current state, and an alternative:

As many have pointed out, the very high cost of $13,140 for setup, monitoring, alerting, backups, documentation & support all for 3 months time-boxed life of service would result in Zcash ecosystem left with less by having a temporary player providing the service. The high funding amount has only 11% of the funding allocated to the actually infra costs without details on what kind of documentation, support or maintenance that will be provided.

Let’s break down the expenditure:

  • Setup nodes, monitoring, alerting and backups - $3000
    Assuming a standard to high rate of $100/hr for dev ops, this turns out to 30hrs of work, which seems excessive and more in tune of learning experience.

  • Three months of maintenance - $3600
    There is very little maintenance requirement, as low as restarting the server or applying a new patch. Compare it to Nighthawks grant and the allocated 1-2hrs of maintenance per month, which is sufficient.

  • Documentation development and maintenance - $1500
    Lightwalletd has good enough documentation, including help for creating self signed certificates GitHub - zcash/lightwalletd: Lightwalletd is a backend service that provides a bandwidth-efficient interface to the Zcash blockchain
    @chris-remus Can you please provide more specifics to what exact developer documentation you plan on providing?

  • Three months of support - $3600
    What does support mean?
    Lightwalletd is not a finished product and does require some ongoing monitoring and upkeep, which is best undertaken by dev team of apps that are actively in use(that can detect issues when they occur) and requires working with ECC engineers and patch software. It is the ECC engineers who end up providing support to patch issues.

  • Three months of infrastructure for two nodes - $1440

The fact is, right now, there are not many applications that are building on ZEC, and only Nighthawk’s Android wallet even has the feature to switch lightwalletd server for end users.
I do not believe there is a demand for dedicated lightwalletd infrastructure which cannot be replaced with existing infra. If there are new developers who want to connect to an existing lightwalletd, they can connect to Nighthawk’s shielded.nighthawkwallet.com:9067 @bradmiller. And our dev ops can support increased usage and scale up from there till we peak out(following which we can submit an extension for hosting lightwalletd infra, nowhere near the costs of ~$13k for 3 months).

Following up a recent discussion with my team, I can say that Nighthawk team can setup 2 dedicated instances of lightwalletd running for 2 years with support & maintenance for less than $13k along with documentation to automate configuration & deployment via Ansible Playbooks. I’m not sure if @ZcashGrants plans to have a bidding market for infra proposals, but I strongly believe that infra that serves new developers should be aligned with long term support & voluntary goals(thanks @Le_Bleu) with just enough incentive to support the infra, as that is not the place where innovation happens.

1 Like

Thanks for everyone’s advice on this!

I have a few questions:

I know that the few light clients that exist (ZecWallet, Nighthawk, Unstoppable) each rely on thier own back-end lightwalletd service. And only one (Nighthawk) has the option for the user to choose a different one.

Overall my first impression is that users having more random instances to choose from = good.

So, from a privacy perspective would it be advantageous for users for all wallets to have the ability to choose a random lightwalletd or have the software choose one at random on each open?

What would a decentralized “array” of high-availability lightwalletd instances look like? How best to get there?

Is this something that the core code (zECC wallet) could support? @bradmiller

1 Like

Majority of the users do not want to worry about server selection and instead prefer having reliable service. From privacy perspective, I believe the networking aspect: tor, nym based connections to lightwalletd infra is preferable for the majority of the users and there is work that needs to be done in that area. Advanced users can always custom build the open source zcash apps and change the light client server to their own choosing. This is why Nighthawk only has option in Android to switch servers, while iOS does not.

Not sure if there is a demand from end-users for that, but for new developers in Zcash ecosystem, having a steady, available open instance to use as sandbox would be a good pathway before they deploy their own infra.

5 Likes