Operations

Consumers

Registration

Each consumer needs to be registered in the system and approve a minimum amount of Polyzoa tokens to be able to pay the fees.

Request

When a consumer submit a request, it will be charged the fee after a successful response is sent back.

If the consumer has not enough tokens approved for the fee, the request is rejected.

Distribution Nodes

Registration

To register a new node, operators must register themselves in the system. An operator can also act as a consumer once it has been registered in the system.

When a new node is registered by the operator, the distributor will create a new node, configure it and notify the gateway of its presence.

The node will be active and deemed ready to accept requests when:

• has staked funds in the Stake Contract

• has updated its database with the latest patch

Serving requests

Off Chain

When a request is sent to the gateway, the gateway will identify the consumer and then forward it to a node to serve the request.

In order for the gateway to know which nodes are active at a give time, the node is requested to send a heartbeat regularly. Nodes that fail to send the heartbeat will be considered down and deactivated till a new heartbeat is received.

The selected node will receive the request and provide a response.

In order to make the response safer, the node will be requested to sign the response with the associated address, in order to verify the identity of the node and protect the system.

The consumer will be charged only if the address being checked is known to the system.

Address that are unknown to the node are sent to a queue for further processing in the background, and made available on the next round of updates.

On Chain

In case on an oracle, the request is generated from a contract.

The request includes a callback function signature and is sent to a Token that forwards it to the relevant oracle.

The oracle will check if the response is already stored on-chain.

If the response is immediately available, the response is directly sent to the original requester using the callback signature.

Otherwise, new data are requested off-chain. When the new date are available, they are sent to the requester.

Update

When new data are releases, the distributor will create patched for the new data and distribute across the active nodes.

Each node will then update its own database and notify the distributor of the latest update.

Node that fails to notify the distributor will be considered down and deactivated until the database has been update with the latest data.

Data Production

An address is sent to a queue that distributes the address to all available data producers:

• by the distributor nodes when the address is not found in the list of known addresses

• by the data wrangler

Each data producer produces a score for the address and send it to a validator.

The validator collects all the scores, and determine which score is acceptable according to this algorithm:

• Scores are aggregated in clusters according to risk thresholds.

• Cluster with the majority of scores will be selected as most likely candidate.

• The median or the average score is calculated for the cluster (TBD)

In the figures below, we can see the scores produced by 20 data producers.

In the figure A the majority of scores falls above the 0.75 threshold (red line), so the scores in the area above the line will be selected; the overall score will be the median between the scores, 0.86

In the figure B the majority of scores falls below the 0.45 threshold (orange line), so the scores in the area below the line will be selected; the overall score in this case is 0.30

Case A

Case B

If a quorum is reached, then the address with its score is propagated to the database and distributed across the nodes.

If no quorum is reached, the address is promoted to manual check

Producers that fail to produce scores or produce scores that are consistently different from the rest (several standard deviations from the mean), will be sanctioned or deactivated.