付费任务系统设计文档

一．引言

1. 目标读者

本文档面向付费任务系统的产品、开发、测试，及其他相关人员。对此文档有任何问题，都可以新建Issue向我们提问，也可以联系Chole（微信 grey0805）加群讨论。

2. 项目介绍

付费任务系统是 DEC 旗下生态系统中重要的垂直行业细分领域产品，专门针对软件开发相关人员，包括但不限于开发、产品、运营及外包等。

3. 名词解释

付费: 该文档中所说的付费，通常指的是支付 DET。
解决方案: 对应任务的系列解决方法或完成后的产出物，如教程或者软件包。
ABI: Application Binary Interface，应用二进制接口，以太坊智能合约编译时会随二进制一起提供。
MissionID: 全局唯一的任务ID，由任务管理平台在任务上传时生成。
SolutionID: 全局唯一的解决方案ID，由任务管理平台在任务完成时生成。

4. 参考资料

以太坊(ethereum): https://ethereum.org/
Oraclize: https://docs.oraclize.it/

二．总体设计

付费任务系统是一个基于区块链的分布式系统，运行于多种兼容的云计算平台上，并且可以平行扩展。

使用该软件系统，可以实现发布开发任务、结算佣金、争议解决等协作任务。

1. 需求概述

发布开发任务：用户可以在系统内发布自己的付费任务，指定一定数额的 DET 作为回报，该任务应该被所有人看到；
发布解决方案：对任务感兴趣的用户，可以留言尝试解决任务，并在完成后提供自己的解决方案；
提起争议诉讼/任务鉴定：如果付费方（甲方）和方案提供方（乙方）对任务完成结果意见不一致时，可以通过请求第三方鉴定的方式解决争议，类似于法律诉讼；
围绕任务互动：任务列表是公开的，因此所有用户包括发布者在内，均可以围绕任务进行互动，比如评论、回复评论、点赞等；

2. 软件结构

付费任务系统由智能合约，任务管理平台、任务展示平台、任务鉴定平台、任务鉴定平台构成。

智能合约（Smart Contract）：系统交易部分，会全部上链，做到公开透明。因此交易逻辑会由多组智能合约协同完成。
任务管理平台（Task Engine）：托管用户上传的任务说明和后续的交付物。是智能合约最主要的驱动方。
任务展示平台（Task Client）：展示现有任务列表，以及一些较为简单的互动，如点赞、关注等，包括但不限于客户端、网页等。
任务鉴定平台（Task Arbitrator）：对任务完成与否进行鉴定。一般不需要，只有交易双方出现分歧时才引入。
任务撮合系统（Task Matcher）：对任务进行撮合并推送到相关用户。因前期采用广播模式，该模块不需要实现。

各组件及交互可见下图。

2.1 发布任务

用户发起任务时，使用任务展示平台客户端（PC网页、iOS/安卓客户端）上传相应的说明和必要的文件，任务管理平台验证后，调用智能合约抵押发布人的对应资产，并在成功后通知发布人。

发布任务时序图

2.2 发布解决方案

任务发布后，允许任何人浏览访问，感兴趣的用户可能会尝试提交解决方案并期望获得对应报酬。解决者使用任务管理平台上传解决方案说明和必要的文件，任务管理平台验证完整性，获得通过后会得到通知。

发布解决方案时序图

注意： 此时并未发生资产转移。

2.3 确认解决方案

如果任务发布人对解决方案较为满意，会直接“确认”解决方案，此时任务管理平台会尝试调用智能合约转账对应报酬到解决方案提供方帐户。同样的，成功后双方会获得通知。

确认解决方案时序图

2.4 请求鉴定

如果发布者不满意解决方案，或者希望获得专业意见，可以通过请求鉴定的方式，获得任务鉴定平台的专业意见，并按裁定的任务完成比例支付报酬。

请求鉴定时序图

三．详细设计

以下分模块介绍详细设计方案及相关指标。

智能合约

智能合约完成的是核心交易逻辑，包括提交任务时抵押 DET，完成任务时支付 DET 等。

1．功能

向指定地址转账指定数额的 DET，可用于指定任务的抵押或者支付；
获取指定任务的鉴定结果（是否胜诉及可获得财产比例）；
从系统账户取回 DET，可用于鉴定胜诉时取回资产；
核心数据使用对方公钥加密（ ECDSA 算法），拥有私钥才能解密查看；

2．性能

目前基于以太坊，执行速度取决于Gas Price设置，不建议使用超高Gas加速，推荐将所有交易和回调异步化。

3．输入项目

预先定义的合约函数，一般由任务管理平台发起调用。当然也可以由其他任何第三方发起调用。

4．输出项目

除合约状态改变外，还会输出 Event Log 。部分场合可能还会通过 Oraclize 调用其他平台，如任务管理平台和任务鉴定平台等。

5．算法

无特殊算法。

6．程序逻辑

以太坊智能合约代码风格采用 Solidity 官方推荐风格。

合约代码样例如下。

// OpenTask.sol
pragma solidity ^0.4.25;
import "github.com/dececo/dechainio/contracts/DET.sol";

contract OpenTask  {

    DET det;
    address owner;

    constructor(address initialDETAddress, address initialOwner) public {
        det = DET(initialDETAddress);
        owner = initialOwner;
    }

    function updateDETAddress(address newDETAddress) public onlyOwner {
    }

    function updateOwner(address newOwner) public onlyOwner {
    }

    function publish(string missionID, uint amountInWei) public {
    }

    function solve(string solutionID) public {
    }

    function confirmSolution(string solutionID) public {
    }

    function confirmArbitration(string solutionID, string arbitration) public {
    }

}

7．接口

见示例代码。

8．存储分配

EVM 内部存储分配取决于具体实现，不使用任何以太坊外部存储。

9．限制条件

任何人都可能对合约发起调用，但只有符合条件的才能执行成功。例如，只有完成了任务的人才能取走属于自己的那部分佣金。

10．测试要点

完成任务后才能取走相应比例的佣金；
任务发起后资金抵押，任务取消前或完成前，资金不能移动；
通过其他合约调用OpenTask，不会改变现金流走向；更多要点详见功能。

任务管理平台

任务管理平台托管用户上传的任务说明和后续的解决方案交付物。是智能合约最主要的驱动方。数据存储在 AWS RDS 数据库中，兼容 MySQL。

1．功能

简单的登录功能，无需实名验证，并可以把 ID 与公钥/地址关联；
上传任务说明（引入版本控制前，暂定上传后不能更改），生成全局唯一的任务MissionID；
上传解决方案说明（交付物，引入版本控制前，暂定上传后不能更改），生成全局唯一的SolutionID；
对任务说明和完成说明留言评论，及点赞互动；
确认接受任务交付/任务完成；
请求鉴定机构鉴定任务是否完成及完成百分比；
按完成百分比支付佣金（调用智能合约）；
提供鉴定结果（供智能合约调用）；
权限控制（仅能查看自己发布的任务的解决方案，或自己提交的解决方案）；

2．性能

服务将部署在 AWS 上（最好是使用 Docker），并使用 RDS 作为存储。

QPS 无苛刻要求；
内存要求 8G 以下；

3．输入项目

用户上传或点击。

4．输出项目

动作完成的相关提示
智能合约调用
写数据库等持久化存储（RDS）

5．算法

无特殊算法。

6．程序逻辑

待补充细化。

7．接口

登录；
上传/下载任务说明/完成说明/附件；
点赞互动；
任务确认；
发起诉讼/鉴定；
接受鉴定结果；
（胜诉方）取回资产（调用智能合约）；

8．存储分配

AWS RDS。

9．限制条件

依赖项要尽量精简，推荐使用 Docker 方式部署，能打包成 Docker 镜像最好。

10．测试要点

见功能。

任务展示平台

任务展示平台展示现有任务列表，以及一些较为简单的互动，如点赞、关注等，包括但不限于客户端、网页等。

以下功能仅以网页端为例。

1．功能

展示任务列表，包含完成情况和点赞互动统计；
任务详情页面，可以查看完成情况和解决方案细节（仅有权限的任务解决方案）；
点赞互动；
上传任务或解决方案；
发起鉴定；
确认解决方案或鉴定；
取回资产；

2．性能

服务将部署在 AWS 上（最好是使用 Docker）。

QPS 无苛刻要求；
内存要求 4G 以下；

3．输入项目

无

4．输出项目

详见功能。

5．算法

无特殊算法。

6．程序逻辑

待补充。

7．接口

无外部调用方。

8．存储分配

无。

9．限制条件

依赖项要尽量精简，推荐使用 Docker 方式部署，能打包成 Docker 镜像最好。

10．测试要点

详见功能。

任务鉴定平台

任务鉴定平台对任务完成与否进行鉴定。一般不需要，只有交易双方出现分歧时才引入。

1．功能

投票决定是否接受任务完成，以及任务完成百分比；
提供任务完成百分比，供智能合约查询；

2．性能

服务将部署在 AWS 上（最好是使用 Docker），并使用 RDS 作为存储。

QPS 无苛刻要求；
内存要求 8G 以下；

3．输入项目

4．输出项目

5．算法

待补充投票规则。

6．程序逻辑

7．接口

鉴定结果查询接口

标准 JSON-RPC 接口，支持 HTTPS 协议，该接口主要供智能合约通过 Oraclize 调用。URL 路径中推荐含有网络和版本，方便针对不同合约版本进行加密，如https://www.identify.com/rinkeby/v1/verify。

请求参数如下：

solution_id: 要查询解决方案ID

返回参数如下：

solution_id: 要查询解决方案ID
completed: 是否完成，完成: true, 未完成: false
percentage: 完成百分比，0-100的整数，比如30表示该任务完成了30%`

注意： 在合约调用中该URL地址加密。

以下是调用示例：

// Request
curl -s -H 'Content-Type: application/json' -X POST --data '{"jsonrpc":"2.0","method":"dec_verify","params":[{"solution_id":"4d2be90d-24da-4857-8590-a9d3233c888d"}],"id":67}' 'https://www.identify.com/rinkeby/v1/verify'

// Result
{
  "id":67,
  "jsonrpc": "2.0",
  "completed": true,
  "percentage": 100
}

8．存储分配

AWS RDS。

9．限制条件

无。

10．测试要点

见功能。

任务撮合系统

任务撮合系统对任务进行撮合并推送到相关用户。因前期采用广播模式，该模块不需要实现。

1．功能

对已发布的任务进行撮合，找出匹配的潜在解决者，进行消息推送，吸引该用户的注意。

2．性能

暂无。

3．输入项目

现有已发布未解决的任务列表
现有已完成过任务（已提议过解决方案）的用户

4．输出项目

任务与潜在解决者的关联关系
该次撮合的佣金（如用户看过提示信息后开始尝试完成任务，应从最终受益中支付该佣金）

5．算法

自定义撮合算法是撮合系统的核心，每个实现均可以不同。

6．程序逻辑

撮合引擎获得任务列表和用户列表；
尝试撮合并产生匹配结果；
推送匹配结果到用户；
用户浏览推送；
任务展示系统记录下浏览行为及待支付佣金；
用户完成任务；
结算函数（智能合约）扣除佣金后把剩余资产发放给用户；

7．接口

待补充

8．存储分配

待补充

9．限制条件

多个撮合引擎均推送给用户同一任务时，以用户阅读的最早的推送为准。后续即使用户多次阅读类似推送消息，也不会再支付任何佣金。

10．测试要点

见功能。

付费任务系统设计文档

一．引言

1. 目标读者

2. 项目介绍

3. 名词解释

4. 参考资料

二．总体设计

1. 需求概述

2. 软件结构

2.1 发布任务

发布任务时序图

2.2 发布解决方案

发布解决方案时序图

2.3 确认解决方案

确认解决方案时序图

2.4 请求鉴定

请求鉴定时序图

三．详细设计

智能合约

1．功能

2．性能

3．输入项目

4．输出项目

5．算法

6．程序逻辑

7．接口

8．存储分配

9．限制条件

10． 测试要点

任务管理平台

1．功能

2．性能

3．输入项目

4．输出项目

5．算法

6．程序逻辑

7．接口

8．存储分配

9．限制条件

10． 测试要点

任务展示平台

1．功能

2．性能

3．输入项目

4．输出项目

5．算法

6．程序逻辑

7．接口

8．存储分配

9．限制条件

10． 测试要点

任务鉴定平台

1．功能

2．性能

3．输入项目

4．输出项目

5．算法

6．程序逻辑

7．接口

鉴定结果查询接口

8．存储分配

9．限制条件

10． 测试要点

任务撮合系统

1．功能

2．性能

3．输入项目

4．输出项目

5．算法

6．程序逻辑

7．接口

8．存储分配

9．限制条件

10． 测试要点

10．测试要点

10．测试要点

10．测试要点

10．测试要点

10．测试要点