ZCash UniFFI Library (RFP)

ZCash Grant Proposal

  • Project Name: ZCash UniFFI Library
  • Team Name: Eiger
  • Payment Address: zs108p8akldldngn43yjrelskxpajlg4ca9mss8pn3h9ejf8ytz3p7m39hzjsqn0rcqvtkac3r58k8
  • RFP URL: RFP - Zcash UniFFI Library

Project Overview

Currently, the barrier to entry for building apps on Zcash is too high. There is a need to extend interfaces in popular languages such as Python, Swift, Kotlin, and Ruby to allow developers to rely on Zcash’s underlying cryptography without rewriting the code. The extension will be done using Mozilla’s UniFFI, a toolkit for building cross-platform software components in Rust, which currently supports the four platforms mentioned above.

High-Level Requirements

  • The code MUST interface with the librustzcash library’s functions.
  • The code MUST respect best practices, such as logical division of the code in modules, readability, and maintainability.
  • The code MUST be tested in all requested languages (Kotlin, Swift, Python, and Ruby).
  • Core functions MUST be fully covered by unit tests to ensure functionality and robustness.
  • Core functions SHOULD be sufficiently covered by integration tests
  • The documentation SHOULD make it reasonably easy to use the libraries.
  • The output of the interfaces MUST be fully equivalent to the Zcash Rust library outputs, i.e. the library’s interfaces MUST NOT make any transformation to the content.
  • The delivery period SHOULD be kept inside the time brackets given in the RFP specification (3 months)
  • Each library will be written keeping into consideration the support needed by Sapling, Orchard, and NU5 shielded protocols.
  • The development team MUST collaborate with Zcash core developers
  • The Zcash core developers SHOULD give advisory assistance to the development team.

User Experience

  • Each library MUST be architected to minimize the coupling of interfaces and core implementation.
  • Each library MUST support linux targets. It SHOULD be implemented in a cross-platform way, but full support of other platforms (e.g. Windows, Mac OS, Android) is out of the scope.
  • Each library MUST be sufficiently documented in a way that clarifies the purpose of each public (exposed) function.
  • Each library MUST contain standalone usage and installation instructions for users.
  • Each library code MUST contain inline documentation for current and future developers.
  • Each library MUST contain guidelines for potential contributors to be successful.
  • Each library MUST reflect community standards of the platform to which it belongs.

Functionality

  • Each library MUST be able to give access to Unified Addresses, Sapling and Orchard Z-address, and Transparent T-address and all the related resources.
  • Each library MUST be able to parse eventual hashes and addresses.
  • Each library MUST be up-to-date with all the ZIP accepted by the Zcash community.
  • Each library MUST be well documented.
  • Each library MUST be publicly accessible at all times via package manager or Github.
  • Each library MUST allow developers to create any kind of transaction allowed on the Zcash blockchain.
  • Each library MUST implement a similar structure insofar as each language ecosystem standards allow.

Development Roadmap

Please note that Milestones include writing tests with pre-generated data for each method for every supported platform - Kotlin, Swift, Python, and Ruby, and documentation for every method with emphasis on utilizing Unified Addresses by default. Upon evaluating the milestone completion, the “requirements for evaluation” section should be used for validation. (FTE = Full-Time Equivalent). “Per each language” refers to the supported languages mentioned above - Kotlin, Swift, Python, and Ruby. We are open to any change in the timing or in the scope of the project.

Milestone 1 - Setup

Estimated duration: 1 week

FTE: 3

Costs: $18,000 (120 hours)

Deliverables

  • An upstream version of the last stable version of the Mozilla UniFFI library or a copy of it
  • Test environments for all four proposed languages readily setup (Kotlin, Swift, Python, Ruby)
  • A separate folder for the Rust interface to the UniFFI
  • CI/CD pipeline setup
  • Code conventions in place
  • HTML/PDF Documentation automatically generated
  • Demo test suites
  • Dockerfile to quickly run all test suites
  • License respecting libraries used (MIT license)

Requirements for evaluation

Per each language, the user should be able to:

  • Generate documentation
  • Run demo tests in docker
  • Run demo tests in native environment
  • Create a Pull Request and see it running through the pipeline with all green
  • Understand how to make/compile libraries locally
  • Understand how the team conducts the development work
  • Understand what are the code conventions in place
  • Understand how the code can be licensed

Evaluation Plan

  • Feedback from the community
  • Feedback from the Zcash core developers during the development
  • Feedback from stakeholders will be provided once the milestone is delivered and/or presented

Milestone 2 - Keys handling

Estimated duration: 2 weeks

FTE: 3

Costs: $36,000 (240 hours)

Deliverables

  • Obtain Spending key for UA, Sapling Z-address, Orchard Z-address, and Transparent T-address private keys.
  • Obtain Incoming Viewing key (for UAs, Sapling, and Orchard) from spending key
  • Obtain Full Viewing key (for UAs, Sapling, and Orchard)
  • Obtain Outgoing Viewing key (for UAs, Sapling, and Orchard)

Requirements for evaluation

Per each language, the user should be able to:

  • Create a new private key
  • Derive a new spending key (SK) from a private key
  • Derive an incoming viewing (NVK) key from a spending key
  • Derive a full viewing key (FVK) from a spending key
  • Derive an outgoing viewing key (OVK) from a spending key

Evaluation Plan

  • Feedback from the community
  • Feedback from the Zcash core developers during the development
  • Feedback from stakeholders will be provided once the milestone is delivered and/or presented

Milestone 3 - Addresses, ZIP-313, ZIP-321, Payment disclosures

Estimated duration: 4 weeks

FTE: 3

Costs: $72,000 (480 hours)

Deliverables

  • Parsing, validation, and production of addresses
  • HD (Hierarchical Deterministic) key management (ZIP-32)
  • integrity verification for Payment request URIs (ZIP-321, ref. implementation)
  • integrity verification for Payment disclosure
  • Get a fee rate, which will be a flat 1000 ZAT according to ZIP-313, keeping in mind that there could be some change including fee dependency on the payload, like ZIP-317.

Requirements for evaluation

Per each language, the user should be able to:

  • Create a new Account
  • Create a new Unified Address from an Account
  • Parse and validate a Unified Address
  • Parse and validate a Sapling Z-address
  • Parse and validate a Transparent T-address
  • Get Unified Address from Z- or T- address
  • Parse and validate Payment disclosures
  • Verify Payment disclosures
  • Parse Payment requests
  • Produce Payment requests
  • Get a fee rate

Evaluation Plan

  • Feedback from the community
  • Feedback from the Zcash core developers during the development
  • Feedback from stakeholders will be provided once the milestone is delivered and/or presented

Milestone 4 - Transactions

Estimated duration: 3 weeks

FTE: 3

Costs: $54,000 (360 hours)

Deliverables

  • Transactions broadcasting
  • Transactions generation: sending ZEC notes from/to UA, Sapling/Orchard Z-address, and Transparent address (by providing an input of notes to spend from).
  • Transaction struct definition

Requirements for evaluation

Per each language, the user should be able to:

  • Correctly produce a raw transaction
  • Encode a transaction to binary/string
  • Decode a transaction from binary/string
  • Sign a transaction
  • Broadcast a transaction
  • Explore the internal structure of a transaction (using structs or the equivalent in the given language)

Evaluation Plan

  • Feedback from the community
  • Feedback from the Zcash core developers during the development
  • Feedback from stakeholders will be provided once the milestone is delivered and/or presented

Milestone 5 - Tutorials & testing tools

Estimated duration: 2 weeks

FTE: 3

Costs: $36,000 (240 hours)

Deliverables

  • Basic testing tools
  • Tutorials on how to use each language library, taking into account the standards used in each ecosystem.

Requirements for evaluation

Per each language, the user should be able to:

  • Read and understand tutorials (in English language) taking into patterns of functionality practiced by the single community
  • Write tests to assert address format correctness
  • Write tests to assert transaction data correctness

Tutorials should at least cover, per each language:

  • Generate the private key and derive the other keys with a step-by-step approach (answer to why do we generate this key?)
  • Build and broadcast a transaction
  • Wallet handling

Evaluation Plan

  • Feedback from the community
  • Feedback from the Zcash core developers during the development
  • Feedback from stakeholders will be provided once the milestone is delivered and/or presented

Summary

Estimated duration: 3 months (12 weeks)

Total costs: $216,000

Risks and Mitigations

Severity Likelihood Risk Mitigation
Low High Throughout the design of the test plan stub, we will invariably have questions for the core development team, particularly team members that were involved in the networking aspects of the code. If the team members are busy, estranged, or otherwise unavailable then this could be more work. The mitigation here is to Accept this risk, and fall back to practices such as reading existing OSS code in the absence of human interactions.
Low Medium All programming languages are different and have features and caveats that are specific to them. This leads to the outcome that implementation in some languages may be easier than others. Examples of this are features such as support for asynchronous operations, as well as cryptographic primitives. Since modifying the programming languages themselves is both time-consuming and far out of the scope of this grant, this risk must be accepted and worked through when possible.
Medium Low Since the goal is full parity with the existing librustzcash library output, we assume that this output is generally correct and free of flaws. If this is not the case, then we risk copying these flaws to the other language implementations. It would be good to double check all output in the existing code against expectations and existing test suites, just to ensure that the output is as expected.

Team

About Eiger

The promise of web3 is to upgrade the very foundations of our society – from money, finance, and governance to media, gaming, and science. To deliver on that promise, decentralized technologies are to be integrated into the everyday experiences of billions of people. For engineering, this is a mountain of a challenge.

Eiger was founded to develop infrastructure for web3 mass adoption. We help technology companies improve and integrate the core technologies of web3 to meet the climbing demands for scale and performance.

We currently employ 25+ senior web3 engineers across the globe and work with some of the most ambitious organizations in the industry, including Forte, Aleo, and XRP Labs, to name a few.

Eiger is part of Equilibrium Group, a blockchain powerhouse founded in 2018, composed of three entities:

  • Eiger – high-value add engineering services
  • Equilibrium – applied research, proprietary products, and investing in early-stage ventures
  • Membrane Finance – infrastructure and services for EUROe, a euro-backed stablecoin

Team members

Development members

Łukasz Wojtów (GitHub, LinkedIn) is a Software Engineer at Eiger. He has many years of experience building large-scale, performant systems. During his career, he’s been involved in a broad range of work: networking, security, OS kernels, backend, and frontend. At Eiger, he specializes in reverse-engineering p2p protocols.

Luca Campobasso (GitHub, LinkedIn) is a Software Engineer at Eiger. He has extensive experience with functional languages (7 years), especially with Scala and Elixir, mostly focused on backend systems design. Luca has participated in Exercism as a student and mentor in several tracks (including Kotlin track). He also has experience with Kotlin development on Android.

Marko Sabec (GitHub, LinkedIn) is a Software Engineer at Eiger. He has around 15 years of experience with DevOps, full stack development, and smart contracts, with a focus on security. During his career he’s been involved in a multitude of roles (DevOps Engineer, Software Engineer, CTO) and projects involving networking, security, and backend design. As for used languages, he specializes in Rust, Golang, and Python.

Advising members

Niklas Long (GitHub, LinkedIn) deeply cares about open source, distributed systems and data privacy. He has been on the Aleo Core Team since late 2020, mostly overhauling, testing and profiling their network; he is the author of Ziggurat and an active contributor to Rust IPFS.

Mark Henderson (GitHub, Twitter) is the VP of Engineering at Equilibrium. He has led the team starting with the original Rust IPFS grant in late 2019, through engagements with many of the largest names in Web3, and is now circling back to finish the critical work the team started with the original Ziggurat proposal. Core contributor to OrbitDB, Rust IPFS, and Ziggurat.

Future Plans

Once the library is delivered, we hope to continue maintaining the library by working on some further performance improvements. These could be based on our own ideas during the implementation as well as on community feedback. In addition, we’d like to explore the possibility of helping expand the Zcash core library and consequently the interface language. We also look forward to long-term cooperation in the form of a maintenance grant, as mentioned in the RFP.

Additional Information

Why Zcash?

Equilibrium/Eiger believes that Zcash is exceptional for the following reasons:

  • Well-maintained ecosystem, with exceptional developers guiding its evolution
  • Privacy-centered blockchain infrastructure
  • Structured roadmap, well-defined steps based on a precise plan.
  • Built on the most widely accepted and used blockchain, bitcoin, but heavily improved with the last 20 years of research and development.
  • Low fees, especially compared to Ethereum or Bitcoin.
  • Zcash has implemented a number of features, such as access control with keys without smart contracts, that prove that contracts and EVM-interoperability are not the only way forward.
  • It has a highly active community full of ideas and people ready to help. There is active encouragement to vote and participate in decision-making.

Privacy

Zcash gives you the choice to make transparent, semi-transparent (or semi-shielded), or shielded transactions, and it is an essential part of the crypto ecosystem. Other projects impose privacy as the only way forward or don’t offer native privacy options at all. Zcash, on the other hand, believes in giving the freedom to choose. You can send transactions anonymously or not, it’s up to you to decide. The keys permissioning system is not black-and-white but designed to give the needed permissions, as typically done in non-blockchain tooling.

Institutional Adoption

Zcash, thanks to the many efforts of the team behind it (ECC co.), is heavily working towards institutional adoption, as shown in their many blog posts. They also have invested in collaboration with other blockchain foundations. Regular transparency reports are another important part of this, showing that Zcash is not interested, not now or ever, in knowingly aiding money laundering and similar illicit activities (support for auditing by the authorities is already valid proof).

Security

In a world where most blockchains have EVM-compatible smart contracts and risk a lot by opening up to manipulation, Zcash decided to focus instead on a functional, private blockchain. Although it is a PoW-powered blockchain, it is carefully researching the PoS panorama for alternatives, taking the time to choose wisely and without haste the most convenient between the alternatives. The security concern is also visible from the continuous and strenuous improvements in the cryptographic methods (the ECC itself is involved in the research), striving to balance performance and security.

6 Likes

Are synchronization and wallet functions included?

1 Like

no support was previewed for that, at least for this grant. We can extend the proposal though, allowing some extension of the timeline too.

the most basic things are in the description (addresses + transactions), let me know if you think something is missing and could be ideally added.

1 Like

Part of building a transaction is setting the input notes. For this, an app would need to detect and track incoming funds, maintain witnesses, and tree state (synchronization). Then notes need to be selected in order to maximize privacy and utility (wallet functions).

IMO, the basic use cases: send/receive/balance should be covered. In other words, a demo app that does these would be great for me.

Edit: Maybe the intent of the RFP is to only provide low-level functions and another RFP will cover sync & wallet. It seems that to write apps like free2z, one would need a wallet though.

2 Likes

First of all, I would like to thank you for your grant submission. IMO, the zcash dev ecosystem lacks support outside of rust.

Though it seems to me that the resource and time estimation are higher than expected. The grant shows a budget of ~200k which is roughly 1 year of dev.
Since there are ~20 functions, that’s about 2 weeks per function per dev.

The work is about wrapping existing functions and the UniFFI generator does a significant part of the job.

As a proof of concept, I implemented the first two tasks: Parsing a sapling secret key into a spending key and deriving the z-addr from the spending key. The repo is here: GitHub - hhanh00/zcash-uniffi

Thanks to UniFFI, that was done in a couple of hours. I understand there is more to the grant proposal than code but could you help me understand how the grant estimates it at two weeks in average per function?

Thanks

1 Like

There are several features in each milestone, moreover there is testing and documentation for all four languages to include at each step (feel free to measure how long that takes you with your example).

Taking care of eventual feedback and small corrections in the overall process need to be included in the timing too. There are several factors to consider for quality software to be such - ergonomics, for example, is not something that can be considered in a couple of hours, but rather with repeated testing and usage.

1 Like

Hello and Welcome @MeerKatDev, Thank you for submitting your grant proposal in response to ZCG’s RFP. I’m delighted to read through your grant application that aims to simplify Zcash integrations on various platforms.

We will review your proposal in the following weeks and reach out if we have any questions.
In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.

Thank you.

2 Likes

Thanks for your explanation.

For what it is worth, I think it is a bit too high. In fact, I’d be glad to do this RFP for 100k.

Edit: one possibility would be to allocate 100k for the implementation and earmark 100k for future projects that use this in python, etc.

1 Like

@MeerKatDev & Zcash Community, I am happy to announce that the @ZcashGrants Committee has unanimously voted to approve this proposal.

6 Likes

We opened the repo today. We believe that most of what we promised for the first week is present, apart from the doc generation checklist point which we should complete this or the next week. We tried to fit the relevant details in this issue.

I’ll be happy to answer any doubts.

2 Likes