CGP Application - RollApp Shielded Pool (RSP)

In a sentence, what are you going to build?*

RollApp Shielded Pool (RSP) is a module that will make it easy for developers to add a multi-asset shielded pool to their Cartesi applications and give users access to private transactions.

Please describe in more depth here*

As shown by CarteZcash, the predecessor to this project, Cartesi serves as an excellent vehicle to bring privacy features to Ethereum. While CarteZcash allowed for shielding Eth transactions, CSP expands upon this to support any asset (including NFTs) and swapping between assets without leaving the shielded pool.

CSP is designed as a service that other rollApps can install in their Cartesi machine. For example a game or DeFi project building on Cartesi could use CSP for managing funds and thus ensure all user transactions are private. CSP could be considered as a private multi-currency bank account plugin for apps. It could also be run by itself in a rollApp to provide a simple transaction rollup similar to CarteZcash.

Following the example of the rollApp API we propose an HTTP interface for CSP to allow simple integration from apps written in any language.

Further developments in Cartesi dApp composability open up the possibility of a single instance of CSP that is shared between multiple dApps which would improve the size of the annonmynity set.

In the architecture diagram below the green components are what is covered by the scope of this grant.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

Technical Considerations

As in CarteZcash there is a need to reduce state growth inside the Cartesi machine. As a result the CSP service running inside the machine must maintain the absolute minimal state required to verify transactions. This is comprised of:

unspent UTXO set
nullifier set
commitment tree frontier
commitment tree historical roots

The full state required by wallets will be computed by a full-node process which runs outside the Cartesi machine. Anyone can run a full-node and all data required to sync can be retrieved from the L1 calldata.

Private pools depend heavily on wallet side computation so users can view their balances and maintain the required state to produce new ZK proofs for transactions. The storage and computation requirements for such wallets are quite high compared with non-private applications.

For this grant we proposes forking the Rust CLI wallet developed by Namada to communicate with CSP applications although we acknowledge this is not the ideal user experience. Currently ChainSafe is developing an SDK for Zcash to allow browser based wallets and snaps to be developed for private applications. A follow-up grant could modify this SDK to support CSP.

What factors contribute to the potential success of your project?*

This project assumes a demand for private transactions in application specific rollApps, or at least demand for a shared pool in which users of Ethereum, or other supported L2s, can transact privately. Given the current sentiment it is expected that privacy will be one of the leading areas of development in Ethereum in the mid to long term and users will come to expect privacy in their applications.

The project also depends on a user-friendly way to interact with CSP applications being developed in the future. See the above paragraph on wallet development.

Does your project use any novel technology?*

CSP makes use of ZK SNARKs as implemented in the Multi-Asset Shielded Pool (MASP) protocol implemented by Namada. MASP is constructed using the Groth16 proving system and thus requires a trusted setup. Existing trusted setups can be reused and shared between rollApps without issue.

What are some competing alternatives to what you are going to build? Is there any previous work you’ll be building on?*

CSP is inspired and will derive much of its functionality from the Namada protocol (which is turn forked from Zcash). Namada is a Cosmos chain supporting the inter-blockchain communication (IBC) standard as well as an Etheruem bridge. It aims to be a unified privacy layer backing assets across both ecosystems.

The cosmos chain design does not compose well with the application specific rollup architecture. For an application specific rollup to use Namada as its shielded pool it would require every private transaction to be executed on the Namada chain, the receipt to be bridged back to Ethereum, and then sent to the rollup. This requires at least 3 transactions across 3 different chains (with different gas requirements).

Embedding the shielded pool inside the rollApp itself make composabilility far simpler and avoids verification cost by pushing it off-chain into the Cartesi machine. This is at the expense of reducing the available anonomity set to only users of a particular rollApp.

Name and role of team member(s)*

Tell us about your team’s strengths and qualifications that make you well-suited for this project*

ChainSafe R&D

ChainSafe R&D is a consulting team within ChainSafe with specialized skills in cryptography and systems design. Founded in 2020 we have successfully delivered projects for dozens of notable clients including:

Ethereum Foundation
Mina
ZCash
Protocol Labs
Gnosis

ChainSafe R&D sets itself apart by bridging the gaps between research, design and implementation. All of our team members are accomplished developers in addition to being practitioners in applied cryptography and protocol design.

Team Members

Willem Olding

PhD in Engineering (signal processing)
Rust developer with 6 years professional experience
Previously lead developer for Mina-rs

Tell us about your product development journey. Be sure to describe your product development to date (if any).

CSP is the evolution of CarteZcash, the winner of the 2024 Cartesi hackathon and recipient of a follow-on Cartesi seed grant.

Much was learned through the the development of CarteZcash for what is required to run a privacy protocol successfully in the context of a Cartesi dApp. In particular how using an external full-node can reduce the state storage requirements of the Cartesi node while allowing wallets to connect and sync the chain data. This architecture will also be used for CSP.

Additionally several of the Rust crates developed for CarteZcash (e.g tower_cartesi) can be reused directly in CSP.

Tell us your implementation plan for your project. Clearly define the milestones you expect to achieve in order to receive milestone-based installments.*

Milestone 1 - MASP Refactor (1 engineer, 1.5 weeks)

Refactor all blockchain related components out of Namada codebase
Split into stateless and stateful components which will run in the cartesi machine and full-node respectively

Milestone 2 - CSP process wrapper and interface (1 engineer, 1 week)

Design and build the HTTP API that dApps will use to communicate with CSP
Document the interface

Milestone 3 - CSP Wallet Fork (1 engineer, 1 week)

Fork Namada wallet to sync from CSP fullnode
Create interface for app wallet integration

Milestone 4 - Example dApp (1 engineer, 0.5 weeks)

minimum viable CSP dApp - wraps the shielded pool and allows deposits/withdrawals of multiple asset types from L1

What is your estimated timeline for completion of the project?*

Project will be completed in 4 weeks by one engineer working full-time with support from 1 additional engineer as required.

Try to detail out the plan to leverage Cartesi.*

Why will this solution be a source of growth for the Cartesi ecosystem?*

As users begin to demand privacy in their applications, CSP allows for Cartesi to emerge as a leader in this space.

By focusing efforts on a single shielded pool solution that can be shared across many projects, CSP frees up developer time to focus on the applications themselves rather than bespoke privacy solutions.