Design

The POB Protocol implements a Decentralized Verifiable Reputation Protocol, which enables users to acquire a web3 BUIDL reputation by participating in verifiable workflows without having to accumulate their reputation from any centralized and siloed infrastructure.

System Overview

The POB Protocol can be divided into a stack of distinct interoperable layers as shown in Figure 1.

Figure 1: The POB Protocol Architecture

stack

Consensus Layer

The POB Protocol has several components which require a blockchain-based consensus layer to provide guarantees that mechanisms in the protocol (validation, payment, voting, etc.) are immutable, irreversible, and can be carried out without the help of a central governing authority. We will use an existing EVM-compatible blockchain such as Ethereum, or Polygon for this purpose.

Storage Layer

Other than core assets and states in smart contracts, the POB protocol stores data such as user submissions, workflow profiles, and other data on decentralized content-addressable networks such as IPFS or Arweave for permanent data storage.

Validator Network

The network is grouped according to the type of task requested by the reviewer, with each group consisting of a number of validator nodes, each node providing the same functionality and specifications. When a task triggers the validator network to provide a service, the node will sign the result data according to the service content and then upload it to the data center. Within a certain period of time, the validator network gets the data from the data center and calculates the final data based on rule aggregation (BFT, or Byzantine fault tolerance). If the user has authorized the validator network, then the network will automatically authorize or deny based on the results. If not authorized, the user can get the reference data from the POB backend.

Validator requires to stake $POB, the native token of POB Protocol, to join the network and will be rewarded or slashed by the system based on its own validation performance.

Contract Factory

The POB protocol uses a specifically designed Contract Factory to process workflows consisting of single and multiple tasks created by the protocol participants involved on-chain, combined with the work of the validator network to produce Incentive Token and Reputation Credentials as incentives and reputation validation.

Factory Contract - the decentralized workflows implemented by the POB protocol require using multiple smart contracts with similar functionality but different data, with factory contracts acting as units dedicated to producing contracts to represent and implement their workflow instances.
Task - the basic unit that executes the workflow. The task can be created by all protocol participants, and the taker can only submit content on the task. The task contains information about the reviewer, the taker, and the flowing states.
Workflow - a set of tasks that represent workflow instances and store some core rules data. Workflow is created and approved by the issuer, claimed, and minted soulbound token by the taker.
Incentive Token - The POB protocol supports the protocol native token $POB, stablecoins such as USDT/USDC/DAI, and other ERC20 tokens as incentive tokens for accomplishing workflows.
Reputation Credentials - The POB protocol enables takers to mint soulbound token as their reputation credentials for accomplishing workflows since reputation results from the social evaluation of a set of behavior or performance of a social entity by the counterpart.

Marketplace

The decentralized marketplace supported by the POB Protocol not only enables users to pay to use workflow templates developed by the protocol but also enables community developers to create task templates and workflow templates applied to different specific needs and scenarios for others to pay to use in order to prosper the protocol ecosystem.

Workflow Template - it is a mandatory option when creating workflow, and it represents a specific application scenario for workflow that users can get from open API or SDK powered by the POB Protocol in the marketplace.
Task Template - user needs to select the task template when creating workflow, which represents the type of tasks supported and which users can get from open API or SDK powered by the POB Protocol in the marketplace.

DApp Store

The POB protocol supports a wide range of use cases (described below) and encourages community developers to build DApps for a variety of different needs and scenarios using the combination of capabilities and markets provided by the protocol.

Participants

There are four different roles of protocol participants as follows:

Builder - the participant who creates task templates and workflow templates for the Issuer to use, and provides the corresponding validation services for the task if needed.
Issuer - the participant who publishes the workflow. Issuer requires to configure the workflow information and task information.
Taker - the participant who claims the workflow. Only the taker can claim the workflow and submit the task.
Reviewer - a participant who reviews and approves a workflow, either by the issuer or by a third party designated by issuer. The reviewer can request verification from the validator network.

System Operation

Based on the POB protocol, users can customize a public or encrypted on-chain workflow and configure parallel or serial sets of tasks, and each workflow supports the configuration of the fungible token including $POB and soul bound token as incentives and reputation credentials respectively.

Meanwhile, the validator network is also available to provide verification data as the verifier of the task. Through the network, a combined on-chain and off-chain (e.g. GitHub records) workflow protocol is constructed to support full-link data.

On-Chain

The POB Protocol provides workflow creation, task state iteration, tracking, and validation through factory contracts, which maintain workflows, per-user status, and permanent storage data.

Off-Chain

Regarding the status quo high gas fee, we currently deploy the validator network off-chain. The nodes of the validator network will be grouped according to different task templates, and each group of validators will be responsible for the same tasks and report data through feeding mode, and then recommend final data for user reference by aggregating data.

Each task has an executor and a validator:

the executor - executes some special logic for workflow state iterations based on the workflow configured by the user and the template selected.
the validator - is responsible for verifying the reliability of the data in the validator network.

Users can also authorize the validator network to automatically complete the authorization and approval of workflows when the network becomes more stable. And we are going to migrate the oracle network to the blockchain when the gas fee falls low enough due to the advancement of blockchain technology in the future.

Procedure

We outline how participants such as builder, issuer, taker, and reviewer collaborate through the POB Protocol with the illustration in Figure 2.

Figure 2: The POB Protocol Procedure

Issuer

The issuer needs to choose to configure a collection of tasks and some data needed to configure the workflow template when creating the workflow, which taker can discover in the marketplace when the workflow is created.

Validator Network - When selecting a task that contains the validator node service, the issuer can configure whether the validator network is required. When the service is configured, the issuer needs to authorize it to the validator network, which will automatically approve or reject the task based on the rules.

Taker

The taker can claim their favorite workflow and submit the task content within the deadline. The order of submission between tasks depends on the workflow configuration. When the number of tasks is greater than 1, the taker can choose the order of submission if it is parallel, and the taker must wait for the previous task to be approved before submitting the next task if it is serial.

Reviewer

The reviewer can see the list of the pending approvals in the POB backend, and the reviewer needs to complete the approval within the specified time. Once the reviewer has completed approval, if the task has an incentive that is exclusive to only one person, the system will automatically send the incentive; if the incentive is not exclusive, the reviewer needs to allocate the amount of incentive to be assigned and then complete the approval. When the reviewer rejects a submitted task, the taker can continue to submit the new one within the deadline, thus creating a cycle. The workflow is approved when all tasks of the workflow have been approved and the taker can claim the soulbound token tied to the workflow.

Soulbound Token as Reputation Credentials - Once a workflow is validated, the taker who accomplished the workflow can claim a non-tradable, non-transferable NFT, known as a Soulbound Token to signal the achievement of the taker as reputation credentials.

Builder

The composability of the POB Protocol allows community developers to submit workflow templates, task templates, and validator node services to POB DAO as builders, which we call CaaS or Code-as-a-Service. Builder can charge CaaS for the use by the issuer and the POB Protocol will take 20% of the sale as treasury revenue.

The community will vote on the CaaS submitted by the builder and the protocol will automatically list the CaaS using a pre-deployed workflow when the vote is approved. Once listed, it will be available for all participants to view from the marketplace.