Zecwallet Lightwalletd server continuation

Who is the primary contact or organization for this project?

hanh

What USD ($) amount are you requesting?

$6000.00 USD

Are you requesting payment up front or upon completion of the grant?

We require the grant funding before commencing work on the grant.

Why is an upfront payment required?

The cloud provider requires upfront payment.

Describe your grant.

Zecwallet Light servers are down and not maintained anymore. Unfortunately, this leaves the Zcash public infrastructure with fewer options. There are no servers that run the ZecWallet fork of LWD that includes the Spam Filtering capabilities, and basically only mainnet.lightwalletd.com This grant is about running the servers on a cloud provider for 1 year AT COST. 2 servers at 200 + 100 for maintenance/bandwidth = 500 $/mo Bills will be provided on request. We’ll use https://bithost.io and pay directly in ZEC.

The grant will be entirely deposited in the bithost account. Then, it will be used to pay for the services until it runs out. Besides setting up the servers, there will be no guaranteed devop support.

Please introduce the team that will be responsible for delivering the grant.

Head of Devops Mentoring and supervision of the data and devops team Implementation of data and software infrastructure to ensure maximum security and scalability while respecting the budget Technology watch and implementation of best practices to optimize the quality of work and productivity of the team. Technologies: Microsoft Azure, AWS, OVH Cloud, Terraform, Git, Airtable

Are any members of the team currently members of ZCAP?

hanh is a member of ZCAP.

13 Likes

Which server do you plan to use? From a quick check on bithost I don’t see any at that price range that would have the space required for a node

1 Like

I was looking at the Digital Ocean website directly. They have more configurations available.
It seems that https://cloudzy.com/ would be a better option then.

1 Like

The lack of infrastructure for lightwalletd has been a thorn in our side, and something I actively discussed during my time at ECC. I’m a fan of this proposal!

However, as there is no devop support I would want access shared with ZF/ECC for simple reboots and the like!

1 Like

It would be good if devop could be crowd sourced. And funding too. Here’s a UA for donations:

u1jfdt9klkahj4yagjy93ejawyk2ag7yqrjlna2tfqwet2z8pc4wja425wglm0ggruumuexn9fs4eq82zhuh6zpxkaczqv8m7rck46azcqjjjwh4w7u9rxrt7rgx90z2awrjepwnzyp5wlu0dk7kavqh2vgjfgc8ydx5l7qw278c036ww3aws6athz59ux5vcdhwl7upumv0t92mu50dk

1 Like

This idea reminds me of Nighthawk’s alternative to ZecWallet infra grant in 2020 from the Zcash Foundation. We’ve come a long way since running light wallet service infra on shared cloud instances.

Note that lightwalletd.com service expanded to a globally distributed (na.lightwalletd.com, sa.lightwlletd.com, eu.lightwaletd.com and ai.lightwalletd.com), scalable(with k8s) infrastructure since June. The bandwidth requirements may not be fulfilled running a VPS setup given the ongoing sandblasting attack. My team will share more info regarding load on the public infra in our quarterly report soon.

The idea of adding “Spam Filtering” to the service needs to be thought about carefully. It has ended up ignoring real transactions with lots of inputs and outputs. This has caused problems because people had to fix their wallets using a full node zcashd wallet.

Also, we need to be careful about using an un-maintained ZecWallet fork of lightwalletd in this deployment. It is okay for some personal experiments, but not good enough for production use where real people rely on a daily basis.

Yes, and identifying those gaps with the Light Client Working Group, @NighthawkApps took the responsibility of architecting a scalable infrastructure, available in 4 continents. With ongoing upstream lightwalletd protocol development and its upcoming improvements, the global infra that the community has invested in will soon bear fruits.

Has this really happened? I asked hanh before and IIRC he said that this only happened on a test transaction from ECC.

This is a valuable global infra for sure. However, at this moment, every wallet client relies on it (YWallet, Zingo, NH). It is a single organizational centralization point. The entire LWD infra is under the @NighthawkApps management and is running the same ECC lightwalletd source code.

Also AFAIK from the grant document, the cost of the global infra is 4000 USD per month, including 2000 USD of devops cost.

This proposal is 500 USD for cloud cost and 0 USD for devops. It is clearly not the same level of service but it is a step forward toward decentralization and I hope the beginning of a new model of community involvement.

Btw, could you reply to Zcashblockexplorer
We have several reports of users seeing incorrect fees.

3 Likes

I support this grant.

These people were ECC testers who were receiving funds from their company. They didn’t have to use zcashd. The filter is optional. They could have turned it off and rescanned.

This is the version that ZecWallet Lite was running until they shutdown.

btw I support this grant, but I think it requires some additional steps to be worthwhile:

  • Include effort required to keep the fork up to date with upstream (though I’d really like to see it getting merged upstream)
  • Have a continuity plan - what happens after a year and you decide to not maintain it anymore? Would you commit to relinquishing the domain of the server to another party?
1 Like

The patch is only a few lines. It shouldn’t t be much effort to rebase.
The domain name is not guaranteed to stay active forever. If it dies, it dies.

Monero has this list of remote nodes: List of Monero Remote Node - ditatompel.com

Zcash has only the NH nodes (4 servers under 1 entity).
I think it is necessary to have more servers.

I think you are being a bit too harsh and demanding.

Again, we are doing it for free devops. It is just like running a zcashd/zebrad node.

2 Likes

For clarity, I support this proposal. I would go further to say it is a MUST unless ECC or ZF steps up and does it themselves. I’d propose, for decentralization, that all 3 things happen!

1 Like

The first instance is up. There are going to be many more…

grpcurl lwd1.zcash-infra.com:9067 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetLightdInfo
{
  "vendor": "Zecwallet LightWalletD",
  "taddrSupport": true,
  "chainName": "main",
  "saplingActivationHeight": "419200",
  "consensusBranchId": "c2d6d0b4",
  "blockHeight": "2267708",
  "gitCommit": "a67fcecc7d0e91aa3ad4d8b154d532652ce1381f",
  "buildDate": "2023-10-20",
  "buildUser": "hanh",
  "estimatedHeight": "2267709",
  "zcashdBuild": "v1.3.0",
  "zcashdSubversion": "/Zebra:1.3.0/"
}
13 Likes

One of the few devs doing actual work here. Nice job @hanh, per usual.

2 Likes

I only saw this now - apologies if I sounded harsh, it wasn’t my intention.

The reason I mentioned a continuity plan is because of what happened with ZecWallet. People switch to a server and years late it stops working, and suddenly a lot of wallets stop working. Having some continuity plan would help with that. Running a server does not simply require running the server, it’s a responsibility.

That’s moot anyway, congrats on the grant and on the first deployment. Do you plan to run servers in different regions?

2 Likes

I beg to differ. Nothing lasts forever, especially software. What we should have is an easy transition path.
In the case of lwd servers, it could be simply that clients have the ability to find another server automatically.

1 Like

If only @zooko had created Zashi years ago…

2 Likes

Also, this wouldn’t happen if we had more than 1 server !!!

Edit:

  • lwd1.zcash-infra.com:9067 (East Europe)
  • lwd2.zcash-infra.com:9067 (Hong Kong)
  • lwd3.zcash-infra.com:9067 (USA)
6 Likes

:thinking: Thought of the day :thinking: - Relying on a specific server too much adds an attack vector.