Quatro instruções, um ciclo fechado.
Todo o mecanismo cabe em quatro chamadas ao programa Anchor. Cada uma deixa um registro que ninguém — nem a autoridade — consegue apagar.
- 01
Registrar
Cada instituição cria sua conta de participante on-chain e entra com reputação 500, o ponto neutro da escala.
register_participant() - 02
Contribuir
A cada rodada, o nó publica o hash da atualização de pesos e suas métricas. Os dados nunca saem da instituição — só o compromisso criptográfico.
submit_contribution() - 03
Validar
O agregador pontua a contribuição de 0 a 1000. A reputação move por média móvel exponencial: metade do histórico, metade da rodada atual.
validate_contribution() - 04
Penalizar
Detectado envenenamento, a reputação é dividida por 10 e o banimento é permanente. Sem instrução de reversão, nem para a autoridade.
penalize_participant()
A reputação sobe devagar e cai de uma vez. A média móvel exponencial pondera metade do histórico e metade da rodada atual, então nenhuma rodada isolada — boa ou ruim — domina o resultado. Já a penalidade não negocia: divide por dez e bane em definitivo.
O atacante mais perigoso é o mais paciente.
Um envenenador óbvio é fácil de barrar. O problema real é o sleepy adversary: ele contribui honestamente por muitas rodadas, acumula reputação e peso na agregação, e só então começa a envenenar — sutilmente o bastante para que a detecção demore.
Ninguém consegue provar quem foi
Sem registro imutável, a contribuição de cada rodada é uma alegação. Depois do dano, o histórico já pode ter sido reescrito por quem controla o servidor.
A reputação vira uma arma
Sistemas que dão mais peso a quem tem histórico bom entregam ao atacante paciente exatamente a alavanca de que ele precisa.
A média móvel reage devagar
É o que a torna estável contra ruído — e o que abre a janela de dano. Por isso a punição precisa ser abrupta, não gradual.
Por que não um banco de dados.
Esta é a pergunta que todo projeto com blockchain precisa responder sem rodeios. A resposta aqui é específica: um consórcio de instituições concorrentes não tem um terceiro em quem todas confiem.
| Requisito | Servidor central | AwakeFL |
|---|---|---|
| Histórico à prova de reescrita | Depende de quem administra | Imutável por construção |
| Auditoria por qualquer participante | Só o que o dono expõe | Aberta, sem pedir acesso |
| Regra de punição não negociável | Alterável a qualquer momento | Fixada no programa publicado |
| Custo de operação | Baixo | 0,0019 SOL por contribuição, medido na Devnet |
| Latência | Milissegundos | Ainda não medida |
Um servidor central ganha em latência e custo. Perde no único ponto que importa aqui: quem controla o histórico.
O que costumam perguntar.
Os dados de treinamento vão para a blockchain?
Não. Só o hash da atualização de pesos, as métricas declaradas e o score. O dado clínico ou financeiro nunca sai da instituição — é essa a premissa do Federated Learning, e o sistema a preserva.
Por que blockchain em vez de um banco de dados?
Porque num consórcio não existe autoridade central em quem todos confiem. Um banco de dados pertence a alguém, e esse alguém pode reescrever o histórico de reputação. Na chain, o registro é imutável e qualquer participante audita sem pedir permissão.
Quem decide o score de cada contribuição?
No MVP, o agregador da rodada. É a limitação honesta desta versão: ele é confiável por construção. Descentralizar essa decisão — votação por comitê ou Krum on-chain — é o próximo passo do roteiro.
O banimento pode ser revertido?
Não. O programa não expõe nenhuma instrução que remova a marca de banido, nem para a autoridade. É uma decisão de projeto: um banimento reversível é um banimento negociável.
Em que estágio o projeto está?
MVP. O programa Anchor está escrito e versionado, com testes de integração cobrindo o ciclo completo. A demo deste site é uma simulação determinística das mesmas regras.
Veja o ciclo rodando.
A demo roda as doze rodadas com as mesmas regras e mostra o momento exato do banimento. O console de Devnet lê as contas reais do programa.