Design

POB 协议实现了一个去中心化的可验证信誉协议，该协议使用户能够通过参与可验证的工作流来获得 web3 BUIDL 信誉，而无需从任何中心化和孤立的基础设施中积累他们的信誉。

System Overview

如图 1 所示，POB 协议可分为不同的互操作层的技术栈。

图 1: POB 架构图

stack

共识层

POB 协议有几个组件，它们需要一个基于区块链的共识层来保证协议中的机制(验证、支付、投票等)是不可变的、不可逆的，并且可以在没有中央管理机构的帮助下进行。为此，我们将使用现有的与 evm 兼容的区块链，如以太坊或多边形。

存储层

除了智能合约中的核心资产和状态数据之外，POB 协议将其他数据(如用户提交、工作流配置文件和其他数据)存储在分散的可内容寻址网络(如 IPFS 或 Arweave)中，用于永久数据存储。

验证者网络根据任务类型进行分组，每个组由许多验证器节点组成，每个节点提供相同的功能和规范。当任务触发需要验证器网络提供服务时，节点会根据服务内容对结果数据进行签名，然后上传到数据中心。在一定的时间内，验证者网络从数据中心获取数据，并基于规则聚合(BFT，或拜占庭容错)计算最终数据。如果用户已经授权了验证器网络，那么网络将根据结果自动授权或拒绝。如果未经授权，用户可以从 POB 后端获取参考数据。验证器需要质押 $POB (POB 协议的原生令牌)来加入网络，系统将根据其自身的验证性能获得奖励或削减。

Contract Factory

POB 协议使用专门设计的合约工厂来处理由链上参与的协议参与者创建的单个和多个任务组成的工作流，结合验证者网络，产生激励代币和信誉凭证作为激励和信誉验证。

Factory Contract - 由 POB 协议实现的去中心化工作流程需要使用多个具有类似功能但不同数据的智能合约，工厂合约作为专门生产合约的单位，负责发布和管理其工作流程实例。
Task - 是执行工作流程的基本单位。任务可以由所有协议参与者创建，而任务承接人只能在任务上提交内容。任务包含关于审批人、承接人和任务流动状态的信息。
Workflow - 代表工作流实例并存储一些核心规则数据的一组任务。工作流由发布人创建、审批，由承接人申领工作流、申领绑定灵魂绑定令牌。
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.