DAO v1.1 Bug Fixing Report
Issues and Fixes
Thanks to the community member @phroi for the voluntary work. More bugs of the DAO v1.1 platform have been uncovered and listed here
The table below shows the current progress on bug fixes; the numbers in the first column correspond to those in Phroi’s original post.
Additionally, since community members @woodbury.bit and @phroi both raised concerns about the system design’s centralization risk, the proposal team proposes a possible countermeasure in the last section of this post.
| Problems | Description | Status | Notes |
|---|---|---|---|
| 3.1 - 4.1 | voter list-related issues | Design retained with documentation | The current decision is still to keep the existing design. With an audit tool developed by the community, the results would be easily verifiable. Below is the system design doc: Vote System |
| 4.2 | Unverified indexer trust | Solution proposed | An alternative solution has been proposed in the last section of this post - “Regarding Centralization”. |
| 4.3 | Sybil weight amplification | Fixed | |
| 4.4 | Unauthenticated update_state | Fixed | |
| 4.5 | DID-level proposal whitelist | Fixed | |
| 4.6 | Stale whitelist via timing | Fixed | |
| 4.7 | Unauthenticated build-whitelist | Fixed | |
| 4.8 | Selective proof denial | Fixed | |
| 4.9 | Premature vote termination | Fixed | |
| 4.10 | Voter enumeration via proof endpoint | Fixed | |
| 5.1 | Browser-only key storage | Design Retained | Explained in detail below this table. |
| 5.2 | 8-minute voting window | Fixed | |
| 5.3 | Whitelist ID format mismatch | Fixed | |
| 5.4 | Hardcoded testnet | Fixed | |
| 5.5 | DAO deposit detection failures | Fixed | |
| 5.6 | Wrong hashes in frontend config | Fixed |
On Issue 5.1 (Browser-only key storage)
Before reaching the current solution, the proposal team also considered the following options:
- Same as Bluesky: Store sign key in a centralized PDS. Rejected due to high centralization risk.
- Reuse existing CKB wallet: Two possible ways have been considered.
- Set a dedicated key derivation path: Use the user’s existing ckb address to derive a sign key. Rejected because wallets do not support customized private key derivation paths for security reasons.
- Deterministic signature: Use the user’s existing ckb address to sign a pre-determined message, and use the hash of the signature as the sign key. Rejected because ckb does not require the signature algorithm used by wallets to be deterministic.
- Use one DID document to manage multiple sign keys: Create a new sign key each time a user uses the same DID on a new device. Rejected due to the complex key maintenance procedure, requiring on-chain transactions when adding/deleting keys, and poor compatibility with the AT protocol.
- Similar to Google: Key backup service. Rejected due to high centralization risk.
After the above discussions, the proposal team had to make a trade-off between user experience and security, which led to the current solution: store the sign key in the user-controlled browser’s local storage.
The Original Context of DAO v1.1 Proposal
It is important for the community to understand the proposal’s scope and its goals - a small step forward to a better governance system. So the proposal team highlighted some crucial information from the original proposal below.
The Problems v1.1 Tried to Solve
Five challenges were identified in the original DAO v1.1 proposal. Three of them are listed here, which are most relevant to the current debates happening around the platform.
- Problem 1: Lack of institutionalized operational processes
- Problem 2: Fragmented governance tools
- Problem 3: Lack of information dissemination channels
The DAO v1.1 was never meant to be the final solution for CKB governance; it is a “small step forward,” as stated in the original proposal. The v1.1 platform is an attempt to provide a unified tool to help the community govern DAO proposals (Problems 2 + 3). The steward team is meant to provide guidance and assist the community during the entire proposal process (Problem 1).
However, the effects of Problem 1, combined with those of Problem 3, have already been shown. The discussion about the DAO v1.1 M2 delivery has been scattered across different Nervos Talk posts and Discord and Telegram channels.
The proposal team acknowledges that bugs are preventing the v1.1 platform from being launched, even as a trial run, and is providing active fixes based on community feedback (as shown in the Issues vs. Fixes table).
But, 1) as a result of lacking a formal procedure for evaluating deliveries (the exact problem the v1.1 platform meant to solve), the proposal team and the community have gradually come to a deadlock; 2) as a result of lacking information dissemination channels, some community members might feel unheard of or abandoned in the discussion, even though the problems have been answered in detail in other places.
The Steward Team
The steward team’s role has been described, debated, and modified in the original proposal. The steward team also prepared a document, “Steward Operation Manual,” to help the community understand the steward teams’ responsibilities.
- Description in proposal: Section 3.A
- Steward Operation Manual: Steward Operation Manual (Draft) - Google ドキュメント
The first three-person steward team serves only a transitional role for the first year, handling complex situations like the one we are currently in. After that, the steward team would be selected and voted on by the community. This was also described in detail in the proposal, which has passed the meta-rule change voting.
Core Design Philosophy
The three core philosophies are:
- Unified experience: to solve the fragmented tooling issue.
- Transparency: coordinated by the steward team to let the community know what happens in the full lifecycle of a proposal.
- Data ownership: web5-based identity solution.
Deliverable Checklist
The core deliverables of M2 described in the proposal are listed here, so the community can have a focused discussion to push this project forward:
- (Implemented) Enhancement of homepage functionality, including a data overview dashboard, proposal search, and status filtering.
- (Implemented) Launch of the milestone-based proposal governance feature.
- (Implemented) Completion of the Stewards Team and Governance Rules information pages.
- (In progress) The first round of bug fixes and UI/UX optimizations based on community feedback.
- (In progress) A feature-complete platform stably deployed in the mainnet production environment.
Milestone Evaluation
Since the CKB governance is transitioning from v1.0 to v1.1, with the new rule not yet in effect, the milestone evaluation will follow the v1.0 procedure. Since there is no specific process for milestone evaluation under the v1.0 rule, the proposal team will publish the M2 report (after Apr.17) to the community for evaluation. In case of a dispute, the final arbitration power lies with the Committee, not with the steward team or any members of the proposal team.
Regarding Centralization
The platform has already entered the third week of a 4-week public testing, and the proposal team is working to fix bugs; however, there is another issue they’d like the whole community to discuss.
Deployment and Maintenance
The proposal team is willing to cover deployment and maintenance themselves. However, since the community has raised concerns about potential manipulation, the proposal team is also open to funding a third party to manage deployment and maintenance.
Proper Maintenance Process
Even if the community feels comfortable letting the proposal team handle maintenance, it’s still important to establish a clear process for community members who want to contribute to the codebase. The proposal team would like to hear the community’s suggestions on this matter.
Sincerely,
Haoyang - The Steward Team
DAO v1.1 修复报告
问题与修复
感谢社区成员 @phroi 的志愿工作。更多关于 DAO v1.1 平台的错误已被发现并列出 在此。
下表展示了当前的修复进度；第一列中的编号与 Phroi 原始帖子中的编号相对应。
此外，由于社区成员 @woodbury.bit 和 @phroi 都对系统设计的中心化风险提出了担忧，提案团队在本帖的最后一部分提出了一个可能的应对措施。
| 问题编号 | 问题描述 | 状态 | 备注 |
|---|---|---|---|
| 3.1 - 4.1 | 与投票者列表相关的问题 | 保留设计，并提供文档说明 | 当前决定仍是保留现有设计。借助社区开发的审计工具，结果将易于验证。以下是系统设计文档： Vote System |
| 4.2 | 未经验证的索引器信任 | 已提出解决方案 | 在本帖最后一部分“关于中心化”中提出了替代方案。 |
| 4.3 | 女巫权重放大 | 已修复 | |
| 4.4 | 未经验证的 update_state | 已修复 | |
| 4.5 | DID 级别的提案白名单 | 已修复 | |
| 4.6 | 因时机导致的陈旧白名单 | 已修复 | |
| 4.7 | 未经验证的 build-whitelist | 已修复 | |
| 4.8 | 选择性证明拒绝 | 已修复 | |
| 4.9 | 投票提前终止 | 已修复 | |
| 4.10 | 通过证明端点枚举投票者 | 已修复 | |
| 5.1 | 仅限浏览器的密钥存储 | 保持当前设计 | 详情见下表后说明。 |
| 5.2 | 8 分钟投票窗口 | 已修复 | |
| 5.3 | 白名单 ID 格式不匹配 | 已修复 | |
| 5.4 | 硬编码测试网 | 已修复 | |
| 5.5 | DAO 存款检测失败 | 已修复 | |
| 5.6 | 前端配置中的错误哈希值 | 已修复 |
关于问题 5.1（仅限浏览器的密钥存储）
在达成当前解决方案之前，提案团队也考虑了以下选项：
- 与 Bluesky 相同：将签名密钥存储在中心化的 PDS 中。因中心化风险过高而被拒绝。
- 复用现有的 CKB 钱包：考虑了两种可能的方式。
- 设置专用的密钥派生路径：使用用户现有的 ckb 地址派生签名密钥。因钱包出于安全考虑不支持自定义私钥派生路径而被拒绝。
- 确定性签名：使用用户现有的 ckb 地址对预先确定的消息进行签名，并将签名的哈希值作为签名密钥。因 ckb 不要求钱包使用的签名算法具有确定性而被拒绝。
- 使用一个 DID 文档管理多个签名密钥：每次用户在新设备上使用同一个 DID 时创建一个新的签名密钥。因密钥维护流程复杂、添加/删除密钥需要链上交易、以及与 AT 协议兼容性差而被拒绝。
- 类似谷歌的方案：密钥备份服务。因中心化风险过高而被拒绝。
经过上述讨论，提案团队不得不在用户体验和安全性之间做出权衡，从而得出了当前的解决方案：将签名密钥存储在用户可控的浏览器本地存储中。
DAO v1.1 提案的原始背景
让社区了解该提案的范围及其目标——朝着更好的治理系统迈出的一小步——非常重要。因此，提案团队在下方强调了原始提案中的一些关键信息。
v1.1 试图解决的问题
原始 DAO v1.1 提案中确定了五个挑战。此处列出其中三个，它们与当前围绕该平台发生的讨论最为相关。
- 问题 1：缺乏制度化的运营流程
- 问题 2：治理工具碎片化
- 问题 3：缺乏信息传播渠道
DAO v1.1 从来都不是 CKB 治理的最终解决方案；正如原始提案所述，它只是“迈出的一小步”。v1.1 平台试图提供一个统一的工具来帮助社区治理 DAO 提案（问题 2 + 3）。物业团队则旨在在整个提案过程中提供指导并协助社区（问题 1）。
然而，问题 1 和问题 3 的影响已经显现。关于 DAO v1.1 M2 交付的讨论分散在不同的 Nervos Talk 帖子以及 Discord 和 Telegram 频道中。
提案团队承认，代码bug阻碍了 v1.1 平台的启动（即使是试运行），并且正在根据社区的反馈积极提供修复（如“问题与修复”表格所示）。
但是，1) 由于缺乏评估交付成果的正式程序（这正是 v1.1 平台试图解决的问题），提案团队与社区逐渐陷入僵局；2) 由于缺乏信息传播渠道，一些社区成员可能会感到自己的声音未被听取或在讨论中被忽视，即使相关问题已在其他地方得到详细解答。
物业团队
物业团队的角色在原始提案中已被描述、辩论和修改。物业团队还准备了一份文件《物业团队操作手册》，以帮助社区理解物业团队的职责。
- 提案中的描述：第 3.A 节
- 物业团队操作手册：Steward Operation Manual (Draft) - Google ドキュメント
首届三人物业团队仅在头一年担任过渡角色，处理像当前我们所处的这类复杂情况。此后，物业团队将由社区选拔和投票产生。这一点在已通过元规则变更投票的提案中也有详细描述。
核心设计理念
三个核心理念是：
- 统一体验：解决工具碎片化问题。
- 透明度：由物业团队协调，让社区了解提案完整生命周期中发生的事情。
- 数据所有权：基于 Web5 的身份解决方案。
可交付成果清单
以下列出提案中描述的 M2 核心可交付成果，以便社区进行有针对性的讨论，推动该项目向前发展：
- （已交付） 增强首页功能，包括数据概览仪表板、提案搜索和状态筛选。
- （已交付） 推出基于里程碑的提案治理功能。
- （已交付） 完成物业团队和治理规则信息页面。
- （进行中） 根据社区反馈进行第一轮错误修复和 UI/UX 优化。
- （进行中） 一个功能完备的平台，稳定部署在主网生产环境中。
里程碑评估
由于 CKB 治理正在从 v1.0 过渡到 v1.1，新规则尚未生效，里程碑评估将遵循 v1.0 的流程。由于 v1.0 规则下没有具体的里程碑评估流程，提案团队将在 4 月 17 日之后将 M2 报告发布给社区进行评估。如果发生争议，最终仲裁权属于委员会，而不是物业团队或提案团队的任何成员。
关于中心化
该平台已进入为期 4 周公开测试的第三周，提案团队正在努力修复错误；然而，还有另一个问题他们需要整个社区共同讨论。
部署与维护
提案团队愿意自行承担部署和维护工作。但是，由于社区对潜在的操作风险提出了担忧，提案团队也对资助第三方来管理部署和维护持开放态度。
规范的维护流程
即使社区对由提案团队处理维护工作感到满意，为希望为代码库做出贡献的社区成员建立一个清晰的流程仍然很重要。提案团队希望听取社区对此事的建议。
Sincerely,
Haoyang - 物业团队