Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

P3 dispute: upheld S4 dispute slashes colluders but never replaces the wrong finalCID or refunds the honest dissenter

Đang mở
#194 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
solidity
Lĩnh vực
blockchain, security

Hướng nghiên cứu

Read foundry/src/DINTaskCoordinator.sol around settleRecomputation and the bad consensus slash in DINTaskCoordinator.sol:971, then review Developer/design/adversarial-threat-model.md row 5 and Part 2's test_knownGap_t1WrongCID. First define how confirmed disputes recover dissenters' slashes and install a recomputed CID through downstream T2 and global model state; completion should make test_defended_t1WrongCID pass.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Summary

An upheld and confirmed S4 dispute punishes the colluding T1 aggregators but does not repair the damage. The wrong CID stays the batch's result, and the honest dissenter stays slashed.

Scenario: 2 of 3 aggregators in a T1 batch collude and submit the same wrong CID. Majority vote finalizes it, and the honest third aggregator is slashed a full minStake for AGG_T1_BAD_CONSENSUS (foundry/src/DINTaskCoordinator.sol:971), because its CID disagrees with the (wrong) majority.

The S4 path is openDispute → lockDisputeSeed → resolveDispute(upheld=true) → settleRecomputation(confirmed=true). On confirmed=true, settleRecomputation (DINTaskCoordinator.sol:1351-1400):

  • returns the challenger's bond (disputeBondClaimable),
  • slashes the aggregators whose submission matched the disputed CID, S4_INVALID_AGGREGATION,
  • does not replace tier1Batches[_GI][batchId].finalCID (or the T2 equivalent), so the wrong model remains in that GI's aggregation,
  • does not refund the honest dissenter's AGG_T1_BAD_CONSENSUS slash.

_assignFreshSubgroup is bookkeeping only and does not re-open the GI state machine. The fresh subgroup never submits a CID on-chain, so there is no corrected CID to install even if the contract wanted to.

Impact

This holds even with an honest owner-adjudicator (TA-1). The attack partially succeeds: the wrong model propagates for that GI, and the only validator who behaved correctly loses a full minStake. That also discourages honest dissent in future batches.

This is separate from No. 181, which is about who adjudicates disputes (removing the owner-adjudicator trust assumption). This issue is about what a successful dispute does, whoever adjudicates it.

Needed

  1. Refund the dissenter: on confirmed=true, reverse the AGG_T1_BAD_CONSENSUS / AGG_T2_BAD_CONSENSUS slash for batch members whose submission differed from the disputed finalCID. This needs either a refund path on DinValidatorStake or the bad-consensus slash held pending until the dispute window closes.
  2. Repair the result: have the fresh subgroup submit its recomputed CID on-chain and install it as finalCID on confirmed=true, or define what happens downstream (T2 / next GI's global model) when a finalized CID is later shown to be wrong.

Both touch slashing/dispute mechanism design, so this likely needs a design note before implementation.

Tracking

Row 5 (KNOWN GAP, decided in PR No. 182's review) of the adversarial threat model, Developer/design/adversarial-threat-model.md (task_240926_17). Part 2's test_knownGap_t1WrongCID should flip to test_defended_t1WrongCID when this is fixed.

Ngôn ngữ chính
Python
Star
4
Fork
7
Merge trung bình
3 ngày 58 phút
Pull request đã merge (30 ngày)
39

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của InfiniteZeroFoundation/DevNet

Tất cả issue của InfiniteZeroFoundation/DevNet

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.