Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

feat(trust): random re-execution audits of worker fragments (VRF-capable)

Aberta
  • Algo errado?
#27 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend, distributed-systems

Direção de pesquisa

Start by reading marketplace_service.py for reputation and runtime/executor.py for fallback workers, then inspect the provenance work in issue #4. Define the audit and randomness interfaces, configurable rates and tolerances, and an integration test with a faulty worker. Done means mismatches are detected, audits are recorded in job provenance, and audit costs never double-charge the owner.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

agents chain-integration enhancement tier-2

Summary

Randomly pick completed fragments and re-run them on a second worker to detect cheating or faulty nodes, with a pluggable randomness source that can be Chainlink VRF.

Motivation

Workers are paid for results the coordinator cannot cheaply verify. Unpredictable audits make cheating unprofitable and feed reputation.

Current state in this repo

  • Workers report observed fidelity; reputation exists in marketplace_service.py; the runtime already supports fallback nodes (runtime/executor.py).

Proposal

  • Audit service: select a fraction of fragments by a randomness source and re-execute on a different eligible worker.
  • Compare results within a tolerance suited to the fragment type; mismatches flag both workers for review and adjust reputation or holds.
  • Randomness interface with a local CSPRNG default and a Chainlink VRF implementation as an option (the audit logic must work with no chain at all).
  • Record audits in the job's provenance (#4).

Acceptance criteria

  • Audit rate and tolerance are configurable.
  • A deliberately faulty test worker is detected in an integration test.
  • Audits never double-charge the job owner (cost is platform-borne or budgeted explicitly).

Out of scope

  • Slashing stakes (no staking exists yet).

Dependencies

  • #4

Testing plan

  • Fault-injection test with a simulated bad worker.

Verify before implementing

  • VRF availability on the chosen testnet if the on-chain option is built.

Part of ##1. Ground rules for all issues in this roadmap are listed there (testnet-first, no secrets in the repo, chain logic behind the registry, tests and docs with every PR).

Linguagem predominante
Python
Estrelas
2
Forks
4
Merge médio
6h 14min
PRs com merge (30d)
18

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de QMeshPy/distributed-quantum

Todas as issues de QMeshPy/distributed-quantum

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.