Privacy with Chain Signatures

[ilblackdragon]

Introduction

One of the challenges with blockchain is the absurd lack of privacy for users’ assets and interactions. The lack of privacy on-chain for any user account means that user's end up using a number of desperate accounts to dissociate various on-chain activities (e.g. investing in X vs buying Y).

Remote account privacy

With introduction of Chain Signatures we have an opportunity to offer a novel privacy primitive. Instead of user managing a number of separate accounts, figuring out how to maintain balances on them without linking them.

This is a proposal to introduce a ZK approach for remote address management within a relayer.

Let's say we have an user account is alice.near and a gas/intent relayer contract relayer.near.

Relayer contract has internal balances for users, which are maintained in shielded transaction. There is an alternative design of wNEAR or other FT token having shielded balances, where relayer operator first withdraws from it.

User sends the ZK confirmation directly to relayer operator, containing ZK proof that would transfer assets from user to operator without revealing originating user account and proof that this user has ownership of given derivation inside relayer.

• Visible input: remote account derivation, remote tx body, relayer_operator_account_id
• Constraint: given user has at least X $NEAR, given derivation belong to this user, user is not part of this operator's exclusion list

Relayer operator can validate these conditions and if accepted, sends tx paying $NEAR fee for inclusion of the NEAR network transaction (e.g. works also as a meta transaction relayer).

Relayer contract validates incoming ZK conditions, records the transfer for paying fees in ZK pool to relayer_operator_account_id, initiates signing a transaction from given derivation. Sends remote tx body for signing for given derivation.

There is additional function to allocate new derivation for a given user that also needs to be shielded in similar way.

This approach means that user with a single NEAR account can have 100s of addresses for each independent interaction they are taking, while paying in $NEAR (or other shielded FT on NEAR) to initiate transaction.

Operator's compliance

Relayer operators can have their own compliance requirements. To support that, exclusion lists are introduced on relayer smart contract. Such list maintained on-chain by each relayer operator individually and also as a group.

When user generates ZK proof, they need to include a proof that they are not on exclusion list of the operator they are relaying tx.

Additionally operator can inspect the clear text remote transaction body to check for interactions with excluded parties on the remote chain.

[veigajoao]

Very interesting, this could essentially turn the relayer into a chain abstracted mixer. The current design supports all funds from within Near being mixed when transferred to other chains.

Would be nice to have a different flow that allows the relayer to be paid in different chains and credit funds in the relayer internal balance of the user on Near. Are there any thoughts in this direction?

Btw, is this something that is going to be pushed at protocol level or do you envision application layer providers operating the relayers? I was part of the team that built the first ZK lib and mixer on Near and would be very interested in contributing to this project

[ilblackdragon]

@veigajoao

is this something that is going to be pushed at protocol level or do you envision application layer providers operating the relayers?

This lives fully in application space. Anyone can spin up relayer smart contract with single or a network of relayers.
Pagoda currently implementing reference relayer to pay for gas on remote chains specifically. Adding support for paying with remote account or such privacy features can be extension of that implementation.

[robert-zaremba]

Why do we need a remote account derivation? User should be able to transfer to any remote address, including an address he doesn't own.

[robert-zaremba]

remote account derivation should be only used to manage a remote account, assuming we can easily derive new private keys in MPC. Do you know any good solution for the latter?

[veigajoao]

@ilblackdragon

Is the Pagoda repo for the reference implementation already public? Didn't find it in Github and would be nice to see how it works and start playing around with it.

Also, in the new MPC for account derivation, does it only support signatures? If it also supported decryption using private key it would be possible to build an AML logic on top of the relayer and reveal transaction information when compliance requirements were triggered.

[firatNEAR]

@veigajoao You can find the repos that are being worked on here
Gas Station Contract https://github.com/near/multichain-gas-station-contract
Multi-chain Relayer Service https://github.com/near/multichain-relayer-server

They are in active development and not finalised so things might change fyi.