reputation/personhood oracle as an Integritee OCW

[brenzi]

Motivation

It is not always practical to run or trust an encointer collator api endpoint. Sometimes, we just want to know the reputation of a specific encointer account.

A TEE oracle could fill this gap.

Potential Integrations

• nostr. This oracle could be a nostr badge issuer that Encointer reputables can use to get a personhood badge (unlinkable to their encointer account)
• gitcoin passport: how to integrate a new stamp
• subsocial (no concept of badges. how to do this?)
• OAUTH2 provider or
• KILT: issuer of perishable credential on Kilt network (although Kilt could potentially verify chain proofs directly, without the need for a TEE)

Idea

1. Build an OCW service that runs a light client into the Encointer parachain and registers RA on the Integritee Parachain
2. this OCW runs a https server that listens to oracle requests
   a. "get reputation for account XYZ" callable by anyone (not a proof of unique personhood without commitment)
   b. "get reputation badge for myself. here's my nostr pubkey", authentication needed with one or several encointer accounts

For nostr, the oracle has its own nostr profile which is the issuer of the badges (see NIP-58. the oracle can send nostr events and issues badges like "has a uniqueness reputation of 3/5 on the encointer network". Such badges have a TTL (see NIP-40) after which more recent reputation has to be presented to obtain a new badge

Requirements

• No direct linkability between Encointer accounts and account that receives a badge
  • Timing correlation linkability is acceptable (It is up to the user or frontend to obtain plausible deniability by not committing at the same time as requesting the badge)
• Reputation linkability per purpose. In order to provide a proof of unique personhood, reputation may only be used once per purpose/platform

Implementation Option 1

Onchain: new pallet encointer_reputation_commitments

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

OCW:

pub fn request_nostr_badge(reputation_commitments: vec<accountid,cid,cindex,salt,signature, nostr_pubkey)

[brenzi]

some test snippets:

rust code:
https://gist.github.com/brenzi/32e9109599ea659a3d7277bfe2e8b9c7

result:
https://coracle.social/chat/note18kst54gwje8n5t3cfpdud4duwh37wtfu4zpefd6a6q24nc2uecqs6vy8lq

[brenzi]

This task could actually also help with another problem: Maybe we want to be a bit more inclusive and just know "who has an account with nonzero balance?" in some local community. There is a cryptographic ZKP way for this: https://forum.polkadot.network/t/mmr-por-how-to-do-a-proof-of-reserves-on-a-parachain-without-leaking-information/2075

but the TEE approach seems much simpler

[brenzi]

to get started, test your OCW against this encointer node, which includes the teerex pallet
https://github.com/encointer/encointer-node/tree/community-sidechain
also, please have a look at this dated tutorial:
https://docs.integritee.network/4-development/4.4-sdk/4.4.4-custom-business-logic-stf/4.4.4.1-example-encointer
which shows you how you could query reputation