PlatformNetwork/bounty-challenge

## 概述 悬赏挑战是一个面向需要人类判断的项目赏金的平台子网。它奖励那些将项目所有者创建的简报转化为最佳完成版实现、设计、界面或产品改进成果的矿工。 该子网专为严格自动化测试套件不足以应对的工作场景设计，例如： - 构建所要求的产品流程； - 改进现有应用的用户界面/用户体验； - 为项目生成最佳视觉渲染； - 打磨前端、新手引导、无障碍访问或交互质量； - 完成开放式任务（项目所有者需比较最终成果）。 ## 子网功能 悬赏挑战在项目所有者与矿工之间建立直接市场： 1. 项目所有者发布包含目标、资源、要求和可选截止日期的项目简报。 2. 矿工选择活跃项目，并以 GitHub 链接形式提交其完成的工作成果。 3. 项目所有者审阅提交内容、比较质量并记录反馈。 4. 项目所有者将发行代币分配给产出最佳工作的矿工热键。 5. 平台读取这些发行代币并将其归一化为子网权重。 最终形成一个奖励与完成的项目成果质量而非简单参与度挂钩的子网。 ## 角色 ### 矿工 矿工负责构建所要求的项目成果。矿工应阅读简报、实现所要求的工作、提交 GitHub 链接，并确保提交内容具有足够的可复现性以供项目所有者审阅。 ### 项目所有者 项目所有者创建项目、定义评分标准、审阅提交的工作成果，并决定最终的发行代币分配。这使得主观的项目质量处于人工控制之下。 ### 验证者 验证者和平台运营者运行挑战程序、公开项目和提交数据，并向网络提供经项目所有者批准的当前发行代币分配信息。 ## 生命周期 ``` flowchart LR Owner["Owner creates project"] --> Miner["Miner builds solution"] Miner --> Submit["Miner submits GitHub work"] Submit --> Review["Owner reviews quality"] Review --> Emissions["Owner assigns emissions"] Emissions --> Platform["Platform normalizes weights"] ``` ## 奖励逻辑 奖励由人工控制。项目所有者可以奖励单一获胜者，将发行代币分配给多个优秀的提交内容，或在项目演进过程中更新分配方案。平台负责最终的权重归一化，而挑战程序保留项目所有者设定的原始发行代币分配记录和审阅记录。 预期优秀的提交内容应： - 完全满足项目目标； - 易于从提交的代码仓库中检视和运行； - 符合所述评分标准； - 文档记录足够清晰以供审阅； - 在存在截止日期时按时交付。 ## 文档 详细操作指南位于 `docs/` 目录下： - [矿工指南](docs/miner/README.md) - [验证者与项目所有者指南](docs/validator/README.md) ## 仓库结构 ``` bounty-challenge/ ├── assets/ ├── docs/ │ ├── miner/ │ └── validator/ ├── src/bounty_challenge/ └── tests/ ``` ## 许可证 Apache-2.0

标签：bug发现, Linux 内核安全, UI/UX设计, 代码审查, 任务奖励, 任务平台, 众包, 区块链, 奖励系统, 子网, 激励机制, 矿工, 社区驱动, 质量评审, 软件开发, 软件改进, 逆向工具, 项目管理