veigajoao
commented
6 months ago 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
robert-zaremba
firatNEAR
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.
relayer_operator_account_idRelayer 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.