Servizi e gestione operativa
Il repository contiene due processi indipendenti: un keeper che invia chiamate permissionless e un relay degli eventi che può preparare pubblicazioni. Una configurazione locale non prova che un servizio sia operativo in modo continuo.
Il keeper
Il keeper verifica rete e collegamenti Hook/Lens, poi consulta lo snapshot. Nel percorso documentato privilegia il ribilanciamento quando ammissibile, altrimenti il collocamento dei fondi, poi il burn isolato quando le altre operazioni non sono disponibili.
Simula prima dell’invio e tratta al massimo un’azione per blocco. I rifiuti di ammissibilità previsti sono risultati normali; gli errori RPC e le simulazioni inattese devono emergere come errori operativi su cui intervenire.
Iniziare in dry-run
Da services/, dopo installazione e configurazione locale conformi al README:
DRY_RUN=true pnpm keeper:once
Questa modalità permette di verificare rete, deployment, indirizzi risolti, ammissibilità e stime senza inviare transazioni.
Il wallet operativo deve essere dedicato al gas. Non deve necessariamente essere deployer, team o guardian. I parametri di gas massimo e premio minimo limitano l’esecuzione; non garantiscono un guadagno.
Registro delle transazioni e ripresa
Il keeper separa gli stati per catena, hook, wallet e modalità dry-run/live. Usa un blocco di processo locale e un registro persistente di intenzione, nonce e hash.
Dopo un timeout o un riavvio riprende il monitoraggio della transazione esistente prima di preparare una nuova azione. Un’intenzione senza hash è ambigua: confronta i nonce pending e minati del wallet prima di modificare il registro.
Un file .lock va rimosso solo dopo aver confermato che il vecchio processo non è più in esecuzione. Questi blocchi sono locali; non coordinano più macchine. Usa un wallet e uno stato adatti a ogni istanza.
Evoluzione dei moduli
Il Lens corrente viene risolto dal registro. Conserva l’identità del nucleo e il contesto della revisione durante tutta l’operazione.
La versione a più muri richiede l’aggiornamento di ABI, anteprime, motivi di rifiuto ed eventi. Un keeper adattato al muro unico non va presentato come validato per questa nuova versione senza il relativo collaudo.
Il relay degli eventi
services/floor-bot legge gli eventi, prepara un testo e conserva un cursore insieme alle chiavi di deduplicazione transactionHash:logIndex.
Le modalità dry-run e pubblicazione hanno stati separati. I cursori includono il contesto di catena e hook; sui network previsti dal servizio si usano blocchi finalizzati. Una riorganizzazione o un checkpoint incoerente va riconciliato prima della ripresa.
Il relay salva un pendingPost prima della pubblicazione. Se il servizio esterno accetta il messaggio ma il processo si arresta prima di registrare il successo, bisogna verificare che il messaggio esista prima di riprovare: un database locale e un social network non possono effettuare un commit insieme.
Il GitBook non esegue pubblicazioni. Mettere in funzione il relay richiede configurazione e autorizzazione operative separate.
Adattare il vocabolario ai muri fissi
Il vecchio relay annunciava eventi FloorRaised. Con la politica istantanea, un finanziamento può creare un muro a un prezzo inferiore all’ultimo finanziamento mantenendo i vecchi livelli.
Il relay deve quindi citare il muro interessato, il suo livello e i fondi aggiunti, senza dedurre un aumento globale dal solo nome dell’evento. I vecchi messaggi “il floor sale sempre” non descrivono questa politica.
Controlli operativi utili
Segui errori RPC, scostamenti di configurazione, ricevute in attesa, fallimenti di simulazione, saldo gas del keeper ed età dell’ultimo blocco elaborato. Conserva i registri di ripristino e le identità di versione, senza dati privati di firma.
Una supervisione che riavvia i processi non sostituisce la risoluzione di un nonce ambiguo o di un cambio di registro.
Fonti: services/keeper/README.md, services/floor-bot/README.md, services/keeper/src/index.ts e services/shared.