Zcash Node and lightwalletd Running PoC Proposal

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

@chris-remus — we discussed the proposal at our last meeting, and I’ll summarize our decision here:

Lightwallet infrastructure is definitely on our list of funding priorities, so we want to encourage proposals like this, and we’re grateful for your being one of the first people to submit a proposal to ZOMG!

To proceed with considering the proposal, we would need to see need more transparency around costs. For example, for the pieces of this that are developer time, how many hours do you estimate, and what rates are you billing at? And for the pieces that are server costs, what are your cost estimates?

We’re also open to you increasing the scope of the project, if that makes sense for you.

At least a few of us agreed that it’s helpful and healthy for there to be highly reliable lightwallet infrastructure that is managed independently from existing wallet app teams, and the things we’d look for would be proposals that provide high levels of privacy, reliability, and security for users.

If you’re open to discussing this more and refining the proposal, we’d welcome that, and thanks again.

2 Likes

FYI, ZecWallet Lite allows the user to choose between two preselected servers or a custom one (see: Wallet » Server info » Switch LightWalletD Server)

2 Likes

Thank for the feedback @aiyadt. To answer your question, the idea here was to develop -

1 - User documentation to help users understand how to connect to the service

2 - An FAQ documenting common questions and error messages with their resolution that may arise when trying to connect

Please see inline -

Sure, I hope the dialogue the submission sparked is beneficial to the community.

To proceed with considering the proposal, we would need to see need more transparency around costs. For example, for the pieces of this that are developer time, how many hours do you estimate, and what rates are you billing at? And for the pieces that are server costs, what are your cost estimates?

Did you see the breakdown in this spreadsheet? It was included in the original proposal. Is there anything else you need?

We’re also open to you increasing the scope of the project, if that makes sense for you.

Yes, it does, since if approved, we intend to be in this for the long haul. To clarify, would we be talking about increasing how long we run the services and adding a testnet implementation?

At least a few of us agreed that it’s helpful and healthy for there to be highly reliable lightwallet infrastructure that is managed independently from existing wallet app teams, and the things we’d look for would be proposals that provide high levels of privacy, reliability, and security for users.

If you’re open to discussing this more and refining the proposal, we’d welcome that, and thanks again.

Please let me know if you need anything else regarding the cost breakdown and confirm the potential scope increase intention and we’ll be glad to continue the discussion!

1 Like

@holmesworcester once I receive your feedback on the above response, I can update our proposal.

Please let me know if you need anything else regarding the cost breakdown and confirm the potential scope increase intention and we’ll be glad to continue the discussion!

Thank you!