Wiki di ZooBC
Transazioni

Scadenza e timestamp

Ogni transazione ZooBC porta, all'interno dei suoi byte firmati, il momento in cui è stata creata, in secondi Unix. Quel timestamp apre una finestra di validità: un blocco può includere la transazione solo entro la finestra, e dopo la transazione è morta e deve essere firmata di nuovo. La finestra protegge chi firma. Un pagamento che non è riuscito a entrare in un blocco in un momento di traffico non resta in giro per giorni per poi coglierlo di sorpresa; semplicemente scade, e chi firma può decidere di nuovo.

La finestra predefinita: un'ora

Per impostazione predefinita un blocco può includere una transazione fino a 3.600 secondi dopo il suo timestamp: un'ora, cioè 240 blocchi a un blocco ogni 15 secondi. Dopo di che i nodi la rifiutano con un messaggio che termina con «...sign it again».

La finestra ha anche un bordo anteriore. Anche una transazione datata più di 3.600 secondi nel futuro viene rifiutata, con il suggerimento di controllare l'orologio di chi firma. Questo intercetta un dispositivo con l'orologio sbagliato.

Un asse del tempo dal timestamp della transazione: una fascia verde fino a un'ora in cui un blocco può includerla, una zona rossa dopo, e una fascia tratteggiata che arriva a 24 ore per la versione 3
Un asse del tempo dal timestamp della transazione: una fascia verde fino a un'ora in cui un blocco può includerla, una zona rossa dopo, e una fascia tratteggiata che arriva a 24 ore per la versione 3

Scegliere la finestra: la versione 3

Una transazione di versione 3 contiene un campo di scadenza di 4 byte, subito dopo la commissione e il campo di sopravvivenza, e indica la propria finestra in secondi:

  • 0 significa l'ora predefinita;
  • un valore più piccolo accorcia la finestra, per un pagamento che deve avvenire presto o non avvenire affatto;
  • il valore massimo ammesso è 86.400 secondi, un giorno; un valore più grande viene rifiutato.

Una transazione di versione 1 o 2 non ha un campo di scadenza, e una che indichi comunque una scadenza viene rifiutata. Qualunque sia la versione, il limite di un'ora nel futuro resta valido.

Una finestra più lunga aiuta quando raccogliere una firma richiede tempo: su un hardware wallet, o tra i partecipanti di un account multifirma.

Come si adeguano pool e catene

Due regole complementari rendono sicura la finestra di un giorno:

  • il pool delle transazioni di un nodo conserva ogni transazione per la finestra che essa stessa dichiara;
  • ogni catena conserva gli id delle transazioni per almeno 25 ore: la finestra più lunga più l'ora di tolleranza nel futuro.

Poiché un nodo rifiuta un id che ha già confermato (vedi firmare una transazione), una transazione non può mai essere riprodotta finché è ancora valida.

Un righello dal timestamp con tacche a 1 ora (il valore predefinito), 24 ore (il limite) e 25 ore (per quanto si conservano gli id), e una zona rossa oltre le 24 ore
Un righello dal timestamp con tacche a 1 ora (il valore predefinito), 24 ore (il limite) e 25 ore (per quanto si conservano gli id), e una zona rossa oltre le 24 ore

Il tempo nei blocchi

I blocchi vengono verificati rispetto alle stesse finestre, così ogni nodo arriva allo stesso verdetto:

  • un blocco il cui timestamp supera il timestamp di una transazione più la sua finestra non è valido;
  • lo stesso vale per un blocco che contiene una transazione datata più di 3.600 secondi dopo il blocco.

Alcuni regolamenti avvengono da soli, blocco dopo blocco: le scadenze degli escrow, il completamento dei pagamenti liquidi, i trasferimenti pianificati che arrivano a scadenza, la scadenza degli ordini presenti nel book di un mercato e le fasi del voto sulla commissione. Questi leggono il timestamp del blocco precedente, non quello del blocco stesso. Un produttore non può quindi datare il suo blocco un po' in anticipo per includervi un pagamento.

Come i blocchi sono distanziati nel tempo è spiegato in blocchi e tempo.

Vedi anche