lightwalletd.com is funded as the public deployment for all Zcash light clients, not only for Nighthawk Apps. Our vision has materialized and several projects(searchable on GitHub/GitLab) have adopted our Infura-like public facing service.
The goal of this grant is to make available Zcash infrastructure as a test-net sandbox for new developers and stable main-net infrastructure for existing applications like Nighthawk Wallet and Zbay. This goal is in line with ZF’s mission of enabling R&D and community involvement while opening up access to Zcash blockchain to other cryptocurrencies and oracles. This operation will serve the Zcash light wallet and services users.
Additionally, lightwalletd.com operators are non-US based and have multiple redundant infra available in various jurisdictions, the team members are available round the clock(living in opposite sides of the world).
I support further decentralization, I like zebrad’s approach of including lightwalletd RPC functionality within the node. I would like to see development of zebrad node, to allow operators to open up the capability for light clients to search and connect to the nearest reachable node.
When I said “Infura” I was meaning a hosted multi-tenant PaaS offering with private endpoints and tiered pricing for different SLA requirements. The users i’m thinking of is someone wanting to have their own private nodes without the burden of managing the backend. Lightwalletd is great for light wallets, light wallets are ok for users. They are not the endgame for all people wanting to run nodes.
Sure more business will be incentivized to provide private node services to Zcash clients, especially with the public launch of ZSAs and extended Zcash network use cases.
For now, having block rewards that fund decentralized teams contributing to Zcash is a big win over parties that are against the interests of their users:
It is a different customer base. It is not a choice between having public open api end points and companies offering blockchain as a service to paying customers.
I don’t think that a most wallet users would willingly pay for an api endpoint. In fact, I don’t think most care about how nodes or networks or wallets work. Funding these out of the block tax makes sense for now because it is a public good until something more decentralized comes along. I would hope that request logging wouldn’t happen because it would be a waste of time, money and is a nightmare with gdpr.
I would pay for a BaaS so I have an api key so only I can access the endpoint. I know my addresses and ip address. For power users and developers having a service to securely host nodes that have restricted access is ideal. When things like staking and high use applications come along, uptime will be king. Businesses cant have their service go down because there is a power outage in their area. They also don’t want to spend the time and resources learning which version they should be running or what size ram they should use because they really want to focus on what ever their real business is.
I don’t use either today because I don’t have uptime requirements and don’t mind running a server at home. Cost/Benefit is different for everyone. I don’t like using endpoints I don’t control and I don’t want to pay for more cloud storage when I can run what I need myself.
Following the deployment of ZIP-317 with zcashd v5.5.0, the new fee structure is introduced, but will not be enforced strictly(as in blocking the transactions that do not conform to the new conventional transaction fees). This is to prevent sudden breakage of all software/hardware wallets, exchange operations, and custom Zcash services, to give time for us to observe(and advocate the upgrade to Zcash service providers) how the new fee structure is adopted by monitoring the transaction fees paid to miners(which are publicly visible on the Zcash chain).
NOTE: The new conventional transaction fee structure does not discriminate against any of the Orchard, Sapling, or transparent protocols.
Once enough % of the ecosystem has adopted the new fee structure, we can deploy zcashd updates toward enforcing the new transaction fees requirement and block nodes from relaying transactions that do not conform.
(Forward-looking statement) 1TB disk requirement would soon(this year) become a recommended specification for running a zcashd node and even higher specs. if running a lightwalletd instance as the heavy load on the network continues.
There are no hard dates for the zcashd v5.5.0 release. There are higher-priority bug fixes that are being worked on which will be released as mandatory upgrades coming next week.
Are these Bugs with the Zcash protocol layer?
Have you got a few minutes to share GitHub links so that people from the forum can track status directly?
I wanted to join the conversation as I took over the Engineering Director role at ECC that Steven previously held. ZIP-317 enablement along with a set of performance enhancements to address the current sync performance is actively being worked on. In taking on this role, I’ve read the comments regarding the high tx load and the arguments on whether it is spam or something else. The proportional fee implementation and enforcement by node operators would at least help to identify if it is indeed someone taking advantage of low fees for large txs. The issue around blockchain size is something we continue to discuss, although the main driver right now is as listed above.
From a node perspective, I am currently running zcashd on a Raspberry Pi 8GB Extreme edition with a USB 3.0 external drive for the chain data. The system is running well, keeping up with the chain growth. That is not to say that the growth is or isn’t a problem, as many have argued both ways. It is definitely something we will evaluate as part of our continuing work to evaluate the scalability of the protocol.
Can you strawman the argument that would claim the rapid blockchain size growth is not an issue? I’m caught off guard by the fact that anyone could make a case that it isn’t a (severe, if allowed to persist for a long duration) problem - regardless of whether the data is spam or not.
There is an option to run zcashd node pruned, i’ve never done it but i suppose i could try and let you know how much memory takes up, gonna take a little while to reindex. As far as like shrinking the block chain I have no idea how they would do that.
I’m not sure blockchain growth can be considered “out of control” when it’s functioning within the scalability limits, ~75 seconds between blocks + 2MB max block size, governing the network.
The short term issues are the implications of the tx load requiring things like the use of filters for lightwallets and lightwalletd, deterring full node adoption by individuals and businesses, rendering virtually non-functional the mobile wallet SDK, etc
And the long term issues are increasing scalability through methods like a fee market for txs, raising the block size limit or increasing block frequency, pruning and/or sharding of the blockchain while maintaining full wallet functionality, lowering the computational cost of creating and verifying txs, lowering shielded tx size, etc
A possible open question is what is the nature of the so called spam transactions? Are they merely an attempt to bloat the size of the chain and induce the outlined issues or are there other motives?
I use the term out of control to describe the rate and duration of this blockchain size phenomena because of the undisputable impacts that have been created by it that are negatively affecting Zcash’s decentralization (network nodes are dropping offline/ out of sync), its wallets (also having usability and sync issues), there is a negative impact on the Zcash brand, and the development teams who have been pulled off of other planned work to do mitigation efforts for a fix (none of this mitigation work was on the 2022-2023 roadmap). I’d call it controlled if the same rate and duration were happening but there wasn’t correlative damage to the Zcash ecosystem.
These issues aren’t short term anymore, the spam attack has been persistent for almost 9 calendar months. This was a short term issue if it was identified and resolved in a few months. The long term issues to retaining a bloated blockchain won’t be known until we get there in let’s say 3-5 years or beyond (your list is a set of feature ideas).
I’ve taken a slightly different view of the increased load on-chain. Regardless of whether the transactions are spam, legitimate commerce or some combination of them, the protocol today allows for those transactions to occur at a very low cost. Proportional fees would increase the price of higher output/action transactions, making it less likely (but not impossible) that the higher transaction load will slow down. But let’s say for arguments sake that ZEC adoption doubled in the coming months and the number of transactions that were typical pre-NU5 also doubled. We would be in the same type of situation with chain growth.
If you look at the current growth, I would argue “out of control” suggests a non-linear or otherwise exponential growth rate. While the slope of the growth has increased due to more transactions and thus a higher percentage of filled blocks, the overall growth rate appears to be stabilizing.
From a node perspective, the current 5.4.0 zcashd node software keeps up with this growth. I run two different nodes, the least powerful is on a Raspberry Pi with 8GB of RAM and a USB3.0 external hard drive and have had no issues. Regarding the wallets, that’s a different story for a variety of reasons, which is why we are continuing to work on delivering a sync capability and fund availability feature to reduce the need for wallets (other than node-linked wallets) to sync the entire chain.
We’re talking beside each other. That chart (Zcash all-time blockchain size) is a non-linear chart. I’m not interested in going back and forth about this because we are clearly doing gymnastics with words and perceptions of reality, I understand that ECC intentions are just! Godspeed on your efforts to reach a sustainable implementation with the fee market.
Are any of you tracking the blockchain daily size increase post-fix? Have we got demonstrable evidence that the spam attack is subsiding? The chart visualized on Blockchair doesn’t precisely show the daily sizes committed to Zcash each day.
