Zaino Respecification, No Delays

Community Grants Applications
1

Parallel Efforts

As noted here significant new architecture is required for Zaino to optimally support Zallet.

Zingo Labs has allocated full time attention of lead Zaino developers to ensure that the updated architecture is implemented immediately.

Meanwhile we have onboarded more developers to begin work on the already planned Complete Zaino! grant.

Onward, Without Delay

This new request for funding our rearchitecting work is necessary to fund this expanded effort, and ensure that @str4d 's implementation of Zallet won’t be delayed by Zaino.

5 Likes
2

Application Owners

Organization Name

Zingo Labs

How did you learn about Zcash Community Grants

I was involved in the design discussions.

Requested Grant Amount (USD)

$54,560.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

Unanticipated architectural requirements have emerged.

To rearchitect to meet these requirements, with minimal impact on the Zaino continuation schedule we are allocating more development resources to Zaino. We need funding to cover these costs.

Project Description

We are rewriting a significant portion of the core Zaino architecture to meet (re)newed requirements.

Proposed Problem

The earlier draft of Zaino, assumed published zcashd RPC specs were acccurate and their support was sufficient. It’s now clear that that’s not the case.

Proposed Solution

Define a implement an authoritative, and test spec that is sufficient, and matches the new Zaino implementation.

Solution Format

Running, tested, provisioned, open source Rust and supporting documentation and community.

Dependencies

Collaborations with the ECC, and the ZF.

Technical Approach

Our approach will be identical to that taken in all the Zaino effort.

Upstream Merge Opportunities

We contribute code, ideas, docs, etc. to the upstream projects.

Hardware/Software Costs (USD)

0

Hardware/Software Justification

NA

Service Costs (USD)

0

Service Costs Justification

NA

Compensation Costs (USD)

$54,560.00

Compensation Costs Justification

Two lead developers working full time for 5 weeks.

$110/hour * 40 hours/week * 5 weeks * 2 developers

Total Budget (USD)

$54,560.00

Previous Funding

Yes

Previous Funding Details

One complete and one approved and to be scheduled, this week.

Other Funding Sources

No

Other Funding Sources Details

No response

Implementation Risks

Inadequate consensus from the community could cause unexpected reimplementations.

Potential Side Effects

Zcash is ever more locked into Rust.

Success Metrics

Zaino elegantly supports Zallet.

Startup Funding (USD)

0

Startup Funding Justification

NA

Milestone Details

  • Milestone: 1

    • Amount (USD): $54,560.00
    • Expected Completion Date: 2025-07-01

  • Deliverables:

    • The core architecture of Zaino is intuitive to ECC and ZF developers, and supports clean separations of concerns in critical software design and security dimensions.
    • The running implementation of Zaino (as a library) correctly supports Zallet operations, according to best practices.
3 Likes
3

The original cache design we implemented for zaino was reliant on assumptions that we made when zaino was still scoped to be a lightwalletd replacement. The scope of zaino grew considerably before our local cache implementation began, but the difference between what lightwallets need and what full node wallets need was not fully understood until closer collaboration with the ECC brought it to to light.
To this end, we are designing a new cache, with the following requirements:

  • Cache sidechain blocks, instead of only maintaining a copy of the best chain.
  • Track all chaintips, with special handling for whichever one is currently the ‘best’ tip.
  • Ensure each consumer can get a self-consistent view of cached state, even if a reorg occurs mid-request.*
    • This includes the ability to chain together multiple api calls, which all look at a consistent view of cached state, while we allow zaino to continue to sync new blocks during this process.
  • Handle many more fields and data types, in order to better serve consumers other than lightclients.
  • Structure fields of zaino data types to specify if they are needed for building queries, or stored to avoid making queries to the backend for frequently-needed data.
    • This is also a precursor to future work, in that it will enable us to adapt how much data is cached. future options include:
      • removing all optional data to minimize disk usage
      • caching more fields for faster service when validator bandwidth is a concern (at the cost of more disk use)
      • caching more or less data depending on what the zaino instance is expected to be serving

*This is currently already somewhat supported, by removing some of the incorrect ‘optimizations’ our cache was relying on, but it is nonetheless another incentive to redesign our cache. (See `zaino-state` is vulnerable to state corruption during reorgs · Issue #295 · zingolabs/zaino · GitHub for the original issue)

8 Likes
4

As noted here we have pushed our delivery date back to July 8th.

ECC and Zaino engineers have had begun regular meetings that have already resulted in substantial improvements to the design.

This collaboration is substantially expanding the core infrastructure knowledge base, I’m excited about it.

7 Likes
5

And we’re increasing our ask to cover the costs of the additional development, for automating the acceptance criteria, which we view as essential to reliable infrastructure, going forward.

The increased cost as indicated in the github grant is:

$10_560.00

6

@zancas, ZCG voted async to approve this proposal. Congratulations!

Please check your forum inbox for a direct message from us with important next steps, including a link to the Milestone Payment Request Form and your unique validation code for submitting payment requests

4 Likes