感谢补充这篇文档。我认真读了以后，反而觉得我的核心疑问更明确了。
我现在的理解很简单：在 DAO1.1 里，投票不是“谁满足公开规则就能直接投”，而是“先进入一份名单，才能投”。
因为文档已经明确写了，DAO1.1 实际上采用的是 restricted vote：smt_root_hash 在实际使用中是 required，合约会先验证投票地址是否在 voter list 里。也就是说，不在这份名单里，就算你有真实的 CKB 质押，也进不了投票环节。
所以，对我来说，问题已经不只是 “whitelist 这个名字好不好听”，而是：
这份名单，到底只是机械生成的资格快照，还是后台在实现层面仍然保留了手动影响它的能力？
这正是我现在最想确认的点。
因为 @phroi 的代码审查里有一句非常关键的话：
“Anyone with database access can… Directly UPDATE the vote_whitelist table to add or remove addresses”
@phroi 后面还把这个过程解释得很具体：
如果有人能访问数据库，就可以等 nightly whitelist cron job 跑完后，直接改 vote_whitelist 表，增删地址；之后新创建的 vote 会引用修改后的名单，被移除的人去调用 /api/vote/prepare 时，就会收到 “Not in the whitelist”。这当然不等于已经发生了操控，但它说明一个更关键的问题：
当前公开文档解释了名单按什么规则生成，却没有充分证明当前实现已经在技术上排除了后台手动影响名单的可能。
这也是为什么我觉得，把 whitelist 改叫 voter list，并没有改变事情的本质。
只要链上合约验证的仍然是“你是否在这份预先生成的名单里”，那治理逻辑就已经从“符合公开规则即可参与”，变成了“先被纳入资格集合，才可以参与”。
这不是术语问题，而是治理结构问题。
进一步说，如果 whitelist / voter list 真的是核心架构的一部分，那么它就应该在最早的系统设计说明和治理讨论里被明确提出，并接受充分讨论。
如果它直到接近上线时，才被系统化解释为一个 design trade-off，那么问题就不只是设计本身，而是设计透明度和治理流程顺序都出了问题。
另外，我也想补充一点关于你们提到的 independent chain-reading audit tool。
我理解，团队说会和社区贡献者一起开发一个独立的链上审计工具，这当然比完全由提案团队单独开发更好。
但在我看来，“有社区贡献者参与”本身还不自动等于“已经足够独立”。
真正关键的是：
- 这些社区贡献者具体是谁，是否具有足够的独立性；
- 工具最终由谁主导，谁定义验证范围，谁掌握解释权；
- 代码和规则是否会完全开源；
- 社区是否能够自己运行这个工具，独立重建 voter list、重算
smt_root_hash、重算 tally，并复现相同结果。
如果这个工具只是团队自己开发、自己发布、自己解释，那么它仍然没有从根本上消除同样的信任问题。
所以在我看来，这样的工具至少需要做到：代码开源、规则公开、社区可自行运行、独立贡献者可以复现相同结果。
只有这样，它才更接近真正意义上的 “independent audit tool”，而不只是平台方提供的一个查看工具。
我也想顺便补一句：
如果这仍然是一个 still under testing / public review 的系统，我也希望团队能更明确地说明：
- 整体测试到底是谁做的？有没有公开的测试用例和测试报告？
- 测试环境和生产环境现在是否已经完全分离？对应的 URL、API、合约地址分别是什么？
- 为什么社区测试者还要先承担 450+ CKB 的 DID 成本，才能真正参与完整测试流程？
这些问题虽然是次级问题，但也都会影响社区对系统是否已经准备好正式上线的判断。
所以，我现在最核心的想法其实很简单：
如果投票资格边界仍然依赖一份预先生成的名单，那么团队除了说明这份名单“按什么规则生成”，还应该进一步说明并证明：当前实现是否真的已经排除了后台人工 override、数据库改表、临时替换 root、或者在 proof 准备阶段人为影响名单的可能。
同样，即使审计工具由开发团队与社区贡献者共同完成，团队也仍然需要进一步说明：这个工具是否足够独立、是否可以由社区自行运行、以及是否真的能在不依赖平台运营方的前提下完成验证。
如果这些问题还没有被明确回答和证明，那么在我看来，核心争议就仍然没有真正解决。
Thank you for sharing this document. After reading it carefully, my core concern actually became clearer.
My understanding is now very simple: in DAO1.1, voting is no longer “whoever satisfies the open rules can vote directly,” but rather “you must first be included in a list in order to vote.”
The documentation now makes this explicit: DAO1.1 is using a restricted-vote model in practice. smt_root_hash is required in actual usage, and the contract first checks whether the voting address is included in the voter list. In other words, if you are not in that list, then even real CKB deposits do not get you into the voting process.
So for me, the issue is no longer whether the word “whitelist” sounds too centralized. The real question is:
Is this list merely a mechanically generated eligibility snapshot, or does the backend still retain implementation-level ability to influence it manually?
That is the point I most want clarified.
Because @phroi’s code review contains one especially important line:
“Anyone with database access can… Directly UPDATE the vote_whitelist table to add or remove addresses”
@phroi then explains the flow more concretely:
if someone has database access, they can wait until the nightly whitelist cron job finishes, then directly modify the vote_whitelist table by adding or removing addresses; any subsequent vote creation would then reference the modified list, and a removed user calling /api/vote/prepare would get “Not in the whitelist.” This is of course not proof that manipulation has already happened, but it points to a more important issue:
the current public documentation explains how the list is supposed to be generated, but it does not yet sufficiently prove that the current implementation has technically eliminated backend-side manual influence over that list.
That is also why I do not think renaming “whitelist” to “voter list” changes the substance of the issue.
As long as the on-chain contract still checks whether a voter is included in a pre-generated list, the governance logic has already shifted from “whoever satisfies open rules can participate” to “whoever is first admitted into the eligibility set can participate.”
That is not a terminology issue. It is a governance-structure issue.
Going one step further: if the whitelist / voter list is truly part of the core architecture, then it should have been made explicit in the earliest system design documentation and governance discussions, and subjected to full debate at that stage.
If it is only being systematically explained near launch as a design trade-off, then the problem is no longer just the design itself, but also the transparency of the design and the sequencing of the governance process.
I would also like to add one more point regarding the independent chain-reading audit tool mentioned by the team.
I understand that the team says it will work together with community contributors to build such a tool, and that is certainly better than having the proposal team build it entirely on its own.
However, in my view, the mere fact that “community contributors” are involved does not automatically mean the tool is already sufficiently independent.
What matters more is:
- who those community contributors actually are, and whether they have sufficient independence;
- who ultimately leads the tool, defines the verification scope, and holds interpretive authority;
- whether the code and verification rules will be fully open-source and transparent;
- whether the community will be able to run the tool independently, reconstruct the voter list, recompute the
smt_root_hash, recompute the tally, and reproduce the same results on its own.
If the tool is still developed, released, and interpreted primarily by the team itself, then the same trust problem is not fundamentally removed.
So in my view, such a tool must at minimum be: open-source, rule-transparent, runnable by the community, and reproducible by independent contributors.
Only then would it be closer to a truly independent audit tool, rather than simply another platform-provided viewing tool.
I would also add one more point.
If this is still a system under testing / public review, then I also hope the team can clarify the following more explicitly:
- Who actually performed the overall testing, and is there any public test plan or test report?
- Are the test environment and production environment now fully separated, and what are the corresponding URLs, APIs, and contract addresses?
- Why must community testers first bear the 450+ CKB DID cost in order to meaningfully participate in the full testing workflow?
These may be secondary questions, but they also affect whether the community can reasonably view the system as ready for formal launch.
So my core point is actually very simple:
If voting eligibility still depends on a pre-generated list, then in addition to explaining how that list is “supposed” to be generated, the team should also explain and demonstrate whether the current implementation has truly eliminated manual override, database-level list modification, temporary root replacement, or human intervention during proof preparation.
Likewise, even if the audit tool is developed jointly by the dev team and community contributors, the team should still further clarify whether that tool is truly independent, whether it can be run by the community itself, and whether it can actually verify results without reliance on the platform operator.
If these questions have still not been clearly answered and demonstrated, then in my view the core controversy has not actually been resolved.
附录：DAO1.1第一步发起提案字体反色BUG | Appendix: Font Contrast Bug in Step 1 of DAO1.1 Proposal Submission
