Servizi di programma

Alcune cose che una piattaforma deve sapere su un conto non si possono calcolare mentre un blocco viene eseguito. Un livello commissionale per volume dipende da trenta giorni di operazioni. Una ricompensa dipende da una finestra che non si è ancora chiusa. Un’attribuzione di referral dipende da un rapporto nato mesi fa. Mettere quel lavoro dentro l’esecuzione del blocco sarebbe sbagliato due volte: farebbe pagare a ogni blocco un calcolo di cui quasi nessun blocco ha bisogno, e costringerebbe il kernel a portarsi dietro uno storico che non avrebbe altra ragione di conservare. I servizi di programma lo risolvono invertendo la direzione. Il calcolo viene eseguito fuori dal blocco, sul registro consolidato. Il risultato viene poi riscritto sulla catena come stato di protocollo, dove l’esecuzione può leggerlo in tempo costante come qualsiasi altra configurazione. La catena resta l’autorità. Un servizio non custodisce stato da cui la rete dipende: propone un valore, e reale è solo ciò che la catena ha accettato.

​

Che cosa è in funzione oggi

Livelli commissionali per volume. Il servizio consuma lo storico delle operazioni trasmesso in streaming da un nodo, accumula il volume per conto e ne salva istantanee a intervalli regolari. Alla chiusura di un periodo calcola il volume di ogni conto sulla finestra mobile, lo mappa sulla configurazione delle commissioni letta in tempo reale dalla catena, e riscrive a lotti i conti che sono cambiati. In quella frase diversi dettagli sono portanti:

• La tabella dei livelli si legge dalla catena, non si scrive fissa nel codice. Un servizio che ne tenesse una copia propria continuerebbe ad applicare il tariffario di ieri dopo che la rete lo ha cambiato.
• Il confronto si fa sulle aliquote, non sulla posizione nella tabella. Confrontare gli indici di livello non coglie due casi reali: una soglia che si sposta e fa finire in un livello diverso un conto rimasto uguale, e un livello che viene riprezzato mantenendo lo stesso indice. Entrambi cambiano quanto paga un conto; nessuno dei due cambia l’indice.
• È la catena a risolvere l’aliquota finale. La transazione porta un indice di livello; l’esecuzione lo risolve sulla configurazione delle commissioni in vigore. Un indice di livello fuori dall’intervallo valido fa fallire l’intero lotto invece di applicarsi in parte.
• Un periodo risulta applicato solo dopo che ogni lotto è stato scritto. Un crash a metà periodo comporta il replay dell’intero periodo, operazione sicura perché il calcolo è idempotente: la stessa finestra produce lo stesso risultato.

​

Il modello di guasto

Questi servizi stanno fra due sistemi che ogni tanto saranno indisponibili. Il progetto lo dà per scontato invece di trattarlo come un’eccezione. I guasti delle dipendenze — il database, lo stream del nodo, l’API del nodo — vengono riprovati con backoff. Non terminano il processo, perché un riavvio non risolve una dipendenza irraggiungibile: aggiunge solo un avvio a freddo al disservizio. Resta fatale ciò che un riavvio può risolvere o che un operatore deve vedere: configurazione non valida all’avvio, impossibilità di mettersi in ascolto sull’endpoint di health, e i panic. Durante un disservizio il processo resta in esecuzione, si dichiara not-ready e conta gli errori. Il segnale operativo è quindi «è not-ready da N minuti?», che è la domanda utile, e non «il processo è vivo?»: un processo vivo che da un’ora non riesce a ingerire dati è l’incidente vero. L’arresto è controllato sui segnali che invia un orchestratore: il lavoro si ferma, i checkpoint vengono scritti su disco e il processo esce in modo pulito. Senza questo, ogni rilascio di routine costerebbe una finestra non salvata e un replay.

​

Perché lo schema si generalizza

Il percorso di riscrittura è generico. Esistono transazioni di protocollo per impostare la configurazione a livello di conto e per impostare quella globale, e un servizio di programma è qualunque processo che calcoli un valore per una delle due a partire dallo storico consolidato. Quello dei livelli commissionali è l’unico in funzione. Programmi di incentivi, attribuzione dei referral e idoneità alle campagne avrebbero la stessa forma: un calcolo su finestra sullo storico delle operazioni, un confronto con ciò che è applicato adesso, e una riscrittura a lotti. Starebbero qui e non nel kernel per la stessa ragione dei livelli commissionali: il calcolo è periodico e storico, mentre all’esecuzione serve che la risposta sia una lettura in tempo costante. Nessuno di questi è realizzato; a generalizzarsi è lo schema, non l’impegno che lo useranno. Le condizioni commerciali di questi programmi si trovano in Commissioni e programmi. Questa pagina riguarda come il risultato finisce on-chain.

​

Dove proseguire