Complete Zaino!

Community Grants Applications
1

Zingoistas are upgrading and extending core Zcash infrastructure to a state of the art secure Rust implementation.

In order to complete the Zaino project, we’re asking the ZCG to support that work via a grant.

Copied here for ease of review:

Terms and Conditions

Application Owners (@Octocat, @Octocat1)

Organization Name

Zingo Labs

How did you learn about Zcash Community Grants

I was involved in the design discussions.

Requested Grant Amount (USD)

$151,240.00

Category

Infrastructure

Project Lead

Name: Za Wil
Role: Zingo Labs Coordinator
Background:  I am a long time hacktivist in the Zcash Community
Responsibilities: I provide an interface to other organizations when a Zingo Lab needs one, that's not otherwise available.  I represent the internal discussions of Zingoistas publicly when I am asked to do so.

Additional Team Members

- Name:  Undisclosed
   Role:  Zcasher
   Background:  Undisclosed
   Responsibilities: Various

We provide internal details to members of the ZCG on request.  In order to maximize inclusivity we do not disclose member information.

Project Summary

The Zaino project decentralizes critical Zcash infrastructure bringing diverse stakeholders in to grow the economy. This proposal would fund development, test, and deployment of core Zcash “Zaino” nodes, and “Zaino” APIs.

Project Description

Over a scheduled period of about 3 months, Zingoistas will implement many RPCs needed for core Zcash infrastructure to properly function.

Proposed Problem

The current implementation of the Zcash protocol is increasingly out-of-date with modern programming practices and paradigms. In particular it is implemented in a legacy programming language (C++) that significantly, perhaps radically, slows development.

Proposed Solution

In concert with other core Zcash teams Zingoistas are working to upgrade and replace all components of the original Zcash implementation with modern state of the art technologies (in particular Rust).

Solution Format

Zingoistas will implement core functionality (RPCs) in Rust. Preference will be given to block explorer RPCs, where feasible, to enable a rapid-rollout of User-facing functionality. This will facilitate outreach efforts by providing working examples built on the new stack.
The architecture of the Zaino was created with mixnet support in mind, this will make migrating to Nym for network privacy relatively easy.

Dependencies

We are in close collaboration with the ECC, the ZF, SL, and the Blockchain Commons.

Technical Approach

We use the tools and procedures that are standard across the Rust ecosystem.

Upstream Merge Opportunities

We are actively engaged in review, test, and contribution to codebases maintained by the Blockchain Commins, the ECC, and the ZF. It’s likely we’ll have similar patterns of cooperation with SL.

Hardware/Software Costs (USD)

$17,200.00

Hardware/Software Justification

Developers need privacy oriented, capable laptops and mobile devices.
We will test all F-Droid published Zcash wallets against each version of Zaino.

We budget $4300.00 per laptop/phone combination.

We schedule 4 Zaino developers.

Service Costs (USD)

$6440.00

Service Costs Justification

Two years of Github Enterprise for CI efficiency. 24 months * $210/month for 10 seats = $5040
Two years of Gitlab Premium $700/year * years = $1400

Compensation Costs (USD)

$127,600.00

Compensation Costs Justification

$110/hour developers
4 devs full time
3 months

Total Budget (USD)

$127,600.00 + $17,200.00 + $6,440.00 = $151,240.00

Previous Funding

Yes

Previous Funding Details

The current Zaino Grant.

Other Funding Sources

No

Other Funding Sources Details

No response

Implementation Risks

Failure to receive funding in a timely manner. Failure to coordinate with partners.

Potential Side Effects

There’s always the possibility of unforeseen downsides to Rust.

As mentioned before and elsewhere, this project and partners aims to upon completion decrease the number of node implementations from zcashd/lightwalletd and zebrad/zainod to just zebrad/zainod. This is a reduction in diversity, and therefore potentially resilience.

Success Metrics

The Zcash economy runs over Z3 (and therefore Zaino).

Startup Funding (USD)

$0

Startup Funding Justification

N/A

Milestone Details

Milestone 1: Zcashd RPC Replacement

  • Amount (USD): $70,400
  • Expected Completion Date: ~ 6 weeks
  • Deliverables:
    • Implement new RPCs using both JsonRPC and ReadStateService backends (Low priority not included in current roadmap):
    • Debug [3 weeks]

Milestone 2: Updated Zcash RPC spec.

  • Amount (USD): $57,200
  • Expected Completion Date: ~ 6 weeks
  • Deliverables:
    • New wallet indexes to zaino
      • Add transparent tx data to compact blocks. [2 weeks]
      • Add transparent outpoint to tx RPC. [2 weeks]
      • Debugging. [1 week]
      • $22,000 (5 dev weeks - $110/h)
    • Update Zcash RPC spec and add tonic (gRPC) backend to Zaino
      • Replace LibrustZcash’s CompactTxStreamer with a new IndexerRpcService that encapsulates the complete set of RPCs served by Zaino
      • update duplicate / deprecated services. [6 weeks]
      • Add Tonic Backend to Zaino’s IndexerService to enable light wallets to use Zaino’s integrated chain fetch services. [2 weeks]
      • Debugging [1 week]
      • $35,200 (8 dev weeks - $110/h)
11 Likes
2

This may be a typo but where does the $142,040.00 come from?

Also which devices are you getting for the team, those prices seem high for dev work?

Thank you

3

Sorry, you’re correct that total was wrong. Fixed.

1 Like
4
How we calculated hardware costs:

For a Pixel 9 Fold with 512GB of storage I have a price point of $1,919.00. That’s the most expensive possible model on the market (that I am aware of).

Assuming shipping and taxes, I rounded the mobile device price to $2000.00.

For a Framework 16 laptop with 96 GB RAM, I have a price point of ~ $2,300.00.

That totaled to $4300.00 per developer.

There are 4 Zaino-focused developers who required hardware upgrades.

4*$4,300.00 = $17,200.00

Do developers need top-end equipment?

Yes absolutely.

Top end is faster, and more reliable (usually) and developer time is precious.

Lower end at the developer-interface is decreased development velocity.

Moreover, Zcash developers need the security properties that come from the Framework series (e.g. the ability to physically remove the WiFi card..), and they need to be able to sanity check assertions locally to verify that remote services are behaving as expected.

In other words, powerful developer devices decentralize trust.

For frame of reference, I have a top-end Apple Laptop price point at $4,249.00 by itself. And such a laptop does not permit its User to control the hardware components it is composed of.

Do we need all those fancy phones?

No, not really. We probably don’t need 4 absolute top-end Pixel devices.

We do need at least 2, in order to test against them and between them.

Beyond those two, we need a range of Pixel mobile devices ideally two of each that are common in the marketplace. More realistically our test coverage will be sparse relative to that with a few (hopefully) representative devices.

Do we need end User testing to validate that Zaino is properly supporting the Zcash ecosystem?

Yes.

Should we be focusing on supporting the remarkable

Wallet (at least Zashi) <--> F-Droid <--> GrapheneOS <--> unlocked Pixel

stack.

YES

5 Likes
5

Appreciate the details and your thoughts. I would like to point out its important that devs test on lesser hardware too, because most folks in the world run that.

I support your team and hope we can get Z3 ready for lift off.

5 Likes
6

I completely agree, and in fact we will be testing against the most common devices.

That is to say in all probability our mobile device equipment budget will be largely allocated to less powerful devices, but we need the option to sample the top.

In practice, we’ll be purchasing incrementally, adapting to findings from User reports and our existing test history.

I think it’s very likely that a significant Zcash User base will invest in top-end devices, and we would like to have proven functionality in that space as well.

3 Likes
7

Documenting while the fire is hot.

In both milestones it would be great to see a small slice of time focused on the thinking behind these important steps. One of the goals is to increase usability for current but more importantly future developers to pick up from a cold start, understanding something of a reference point could be great.
Pushing a bit more, having a fire side chat among zaino, zallet, zebra developers could be enlightening.

Good luck!

4 Likes
8

Fireside chat sounds great to me!

A lot of conversations in flight have me thinking that we need to prioritize explaining what Zaino is (and is not), more clearly.

Amended: The Zaino devs don’t have time for a chat right now, but see the next message about the planning call…

The best place for a chat is the would be the weekly Zcash Z3 call. Zaino is The Z In the Middle of Z3!

3 Likes
10

I’ve amended the rationale for the CI-backing services budget on Github.

It was always intended to accelerate our test runs, we need budget to do that, but precisely how depends on a few variables.

The current price tag $5040 would get about 1 day of high-speed test-infrastructure, per month for about 13 months, from github.

If we can find competitive offerings from other providers, we’ll allocate that money to that provider (for example @emersonian ). Our intention (and @emersonian 's, I presume) is to get the best/fastest tests for Zaino that we can.

Please review this post to see the current the amended rationale:

1 Like
11

Hey,

I wanted to add a little context as to why I think this work is:

(A) important for the completion of Z3, AND
(B) different to the work set out in the initial Zaino dev grant."

The extension grant we are proposing centres around 2 goals, both important for a reliable and user friendly Z3.

Zcashd RPC replacement:
We have started this work in the current Zaino dev grant, however the number of RPCs that are required was unknown at that point and our initial research centred around the Zcash RPC services required for wallet (in particular lightwallet) functionality. We are currently working with the ECC to implement the remaining functionality required for Zallet (and other “full node” wallets).

We did set time aside for unplanned functionality in the current grant (3 weeks dev time), but it is now clear that it is not possible to complete all the work necessary to fully support block explorers and exchanges in the allotted time. During planning the engineering teams have suggested that full support of these use cases is top priority, and should not be deferred.

We made the decision that it would make more sense to use the extra time in the current grant to switch Json RPC libraries to have parity with Zebra and Zallet (Reqwest → JsonRpSee) and to add the Json RPC server required to serve these RPCs (originally we had planned to only serve gRPC). Although this leaves the unplanned RPCs for the continuation grant it means we have all the functionality in place to quickly add new RPCs as required.

Updated Zcash PRC spec:
The current Zcash RPC spec is both confusing and non-optimal. The biggest source of confusion is that there are currently 2 RPC specs (the Zcash RPC Interface and the lightwallet CompactTxStreamer), that are on the surface very similar but hold subtle differences that have caused confusion even among experienced wallet devs. This, along with redundant RPCs (eg. get_block), confusing names (eg. get_taddress_txids) and even RPCs that can introduce bugs (see conversation relating to get_mempool_stream in [Issues encountered while integrating Zaino into Zallet · Issue #249 · zingolabs/zaino · GitHub] for one exmple), is a big barrier to entry for anyone wanting to integrate with Zcash.

We want to update this spec to a single set of gRPC services that are easy to understand and are robust in design. We would continue to serve the current zcash RPC specs for an extended deprecation period (~2 years?), and could even keep on maintaining them beyond then if a backward compatibility option is desired.

While updating the current spec we also plan to add several new RPCs that have been discussed (eg. and RPC serving a transparent outpoint to tx index). This will also tie into work on crosslink, as I believe the current plan is to only use gRPC (the current Zcash RPC spec is only implemented for Json RPC).

9 Likes
12

@zancas at the most recent meeting, the @ZcashGrants Committee voted to approve this proposal. Congratulations!

ZCG requests that you provide monthly updates via the forum in this thread.

9 Likes