Hi Everyone
We submitted this ZOMG grant application yesterday -
Following the submission process, we’re now posting here to encourage feedback and discussion.
We look forward to your thoughts and hope for your support!
Chris
@cjremus
Hi Everyone
We submitted this ZOMG grant application yesterday -
Following the submission process, we’re now posting here to encourage feedback and discussion.
We look forward to your thoughts and hope for your support!
Chris
@cjremus
is this a joke?
No! And I think it could be quite helpful.
Thanks so much for the proposal, Chris!
I have a bunch of questions, but I’m interested to hear what folks from Nighthawk and Zecwallet think about how they would use an alternate lightwalletd. It would be amazing to have a few trusted lightwalletd’s as backups in case the primary one these wallets use were to fail.
I think it’s also helpful to the ecosystem just to have other people running this infrastructure, hitting any pain points, and helping to identify how it needs to improve.
I clarify my question. I just always thought that nodes are something that users can install at any time of their own free will in order to maintain decentralization and for the benefit of the network. I don’t have enough technical understanding to understand the essence of this problem, but I just keep a couple of running zcashd all the time, simply because I find this useful for Zcash.
I believe that there should be nothing complicated in installing the nodes, there should just be clear documentation and one launching file. Let’s fund the creation of simplicity and usability for the mass user. If the nodes are something exclusive and this process requires constant monitoring, then something is wrong with these nodes.
@artkor one maybe helpful clarification (and @chris-remus this might be a helpful edit to the proposal title just to avoid confusion) is that the proposal is for running a node plus a lightwalletd, and not just a node.
The nodes you’re running @artkor are supporting the network, but they probably aren’t running a lightwalletd and set up to support a large number of light clients. Right now there are a very small number of available lightwalletd’s out there. Zecwallet runs one partly with funding from Zcash Foundation I think, and I think Nighthawk is running one as well. It’s helpful to think about how we can get more of these up and running.
Does that make sense?
Absolutely. I’m totally in favor of making the “light” nodes as more as possible. And if this work brings us closer to this goal, then of course it is necessary. Thanks for clarifying.
I would say that running a node that requires 30-50GB of hard disk space is not for “normal people”.
Even the current light wallets are not there yet.
Thanks for the feedback. I’ve updated the title here -
But can’t seem to figure out how to edit my original post here in the forum. I wonder if it’s related to Discourse permissions?
It’s a spam setting since you are an account that has not posted much. I have bumped up your trust level so you can post and edit more
I think it’s a generally healthy idea to have multiple 3rd party providers for lightwalletd services. I don’t have any specific comments about this proposal per se, but there’s a couple of technical points to keep in mind:
Short version of the explanation: When Zecwallet Lite originally launched, it supported t-addresses, which lightwalletd didn’t support. So, Zecwallet forked lightwalletd to add support for t-addresses. Since then, ECC has added support for t-addresses, and there’s some work needed on Zecwallet’s side to reconcile the differences and upstream all the changes so that Zecwallet can work against ECC’s lightwalletd. (I’m hoping to submit a proposal for this to ZOMG soon)
This is also the reason why Zecwallet Lite mobile wallets currently don’t support switching LightwalletD servers. Therefore, this proposal, as it is currently written, will not support Zecwallet Lite.
Even after we fix the differences and make the gRPC interfaces compatible, there are likely to remain implementation differences in the two LightwalletDs. Most notably, ECC’s lightwalletd uses a disk-backed store, whereas Zecwallet’s LightwalletD holds the entire (compact) blockchain in memory, trading off higher RAM requirements for sync speed. Therefore, Zecwallet’d LightwalletD has higher memory and runtime requirements.
Also note that the zcashd that backs LightwalletD needs to run with txindex=1
and insightexplorer=1
, which increases hardware (disk, CPU) requirements further.
Thought so, thank you! I’ve updated the title now.
Thanks for the feedback. Regarding hardware costs, I looked at those in this funded grant -
And tried to align the expenses included in our application with it.
Does nighthawk use ECC’s version or yours? do we have a sense of which has the most users?
Hi Holmes,
It’s my understanding that Nighthawk and Unstoppable, as well as any future wallets built atop the ECC created mobile SDK’s for Android and iOS will use the “stock” lightwalletd, rather than the (high performance) fork of lightwalletd created and maintained by @adityapk00. Longer term we’re hoping to converge this fragmentation while preserving the performance gains of Aditya’s approach.
@bradmiller can probably connect ZOMG with the right folks at Unstoppable and Nighthawk folks so they can provide perspective as to the attractiveness of pointing their apps at lightwalletd’s run by third parties such as Chainflow.
Longer term, I would like to see economic incentives for node operators (including full nodes and lightwalletd’s) built into the protocol.
Finally, I’d like to put in a personal vouch for @chris-remus at Chainflow, whom I met through my involvement with the Celo validator community. I believe that Chris’ organization is mission aligned with Zcash broadly, and welcome him into the Zcash community.
DC
I believe this proposal has two main customers, 1) mainnet products that want to avoid the cost of running their own mainnet node to support their product and 2) developers looking to bootstrap into the light client development ecosystem. To that end I believe the proposal should consider both customers equally and also run a testnet node.
I echo @alchemydc’s comments about a desire to bring the two implementations back together and preserve the performance gains that Aditya has realized while also being keen to create an economically incentivized node model in the future. Settling on a single implementation in the early days of light client development and having it be publicly available also lowers the barrier to entry for new developers interacting with products like the ECC wallet SDKs or leveraging the ZECWallet JS codebase for their own products and in my opinion will accelerate development of new light client based products.
Overall I’m in favor of this proposal and think it brings a lot of value.
I’d love to get some input from @iBek at Unstoppable Wallet and @NighthawkApps.
My gratitude for your support
Thank you for the feedback. We’d be glad to run a testnet node as well, if the community agrees this is important. It makes a lot of sense to me.
Doing so might require modification to the application, to take into account the additional effort and infrastructure costs. I believe a potential cost increase would be incremental, i.e. not a multiplier.
Hi,
As maintainer of Zcashfr.io and all sub services, like insight Zcash explorer, Zcash node and “custom” lightwalletd version, I would like to share my though about this request.
I don’t know how much cost an instance in Amazon to host zcash node because I host everything on my own servers to get control on it. But I know how much time I spend on it to implement and to maintain it, and I think 13000$ for only 3 month of run is too much.
About deployment cost, it’s one time cost and it can be reduce a lot by using existing docker image or at least dockerfile made by ECC and made by me for « custom lightwalletd » hosted by ZcashFR. With this, it should take less than a week to have 2 full instances up and running.
About maintenance cost, If you use docker services, and you monitor it, it’s should be easy to restart automaticaly node if something goes wrong. You will need to update OS packages (maybe not if you use AWS) and update zcash and lightwalletd nodes when a new versions are published but again it will took maximum one week by month. Even without docker, both node are stable and production ready, almost no crash during 2 years of run without docker.
I don’t understand the difference between « 3 months of maintenance » and « 3 months of support » which are similar to me. So 7200$ for maintain up 2 instances for 3 month seems a lot for me.
Of course I think more node is better for Zcash network and ecosystem, is it why I run it for years. But please don’t ask to much. If community think it’s a fair price it’s OK go for it.
I just wanted to say that the community appreciates the services that you have been running for quite some time.
Speaking personally (not for ZOMG) if you and others maintain services that benefit the Zcash ecosystem I support reimbursing maintainers of such services for reasonable expenses.
I also think that $ 13,000 is too much, although I myself have not done such work, but I think that for just such a service on an ongoing basis, a good contractor is needed who, under a contract, will be able to make much longer support for that kind of money, because 3 months in too little anyway and too expensive to continue next year. It would be nice to hear an offer from the market for such services, does the fund have the opportunity to pick up options?