Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#185 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python, solidity
Domaine
backend-api-design, blockchain, devtools, security

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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").
Langage dominant
Python
Étoiles
4
Forks
7
Merge moyen
3 j 5 h
PR mergées (30 j)
34

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de InfiniteZeroFoundation/DevNet

Toutes les issues de InfiniteZeroFoundation/DevNet

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.