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

DIN-Rep approval automation: verify task contracts and manifest CIDs before add-slasher / approveModel / approveManifestUpdate

Đang mở
  • Có gì không ổn?
#185 0 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ệ
python, solidity
Lĩnh vực
backend-api-design, blockchain, devtools, security

Hướng nghiên cứu

Start with dincli/cli/dinrep.py, especially add-slasher and list-pending-requests, then read dincli/services/ipfs.py and the task contract artifacts in foundry. Trace how load_din_info() supplies platform addresses and how tests/test_dintoken.py uses CliRunner and monkeypatch. Done means contract code and wiring checks, manifest classification, guarded approval decisions, and the described tests all work, including dry-run behavior.

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

Mô tả

enhancement Long run

Summary

Model owners deploy their own DINTaskCoordinator / DINTaskAuditor, and the DIN-Representative approves them (and later manifest updates) by hand. Nothing checks that the deployed contracts are the canonical code, that they are wired to the real platform contracts, or that the manifest points at standard services. This issue adds DIN-Rep-side automation that runs those checks and auto-approves, auto-rejects, or flags each request.

This implements the Model Approval decision from the 2026-09-18 testnet session: standard files that match known CIDs are approved automatically, custom code is flagged for review, the network stays permissionless, and the DIN-Rep does not become a bottleneck.

Verified against origin/develop @ 37b2daf.

Problem

  • dincli dinrep add-slasher checks nothing. dincli/cli/dinrep.py:189-246 sends DinCoordinator.addSlasherContract(addr) straight away. approve-registration-request / approve-manifest-update (dinrep.py:260, :282) are also plain transactions.
  • Every trust anchor inside a task contract is set by the model owner.
    • DINTaskCoordinator.dinvalidatorStakeContract is a constructor argument (foundry/src/DINTaskCoordinator.sol:256).
    • dinToken comes from setDinToken, which is onlyOwner and can be called again at any time: no one-shot guard in either the coordinator (:1101) or the auditor (DINTaskAuditor.sol:433).
  • Consequences for a model owner who deploys non-canonical code or wiring:
    • A modified coordinator can drop any access-control fix. For example, No. 181 moves dispute adjudication away from the model owner, and a modified coordinator could simply put it back.
    • A coordinator wired to a fake stake contract makes every slash a no-op, and makes owner()-based checks resolve to whoever deployed the fake.
    • Swapping dinToken after approval changes what dispute bonds and rewards are paid in.
  • Manifest approval is fully manual. Most models reuse the standard services, and a manual review of each one is the bottleneck raised in the session.

Proposed change

All on the DIN-Rep side in dincli. No contract changes.

  1. dincli dinrep verify-task-contracts --coordinator <addr> [--auditor <addr>]
    • Code: compare w3.eth.get_code(addr) with deployedBytecode.object from the canonical foundry artifact. Mask the byte ranges listed in deployedBytecode.immutableReferences first; modelId is immutable, so runtime code differs per model.
    • Accepted builds: a committed list of accepted build hashes per contract, one per release. That way a later docs-only .sol change doesn't fail verification for tasks deployed from an older release.
    • Wiring: read the public getters and compare them with the platform addresses from load_din_info():
      • dinvalidatorStakeContract() must be the platform DinValidatorStake.
      • dinToken() must be the platform DinToken.
      • The coordinator's dinTaskAuditorContract() and the auditor's coordinator must point at each other.
      • Both must report the same modelId.
    • Output: PASS / FAIL per check, with a reason.
  2. add-slasher runs (1) first and refuses on FAIL. --force overrides it with a printed warning, for deliberately reviewed custom contracts.
  3. dincli dinrep verify-manifest <manifestCID>
    • Fetches the manifest through dincli/services/ipfs.py.
    • Compares each service CID with a committed allowlist of standard service CIDs (the reference services in cache_model_0/services/).
    • A manifest with a task_contracts custom-ABI block counts as custom.
    • Result: STANDARD, or CUSTOM with the list of unknown CIDs.
  4. dincli dinrep registry process-requests [--dry-run]
    • Walks pending requests the same way list-pending-requests does (dinrep.py:428).
    • Model request: run (1) on taskCoordinator/taskAuditor and (3) on manifestCID.
    • Manifest request: run (3) on newManifestCID.
    • Decision:
      • Contract FAIL → rejectModel. rejectModel does not refund the fee (DINModelRegistry.sol:261), so the report states that.
      • STANDARD + PASS → approveModel / approveManifestUpdate.
      • CUSTOM → leave pending and list it in the report for human review.
    • --dry-run prints the decisions without sending transactions.

Out of scope

  • AI-assisted review of custom Python: the approval-automation analysis from the session (Santiago).
  • Running process-requests on a schedule: a daemon job once PR No. 32 lands.
  • An on-chain code-hash allowlist in DinValidatorStake.addSlasherContract: immutables make runtime code differ per model, so on-chain verification would need a factory that deploys the task pair. Worth revisiting post-mainnet.
  • Making setDinToken one-shot: the contract-side fix is in No. 181 Stage 1. This issue only checks the value at approval time.

Verification

  • pytest with typer.testing.CliRunner + monkeypatch, in the style of tests/test_dintoken.py:
    • code matches;
    • code differs;
    • only the immutable ranges differ (must PASS);
    • wrong stake or token wiring;
    • manifest STANDARD / CUSTOM;
    • add-slasher refuses on FAIL and proceeds with --force;
    • process-requests --dry-run report for a mix of requests.
  • One integration-marked test: deploy a task pair on anvil with the real DeployPlatform flow, and check that verify-task-contracts PASSes.

Links

  • No. 181: its adjudicator gate only holds if the coordinator is canonical code wired to the real DinValidatorStake, which this issue enforces.
  • PR No. 183 touches dincli/cli/dinrep.py, so rebase onto it once it merges.
  • Session notes 2026-09-18, Model Approval (M1 39:11–44:28) and decisions ("Automate approval for standard manifests; review custom code").
Ngôn ngữ chính
Python
Star
4
Fork
7
Merge trung bình
3 ngày 5 giờ
Pull request đã merge (30 ngày)
34

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.