Zcash UniFFI Library addenda

Community Grants Applications
1

Introduction

In the previous grant proposal responding to this RFP, we proposed to add a layer to Librustzcash that translates the main Zcash library methods into four different languages, which was possible thanks to Mozilla’s UniFFI library. As a result, the Librustzcash library is now usable in other languages, avoiding the need for double work from these developers. Most of the core functionalities needed to code a small light client or a wallet were exposed.

In this grant proposal, we want to take it three steps further, by:

  1. moving the UniFFI-supported library closer to the original library,
  2. creating a small demo of a wallet showcasing how to use this library on Android and iOS

As the Zcash ecosystem grows, so will its technical components, including the Librustzcash codebase. Thus, we should make sure that we keep these upcoming developments in mind and make the Zcash UniFFI library as easy to upgrade and maintain as possible. We want to ease this burden by finding ways to increase the degree of integration between these two libraries, while monitoring future maintenance and preventing hiccups in the normal Librustzcash workflow.

Code demonstrations are often mistaken for purely optional parts of a library’s implementation; many codebases are written down with all kinds of nice tools for static analysis, but more often than not, when developers reach out to use them, they cannot find a way to do so. This is why we would like to include both in the CI and in the examples a demo of the most used functionalities for each major mobile ecosystem, so that a developer may clone it and get up and running quickly on a Zcash-based project.

Most modern blockchain projects utilize Go or Rust as their underlying programming language. Adding Go support the UniFFI library itself would have added value both in itself and for Zcash. The aim of this addition would be to attract developers working on Golang libraries: for instance, from the Cosmos ecosystem, who for some reason would be interested in adding Zcash functionalities, but don’t have easy access to the library. It should be a breeze to include it as a library in an existing Golang project.

Project roadmap and milestones

We will split the process into three milestones of equal value. Each milestone will be submitted consecutively after completion of the previous one.

Milestone 1: Librustzcash integration

To start the integration work, we need to collaborate with the library developers to discuss the best way of conducting a deeper integration of the UniFFI library developers. This may be done parallel to the other two tasks. Some approaches might be

  • CI-based: Setup the CI to react by keyword, and implement a soft block on pull requests, i.e. that warns as a standalone on the pre-push checks, warning that a feature was implemented but did not include its FFI version.
  • Rust-based: implement some kind of “directive” or “trigger” during compilation that warns when a feature on one side changed and the other did not.
  • Manual intervention: the developer has to check whether this breaks the UniFFI part on a case-by-case basis (I suppose doable only when there is a developer having at least half of their time committed to it)

Milestone 2: UniFFI demo wallet

To demonstrate the usage of the library created in our previous endeavour, we will provide sample applications with minimal UI for both Android and iOS platforms, written in Kotlin and Swift, respectively. The demo wallets will have the ability to:

  • Show balance at an address
  • Build a transaction
  • Explore a transaction when inserting the transaction id
  • Broadcast a transaction after connecting to a node
  • Encode and decode addresses

Resumes

Librustzcash integration

  • Eloy López Peñamaría (Github) is a Cloud Software Engineer with extensive experience in Rust and Go, focusing on observability and resilience, with more than ten years of building backends for cloud environments. He likes to collaborate in blockchain-related projects and distributed high-traffic systems. Always attentive to details and documentation. He is the main member of the team who built the Zcash UniFFI library.
  • Tomasz Piotrowski (GitHub, LinkedIn) is a Rust Engineer at Eiger with extensive software development experience. Since joining Eiger he has worked exclusively with Zcashd and Zebra codebases and supported Eiger’s efforts in the Zcash ecosystem.

UniFFI demo wallet

  • Tomasz Piotrowski
  • Simon Keliuotis (GitHub) is a Software Engineer at Eiger. Over his eight years as a software engineer, he worked at various start-ups and organisations, developing Android and desktop applications/games, AR and drone control systems, security-oriented tools, and API platforms/backends.

Advisor team

  • Luca Campobasso (GitHub, LinkedIn) is a Software Engineer at Eiger. He’s been working on research and development for several projects within the company helping in identifying new research opportunities and taking those ideas to full fledged implementations (e.g. the Zcash UniFFI library). He spends a good amount of his time reading the Zcash protocol, the details of the cryptographic operations and primitives involved, the ZIPs implemented so far and the proposed ones. Additionally, he has experience writing academic research documents.

About us

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, decentralised 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 30+ senior web3 engineers across the globe and work with some of the most ambitious organisations 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

Budgeting

  • Librustzcash integration - 1 month, 2 engineers (8 FTEs)
  • UniFFI demo wallet - 1 month, 2 engineers (8 FTEs)

One FTE is 40 hours. Total FTEs: 16.

The standard rate at Eiger for an engineer is 150 $/hr.

The above quantities result in a total budget ask of

150 $/hour x 40 hours x 16 = $ 96 000

1 Like
2

100%! This is also important for security, as writing real apps with the library’s API can help uncover the pitfalls developers might fall into that lead to insecure use of the API.

Watching developers from outside the Zcash world build things with the library would be even better at uncovering common pain points, insecure usage patterns, and would help show us where the docs are confusing or lacking.

Maybe there’s some room to do some real user testing in the construction of the demo apps, say hiring devs with no prior Zcash experience and measuring things like “how long does it take to build a wallet app using the library?”, “how long does it take to accept Zcash payments in a Ruby on Rails website using the library?”

2 Likes
3

For a demonstration wallet, that seems to be quite a costly expense.

4

Thank you for the suggestion! We may allocate developers with no previous experience on Zcash on this part of the grant, document the process and use this experience to improve the UX of the library.

2 Likes
5

AFAIR, the proposal didn’t include any synchronization logic, or am i mistaken?
Do you have a link to the repo?

Thanks

6

The repo with our previous work may be found here.

the proposal didn’t include any synchronization logic

That’s correct. To my knowledge, librustzcash doesn’t offer that (please correct me if I’m wrong), and that is present only in the node (zcashd or zebrad) logic, so we could not port it.

Anyway, the features expected on the demo wallet are listed.

7

It would be cool to have a library for syncing. That’s something every wallet has to implement and it’s one of the most complicated pieces. I think I’ve audited at least four or five separate implementations over the years!

2 Likes
8

I guess you could propose this as an RFP :smiley:

2 Likes
9

How do you do that without syncing?

10

You can build a transaction and not broadcast it, but in general the demo wallet is supposed to demonstrate the capabilities from librustzcash. In place of synchronization we could use a node or fork that part from somewhere else (e.g. some other wallet?). The objective is to demo a wallet for developers to see how to use the library, not to have a fully working wallet.

11

But how do I build a transaction when I don’t know which notes are mine? i.e. what values to give to the transaction builder?
And how do I know the balance at an address without syncing?

Edit: I see you want your wallet to use another wallet…

12

I think @hanh is right, syncing is probably necessary for the libraries to be useful beyond generating and parsing addresses or parsing transactions that already exist (e.g. for a block explorer).

It sounds like it may be useful to add two pieces:

(a) a syncing logic library that could replace the separate syncing implementations in the ECC wallets, ywallet, and ZecWallet-lite
(b) a super-user-friendly API that makes it possible to accept/spend ZEC without knowing any protocol concepts, with all of the syncing and protocol details are taken care of under the hood

1 Like
13

I will repeat this for clarity: the fact that it is called a “demo wallet” is not supposed to indicate that it will be a fully working wallet with which you can build and broadcast transactions on the testnet. It is supposed to be more like a codebase that showcases how to implement wallet-like functionalities - we want simply to show to other developers keen on using the library how to do that for common functionalities. Which maybe could be built into an executable and put on a phone, and you could debug it by logging what it does, to understand what’s happening under the hood.

This is an extension of the previous grant, which is supposed to build on the code already written in librustzcash. I think for the purpose of the demonstration will be enough to use some hardcoded notes or anything which will be used to build a transaction. In general, the minimal effort should be done to go around the synchronisation phase and build on top of that.

If the need for a sync library will arise, we might find some better method to at least simulate a chain or retrieve data from the testnet somehow. I understand this library, Warp-sync , was supposed to do that but it is available only for Sapling? Also, we could try to extract the needed parts from zebrad.

Write a common library for sync might indeed be useful but that’s not part of this proposal at the moment. We could either add it to the scope or write another proposal specifically for this task :slight_smile: .

3 Likes
14

I would support an additional grant that makes it easy for developers to build a wallet / payment detection logic. I think it would multiply the value of the already-completed grant significantly.

2 Likes
15

It looks like NordSecurity has just released UniFFI bindings for Go:

So we might want to check if that meets our needs before funding that part of the grant.

3 Likes
16

Thanks for notifying us of that library :slight_smile: I modified the extent of the proposal.

2 Likes
17

@MeerKatDev, the @ZcashGrants Committee has recently voted to reject this proposal. They stated they would be interested in having the team potentially reapply after providing more documentation and demonstration of useability of the original grant.

1 Like
18

Hey @decentralistdan, thanks for informing us on this matter. Of course - we are a bit dissapointed as we hold our work to be of very high quality and have an extensive track record of delivering on our work in previous projects (outside of Zcash).

However, we do understand that it might have been slightly premature to apple for this proposal before Milestone 5 of the original proposal had been delivered. From our point of view it was clear that it would be completed on time, and thus we thought to move in accordance to that so that there would be no interruption in our work.

We will take this proposal slightly back to the drawing board - with the edits that came up earlier - and wait for the final milestone of the first grant to be completed. This should provide the documentation you refer to, and at the same time show the clear usability of the grant. Any other comments you might have here that we should take into account before we resubmit?

4 Likes