Skip to content

task_060726_4.md

Latest commit

 

History

History
155 lines (106 loc) · 11.8 KB

task_060726_4.md

File metadata and controls

155 lines (106 loc) · 11.8 KB
Raw

Task: Foundry Contracts Security Review + Filecoin Provider Recommendation (Discussion #18)

ID: task_060726_4 Assigned to: Similoluwa Abidoye (@Abidoyesimze) Created: 2026-07-06 Status: Open Type: Trial task (work from a fork) Repo: https://github.com/InfiniteZeroFoundation/DevNet (base branch: develop) Roadmap ref: P3-6.3b (Smart Contract Audit Preparation) · RES-1 / Discussion #18 (Filecoin storage provider) Dates: Jul 7–13, 2026 (5 working days; deadline Monday, July 13)

1. Project Summary

DIN (InfiniteZero) is a federated-learning network coordinated by Solidity contracts on Optimism Sepolia. Participants run dincli, a Python/Typer CLI, to act as clients (local training), auditors (scoring), or aggregators (combining models). Raw training data never leaves a participant's machine — only model artifacts (pinned to IPFS) and on-chain coordination state are shared. Every artifact is referenced on-chain by CID only, so the storage layer is fully provider-agnostic.

The contract layer has two tiers:

  • Platform-level contracts (deployed once by the DIN-Representative): DinCoordinator, DinToken, DinValidatorStake, DINModelRegistry. These have recently been converted to an upgradeable (Transparent Proxy) pattern — the versions in foundry/src/ are the proxy-ready implementations from PR #13.
  • Task-level contracts (deployed per model by the model owner): DINTaskCoordinator, DINTaskAuditor. These are not upgradeable and were not touched by the proxy conversion.

This task has two independent parts. Part 1 plays to your auditing focus; Part 2 is where your Filecoin/FVM background is exactly what we need — you were cc'd on the discussion for a reason.

2. Setup

# Fork https://github.com/InfiniteZeroFoundation/DevNet and clone your fork
git clone https://github.com/<your-fork>/DevNet
cd DevNet
git checkout develop && git pull

# Pin your review to this exact commit — the contracts are under active
# development (PR #13 proxy work), and a moving target makes findings ambiguous.
git checkout d136ff3ecef06670a3b785807669c40e027bcdf3
git checkout -b security/foundry-src-review

# Baseline: everything must build and pass before you start
cd foundry && forge build && forge test

Read before writing anything:

  1. Documentation/public/workflows/din-workflow.md — how the platform contracts relate to each other.
  2. Documentation/public/workflows/model-workflow.md — the task-contract lifecycle (Global Iterations, LMS, aggregation, slashing).
  3. Documentation/technical/upgradable-contracts/ — the proxy design the platform contracts now follow.
  4. The contracts themselves (§3).

3. Part 1 — Security Review: all contracts in foundry/src/ (Days 1–3)

Review all seven contracts in foundry/src/ at the pinned commit:

Contract Lines Notes
DINTaskCoordinator.sol ~787 Task lifecycle: GI phases, LMS, two-tier aggregation
DINTaskAuditor.sol ~680 Auditor registration, batch evaluation, auditor-slashing logic
DINModelRegistry.sol ~497 Upgradeable. Model registration/approval, fees, kill-switch
DinValidatorStake.sol ~340 Upgradeable. Staking, 7-day unbonding, slashing, blacklist
DINShared.sol ~224 Shared types/library code used by the task contracts
DinCoordinator.sol ~121 Upgradeable. ETH↔DIN exchange, slasher registry admin
DinToken.sol ~61 Upgradeable. ERC20, mint restricted to coordinator

What to produce

A severity-tagged findings report (critical / high / medium / low / informational) at Developer/audits/2026-07_foundry-src-security-review.md in your PR. For each finding: affected contract + function, description, concrete exploit/failure scenario, and a recommended fix. This is a from-scratch pass — there is no existing findings list to cross-check against, so don't assume anything is already known.

Minimum coverage

Everywhere: access control gaps, missing zero-address checks, reentrancy, unchecked external calls, unsafe ETH-send patterns, unbounded loops / gas-DoS in array iteration, integer/accounting errors, front-running exposure.

Upgradeable platform contracts (the 4): proxy-specific classes on top of the usual ones —

  • Initializer protection: can any initialize() be called twice, or called by the wrong party on a fresh proxy? Is _disableInitializers() actually effective at runtime (not just present in the source)?
  • Storage layout safety: variable ordering, gaps (__gap), anything that would corrupt state on a future upgrade.
  • Access control on the upgrade/admin path itself.
  • Any constructor logic that silently stopped running under the proxy pattern.

Task contracts: a few leads we already suspect are worth your time (verify, don't take on faith — and don't stop at them):

  • DINTaskAuditor.slashAuditors() — nested iteration (batches × auditors × models) that may not fit in a block at production scale. Is this a real DoS on slashing?
  • DINTaskAuditor._activeAuditorPool() — unbounded iteration over all registered auditors.
  • blockhash/block.timestamp-based shuffling in auditor selection — predictable by block producers; does slashing/selection fairness depend on unpredictability here?
  • DINTaskCoordinator is the largest contract in the repo and has had the least review attention of all seven — budget time accordingly.

Proof-of-concept tests

Where a finding is exploitable, a Foundry PoC test (foundry/test/) demonstrating it is worth far more than prose. Foundry's fuzzing is available (solc 0.8.28, via_ir = true) if you want to use property-based tests to hunt (e.g., exchange-rate math in DinCoordinator, stake accounting in DinValidatorStake). PoCs are strongly encouraged but prioritize breadth of the review first.

Hard boundary — findings only, no API/storage changes

The platform contracts are mid-flight in PR #13 and gated on a CLI test harness (P3-6.1). Do not change contract APIs, storage layout, or behavior in this task. Recommended fixes belong in the report (inline diffs welcome); PoC tests are additive and fine. If you believe something must be fixed immediately, flag it as critical and say so — the fix will be coordinated, not merged from this branch.

4. Part 2 — Filecoin Provider Recommendation: Discussion #18 (Days 4–5)

Do this first on Day 1: sign up for the provider accounts you'll need (Storacha/Web3.Storage at minimum; Lighthouse if you test the paid tier) so activation delays don't block Day 4. Then return to Part 1.

Read first:

  • Discussion #18: #18 — you're cc'd on it; this section is that cc turned into a deliverable.
  • PR #16: #16 — search the changed files for lighthouse / filecoin. The relevant ones: dincli/services/ipfs_lighthouse.py (the adapter), dincli/services/ipfs.py (provider abstraction), Documentation/public/guides/ipfs.md, tests/test_ipfs_lighthouse.py. You don't need to write Python — read these for how DIN's storage abstraction works and what the adapter assumed.
  • Developer/discussion/add-filecoin-support.md — the internal design doc whose Lighthouse recommendation PR #16 implemented.

The problem: PR #16's live testing found that Lighthouse uploads work perfectly but retrieval is payment-gated — GET gateway.lighthouse.storage/ipfs/<cid> returns 402 Payment Required even for the file's own uploader, and the CID is not discoverable on the public IPFS network at all (ipfs.io: "no providers found"). That breaks DIN's core assumption: aggregators and auditors must be able to fetch any artifact by CID. The discussion lays out the candidate paths (Storacha, Lighthouse paid tier, Filebase Filecoin bucket, FVM-native deals, hybrid).

What we want from you — this is judgment work, not spec execution; you've shipped on FVM (storage-deal escrow with SLA verification and auto-renewal) and we want your grounded take:

  1. Hands-on retrieval verification. For each candidate you assess, actually upload a file and try to retrieve it as a third party (public gateway, no credentials). The specific open questions from the discussion:
    • Is Storacha's retrieval path genuinely open — public gateway resolution and DHT announcement, not just their own gateway?
    • Does a Lighthouse paid plan make CIDs publicly resolvable, or only via their gateway? (Only if testable without significant spend.)
    • Anything else from your Filecoin Orbit experience we haven't listed — including providers we missed.
  2. FVM-native assessment. Discussion question 3 is squarely your territory: is contract-managed storage (escrow, SLA verification, auto-renewal — what you built in Filecoin Smart Escrow) worth the operational complexity for DIN, now or later? A clear "not yet, because X" is as valuable as a design sketch.
  3. A written recommendation, posted as a comment on Discussion #18. Which provider DIN should adopt, the evidence (actual CIDs + gateway results, not vendor docs), migration/cost implications, and whether a hybrid (Filecoin archival + hot IPFS pin for the active round) is sensible.
  4. Provider credits. Through your Filecoin ecosystem network (Filecoin Orbit Africa & Middle East, provider dev-rel, grant programs): can DIN get storage credits or grant support from the recommended provider? Any concrete lead — a contact, a program link, an application you can champion — is a win. Best effort; document what you tried.

5. Deliverables Checklist

Part 1 — Security review

  • Developer/audits/2026-07_foundry-src-security-review.md: severity-tagged findings for all 7 contracts in foundry/src/ at commit d136ff3
  • Proxy-specific checks covered for the 4 upgradeable platform contracts (initializers, storage layout, upgrade-path access control)
  • The seeded DINTaskAuditor leads (slashing loop, pool iteration, shuffle predictability) confirmed or refuted with reasoning
  • Foundry PoC tests for exploitable findings (encouraged, prioritize review breadth)
  • No API/storage/behavior changes to any contract

Part 2 — Filecoin provider (Discussion #18)

  • Retrieval verified hands-on (third-party fetch by CID) for each assessed provider, with real CIDs as evidence
  • FVM-native path assessed (recommendation + rationale, design sketch optional)
  • Recommendation posted as a comment on Discussion #18
  • Provider credits/grant leads documented (best effort)

6. Submission

  • Push security/foundry-src-review to your fork and open a PR into develop on https://github.com/InfiniteZeroFoundation/DevNet (or send the branch link if you'd rather we look before opening it).
  • PR description: findings count by severity, the three most important findings in one paragraph each, and anything you'd do differently with more time.
  • The Discussion #18 comment stands on its own — post it as soon as your provider testing is conclusive; don't hold it for the PR.

If anything here is ambiguous or you think a different approach is better, say so in the PR or the discussion thread — we'd rather you push back on a bad assumption than silently work around it.

7. Notes

  • No dincli/Python code changes are required anywhere in this task. Part 2 needs you to read small parts of the Python adapter, nothing more.
  • Gas optimization is explicitly out of scope — it's scheduled separately (P3-6.3a). Note gas-related security issues (DoS via block gas limit) in the report; skip pure cost optimizations.
  • Governance/DAO design is out of scope (tracked in Developer/issues/decentralized-governance.md).
  • Your review commit is pinned deliberately: PR #13 follow-ups may land on develop during your week. Don't rebase mid-review; note the pin in your report header.