Repository navigation
Conversation
…ker (phase 1) Design for replacing the parachain's permissionless, key-based validator group changes with a main-chain enforced state machine: - validator set changes are proposed by the parachain governance and only take effect via an explicit Activate after a risk-tiered delay: above the locked-asset threshold they require autonomy approval plus a 1 day lock (cancellable in the window), below it a 7 day lock without approval. The commit verification read path is unchanged, so main chain and parachain always agree on the active set. - governance can cut off cross-chain fund flow for a given parachain in both directions as an emergency stop. - phase 2 roadmap (challenge window + mavl witness fraud proofs, sampling and slashing, zk validity proofs) and the residual risk of still permissionless bootstrap are documented. Sections 1-6 were reviewed and confirmed section by section before this spec was written.
12 TDD tasks: constants/params and fork registration, state encoding and kv helpers, Propose/Approve/Cancel/Activate state machine, entry point rewiring (NodeGroupConfig/NodeConfig/SupervisionNodeConfig), query, the governance circuit breaker plus its enforcement on submit and on pending cross tx execution, fork config rollout, main/para consistency and rollback integration tests, and CLI/ops docs. Self-review fixed: error and log constants now declared in task 1, FromAddr added to the state struct up front, exact wire format spelled out, and the six review-focus failure modes each pinned to a task test.
Add docs/cip/ with the CIP process (types, status lifecycle, numbering, header metadata, submission flow), a template, and the first proposal: CIP-001 (Standards Track, Draft): validator set changes on a parachain must go through a main chain enforced state machine - parachain proposal, risk tiered governance approval (above the locked-asset threshold: 1 day, cancellable) or a 7 day lock, then an explicit Activate. Commit verification reads are unchanged so main chain and parachain cannot diverge on the active set. A governance controlled circuit breaker can cut cross chain fund flow in both directions. Phase 2 (challenge window with mavl witness fraud proofs, sampling, slashing, zk) is scoped as a follow-up CIP.
The 100k BTY tier threshold must not be fixed in code or node config, so
CIP-001, the design spec and the implementation plan now define it as an
on-chain paracross parameter decided by main chain governance:
- two-step flow reusing the existing autonomy PropItem pattern
(ParamPropose=15 writes {id=tx hash, value}, board votes on that hash,
ParamApply=16 verifies IsAutonomyApprovedItem and writes the value);
the proposal tx hash binds the value, so an approved item id alone
cannot be used to inject an arbitrary threshold.
- the value takes effect immediately but only for proposals created
afterwards: a proposal snapshots its tier at Propose time, so changing
the threshold cannot retrospectively reclassify an in-flight change.
- chain config now only carries the two delay parameters; the code
default (100000 x precision) applies only while the state key is
absent.
Plan gains Task 8 (param state machine) and a seventh review focus item
for threshold injection; tasks 8-12 renumbered to 9-13.
…ic symbol CIP-001, the design spec and the plan now state every amount in the main chain native coin (the cfg.GetCoinExec() coin, smallest unit given by coinPrecision) instead of naming a particular chain's token. The unit is defined once in the specification, and the plan's global constraints no longer describe the threshold as a chain config value (it is the governance voted on-chain parameter from the previous commit).
The unit-test failure on this branch was a pre-existing data race in plugin/dapp/paracross/testnode (fixed separately in the CI PR); this empty commit re-runs the checks. Drop it when squashing.
|
对 CIP-001 做了一轮审查（文档内部一致性 / 与现有实现和历史对账 / 关键结论均有实跑验证）。总体：方向与结构没有问题（显式 一、需要拍板（方案性取舍）1. 急停期间被跳过的挂起提现：丢弃还是延后？CIP 第 163–164 行写"解除后挂起提现可正常执行，无需重新提交"，但按计划的实现（
⇒ 该高度的跨链交易一生只执行一次，被跳过即永久不可执行（资金仍留在 paracross 池里，不是蒸发）。建议二选一并写进规范：(i) 承诺改为"需重新提交"，并写清平行链侧已扣部分的口径；(ii) 要求实现提供重放队列（需新增状态键与顺序/回滚处理，Phase 1 实现量上升）。 附带：急停的触发与解除都要走完整 autonomy 提案，与"止血"的时效要求不匹配；建议单设低延迟通道 + 自动过期。 2.
|
bysomeone
left a comment
bysomeone
left a comment
There was a problem hiding this comment.
按 10-15 那条审查评论：方向与结构没有问题，但有 3 项需要作者拍板的方案性取舍、7 项可直接修订，建议在定稿前补齐。逐条意见与对应代码位置见该评论：#1327 (comment)
2 participants
背景
Bitcoin 有 BIP、Ethereum 有 EIP，chain33 目前没有任何改进提案机制（仓库内只有零散的
docs/*.md，无 CONTRIBUTING、无 PR 模板）。本 PR 建立 CIP（Chain33 Improvement Proposal） 目录与流程，并提交第一份提案 CIP-001。本 PR 内容
📄 CIP-001 全文（点击查看）
CIP-001 摘要：把 paracross 平行链验证人集合的更换，从"节点组内部 2/3 投票达成即生效"改为「平行链提案 → 主链分档治理/时间锁 → 显式
Activate」，并新增治理可控的双向跨链急停：Activate在到点后完成，commit 校验读路径不变，主链与平行链不会对"有效集合"产生分歧；明确不解决（写入 CIP 的安全考虑）：多数验证人联合作恶仍可伪造状态盗取资产——需 Phase 2（挑战期 + mavl 见证式欺诈证明、抽样罚没、zk）；首次建组仍为自由注册，该缺口作为已接受风险记录并给出监控/急停缓解。
附带的支撑文档
同分支还包含 CIP-001 的设计工作稿与实施计划，便于评审时看到完整依据：
docs/superpowers/specs/2026-10-14-paracross-validator-governance-design.md（逐节评审通过的设计）docs/superpowers/plans/2026-10-14-paracross-validator-governance.md（12 个 TDD 任务的实施计划）实施代码不在本 PR：CIP 定稿后再另开实现 PR。
依赖与评审
requires指向 fix(paracross): bind node group title to its exact para execer #1326（paracross title 与 execer 精确绑定）——该修复是 CIP 规范中"title 必须规范且与 execer 精确对应"的前置项。status: Draft。状态推进（Review → Last Call → Accepted）与 CIP 序号确认请维护者在 PR 中裁定。discussions-to暂指仓库 issue 列表，如需专用讨论渠道/邮件列表请指出。