new pallet encointer_reputation_commitments

[brenzi]

For the purpose of personhood oracle

In order to get reputation linkability, we need an immutable record of commitments to purposes. While each purpose could maintain such registry for themselves, this is not possible for every purpose. Nostr. for example has no way of referring to a common consensus on commitments. Subsocial could, as they run their own parachain, but it would take integration effort which may slow down adoption. So the Encointer mainnet could provide such a simple registry:

pub fn commit_reputation(account_id. cid, cindex, purpose_id: u32, commitment: hash)
  if signature ok and not yet committed to *purpose*
    add commitment to registry double map (purpose, (account_id,cid,cindex))=commitment
pub fn register_purpose(description: String[24])
   append to array (descriptor)
   dispatch Event RegisteredCommitmentPurpose(purpose_id, descriptor)

where commitment is the hash of the requesting purpose account (i.e. nostr pubkey) and a random salt which should be unique per call and must later be provided to request a badge

the scope of purposes is global
including unit tests

[pifragile]

@OverOrion when is this expected to be ready?

[OverOrion]

I haven't started working on it yet as it requires some prerequisite work on my side.
Once I start working on it, I'll let you know.

[pifragile]

ok, i could take the task over, as it is blocking me atm. i could start this week and open the PR with this and the KSM faucet next week if everything goes well. @brenzi what do you think?

[brenzi]

sure, please go for it @pifragile

[pifragile]

ok! could you explain in a little bit more depth the rationale behind the commitment hash, as well as the salting mechanism you had in mind @brenzi ?

[brenzi]

Let me roll out my thought process:

requirement R1: We need to make sure that a prover (encointer account(s) with reputation) can obtain only one badge for a single nostr account

requirement R2: oracles should be stateless (not keep track of issued badges...because that adds quite some complexity because of R3)

requirement R3: R1 must hold for any set of unpermissioned oracle instances

the naive solution would be to just hash the nostr pubkey so the encointer/personhood-oracle would refuse to issue a badge to any other account than the one which hashes to the commitment directly, but

requirement R4: For privacy reasons we want unlinkability between the Encointer account proving its personhood reputation and the nostr account which shall get a badge.

Therefore, we can't just hash the nostr account because then you could rainbow-table the registry and reveal the link between all encointer and nostr accounts.

So, we can let the user add a random salt to the nostr account before hashing. Later, when requesting the badge from the oracle, the user can present the nostr-account and salt to the oracle to prove that the reputation hasn't already been used to get a badge for another nostr account already

This is way too much information for implementing this pallet. It's enough to know that a commitment hash needs to be stored. The rest of the complexity is left for encointer/personhood-oracle#6

[brenzi]

@pifragile as you implement this pallet for the use with #304, you can ignore R2,R3,R4 there because linkability can't be avoided onchain anyway and the chain is "only one instance". you can leave the hash empty for your case and the faucet pallet should just check if the reputation has already been used for its purpose (assuming the dripping/beneficiary account is the same as the prover which has reputation)