How Does Jomo Privately Prove My Aggregated Onchain Activities
Last updated
Last updated
This section describes in detail how we are able to use Zero Knowledge Proofs to privately aggregate the same type of data across multiple wallets a user owns, and prove the aggregated values, all without knowing which wallets the user owns.
Every user gets a Jomo profile automatically when they land on Jomo's webpage. This user profile will be stored locally, and include all their accounts, crypto wallets etc. The detailed accounts information will not get exposed to anyone else, including Jomo.
In order for us (Jomo) to attest and help the users prove that they own those accounts, Jomo frontend helps the users to generate a ZK proof, that all their accounts hash into a merkle root, and we only store the merkle root on the backend, associated with the user.
Now when a user wants to prove that they own one of the accounts, they can just prove that they know the user secret, the account hash, and a list of merkle paths, that will eventually compute to the account merkle root stored for their profile.
When the user connects a new wallet and verifies a sign-in signature, or connects a social account via oAuth, Jomo does NOT associate this information with a user. Instead, we allow the user to attach a secret hash with the request, and essentially register that whoever knows the secret owns the account. All the registrations are then commited to a public merkle tree.
Later the user only has to prove to us that they know a secret and an account, and that there is a registration about them in the merkle tree.
Together with this proof, they will also generate a proof to the backend that the merkle root should be updated to a new value, which includes all previous accounts, and adds this new account.
Based on publicly available onchain data, we have made attestations to accounts connected on Jomo. This include things like bluechip nft ownership, for all the holder wallets.
For each account that we attested, the detailed data is commited to a Pedersen hash, and together with the account hash, stored in a merkle forest.
When a user wants to prove that one of the attestations is about an account that they own, they would prove that
They know one account hash + pedersen hash that exists in the merkle tree
Their user profile owns the account hash (as described before)
Next we allow the users to prove to us that they own multiple accounts, each has attested data, and these data aggregate to a certain value, all while not letting us know anything about which accounts, what data, and even the aggregated result.
With the proof, Jomo could verify that the user is speaking truth without knowing the underlying details. Thus we could issue the user a private verifiable credential (private VC), which basically says that the user owns multiple accounts that aggregate data to a sum value, and the sum value hashes into a meaningless public string.
Finally based on the application's requirements, the user is going to present their private VC, which is basically the meaningless public string, and generate a proof saying that the underlying data within the meaningless string meets the application's criteria.
This is a relatively simple ZK proof where the user supplies the underlying data to the ZK circuits and run the range proofs against the criteria.
