"Yes, chef!" - ECC Weekly Update for April 19

[Cris83]

This spells some doom.

[ZcashRabbi]

ECC kitchen & ZF kitchen I got this on repeat thinking about you right now (even the red & yellow/black colours in the vid reminds me of ECC & ZF lol). When it’s all said and done, we’ll still be here rooting for you. Because you’re our last hope. It’s that simple.

Al Pacino best speech - Any Given Sunday - 1080p HD

[Dodger]

@earthrise

…a lack of trust and collective vision.

I feel like these words hit the nail on the head.

There is definitely a lack of trust, and it doesn’t feel like we have a shared vision for how to take Zcash forward.

[pkr]

Why can’t ECC and Zfnd merge into one?

[cryptomuncher]

Maybe it’s time to seriously consider letting the current dev fund expire completely. Let the orgs figure out alternate sources of funding or let the ecosystem build out the same way other tokens do.

[joshs]

I agree with you, @earthrise and @Dodger, that trust is at the heart of it and continues to fester year after year. While it is not easily fixed, we should be able to move forward through mutual respect and civility, which should be expected. We rebuild trust together.

As for a common vision and roadmap, we have some things in common across the Zcash community, such as privacy being sacrosanct. On other things, different people and teams may not see eye to eye completely. It’s the nature of decentralization and good for the project to recognize where different community participants diverge.

Since Jan 1, ECC has worked to provide clarity on our vision and intended Zcash community contribution. We held Zeboot and invited the community to help design our roadmap, with the next Z|ECC summit scheduled for July. We publish a revised roadmap every quarter and I provide weekly updates on our progress against that roadmap. We also pay attention to others’ roadmaps and weave those things into our planning (e.g., FROST from ZF and Maya integration from Hahn). I understand not everyone will agree with our mission to bring a full-stack “new system…” to Zcash, or how we think we should get there, but I believe what we are building is well aligned with the outcomes we all want to see.

The Zcash Foundation has different perspectives, communication methods, and rhythms. No one but its board of directors and Dodger has the authority to decide on its perspectives or paths. It determines what it thinks is best in its own way and communicates its roadmap and commitments to the community in its own way. I respect their sovereignty.

As @daira mentioned, the ECC team members get along well with the ZF team members. Their interactions are friendly, collaborative, respectful, and fruitful. While not always, there are times when teams have a common priority and it is mutually beneficial to work collectively, as with the transition from zcashd to zebrad. We may have different perspectives on what it will take or how best to get there, but it’s my opinion that these are specifics best left to the teams (engineering, comms, etc.) to work out with one another.

I believe that’s how we can best contribute to a decentralized protocol, with health, and togetherness.

[skyl]

@daira

it is a high priority for us to talk to the major exchanges, mining pools, etc.

I use a few zcashd RPC calls via Python. I imagine that exchanges do something similar to what I do (except they only care about transparent and I only care about shielded, for one difference). I think an incompatible replacement for the RPC/CLI could be acceptable to them - if it’s an obvious improvement and “we” provided help to make the change up to and including directly helping their engineers change the code. “Compatible” is not a requirement for me and I imagine other clients could also accept an incompatible change given ample support.

I’d vote for a clean overhaul then. We should try to supply a minimal definition. One problem with the current RPC interface is that it seems to be bloated with a bunch of semi-deprecated legacy calls and it’s hard to tell what is supported/favored and what isn’t. It’s confusing. A new slimmed-down, minimal definition of favored calls should support auto-generating (typed) clients in popular languages. That would be RAD! As a stretch/future goal, it would be awesome to have more of an event-driven, pubsub-like interface where some program running with the node could listen for events instead of polling the state.

Thinking in the long-term, it would be better to deprecate the existing interfaces and build something modern and awesome. There are only 100-something node operators; so, even if “we” had to manually go in and change the code for each of these operators, that would be better for the long-term health of the project than shimming in some legacy garbage to save each of the hundred node operators an hour or two.

In my original comment, emphasis should be on “minimal” rather than “compatible” …

Let me know if I can help - part of the idea of free2z is that it is a hypothetical/ideal customer for Zcash products and that the learnings can be generalized and applied to other ventures.

I started this:

Python Zcash RPC Client

I didn’t fill it out because it would be too manual to maintain (should be more like swagger/openAPI to generate clients in any language) and the supported/favored call landscape seemed to be shifting. One end goal of an RPC / node wallet overhaul should be import zebra or import zcash (or whatever) in every language.

[noamchom]

@skyl

There are only 100-something node operators; so, even if “we” had to manually go in and change the code for each of these operators, that would be better for the long-term health of the project than shimming in some legacy garbage to save each of the hundred node operators an hour or two.

Based on info from Blockchair, there are probably fewer than ~70 full nodes running near the highest block height.

Is anyone aware of a better site for tracking Zcash full nodes info?

[Cris83]

Good point. I have node idea where to get better info

[daira]

@conradoplg

Who builds the core protocol? What do you mean? The actual protocol ? Check the authors: do you see any ZF people in there?

I agree with your point that ZF doesn’t “build the core protocol” and that @pkr’s argument is not valid. But lest we fail to correctly attribute credit, the authors of the Zcash protocol spec do not include all of the designers of the Zcash protocol, and the latter does include people who have worked or currently work for ZF. For example, @Dodger is credited as a co-designer of Sapling.

(I notice @conradoplg that your name is missing from “people to thank” and will be added.)

[daira]

@noamchom

Based on info from Blockchair, there are probably fewer than ~70 full nodes running near the highest block height.

@str4d’s seeder shows 100 full nodes after the zcashd 5.8.0 EoS (as of 2024-04-24 17:35 UTC):

$ zcseed-counts -c
100
$ zcseed-counts -s
     53 MagicBean:5.9.0
     42 MagicBean:5.8.0
      2 Zebra:1.6.1
      2 Zebra:1.6.0
      1 Zebra:1.5.0

(The 42 “MagicBean:5.8.0” nodes are modified zcashd nodes that have presumably disabled the EoS halt.)

This isn’t published information, though. I agree it would be useful to have a site monitoring the node distribution.

[nuttycom]

@skyl

I’d vote for a clean overhaul then. We should try to supply a minimal definition. One problem with the current RPC interface is that it seems to be bloated with a bunch of semi-deprecated legacy calls and it’s hard to tell what is supported/favored and what isn’t. It’s confusing. A new slimmed-down, minimal definition of favored calls should support auto-generating (typed) clients in popular languages.

This is my preferred approach. Since a new, clean RPC API would necessarily support all the required protocol-level transaction operations, it should be possible for someone requiring backward compatibility to achieve it via a wrapper that delegates to the minimal clean API. There are a few corner cases to this related to how funds are grouped into logical spending pools in the wallet, but the zcashd wallet already defines conventions for how the bitcoin-derived approach to logical spending pools relate to the HD key tree, so there is no barrier there.

[Dodger]

@joshs

I agree with you, @earthrise and @Dodger, that trust is at the heart of it and continues to fester year after year. While it is not easily fixed, we should be able to move forward through mutual respect and civility, which should be expected. We rebuild trust together.

So let’s do that! Let’s come together as two teams (separate from the work to deprecate zcashd) and start a conversation about how we can re-establish trust. Let’s confront and acknowledge whatever mistakes we’ve made in the past, identify all the misunderstandings, miscommunications, and mismatched expectations, get everyone on the same page about where we align and where we diverge, and see if we can’t rediscover what unites us!

@joshs

As for a common vision and roadmap, we have some things in common across the Zcash community, such as privacy being sacrosanct. On other things, different people and teams may not see eye to eye completely. It’s the nature of decentralization and good for the project to recognize where different community participants diverge.

… I understand not everyone will agree with our mission to bring a full-stack “new system…” to Zcash, or how we think we should get there, but I believe what we are building is well aligned with the outcomes we all want to see.

I agree that we don’t all need to agree on everything (no pun intended) but would it not make sense to identify where our goals align (or at least where there is no conflict) and where they diverge or, in the worst case, conflict?

At Zcon4, Zooko, Alan, Andrew and I spent most of a day trying to figure out where we could find common ground between the two organisations, and we settled on zcashd deprecation. To be clear, ZF has no selfish interest in seeing zcashd deprecated but we can clearly see how it benefits the Zcash project and ecosystem by retiring legacy code, and freeing up the ECC engineers to improve Zcash instead of paying interest on technical debt.

However, It’s clear that there were mismatched expectations. We need to all be on the same page to avoi that happening again, and that includes both leadership and the technical teams having a shared understanding of what we’re trying to achieve, and where the boundaries lie.

How about it Josh? Shall we start off with a joint all-hands meeting and try to do some truth and reconciliation?

[Dodger]

@daira

… @Dodger is credited as a co-designer of Sapling.

I feel like my contribution was largely moral support, rather than anything meaningful on the technical or cryptographic front, but hopefully this serves as a reminder that we used to be a great team.

[joshs]

Let’s start off with the zcashd deprecation project. Details here. @daira is leading the effort for ECC.

[skyl]

I love the zcashd deprecation project. Another framing is building a fire, modern, best-in-class software stack for the Zcash protocol. I’m not sure how other Zcashers view it. Maybe some roll their eyes because it doesnt speak to them like something they can click on. But, replacing the RPC/wallet with modern Rust alone has huge implications for the potential developer community. I’m part of a large class of potential contributors who would never begin to attempt a pull request into the zcashd repo. But, in the fresh modern stack, I can absolutely envision getting a feel, getting setup to work on it, and making a contribution.

I guess my point is that it is a hugely important change that can really be marketed as such. It’s not just “ho hum, shuffling code around to get back to where we started.” I’m not under any illusions that it can be fast or easy. Narrative-wise, PR-wise, if everything gets cutover by early 2025, it shouldn’t be, “the Zcash orgs did so little,” “NU6 was small, nothing-burger,” “why dont the devs do something.” It should be more like, “HOLY ****ING ****, LOOK AT HOW INCREDIBLE THIS CODEBASE IS!” It could be the key to increasing the node count and the developer community by an order of magnitude or more and should be marketed as such.

[zerodartz]

what is everyones thoughts on maybe having a small payments to active nodes? just like miners but not every block but more like daily/weekly/monthly (1 of those) payments.

it could improve the decentralisation by having more active nodes by incentivising with shielded ZEC payed to node owners. it wouldnt have to be a big amount i guess. but anything more than 0 would be great imo.

[ZcashRabbi]

Josh and Dodger putting their differences aside and coming together is up there with a Kobe & Shaq reunion (guaranteed championship calibre stuff).

Make it happen gents don’t worry about us, the devs deserve it.

[pkr]

Remind me why we’re glorifying what should be common business decency between two linked organizations?

And why right around the discussion for the dev fund renewal is around the corner?

[Dodger]

@zkcroc

…there is almost NO engagement by ZF to the community forum…

What sort of engagement would you like to see from ZF?