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

Simulation: model validator gas costs to size ETH network fee for model trainers

Ouverte
  • Quelque chose ne va pas ?
#78 5 commentaires 1 réaction 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
25/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
solidity
Domaine
blockchain, fintech-quant

Piste de recherche

The issue names the P3-5.2 simulation requirement and MECHANISM_DESIGN §5; start by reading those to find the existing validator income model and its assumptions. Model aggregation, evaluation, and worst-case dispute gas across the listed participation variables, using current Optimism gas prices. Report low, mid, and high scenario costs in ETH, the fee floor, sensitivity at 10× and 0.1× participation, and any unprofitable scenario.

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

Description

Context

Discussed with @abrahamnash (Aug 2026). The resolved fee model is:

  • All protocol fees in ETH — DIN is staking/utility only, no fee denomination migration
  • Network fee (model trainer → validators, paid per-GI) must be sized from real gas data, not assumed
  • Current design has no hard numbers; this simulation is the prerequisite for setting the fee

The network fee is essentially gas recovery for validators: model trainers pay it upfront, validators get reimbursed for the on-chain work they do per GI. Getting this wrong in either direction (too low = validators lose money, too high = model owners won't participate) blocks the validator economics from being viable at scale.

Scope

Three scenarios to model, covering the full on-chain surface validators touch per GI:

1. Aggregation submissions
  • T1 sub-batch CID submission gas cost (per aggregator, per batch)
  • T2 combined CID submission gas cost
  • Baseline: aggregation logic is off-chain — only the final CID goes on-chain (per Abraham's design intent)
  • Variables: number of T1 batches, number of aggregators per batch
2. Evaluation submissions (batched vs per-round)
  • Gas cost of a single auditor submitting scores on-chain (setAuditScorenEligibility)
  • Batched final-round evaluation: all submissions in one round vs spread across rounds
  • Variables: number of clients per auditor, number of auditors per batch, pass/fail ratio
3. Dispute scenarios (worst-case)
  • Full dispute chain gas cost: dispute open → bond post → fresh subgroup reassignment → re-evaluation submissions → resolution
  • Disputes are rare by design (random assignment + >50% consensus threshold) — but worst-case must be bounded so it does not make the network fee unworkable
  • Variables: dispute window length, subgroup size

Expected output

  • Gas cost range (low/mid/high participation) for each scenario in ETH at current Optimism gas prices
  • Recommended ETH network fee floor that covers validator gas at target participation level
  • Sensitivity table: what happens to validator economics at 10× and 0.1× participation
  • Flag any scenario where gas costs alone make validator participation unprofitable at the proposed fee floor

Notes

  • Aligns with the existing P3-5.2 simulation requirement (validator income stability at target/10×/0.1× participation) — this scopes the gas input to that model
  • Builds on the mitigations already in the design: aggregation off-chain, evaluations batched to final round, disputes rare — the simulation should validate those mitigations hold under load
  • Reward split (clients/validators/treasury %) is a separate open item and out of scope here — see MECHANISM_DESIGN §5

cc @abrahamnash

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.