Avalanche5
会议纪要：Build Games 项目启动会
以下是根据 2026 年 2 月 20 日“Build Games”项目启动会议整理的中文会议纪要及注意事项：
会议纪要：Build Games 项目启动会
1. 项目概述
*
定位：这是一个旨在加速下一代加密货币创业者的 100 万美元构建者竞赛 。
*
核心目标：不仅仅是发放奖金，而是挖掘并培养具有高度自主性（High Agency）和执行力的优秀创业者 。
*
周期：为期 6 周 。
2. 核心评判标准 (Success Criteria)
项目方明确表示，他们正在寻找的是“经营者”而非“奖金收割者 (Grant Farmers)” ：
*
高度自主性 (High Agency)：能够利用想象力和创造力解决独特的、未被预测的问题 。
*
愿景沟通能力：能够清晰地表达想法并让他人感到兴奋 。
*
技术能力：构建的应用程序必须可靠且可扩展 。
*
学习热情：在快速变化的环境中保持极高的学习效率 。
*
创造意义：解决用户的真实需求，而不仅仅是为技术寻找应用场景 。
3. 奖金设置
*
前三名奖金：第一名 10 万美元，第二名 7.5 万美元，第三名 5 万美元 。
*
类别奖 (Category Prizes)：没有预设具体类别，而是根据项目的创意和表现回溯性颁发（如：最具创新想法、最佳 AI 代理、最佳营销策略等） 。
*
Retro 9,000 乘数：所有被录取的项目在 Avalanche 的 Retro 9,000 C-Chain 轮次中将获得乘数奖励 。
需要注意的关键信息
1. 重要时间节点
*
2 月 25 日：第一阶段提交截止日期。需要提交愿景（Vision），包括一个 2 分钟的英文 Pitch 视频 。
*
2 月 25 日起：开始办公时间（Office Hours），每个时区每天有 3 次 。
2. 提交要求与流程
*
分阶段晋级：比赛分为多个阶段，必须通过前一阶段才能进入下一阶段（类似“饥饿游戏”模式） 。
*
视频要求：视频必须使用英语。如果英语是第二语言，建议多加练习以传达项目的能量和氛围 。
*
MVP 开发：第一阶段是“种子”，第二阶段则是“幼苗 (MVP)”，需要展示实际的开发进度 。
*
GitHub 仓库：虽然第一阶段不一定需要，但后续需要分享 GitHub 链接以供评审（非公开，仅限评委） 。建议将 Web3 部分的代码公开，否则可能会影响评选 。
3. 团队与项目管理
*
团队成员邀请：如果队友尚未收到邮件通知，需在 Builder Hub 平台上通过“Refer your teammates”功能生成专属链接邀请他们，以便他们被自动录取并接收通知 。
*
项目聚焦：虽然可以使用不同邮箱提交多个项目，但官方强烈建议将所有精力集中在一个项目上 。
*
已存在项目：允许已有的项目参加，但必须在程序期间构建新的组件或功能，并明确说明增量部分 。
4. 支持资源
*
日历订阅：强烈建议扫描会议中的二维码订阅 Google 日历，以跟踪所有提交截止日期和研讨会（Workshop） 。
*
沟通渠道：主要的实时交流在 Telegram 频道中进行 。
*
技术工具：Builder Hub 提供了 Console（开发工具）、Academy（学习资源）以及 AI 集成等资源 。
第一阶段： ideation创意采集阶段
提交地址
https://build.avax.network/build-games
📦 提交1：创意方案 - 截止日期
2月25日（周三）
🕣 提交截止：美国东部时间当日23:59前
📍 提交地址：待定（将补充链接）
需提交内容：
- 填写概述文档
- 明确问题痛点
- 提出解决方案
- 架构设计
- 用户画像
- 用户旅程
- 团队概况
请参加日历中安排的导师答疑时间，获取创意反馈，帮助打磨完善方案。
❌ 暂无需准备（团队有额外时间或开发人员除外）：
- 代码
- 演示文稿
2分钟pitch video
Hello, we are building a physical asset activation game on Avalanche.
Wine counterfeiting and bottle refilling are serious problems in cross-border trade.
QR codes and laser labels are easily copied.
NFC chips are too expensive.
Blockchain traceability systems only record supply chain processes.
They cannot prevent post-opening bottle recycling.
Consumers have no incentive to verify authenticity.
So we ask: What if opening a bottle becomes a verifiable on-chain quest?
Our solution combines a destructive, tamper-evident laser seal with an Avalanche-based NFT activation protocol.
Each bottle is mapped to a unique RWA NFT on the Avalanche C-Chain.
The QR code is hidden under the seal and can only be accessed when the bottle is opened.
Consumers scan the code, claim the NFT, and complete a simple verification.
Opening data is written into the NFT metadata and permanently locked.
A second scan will expose refilling attempts.
Verification becomes a game mechanic:
claim = unlock, challenge = verification, red envelope = reward, NFT = permanent proof of first opening.
Why Avalanche?
High TPS for millions of bottles, ultra-low gas fees to keep cost under 0.5 CNY per bottle, and USDC for real economic incentives.
This is not a speculative NFT project.
It binds physical irreversibility with on-chain irreversibility, raising the cost of counterfeiting.
We are building a scalable, low-cost, real-world game layer on Avalanche.
Thank you.
Build Games 推荐计划条款与细则
Build Games 推荐计划设有总额为 30,000 美元的推荐奖金池，奖金将根据被推荐团队或个人在 Build Games 中的最终排名进行分配。
推荐奖励仅支付给提交符合条件推荐信息的合格推荐人（不支付给被推荐的团队或个人）。
推荐奖励分配规则如下：
- 推荐获得第 1 名：10,000 美元
- 推荐获得第 2 名：7,500 美元
- 推荐获得第 3 名：5,500 美元
- 推荐获得第 4 名至第 10 名：1,000 美元
严禁自荐推荐。推荐资格遵循先到先得原则，且每位个人或每个团队仅可被归属一次推荐记录，重复推荐或冲突推荐均无效。
推荐信息必须在报名时提交；若参与者已在无推荐或使用其他推荐信息的情况下完成报名，后续补提的推荐信息将不予受理。
推荐奖励将在 Build Games 比赛结果最终确认后发放。
推荐人是否具备领奖资格，由雪崩基金会（Avalanche Foundation）全权判定，且需满足相关核验、税务申报及其他合规要求。
奖金的发放时间、方式及币种，由雪崩基金会全权决定。
在法律禁止的地区，参与本推荐计划无效。
雪崩基金会可自行决定，将其员工、承包商或关联方排除在获奖资格之外。
若发现任何参与者或推荐人存在欺诈、操控、虚假陈述，或任何被认定为损害 Build Games 赛事及本推荐计划公正性的行为，雪崩基金会保留全权取消其参与资格的权利。
雪崩基金会根据本条款作出的所有决定均为最终决定，具有约束力。
所有条款与细则可随时变更。
通过创建或使用推荐链接，即表示您已阅读并同意遵守本条款与细则。
Build Games开幕式PPT
团队分工方案
需要提交的东西：
功能原型、包含代码的 GitHub 存储库、技术实现细节以及产品演示视频（最多 5 分钟），演示关键功能。
评估标准：
技术实现质量、Avalanche技术的使用、MVP架构设计以及UX设计。
我们的MVP：
- 扫码领取nft (已实现) 扫码领取USDT红包(未实现)
- 工厂合约生成子合约（已实现）
- 前端设计，前端界面符合Avalanche防二次灌装方案（未实现）
- 把智能合约迁移到Avalanche（未实现）
- 扫码以后把数据记录到redis数据库（未实现）
- 用户扫码后，前端要提示什么时候在哪里领取的多少红包（未实现）
- 二次扫码以后从数据库调出第一次领取红包的信息（未实现）
重新排期的任务拆解（按“3月7日完成”倒推）
阶段1：技术底层攻坚（3月1日前完成）
| 任务ID | 任务名称 | 负责人 | 核心交付物 | 3月1日验收标准 | 协作要求（每日18:00同步） |
|---|---|---|---|---|---|
| T1 | 智能合约迁移到Avalanche + 验证 | 李师傅 | 1. 迁移后合约源码（带Avalanche适配注释）； 2. C-Chain部署地址+区块浏览器验证链接； 3. 合约调用测试脚本（工厂生成子合约/NFT领取逻辑）。 |
1. 合约部署成功，所有已实现功能（扫码领NFT/工厂合约）在Avalanche测试网100%可用； 2. 无Gas超限/调用失败问题； 3. 测试脚本一键运行验证。 |
李师傅每日同步部署进度，你/米米随时协调Avalanche生态问题（如测试网 faucet）。 |
| T2 | Redis环境+数据结构+核心API | 玥玥（李师傅协助） | 1. Redis云服务器部署（公网可访问）； 2. 扫码数据结构文档（含NFT ID/领取时间/地点/红包金额/扫码次数）； 3. 增/查API（带接口文档）。 |
1. API调用成功率100%； 2. 数据结构覆盖“防二次灌装”所有核心字段； 3. 提供Postman测试集合。 |
玥玥完成API后，李师傅立即联调合约数据关联逻辑，当天闭环。 |
阶段2：前端+数据交互（3月3日前完成）
| 任务ID | 任务名称 | 负责人 | 核心交付物 | 3月3日验收标准 | 协作要求（每日18:00同步） |
|---|---|---|---|---|---|
| T3 | 前端界面开发（符合Avalanche防二次灌装） | 玥玥（你审核） | 1. 前端源码（可直接运行）； 2. 界面原型终版； 3. 多语言（核心语种）适配。如果时间紧就只做英文版，不要中文版 |
1. 前端流程：扫码→领NFT→红包展示→二次扫码提示，100%匹配防灌装逻辑； 2. 界面无UI/交互bug。 |
你在3月2日前确认UI原型，玥玥3月3日前完成开发，当天你完成UX验收，无异议闭环。 |
| T4 | 扫码写Redis+二次扫码查数据 | 玥玥 | 1. 扫码接口与Redis联动源码； 2. 二次扫码数据回显逻辑； 3. “疑似二次灌装”提示文案终版； 4. 测试用例（10组真实扫码场景）。 |
1. 首次扫码数据写入Redis 100%成功； 2. 二次扫码1秒内回显首次数据； 3. 提示文案清晰且符合方案要求。 |
玥玥3月3日中午前完成开发，下午李师傅协助测试链上数据与Redis一致性，当天闭环。 |
| T5 | 前端红包信息展示（链上+Redis双验证） | 玥玥 | 1. 红包信息展示模块源码； 2. 数据验证逻辑文档； 3. 展示样式终版。 |
1. 展示信息（时间/地点/金额）100%准确； 2. 双验证逻辑生效（链上合约+Redis数据一致）； 3. 展示无延迟/卡顿。 |
3月3日下班前验收，你确认展示效果符合UX要求，无异议闭环。 |
阶段3：整合+交付物打包（3月5日前完成）
| 任务ID | 任务名称 | 负责人 | 核心交付物 | 3月5日验收标准 | 协作要求（每日18:00同步） |
|---|---|---|---|---|---|
| T6 | GitHub仓库整理+技术文档编写 | 米米（全员配合） | 1. GitHub仓库（含所有源码+分支管理）； 2. 技术实现细节文档（含Avalanche使用/MVP架构/UX设计）； 3. README（部署+运行+测试全流程）。 |
1. 仓库结构清晰，代码可一键部署； 2. 技术文档覆盖评估所有维度； 3. README能指导新手快速运行项目。 |
李师傅/玥玥3月4日前提交各自源码，米米3月5日前完成整合+文档，你审核文档完整性。 |
| T7 | 演示视频脚本+素材录制 | 你（全员配合） | 1. 5分钟演示脚本终版； 2. 功能演示素材（扫码/领NFT/红包展示/二次扫码）； 3. 视频旁白文案。 |
1. 脚本覆盖所有关键功能； 2. 素材录制无卡顿/错误； 3. 旁白贴合“游戏化+防灌装”核心逻辑。 |
米米协调录制时间，李师傅/玥玥配合演示操作，3月5日下班前完成素材收集。 |
阶段4：最终整合+视频剪辑（3月7日前完成，兜底闭环）
| 任务ID | 任务名称 | 负责人 | 核心交付物 | 3月7日验收标准（最终闭环） | 协作要求（每日18:00同步） |
|---|---|---|---|---|---|
| T8 | 全流程端到端测试+Bug修复 | 米米（全员） | 1. 测试报告（覆盖所有功能点）； 2. Bug修复记录； 3. 最终可运行版本。 |
1. 所有功能100%正常运行（无遗漏/报错）； 2. 测试报告无高/中风险问题； 3. 符合Avalanche评估所有维度。 |
3月6日全天测试，3月7日上午修复所有Bug，下午验收闭环。 |
| T9 | 演示视频剪辑+最终交付物打包 | 你（米米协助） | 1. 5分钟内演示视频（MP4）； 2. 最终交付物压缩包（GitHub链接+技术文档+视频+原型）； 3. 提交清单。 |
1. 视频清晰展示关键功能； 2. 交付物完整无缺失； 3. 提交清单匹配要求。 |
3月7日中午前完成视频剪辑，下午你完成最终验收，米米整理交付物包。 |
关键保障机制（确保3月7日必完成）
1. 每日强制同步机制
- 时间：每天10:00（晨会）+ 18:00（夕会），各5-10分钟
- 内容：
- 晨会：同步当天计划，确认卡点（如合约部署失败、API联调问题）；
- 夕会：同步完成进度，未完成项立即协调资源（你兜底跨角色支持，如协助玥玥调前端、协助李师傅查合约问题）。
- 记录：米米每日更新《进度追踪表》，标记“已完成/卡点/需协助”，同步至全员。
2. 卡点兜底方案
| 可能卡点 | 兜底措施 |
|---|---|
| 李师傅合约迁移遇问题 | 你协调Avalanche生态资源（如官方文档/社区），玥玥暂停非核心前端开发协助排查； |
| 玥玥前端联调Redis失败 | 李师傅优先放下合约优化，协助调试数据联动逻辑； |
| 测试发现高风险Bug | 全员暂停非核心任务，聚焦修复，米米调整排期（压缩视频剪辑/文档美化时间）； |
| 视频剪辑时间不足 | 优先保证核心功能演示，简化非关键画面，确保5分钟内覆盖所有评估点。 |
3. 3月7日验收标准（必须100%达成）
- 功能层面：扫码领NFT、工厂合约、前端防灌装界面、Redis数据记录/查询、二次扫码提示、红包展示，所有功能无报错；
- 技术层面：合约部署在Avalanche C-Chain、Redis数据准确、前端UX符合要求；
- 交付物层面：GitHub仓库完整、技术文档覆盖评估点、演示视频达标；
- 验收人：你+米米，3月7日18:00前签字确认，无异议则闭环。
3月8日查漏补缺计划（预留时间）
| 时间段 | 核心动作 |
|---|---|
| 09:00-12:00 | 你逐一验证交付物： 1. GitHub代码可一键部署； 2. 技术文档无遗漏； 3. 演示视频逻辑清晰； 4. 功能全流程复测。 |
| 14:00-18:00 | 修复微小问题（如文案优化、界面样式调整、文档错别字），最终打包提交物，确认提交路径/格式。 |
最终交付物清单（3月7日完成，3月8日确认）
- GitHub存储库（含合约源码、前端源码、Redis API、README、技术实现细节文档）；
- 功能原型（可运行的前端界面）；
- 技术实现细节文档（重点突出Avalanche使用、MVP架构、UX设计）；
- 5分钟内演示视频（展示：扫码领NFT→红包信息展示→二次扫码防灌装提示）；
- 提交清单（匹配主办方要求，标注各交付物链接/路径）。
此方案通过“节点提前+强制同步+卡点兜底”确保3月7日完成所有开发，预留3月8日全流程查漏补缺，3月9日可无风险提交，且所有任务均对齐Avalanche评估标准（技术质量、Avalanche使用、MVP架构、UX设计）。
各技术点耗时评估（基于3月7日前完成的目标）
以下评估结合“开发+测试+联调+验收”全流程，按人天（1人天=8小时）计算，已预留10%-20%的缓冲时间（应对联调、bug修复等不可控因素），同时标注核心依赖关系，方便你把控整体节奏。
一、智能合约相关（李师傅负责）
| 技术点 | 预估耗时 | 细分耗时（小时） | 关键说明 | 依赖项 |
|---|---|---|---|---|
| 智能合约迁移到Avalanche | 2人天 | 1. 适配Avalanche语法/Gas机制：6h 2. 部署测试（测试网）：4h 3. 功能验证/BUG修复：6h |
核心耗时在“Gas优化”和“跨链兼容性验证”，需多次部署测试；若熟悉Avalanche生态可压缩至1.5人天。 | 无（独立完成） |
| 合约与Redis数据联动逻辑设计 | 0.5人天 | 1. 数据关联逻辑设计：2h 2. 测试脚本编写：2h |
仅需定义“链上NFT数据→Redis写入”的校验规则，无需编码（编码由玥玥完成）。 | 玥玥的Redis API完成 |
二、Redis相关（玥玥负责）
| 技术点 | 预估耗时 | 细分耗时（小时） | 关键说明 | 依赖项 |
|---|---|---|---|---|
| Redis环境搭建+数据结构设计 | 1人天 | 1. 云服务器部署/配置：3h 2. 数据结构设计+评审：2h 3. 增/查API开发：3h |
云服务器环境搭建需考虑网络权限、安全组配置，预留缓冲时间；数据结构需你审核确认。 | 无（独立完成） |
| 扫码数据写入Redis | 1人天 | 1. 扫码接口对接：3h 2. 数据写入逻辑：2h 3. 联调测试：3h |
核心耗时在“扫码接口与Redis的联调”，需确保数据实时写入且与链上NFT信息一致。 | 李师傅的合约迁移完成、Redis API完成 |
| 二次扫码数据查询+回显逻辑 | 0.5人天 | 1. 查询逻辑开发：2h 2. 二次扫码判断逻辑：2h |
逻辑简单，重点是“扫码次数判断”和“首次数据精准回显”。 | 扫码数据写入Redis完成 |
三、前端相关（玥玥负责）
| 技术点 | 预估耗时 | 细分耗时（小时） | 关键说明 | 依赖项 |
|---|---|---|---|---|
| 前端界面设计（符合Avalanche防二次灌装） | 2人天 | 1. UI原型设计+评审：4h 2. 页面开发（4个核心页）：8h 3. 钱包联调：4h |
核心耗时在“防二次灌装流程适配”和“Avalanche钱包联调”，需你审核UI原型，避免反复修改。 | 无（原型确认后独立开发） |
| 红包信息前端展示 | 1人天 | 1. 展示模块开发：4h 2. 链上+Redis双验证逻辑：2h 3. 样式优化：2h |
重点是“双验证逻辑”确保数据准确，样式需符合UX设计要求。 | 扫码数据写入Redis完成 |
| 二次扫码提示展示 | 0.5人天 | 1. 提示模块开发：2h 2. 样式/文案优化：2h |
逻辑简单，重点是提示语清晰、样式醒目，需你确认文案。 | 二次扫码数据查询完成 |
四、整合与交付物相关
| 技术点 | 负责人 | 预估耗时 | 细分耗时（小时） | 关键说明 | 依赖项 |
|---|---|---|---|---|---|
| GitHub仓库整理 | 米米 | 1人天 | 1. 代码整合：3h 2. 目录梳理+README编写：3h 3. 验收：2h |
需全员配合提交最新代码，重点是README的“部署说明”要详细。 | 所有源码开发完成 |
| 技术实现细节文档编写 | 李+玥+米 | 1.5人天 | 1. 李师傅写合约/Avalanche部分：4h 2. 玥玥写前端/Redis部分：4h 3. 米米整合+审核：4h |
文档需覆盖评估的4个维度，重点突出Avalanche技术使用。 | 合约/前端/Redis开发完成 |
| 演示视频脚本+录制+剪辑 | 你+米米 | 2人天 | 1. 脚本设计+评审：3h 2. 功能录制：4h 3. 剪辑+字幕：7h |
录制需全员配合演示操作，剪辑重点是控制在5分钟内，覆盖所有关键功能。 | 所有功能开发完成 |
| 全流程端到端测试+Bug修复 | 全员 | 1.5人天 | 1. 测试用例执行：4h 2. Bug定位+修复：6h 3. 回归测试：2h |
重点测试“扫码→领NFT→查红包→二次扫码”全流程，预留足够修复时间。 | 所有功能开发完成 |
五、总耗时汇总（按角色）
| 角色 | 核心任务耗时（人天） | 缓冲/协调耗时（人天） | 总计（人天） | 对应日历时间（3月1日前启动） |
|---|---|---|---|---|
| 李师傅 | 2.5（合约迁移+联动） | 0.5（联调/测试） | 3 | 3月1日前完成 |
| 玥玥 | 6（Redis+前端全量） | 1（联调/改需求） | 7 | 3月3日前完成 |
| 米米 | 3.5（仓库+文档+测试） | 0.5（进度跟踪） | 4 | 3月5日前完成 |
| 你 | 2（视频+审核+协调） | 1（卡点兜底/决策） | 3 | 贯穿全程，3月7日前完成视频 |
六、关键时间节点验证
按上述耗时，核心里程碑可完全匹配“3月7日前完成”的目标：
- 3月1日前：李师傅完成合约迁移（3人天）、玥玥完成Redis环境+API（1人天）→ 底层就绪；
- 3月3日前：玥玥完成前端全量开发（6人天）→ 功能层就绪；
- 3月5日前：米米完成仓库+文档（3.5人天）、你完成视频素材录制 → 交付物雏形；
- 3月7日前：全员完成测试+修复（1.5人天）、你完成视频剪辑 → 最终交付物就绪。
总结
- 核心耗时集中在前端界面开发（2人天） 和智能合约迁移（2人天），这两个环节是进度卡点，需优先保障；
- 联调/测试/文档类工作合计约4人天，不可压缩，需预留足够时间；
- 所有技术点总耗时（不含缓冲）约14人天，按4人分工，在10天（3月1日-3月10日）内可完成，提前至3月7日完全可行（通过每日同步压缩缓冲时间）。
在区块链系统中，验证者（validators）扮演什么角色？（选择所有适用项）
- 对交易执行的顺序达成共识
- 决定数字资产的价格
- 管控区块链的电力消耗
- 运行一个或多个虚拟机实例
正确答案（方便你答题）：
- They reach consensus on the sequence in which transactions are carried out
- They operate one or more instances of the virtual machines
验证者如何确保它们对状态拥有一致的视图？
A
通过为每个验证者分配区块链中一个独有的部分来监控
B
通过所有验证者以相同顺序在本地虚拟机实例上执行操作
C
通过中心化机构人工检查每一笔交易
正确答案：B
在区块链语境中，什么是虚拟机（VM）？
A
一种能够在受控环境中执行程序的去中心化计算机
B
运行区块链网络的物理机器
C
一台售卖汽水的机器
What’s the P-Chain’s main purpose?
A
Provide a backup for the C-Chain and X- Chain
B
Keep record of all transactions on both the Primary Network and all L1s
C
Have a registry of all validators in the Avalanche network
D
Manage the validator set of all L1s
答案是什么
正确答案是 C。
以下是关于 Avalanche P-Chain（Platform Chain）主要功能的详细解析：
P-Chain 的核心作用
P-Chain 是 Avalanche 网络中的元数据区块链，主要负责管理整个网络的底层架构。
- 管理验证者（Validator Registry）： 这是 P-Chain 最主要的功能。它维护着所有正在验证 Avalanche 网络（包括主网和各个 L1/子网）的节点列表。
- 质押（Staking）： 用户在 P-Chain 上锁定 AVAX 以成为验证者或委托人，从而获取奖励。
- 创建和管理 L1（子网）： 开发者通过 P-Chain 创建新的 L1（原称 Subnet），并由 P-Chain 记录哪些验证者属于哪个特定的 L1。
- 协调网络： 它跟踪整个网络的活跃状态，确保各个分片和 L1 能够正常运行。
为什么其他选项不准确？
- A 错误： P-Chain 并不是 C-Chain 或 X-Chain 的“备份”。三条链各司其职（C-Chain 处理智能合约，X-Chain 处理资产创建与交换），它们共同构成了主网。
- B 错误： P-Chain 不记录 C-Chain 或 X-Chain 上的具体交易内容（如转账额度或合约调用）。它只记录与验证者、质押和网络治理相关的元数据。
- D 错误： 虽然 P-Chain 负责 L1 的创建和验证者名单的登记，但它并不直接“管理”每个 L1 内部的运作。每个 L1 拥有自己的共识机制和规则。
总结： 如果你想查找“目前网络中有多少验证者”或“如何参与质押”，你需要交互的就是 P-Chain。
获取证书
https://build.avax.network/academy/avalanche-l1/avalanche-fundamentals/get-certificate
Avalanche的设计本来是可以下载一个PDF的证书，证明完整了基础课程。
但是他们的网站内部服务器错误导致无法下载。
不仅如此，他们的网站还在报名的时候浏览器崩溃。
程序员水平堪忧，很难相信这种链是Web3排名前几的老链。
