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.
