Rebuilding Provider as a Substrate Node

[forgetso]

Rebuilding Provider as a Substrate Node

Questions below taken from parachain development docs.

Scalability: How much is spent on resources and will the network be subject to bottlenecks?
Isolatability: Are the needs of many accounted for under the same framework?
Developability: Is the system tooling, system support, and overall system integrity dependable?
Governance: Can the network remain flexible to evolve and adapt over time? Can decisions be made with sufficient inclusivity, legitimacy, and transparency to provide effective leadership of a decentralised system?
Applicability: Does the technology address a burning need on its own? Is other “middleware” required to bridge the gap to actual applications?

Pros

The following are pros related to building a substrate node.

Greater fault tolerance in application

Rust's in-built memory safety will make for a more robust application.

Faster code

Rust can run faster than JavaScript.

Web sockets built-in

Currently, our API is using HTTP whereas we simply need to create additional API using impl_runtime_apis.

Governance built-in instead of outsourcing Governance to an existing parachain

Governance modules can be imported and used by our substrate node, allowing operation of a DAO without having to create a smart contract and host it on somebody else's parachain.

A single service for Providers

Providers no longer need to run a JS challenge node and also have access to a substrate node for the parachain they are interacting with. They can simply run the prosopo substrate node. But how does this work with a multi-chain smart contract architecture?

Consensus on Data Sets

Instead of data sets being stored within individual Provider databases, data sets could be committed on-chain. This means data set validity can be easily verified. This would potentially help with the reproducability problem in machine learning.

Content Moderation

Content moderation could be added as a service provided by the parachain. New providers would have their data sets content moderated using pre-defined or custom algorithms. Content moderators would be rewarded for moderating if they sided with the majority of moderators when committing their results on-chain.

Risk Assessment

Results from Prosopo contracts deployed on the various parachains would periodically be rolled up to a master contract sitting on the parachain. Risk scoring of accounts could be performed using the Prosopo data and any chain data from other parachains. Scores could then be passed back down to the parachains and stored in risk contracts that the main Prosopo protocol contracts' call.

Database for Web2 Accounts

Web 2 accounts that answer CAPTCHA could gain on-chain reputation if the provider substrate nodes submitted their transactions to a Prosopo protocol hosted on the parachain for Web2 only. Web 2 frontends could query the chain for the accounts' reputations from the Prosopo protocol smart contract on the Prosopo parachain.

Back Office

Provider back office functionality can be built into the node, meaning everything is in the same place.

Network Health Checks become easier

See discussion.

Cons

The following are cons related to building a substrate node.

Greater time spent developing

We will need to re-implement the provider JS code base in Rust. Although provider has given us a concrete specification, it will still take considerable time.

Complex Architecture

The default method for cross-chain communication between parachains is XCMP. Our Dapp frontend CAPTCHA user flow will need to continue to be via HTTP/websockets and Dapp User CAPTCHA interactions will need to maintained in a contract on a parachain on which the Dapp is running. This avoids XCMP (12s each way) latency in the CAPTCHA flow but it increases the architectural complexity. We must therefore manage the following components:

• parachain nodes (provider)
• prosopo protocol contract on each parachain
• prosopo protocol master contract on prosopo parachain

This seems at odds with parachain architecture in which XCMP is viewed as the communication method for parachains.

What happens to the existing Provider node?

We will need to branch out to other sources of traffic if data labelling becomes a key focus. Currently, we are not going to generate enough traffic from DApp users alone. Therefore, the existing Provider node could be utilised as a web 2 CAPTCHA integration that reaches out to the network via some service like Infura so that on-chain data can be read. The data set validity can be proven in the client due to the on-chain commitment. Therefore, we are allowing Providers to onboard and serve datasets themselves but we will need to initially vet their datasets and approve them on-chain manually.

Web 2 Provider

Based on the above, the following would need to exist to enable a web 2.0 CAPTCHA service and begin to build traffic and Providers.

• Slimmed-down Protocol contract relating to datasets only (solution commitments are not relevant, DApps do not exist)
• Slimmed-down Protocol contract on a parachain
• Modified hashing of datasets to calculate roots with and without solutions for content moderation in frontend
• Frontend react integration that utilised a service provider such as Infura for on-chain data
• Frontend <script>...</script> tag implementation for websites
• Implementation of unsolved solutions becoming solved as solutions are received
• Content moderation scripts to run when new datasets are received
  • How are new datasets received?

Pure Web 2 version of captcha

• All captcha supplied by prosopo
• All data managed by prosopo
• Content is therefore guaranteed to be moderated
• Load balancing is managed by prosopo (Load balancer --> provider nodes)
• Web3 account not required in Web2 app
• IP Address / Browser fingerprint stored and used as identifier on other websites implementing Prosopo captcha
• Identifier stored by prosopo

Web 3 / Web 2 version of captcha

• Captcha supplied by network of providers
• Data owned by each Provider
• Content is moderated through smart contract merkle proof
• Load balancing is managed by get_random_active_provider function in smart contract
• Web3 account is generated in browser per Web2 app
• IP address is not stored anywhere, instead a browser fingerprint is used as the entropy for generating a mnemonic
• Web3 account is potentially NOT portable to other website
• Web3 account is NOT stored anywhere other than local storage and must be generated on each website
• User has the option to keep the account if they install a web3 extension
• An account's previous CAPTCHA results must be stored somewhere. Cannot be on-chain as there are no coins to pay tx fees, unless the Provider pays the fee. The Provider may then be subject to a Distributed Denial of Funds attack, in which attackers continuously submit solutions in order to deplete the Provider's funds. However, the random provider selection method will provide some protection against this attack, given enough Providers are registered in the network.
• If account interactions are not stored anywhere then the CAPTCHA solution will only work per website