Zcash SDK Implementation [JS/TS] - Proposal

Community Grants Applications
1

Hi Everyone :wave: Please take a look at a proposal that the ChainSafe team just sent-in, we’d love any feedback that you may have:

Zcash SDK Implementation [JS/TS]

Many thanks :smiling_face:
CS Team

Zcash SDK Implementation [JS/TS]

Title:
ZCash SDK Implementation [JS/TS]

Applicant name:
ChainSafe - Daniel Choi

Team member name:
Bernard Stojanovic

Team member name:
Ivan Rubido

Pitch: A one-liner elevator pitch version of your proposal
Expanding the reach of the ZCash ecosystem by introducing an SDK that will allow for wider adoption and use.

Total Request (USD):
$300000.00 USD

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?
No

Are you seeking or have you received funding from other sources for this proposed project?
No

Applicant background:
ChainSafe [Organization] -
Established in 2017, the core business of ChainSafe Systems is software development consulting, specifically the research and development of blockchain protocols and products, including infrastructure and tools which enable the onboarding of new developers and novel use cases for blockchain technology. ChainSafe has worked to maintain stable alternative implementations, improve functionality and in turn adoption of some of the top protocols in the space such as Ethereum, Filecoin, and Polkadot - helping to create and secure over 230 Billion USD in combined value measured by market capitalization of these protocols. As part of ChainSafe’s commitment to fostering the growth and adoption of blockchain technology, they also build developer resources that serve as public goods - open source code libraries and tooling that ensures that Web3 infrastructure will be made from technology developed in Ontario. Strong proponents of open-source technology and community-oriented commercialization, and with accessibility and utility for developers as our primary objective - ChainSafe helps to produce and maintain core infrastructure the web3 ecosystem needs to succeed and serves the global web3 community.

Bero [Tech Lead] - An accomplished software engineer with a proven track record of success in the tech industry. Beginning in 2018, he joined a small agency where he quickly advanced to the role of Technical Lead. During his tenure at the agency, he worked on complex data visualization projects, honing his skills in Frontend Engineering. In 2020, he embarked on a new adventure by joining NodeFactory, where he continued to excel as a software engineer. His commitment to open source work and dedication to innovation led to a significant milestone in 2021 when ChainSafe Systems acquired NodeFactory. Following the acquisition, his focus shifted towards creating cutting-edge open source tools that have made a meaningful impact in the tech community.

Ivan Rubido [Developer] - 4 years of active web3 development experience. He began his journey at NodeFactory, working on a lot of dApps for various clients, such as Croatia National Post NFT platform and the Swap-Kiwi NFT dApp. For the following two years at Chainsafe, Ivan continued with consulting projects, statistics tools, dev tooling and maintained various Metamask snaps such as FilSnap and Polkadot Snap, and developed snaps for NEAR, Aleo, and Mina. His primary focus remains on ensuring user-friendly and secure applications and protocols. Ivan has amassed a profound understanding of blockchain technologies and standards.

Daniel [Researcher] - Daniel is blockchain researcher who has been previously a blockchain developer. Daniel has over 7 years of experience in the blockchain field and has done both research and development for various projects. He has contributed to many projects including: Kademlia DHT Double hash implementation, gasless transaction solutions, Chainlink-Cosmos, Ethermint, Polymath wallet, and testing. Currently, his areas of focus for research are ZKs, wallet and smart contract security, and Ethereum-related protocols.

Description of Problem or Opportunity:
Currently in the ZCash ecosystem, there is no convenient way for a developer to implement a web-based application to incorporate ZCash payments. With the implementation of a ZCash SDK in typescript, developers will have the ability to integrate ZEC payments and allow users to interact with the chain. Subsequently, this will potentially expand the reach of the ZCash project and bring in an audience for wider adoption. The SDK will also open up opportunities to implement a ZCash Snap and subsequently web-based wallets.

Proposed Solution: Describe the solution at a high level.
The purpose of this proposal is to add value to the Zcash ecosystem by implementing and maintaining a TypeScript SDK for enabling more Zcash capabilities in the browser. This proposal should provide ground work and a feasibility test for the development of a Zcash MetaMask Snap along with a Web wallet that would utilize said snap as a secure enclave for user keys. Enabling millions of MetaMask users instant access will help significantly with Zcash adoption and usability. The SDK will also bring in opportunities for general web-based wallets (web wallet, extensions, electron applications, etc), that go beyond the scope of Snaps. This document is focused on the initial portion of this vision: the design, implementation, and support of a JavaScript SDK for interacting with the Zcash network.

Solution Format: What is the exact form of the final deliverable you’re creating?
This proposal covers a set of deliverables: the SDK itself, SDK tests & documentation, and examples that demonstrate the use of the SDK from both client- and server-side environments.

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!
We will use monorepo approach with typescript, with it we will able to modularize parts of code for future proofing and customization. With it we will keep KISS and Fasade approach to building API’s.

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?
A couple dependencies that may affect development is librustzcash and halo2. Our team will rely on some pieces of code that will assist our process with WASM compilation and may require those involved in. The lightwalletd team to provide assistance (if any) when required.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?
The biggest concerns will be our dependencies (librustzcash and halo2) and compatibility with wasm, in case of incompatibility we will slow down the first deliverable.
Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.
If the project is a success there would be occasional maintenance and potentially future upgrades to be considered. If there are future upgrades to any dependencies listed in the previous section above, there may be breaking changes to the SDK implementation. This will require maintainers to stay up-to-date with the developmental process of related dependencies and understand the compatibility issues and make any fixes as needed.

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?
The metrics that we can provide include monthly SDK downloads. On the qualitative side, we will gather user feedback when it comes to installation time and ease of use.

Hardware/Software total budget:
$0.00 USD

Please provide justification for the total hardware/software budget:
N/A

Services total budget (cloud, hosting, etc.):
$0.00 USD

Please provide justification for the total services budget:
N/A

Compensation total budget:
$300000.00 USD

Please provide justification for the total compensation budget:

  • 1 Technical Lead
  • 1 FTE Engineers
  • .5 Research Engineer
  • .5 Project Manager
  • Overhead fees (this includes any additional costs such as the research involved in the initial scope of work, marketing, and senior management advisory for the duration of the project)

Do you require startup funding?
No

Milestone 1 - estimated completion date:
02/29/2024
Milestone 1 - USD value of payout upon completion of deliverables:
$150000.00
Deliverable 1.1
Account APIs

Milestone 2 - estimated completion date:
03/15/2024
Milestone 2 - USD value of payout upon completion of deliverables:
$30000.00
Deliverable 2.1
Provider APIs

Milestone 3 - USD value of payout upon completion of deliverables:
$60000.00
Milestone 3 - estimated completion date:
04/15/2024
Deliverable 3.1
Synchronizer

Milestone 4 - USD value of payout upon completion of deliverables:
$60000.00
Milestone 4 - estimated completion date:
05/15/2024
Deliverable 4.1
Utility APIs, Testing & Documentation

Total proposed USD value of grant:
$300000.00 USD

How was the project timeline determined?
The software project timeline is determined by breaking down tasks, considering available resources, and estimating how long each task will take. It involves planning for uncertainties, adjusting as needed, and keeping everyone involved in the loop.

12 Likes
2

Hi @LizBoomLiz - Thank you for submitting your grant proposal! We will review it in the upcoming 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.

Zcash Community - We want to hear your feedback on this grant! You can post your comments to this thread or DM us at @ZcashGrants if you’d like to provide feedback in private.

Thanks!

4 Likes
3

My only concern is that we might waste money duplicating work done by the people integrating zcash into the Brave browser. We could probably get someone to extract components of their wallet into an SDK for less than 300k.

4 Likes
4

Hi @Milton - We took a look at the Zcash <> Brave Integration, it’s written in C and cannot be used on a webpage :confused:

6 Likes
5

Thanks @aquietinvestor!

1 Like
6

Love the idea. Ive been banging my little table about WASM for years. But, beware that several have tried and failed. I think “Zephyr” was one? Paraphrasing @hanh … i think he said it was harder than landing a live animal on Saturn… I kid … but, isnt there some huge bounty somewhere to get ZK snarks running in the browser? Sounds hard. But, i do want the result …

2 Likes
7

The approach taken here is the same as Zephyr, ie compile librustzcash to wasm. Therefore I don’t see how this is going to work in the real world.
I think you will need a different approach if you want a chance to succeed.

1 Like
8

Hi @skyl @hanh
In an ideal case, we are hoping that we would succeed in compiling it to wasm - And, we have also accounted for that, and we will have to take alternative solutions like trying to compile to wasm only parts that are required for wallet functionalities or using/writing pure js libraries instead. Hope this helps!

9

Hi Everyone :wave: We have updated our proposal based on feedback regarding the feasibility of the project. The proposal has been broken down a bit more and the feasibility component is now described in more detail within the section Execution Risks, we have also adjusted Milestone 1 - USD value of payout upon completion of deliverables:

Execution Risks
Another known issue that has been encountered in the past was due to throttling of the browser. This is not a well studied area and may possibly cause issues in the future. Thus, we will conduct a preliminary viability test to assess the challenges and possible blockers that may present an impasse. If such situation makes it impossible to make any more progress, the project will cease after the viability milestone.

Milestone 1 - USD value of payout upon completion of deliverables:
$35000.00

Any additional comments are welcome. Thanks!
ChainSafe Team

(see the full re-post, below)

Applicant name:

Daniel Choi

Do you have additional team members/collaborators?

Yes

Team member name:

Bernard Stojanovic

Do you have additional team members/collaborators?

Yes

Team member name:

Ivan Rubido

Do you have additional team members/collaborators?

No

Please upload an image for your public facing profile and proposal

logo.png

Pitch: A one-liner elevator pitch version of your proposal

Expanding the reach of the ZCash ecosystem by introducing an SDK that will allow for wider adoption and use.

Total Request (USD):

$300000.00 USD

Have you previously received a grant from Zcash Community Grants (formerly called ZOMG) or ZF?

No

Are you seeking or have you received funding from other sources for this proposed project?

No

DETAILS

If you have any questions please contact grants@zfnd.org.

Upload any relevant documentation regarding this project.

n/a

Applicant background:

ChainSafe [Organization] -

Established in 2017, the core business of ChainSafe Systems is software development consulting, specifically the research and development of blockchain protocols and products, including infrastructure and tools which enable the onboarding of new developers and novel use cases for blockchain technology. ChainSafe has worked to maintain stable alternative implementations, improve functionality and in turn adoption of some of the top protocols in the space such as Ethereum, Filecoin, and Polkadot - helping to create and secure over 230 Billion USD in combined value measured by market capitalization of these protocols. As part of ChainSafe’s commitment to fostering the growth and adoption of blockchain technology, they also build developer resources that serve as public goods - open source code libraries and tooling that ensures that Web3 infrastructure will be made from technology developed in Ontario. Strong proponents of open-source technology and community-oriented commercialization, and with accessibility and utility for developers as our primary objective - ChainSafe helps to produce and maintain core infrastructure the web3 ecosystem needs to succeed and serves the global web3 community.

Bero [Tech Lead] - An accomplished software engineer with a proven track record of success in the tech industry. Beginning in 2018, he joined a small agency where he quickly advanced to the role of Technical Lead. During his tenure at the agency, he worked on complex data visualization projects, honing his skills in Frontend Engineering. In 2020, he embarked on a new adventure by joining NodeFactory, where he continued to excel as a software engineer. His commitment to open source work and dedication to innovation led to a significant milestone in 2021 when ChainSafe Systems acquired NodeFactory. Following the acquisition, his focus shifted towards creating cutting-edge open source tools that have made a meaningful impact in the tech community.

Ivan Rubido [Developer] - 4 years of active web3 development experience. He began his journey at NodeFactory, working on a lot of dApps for various clients, such as Croatia National Post NFT platform and the Swap-Kiwi NFT dApp. For the following two years at Chainsafe, Ivan continued with consulting projects, statistics tools, dev tooling and maintained various Metamask snaps such as FilSnap and Polkadot Snap, and developed snaps for NEAR, Aleo, and Mina. His primary focus remains on ensuring user-friendly and secure applications and protocols. Ivan has amassed a profound understanding of blockchain technologies and standards

Daniel [Researcher] - Daniel is blockchain researcher who has been previously a blockchain developer. Daniel has over 7 years of experience in the blockchain field and has done both research and development for various projects. He has contributed to many projects including: Kademlia DHT Double hash implementation, gasless transaction solutions, Chainlink-Cosmos, Ethermint, Polymath wallet, and testing. Currently, his areas of focus for research are ZKs, wallet and smart contract security, and Ethereum-related protocols.

Description of Problem or Opportunity:

Currently in the ZCash ecosystem, there is no convenient way for a developer to implement a web-based application to incorporate ZCash payments. With the implementation of a ZCash SDK in typescript, developers will have the ability to integrate ZEC payments and allow users to interact with the chain. Subsequently, this will potentially expand the reach of the ZCash project and bring in an audience for wider adoption. The SDK will also open up opportunities to implement a ZCash Snap and subsequently web-based wallets.

Proposed Solution: Describe the solution at a high level.

The purpose of this proposal is to add value to the Zcash ecosystem by implementing and maintaining a TypeScript SDK for enabling more Zcash capabilities in the browser. This proposal should provide ground work and a feasibility test for the development of a Zcash MetaMask Snap along with a Web wallet that would utilize said snap as a secure enclave for user keys. Enabling millions of MetaMask users instant access will help significantly with Zcash adoption and usability. The SDK will also bring in opportunities for general web-based wallets (web wallet, extensions, electron applications, etc), that go beyond the scope of Snaps. This document is focused on the initial portion of this vision: the design, implementation, and support of a JavaScript SDK for interacting with the Zcash network.

Solution Format: What is the exact form of the final deliverable you’re creating?

This proposal covers a set of deliverables: the SDK itself, SDK tests & documentation, and examples that demonstrate the use of the SDK from both client- and server-side environments.

Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!

We will use monorepo approach with typescript, with it we will able to modularize parts of code for future proofing and customization. With it we will keep KISS and Fasade approach to building API’s.

Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?

A couple dependencies that may affect development is librustzcash and halo2. Our team will rely on some pieces of code that will assist our process with WASM compilation and may require those involved in. The lightwalletd team to provide assistance (if any) when required.

Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?

The biggest concerns will be our dependencies (librustzcash and halo2) and compatibility with wasm, in case of incompatibility we will slow down the first deliverable.

Another known issue that has been encountered in the past was due to throttling of the browser. This is not a well studied area and may possibly cause issues in the future. Thus, we will conduct a preliminary viability test to assess the challenges and possible blockers that may present an impasse. If such situation makes it impossible to make any more progress, the project will cease after the viability milestone.

Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.

If the project is a success there would be occasional maintenance and potentially future upgrades to be considered. If there are future upgrades to any dependencies listed in the previous section above, there may be breaking changes to the SDK implementation. This will require maintainers to stay up-to-date with the developmental process of related dependencies and understand the compatibility issues and make any fixes as needed.

Evaluation plan: What metrics for success will you share with the community once you’re done? In addition to quantitative metrics, what qualitative metrics will you commit to report?

The metrics that we can provide include monthly SDK downloads. On the qualitative side, we will gather user feedback when it comes to installation time and ease of use.

Budget

  • Please provide the total amount of funding requested for each major heading (Hardware/Software, Services, Compensation) with a detailed explanation regarding how that budget was determined. The total of these three sections should add up to the total funding request amount. The clarity of this section will enable the review committee to quickly understand your reasoning for the funding requested.
  • The “Compensation” explanation should include who is being paid, how much they’re being paid (hourly, monthly, full project, etc.), and how each compensation figure was determined.

Hardware/Software total budget:

$0.00 USD

Please provide justification for the total hardware/software budget:

N/A

Services total budget (cloud, hosting, etc.):

$0.00 USD

Please provide justification for the total services budget:

N/A

Compensation total budget:

$300000.00 USD

Please provide justification for the total compensation budget:

  • 1 Technical Lead

  • 1 FTE Engineers

  • .5 Research Engineer

  • .5 Project Manager

  • Overhead fees (this includes any additional costs such as the research involved in the initial scope of work, marketing, and senior management advisory for the duration of the project)

Schedule and Milestones: What is your timeline for the project? Include concrete milestones and the major tasks required to complete each milestone.

  • Milestones, and the deliverables associated with each milestone, are required for every project. Completed milestones trigger a review of all the deliverables associated with that milestone which leads to a release of funds. Please note that payment will only be made upon successful completion of all the deliverables associated with each milestone, not prior to the milestone being completed. Deliverables show progress toward grant completion and must be verifiable.
  • Each milestone may have multiple deliverables. A deliverable describes the specific outcome that will be evaluated by ZF/Zcash Community Grants committee when determining if a milestone has been achieved. Deliverables must be specific and verifiable. When writing deliverables ask yourself, “How will ZF/the committee evaluate the success or failure of this deliverable?”

Example Scenario:

  • Your project is requesting no upfront payment and two milestones (Milestone 1 and 2) with three deliverables (Deliverables 1.1, 1.2, 1.3, 2.1, 2.2, 2.3) under each milestone. You are estimating that it will take three months to complete the deliverables under each milestone. Three months pass and you’ve successfully completed the three deliverables under milestone 1. You are then eligible to request review and payment for Milestone 1. The same applies for Milestone 2, etc.
  • A lack of deliverables in your proposal, or vaguely written deliverables, will cause your proposal to be rejected. Please direct any questions regarding milestones and deliverables to grants@zfnd.org.

Do you require startup funding?

No

Milestone 1 - estimated completion date:

03/31/2024

Milestone 1 - USD value of payout upon completion of deliverables:

$35000.00

Deliverable 1.1

Feasibility Study

Enter additional deliverables for Milestone 1?

No

Enter additional Milestones?

Yes

Milestone 2 - estimated completion date:

04/15/2024

Milestone 2 - USD value of payout upon completion of deliverables:

$110000.00

Deliverable 2.1

Account APIs & Provider APIs

Enter additional deliverables for Milestone 2?

No

Enter additional Milestones?

Yes

Milestone 3 - USD value of payout upon completion of deliverables:

$80000.00

Milestone 3 - estimated completion date:

05/15/2024

Deliverable 3.1

Synchronizer

Enter additional deliverables for Milestone 3?

No

Enter additional Milestones?

Yes

Milestone 4 - USD value of payout upon completion of deliverables:

$75000.00

Milestone 4 - estimated completion date:

06/15/2024

Deliverable 4.1

Utility APIs, Testing & Documentation

Enter additional deliverables for Milestone 4?

No

Enter additional milestones?

No

Total proposed USD value of grant:

$300000.00 USD

How was the project timeline determined?

The software project timeline is determined by breaking down tasks, considering available resources, and estimating how long each task will take. It involves planning for uncertainties, adjusting as needed, and keeping everyone involved in the loop.

2 Likes
10

I support this proposal. (Glad to see that it has been discussed at recent ZCG meetings)

2 Likes
11

IMO, this proposal needs performance targets. One can theoretically run any algorithm in a browser since it is a Turing Machine, but if it takes hours to produce a Zcash ZKP or months to synchronize, it will not be used by anyone.

That’s the issue that previous similar projects have faced.

3 Likes
12

If would help if people knowledgeable developed the required specifications for these and similar projects so that 3rd parties dont have to create their own. Zcash should have its own predefined performance requirements that must be met.

The main reason why people pay Apple, Amazon, Google so much money because they are obsessed with user experience and customers. They tend to release products designed for optimal customer experience. You might see them as a centralized authority. And in some cases they are; but they are the centralized authoritity to protect customers, the people using their products. Its all about the customer… We need to be just as focused on ZEC customers to make sure they have the best experiences and only then will people learn to trust ZEC.

So what is the minimum requirement so that people will have an A+ experience because we the ecosystem can not handle funding so many projects that are doomed from the start?

I think integrating with metamask would be a very positive development. I find it hard to believe that single asset wallets will survive (other than a projects own reference wallet and even they might become obsolete depending on the use cases).

1 Like
13

Hi @hanh - This is the first phase that will enable a Snap and connectivity to MetaMask. Beyond a Snap, something like a Wallet UI could be a great adoption driver, expanding ZCash reach to new audiences. This proposal is the first steps in getting there.

14

For reference, the other project (Zephyr) that ZCG funded before for similar functionality ran into some pretty big challenges that they were never able to overcome:

Hopefully this project and ZCG can take lessons learned from other projects so they don’t run into the same issues.

5 Likes
15

There are three basic scenarios that are deal breakers for me:

  • creation of a new wallet,
  • synchronization (1 day, 2 days, 1 week of block data),
  • payment

I think these should be included in the feasibility study.

3 Likes
16

Hi @Shawn - Thanks for referencing Zephyr, we have included their work as a reference within the revised feasibility study proposal. Really appreciate your, and everyone else’s feedback, and advocacy for what’s best for Zcash, it takes a village!

1 Like
17

@LizBoomLiz at the most recent meeting, the @ZcashGrants Committee voted to approve the revised proposal you have updated on the Submittable platform and has requested that you provide milestone-based updates via the forum in this thread.

9 Likes
18

That’s great news and thanks for the vote of confidence @ZcashFoundation!

3 Likes
19
3 Likes
20

Web Wallet Feasibility Study Update - 7/3/2024

I’d like to introduce myself (Wollum) and EC2 who are currently working on the browser web wallet feasibility study for ChainSafe and post an update of our progress.

We have spend the last week familiarizing ourselves with the Zcash rust ecosystem, prior attempts at web-wallets and developments in Zcash wallets in general.

Our aim for this project is not to actually build a web wallet but to concretely identify which specific wallet operations hit up on browser restrictions on memory and processing to see exactly what would be required to make this feasible.

At a high level the sub-tasks we want to measure are:

  • Compact block retrieval
  • Trial decryption of notes
  • Note commitment tree and witness updating
  • Proving

Update

This week we have completed two of the three milestones as listed in the grant proposal. The network testing (block retrieval) and Wasm evaluation. We also made progress on the third load testing benchmark focused primarily on deserialization and decryption.

Block Retrieval

The first issue we hit upon (which prior teams have also) is the lack of compatibility for gRPC requests in browser. Since this is the only supported interface for lightwalletd this was the first blocker.

We had success running a grpc-web proxy between lightwalletd and browser requests. This supports streaming requests and our benchmarks indicated we were able to retrieve compact blocks at a rate of several thousand per second. This suggests to us this will likely not be a bottleneck.

Trial Node Decryption / Deserialization

Having access to a stream of blocks we moved on to benchmarking trial node decryption using a dummy key.

We used the zcash_note_encryption and orchard/sapling Rust crates compiled to Wasm with wasm-bindgen.

Interestingly for our initial attempt which accepted the grpc-text serialized compact blocks to deserialize in Rust/Wasm the computation time was dominated by the deserialization time. We found it to be significantly faster to filter out the transactions on the javascript side and convert them to Rust-friendly memory format before passing them for decryption.

We were also able to make use of Wasm-native parallelism via Web Workers to achieve an almost linear speed-up. Our preliminary results show a rate of around 14000 notes per second for Sapling and 18500 notes per second for Orchard. (measured in Firefox on a Macbook M2).

Observations

Support for data parallelism in Wasm with crates like Rayon has come a long way. It is able to use Web Workers behind the scenes pretty effectively to leverage multiple cores.

Deserialization may also be more costly that the cryptography for some operations but there is a possibility for the client to hand-off this cost. For example by developing a fork of lightwalletd that delivers blocks already in the correct Rust/Wasm memory layout.

Next Steps

We are currently working to benchmark the note commitment and witness updating for Orchard and Sapling using the Shard Tree implementation from the incrementalmerkletree crate.

This is expected to be the bottleneck for wallet syncing and any suggestions for how to make this performant within a memory restricted environment would be appreciated.

8 Likes