Su Plasma, la ricevuta viene stampata per prima.
“Txn: 15:00:01.”
Il terminale emette un bip, il cassetto si apre, e il commesso chiude il vassoio dei contanti come se fosse memoria muscolare. Niente sembra fuori posto per ora. La fila si muove. La borsa cambia mano.
Poi il registro dei pagamenti si aggiorna.
“PlasmaBFT finalizzato: 15:00:00.”
Un secondo prima.
Qualcuno lo guarda strizzando gli occhi. Qualcuno scherza sul viaggio nel tempo. Poi la battuta muore, perché i numeri non si muovono quando aggiorni di nuovo. Plasma ha timbrato il pagamento prima che il registratore pensasse che fosse successo.
Non di molto. Un secondo. Ma è il secondo sbagliato.
Il manager del negozio lo segnala come un bug di visualizzazione. Il supporto non ride.
L'hanno già visto prima.
Il relayer ha accettato la transazione quando era valida. PlasmaBFT l'ha finalizzata quando il blocco si è chiuso. La registrazione ha stampato ogni volta che il suo orologio diceva “ora.”
Diventa un problema solo quando il commerciante mette la ricevuta accanto all'esportazione di regolamento e si aspetta che i secondi si comportino.
La contabilità lo fa di default.
Il report giornaliero lo segnala automaticamente. La transazione sembra chiudersi prima di essere registrata come iniziata. Il sistema non gradisce l'inversione dell'ordine, nemmeno di un secondo. Segna la riga. Qualcuno ci clicca sopra. Poi ne appare un'altra.
Il supporto apre il ticket e fa la domanda silenziosa per prima: “Il terminale è sincronizzato?”
Il commerciante dice di sì. Certo che lo è. Hanno NTP. Hanno controlli. Avevano un installatore il mese scorso che ha detto che tutto sembrava a posto.
I log non discutono. Il timestamp di finalità PlasmaBFT è pulito. I log EVM si allineano. Il blocco si è chiuso quando si è chiuso. La stablecoin si è mossa una volta, e la ricevuta esiste on-chain che al POS piaccia o meno.
L'orologio del POS sta derivando. Non in modo eccessivo. Solo abbastanza.
Mezzo secondo qui. Un secondo là. Abbastanza che quando Plasma chiude rapidamente, l'ordine si inverte.
Il commerciante non si interessa a nulla di tutto ciò. Gli interessa che il loro report di fine giornata non si bilancia a meno che qualcuno non spieghi perché il tempo sia andato indietro alle 15:00 di un martedì.
Inviano screenshot. Uno dal terminale. Uno dal dashboard di regolamento. Stessa tx hash. Secondi diversi. Le frecce non si allineano.
“Puoi aggiustarlo?” chiedono.
Riparare cosa, esattamente.
Il supporto apre la traccia EVM e attraversa la sequenza che Plasma ha visto... accettazione del relayer, inclusione del blocco, finalità PlasmaBFT. Tutto normale. Tutto veloce.
Il commerciante punta di nuovo alla ricevuta. “Ma è qui che è successo.”
Il supporto non dice di no. Non dicono neanche di sì.
Un tecnico si unisce. Poi un altro. Uno inizia a parlare di skew dell'orologio. Un altro menziona i secondi bisestili. Qualcuno suggerisce di forzare il POS a sincronizzarsi più spesso.
Nessuna di queste cose aiuta oggi.
La registrazione ha già stampato. Il blocco si è già chiuso. Il report ha già contrassegnato la riga. Il commerciante ha già pagato un'ora di supporto mentre tutti discutono di millisecondi.
Un secondo ticket arriva da un negozio diverso. Stesso problema. Fornitore di terminali diverso. Stesse rotaie Plasma sottostanti.
È allora che smette di essere divertente.
I commercianti non vedono relayer o chiusure di blocchi. Vedono una ricevuta che dice una cosa e un dashboard che dice un'altra. Dal loro punto di vista, il sistema non può concordare su quando si è mosso il denaro.
Il supporto redige una risposta, la cancella, redige di nuovo.
“Ci affidiamo ai timestamp di regolamento Plasma per la riconciliazione.”
Questo suona evasivo.
Provano un altro approccio.
“Gli orologi POS possono derivare.”
Questo suona accusatorio.
Finiscono per inviarli entrambi, cuciti insieme, sperando che il tono faccia il lavoro che la precisione non può.
Nel frattempo, la finanza è già coinvolta. Lo script di chiusura giornaliera non gradisce i delta negativi. Non è stato scritto per rotaie in cui la finalità può superare la cassa di un secondo. Qualcuno aggiunge una condizione. Qualcun altro aggiunge un commento. Nessuno gradisce nessuna delle due.
Un tecnico suggerisce di normalizzare tutto ai timestamp di Plasma ( @Plasma ). Il commerciante si oppone immediatamente. L'intero sistema di vendita al dettaglio funziona con il tempo della registrazione. Registri di lavoro. Prelievi di inventario. Finestra di rimborso. Cambi di turno. Le cose noiose che diventano costose quando non corrispondono.
Non vogliono il tempo Plasma. Vogliono che il loro tempo smetta di imbarazzarli di fronte ai loro stessi report.
Un altro negozio chiama. Stessa situazione. “Txn alle 18:42:09. Chiuso alle 18:42:08.”
La coda di supporto si infittisce. Nessuno dei ticket è catastrofico. Questo è il problema. Sono abbastanza piccoli da accumularsi. Ognuno costa un po' di tempo, un po' di fiducia, un po' di pazienza.
I tecnici discutono sugli intervalli di sincronizzazione. I commercianti discutono sulle fatture. Il supporto discute sulla formulazione.
Plasma continua a chiudere blocchi. Il POS continua a stampare. La contabilità continua a allineare i secondi e cerchiare quello sbagliato.
E ogni volta che il secondo va indietro, qualcuno paga per il supporto per spiegare perché il denaro era giusto anche quando l'orologio non lo era.