Refactor gn-oracle

[PopcornPaws]

Description

Oracle should be refactored into a standalone crate with modular components. It is currently a monolithic block of code that should be split into smaller (unit tested) components. We should do it in a way that makes it easier to integrate the new oracle engine and identity service into it.

An oracle should have two main functionalities

• identity challenger (links web2 identities to crypto identities)
• requirement engine (checks whether a user may get a specific role)

Solution

We could do something similar to Parity's identity pallet and set up a registrar-like id verification service:

• challenger
• watcher

This is very similar to what we already have in the oracle node but it's more polished and modular. Architecturally speaking we should implement connectors for various platforms (telegram, discord, twitter), send them challenges when we catch an identity registration event and wait for the user's response in the specific connector's DM to verify the provided off-chain identity.

Split the code up into the following units

• event subscriber
• data preparation for challenger and engine
  • pass account + H(web2_id) to challenger
  • query user data + requirement data for the engine
• challenger (just use a HashMap for storing challenges initially?)
• engine with plugins
• web2 bot workers (running in parallel with the main service)

[PopcornPaws]

Challenger

The identity challenger should generate a random challenge for each identity linking request. This random challenge should be sent as a DM from the user to the oracle's dedicated bots.

First, an identity linking request arrives via the event listener from the network. This should contain the sender's primary address $a$ and the Blake2_256 hash of the linked identity $H_{id} = H(id)$. These two are passed to the challenger itself, that generates a random challenge $r$ that is known only to the oracle node operator (however, as we'll see, it's not a problem if this $r$ is revealed). The operator then computes the challenge hash $H_c$ which is the Blake2_256 hash of the concatenation of the primary address, the linked identity's hash and the random challenge:

$$H_c = H(a||H_{id}||r)$$

The challenger then bundles this data as

struct ChallengeData {
    account: String, // a
    challenge: [u8; N], // r
}

and saves it via a mapping from identity hash to the challenge data $H_{id}\rightarrow(a, r)$. $H_c$ is queried by the user manually and it can be computed from the stored data any time (unless expired which we need to handle).

After the user queried $H_c$ they need to send it in a DM to the oracle's dedicated bot. Thus, the bot will receive a message $m = H_c^{(m)}$ from a sender $id$. Then, it hashes the sender id to obtain $H_{id}$ and send $(H_{id}, H_c^{(m)})$ to the challenger which

• queries its storage for the respective ChallengeData based on the provided $H_{id}$ as a key
• computes $H_c^{(s)}$ based on the stored $H(id), a, r$ values
• checks whether $H_c^{(s)} == H_c^{(m)}$, i.e. the stored challenge hash matches the challenge hash received from the user