Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Contract size headroom for all contracts (DINTaskCoordinator −9 B over EIP-170 with PR No. 197) + slash reason for committed-but-unrevealed across commit-reveal flows

Aperta
  • Qualcosa non va?
#201 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
solidity
Ambito
devops, security, testing

Direzione di ricerca

Start with .github/workflows/ci.yml, foundry/anvil.sh, and the Foundry artifacts for DINTaskCoordinator and DINTaskAuditor; compare deployed bytecode sizes against EIP-170. Read the related decisions in issues No. 155 and No. 38 before choosing how committed-but-unrevealed validators should be slashed in both commit-reveal flows. Done means the mechanism decision is applied consistently, the size budget and CI gate cover every deployable contract, and both task contracts meet the recorded budget.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement Long run

Summary

Two follow-ups from the PR No. 197 re-review (verification comment, findings No. 6 and No. 4), each widened from PR No. 197 to every contract it applies to:

  • Part A: contract size. Once PR No. 197 is merged, DINTaskCoordinator exceeds EIP-170 and can't be deployed. Nothing in CI or local tooling catches this, and the other large contract (DINTaskAuditor) has only about 2 KB left. We need a size budget with real headroom for all deployable contracts, and a gate that enforces it.
  • Part B: slash reason for committed-but-unrevealed. In both commit-reveal flows (auditor scoring and T1/T2 aggregation), a validator who commits but never reveals is slashed as a liveness miss (30%), not as a wrong answer (100% of minStake). This is a mechanism-owner decision, tied to the No. 155 S1/S2 fraction decision and the No. 38 slashing taxonomy.

Part A: EIP-170 headroom for all contracts

Current sizes (runtime, via_ir, solc 0.8.28, optimizer_runs = 200)
Contract develop @ 4658bf8 Margin With PR No. 197 (b3ff1b9) Margin
DINTaskCoordinator 22,689 B 1,887 B 24,585 B −9 B
DINTaskAuditor 22,567 B 2,009 B 22,567 B 2,009 B
DinValidatorStake / V2 9,881 / 9,919 B 14,695 / 14,657 B unchanged
DINModelRegistry / V2 6,436 / 6,474 B 18,140 / 18,102 B unchanged
DinFeeRouter 5,160 B 19,416 B unchanged
DinToken / V2 4,208 / 4,246 B 20,368 / 20,330 B unchanged
DinFairLaunchDistributor 3,928 B 20,648 B unchanged
DinCoordinator / V2 3,697 / 3,736 B 20,879 / 20,840 B unchanged
DinEmission 3,353 B 21,223 B unchanged
DinTreasury 1,646 B 22,930 B unchanged

The two per-model task contracts are the ones at risk. Both are already about 92% of the limit, and every mechanism-design item on the P3 roadmap (No. 38, No. 155, No. 192, No. 193, No. 194) adds code to one or the other. PR No. 191 and PR No. 197 each fitted on their own; merged together, they don't.

Why nothing caught it
  • .github/workflows/ci.yml runs plain forge build / forge test with no size check, and Solidity CI is green on PR No. 197's b3ff1b9.
  • forge test doesn't enforce the limit: suite results were identical with and without FOUNDRY_DISABLE_CODE_SIZE_LIMIT=true.
  • foundry/anvil.sh starts anvil with --code-size-limit 4294967295, so the local devnet deploys an oversized contract without complaint.
  • forge build --sizes leaves DINTaskAuditor out of its table entirely (reproduced on both trees above; the figure here comes from out/DINTaskAuditor.sol/DINTaskAuditor.json's deployedBytecode). So simply adding --sizes to CI would leave one of the two at-risk contracts ungated.

It would first surface as a revert when DeployPlatform.s.sol / the task-contract deploy runs against Optimism Sepolia.

Proposal
  1. Budget: a minimum runtime margin every deployable foundry/src contract must keep. Proposed: ≥ 1,024 B; to be confirmed. Also check initcode against EIP-3860's 49,152 B, currently far from binding.
  2. CI gate: a step after forge build that reads every foundry/out/<src contract> artifact directly (not the --sizes table, because of the omission above), and fails if any runtime size exceeds 24,576 − budget. The log should print the full table so reviewers can see each contract's margin in every PR.
  3. Bring DINTaskCoordinator back under budget. The immediate blocker for PR No. 197. Candidates, roughly cheapest first:
    • fold the near-duplicate T1/T2 commit…Aggregation / reveal…Aggregation / start…AggregationReveal bodies (PR No. 197, DINTaskCoordinator.sol L807–1041 at b3ff1b9) into tier-parameterised internal functions, with external signatures unchanged;
    • the same for the other T1/T2 pairs (finalize…, the slashAggregators T1/T2 branches);
    • collapse per-tier custom errors into tier-agnostic ones where the tier is already implied by the call;
    • move large pure/view logic (shuffles, batch construction) into an external library;
    • as a last resort, lower optimizer_runs for this contract only (via a compilation restriction), trading gas for size.
  4. Give DINTaskAuditor the same review before the next feature lands on it. It has the same shape of per-phase duplication.
  5. Remove or document the --code-size-limit override in anvil.sh, so local deploys fail the way a real chain would. At minimum, add a comment saying why it's there.
Acceptance
  • CI fails when any foundry/src contract's runtime size is over 24,576 − budget B, and it covers DINTaskAuditor.
  • DINTaskCoordinator (with PR No. 197) and DINTaskAuditor both meet the budget.
  • The chosen budget is recorded in Developer/CONTRIBUTING.md (or the Foundry README).

Part B: committed-but-unrevealed slash reason (all commit-reveal flows)

Current behaviour
Flow Commit-but-no-reveal is treated as Slash Revealed-but-wrong is treated as Slash
Auditor scoring (DINTaskAuditor, PR No. 63) AUD_NO_VOTE (S1 liveness) s1SlashFractionBps (default 3000 = 30% of minStake) AUD_SCORE_DEVIATION (S3) full minStake
T1/T2 aggregation (DINTaskCoordinator, PR No. 197) AGG_T1_NO_SUBMISSION / AGG_T2_NO_SUBMISSION (S2 liveness) s2SlashFractionBps (default 3000 = 30%) AGG_T1_BAD_CONSENSUS / AGG_T2_BAD_CONSENSUS full minStake

In both flows, "committed and then withheld the reveal" can't be told apart from "never showed up".

The problem

Reveals land one at a time within the reveal window. A validator who has committed can watch peers' reveals, see that their own answer will end up in the minority, and choose not to reveal. They then pay the 30% liveness slash instead of the full-minStake slash for a wrong answer. Before commit-reveal, a wrong submission was irrevocable. So commit-reveal closes the copy-the-leader attack (No. 156 M-1) but opens a 70% discount on being wrong. The same holds on the auditor side, where S3 deviation is currently disabled by default (s3SlashingEnabled = false) but is intended to be turned on.

Options (mechanism-owner call)
  • Distinct reason codes (AGG_T*_NO_REVEAL, AUD_NO_REVEAL) with their own fraction, set between the liveness fraction and full minStake, or equal to the wrong-answer slash.
  • Treat committed-but-unrevealed as the wrong-answer case (full minStake). Simplest, but harsh on honest aggregators who miss the window through a genuine outage or a client-side bug (compare the retry/salt-overwrite bug, finding No. 1 on PR No. 197).
  • Keep as-is and document it as an accepted trust assumption, calibrated through the No. 155 S1/S2 fraction decision.

Whichever is chosen, it should be applied uniformly to both flows, and to any future commit-reveal flow (e.g. No. 178's multi-party commit-reveal seed, if adopted).

Related

No. 155 (S1/S2 fractions), No. 38 (slashing taxonomy and penalty tiers), No. 156 (M-1 aggregation commit-reveal), No. 192 (auditor commit hash sender binding), No. 193 (S5 recidivism). This should also get a row in the adversarial threat model (Developer/design/adversarial-threat-model.md).

cc @abrahamnash for Part B.

Lingua principale
Python
Stelle
4
Fork
7
Merge medio
3g 4h
PR unite (30g)
34

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InfiniteZeroFoundation/DevNet

Tutte le issue di InfiniteZeroFoundation/DevNet

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.