Il percorso di ingresso
Transazione firmata
Validazionefirma · formato · stato del conto · capacità del mittente di pagare
Scartata, con un motivonon in silenzio — chi ha inviato sa perché
Archivio transazioni
Broadcast ai peer
Formazione dei batch, poi consenso
La validazione è locale e poco costosa: le risorse costose a valle sono spese solo su transazioni che potrebbero davvero essere eseguite.
rifiutata
accettata
Come vengono tenute le transazioni
Le transazioni accettate non sono tenute in un’unica coda piatta. L’archivio mantiene più viste sullo stesso insieme, ognuna delle quali risponde a una domanda diversa.Un insieme di transazioni accettatecinque viste, non cinque code
Ordinamento per contoPer questo mittente, qual è la prossima?
Indice di prioritàTra tutti i mittenti, che cosa va offerto per primo al consenso?
Indice di scadenzaChe cosa è scaduto?
Indice timelineDi che cosa questo peer non sa ancora?
ParcheggioChe cosa è ben formato ma non ancora idoneo?
Il parcheggio è dove diventa visibile un bug di integrazione: una transazione valida ma non ancora la prossima per il suo mittente viene parcheggiata, non rifiutata — diventa idonea appena il buco davanti a lei si chiude.
Il parcheggio è la vista che merita più attenzione, perché è lì che diventa visibile una classe di bug di integrazione. Una transazione può essere perfettamente valida e comunque non essere la prossima in fila per il suo mittente, quasi sempre perché una transazione precedente dello stesso conto non è arrivata o non è stata confermata. Una transazione così viene parcheggiata invece che rifiutata: resta disponibile e diventa idonea nel momento in cui il buco davanti a lei si chiude. Un client che invia fuori ordine subisce quindi un ritardo, non un fallimento; ma un client che quel buco non lo colma mai lascia lavoro parcheggiato fino alla scadenza.
L’indice timeline è ciò che rende incrementale la diffusione verso i peer. Per ogni peer si tiene traccia di quanto è stato servito lungo la timeline, così un broadcast invia ciò che a quel peer manca invece di rispedire l’intero pool. La timeline è suddivisa in bucket anziché essere una fila unica, e questo impedisce a un singolo mittente pesante di monopolizzare ogni slot di broadcast.
Diffusione ed equità
I nodi non vengono a conoscenza delle transazioni ciascuno per conto proprio. Un nodo che accetta una transazione la trasmette ai peer, e i peer non sono trattati allo stesso modo: quelli a monte hanno la precedenza, così una transazione si muove verso i validatori che possono darle seguito invece di diffondersi in modo uniforme nella rete. L’equità è tracciata sulla storia recente invece che imposta messaggio per messaggio. Il mempool tiene un registro scorrevole di quali mittenti e quali tipi di traffico hanno consumato capacità di recente, e lo usa per modulare che cosa servire dopo. È il meccanismo che impedisce alla tempesta di ordini e annullamenti di un singolo conto di soffocare il resto della rete, senza bisogno di un rate limit rigido per conto che penalizzerebbe il market making legittimo.Il passaggio al consenso
Il consenso non prende le transazioni dal mempool una alla volta. Le transazioni vengono raccolte in batch, i batch vengono diffusi ai validatori in background e ogni batch viene riscontrato finché chi lo ha originato può dimostrare che una parte sufficiente della rete lo detiene. Solo allora una proposta di blocco può farvi riferimento. La conseguenza è che una proposta di blocco porta i digest dei batch e non i corpi delle transazioni, così la dimensione dei messaggi di consenso resta piatta al crescere del throughput — e un blocco confermato è sempre rieseguibile, perché i dati sottostanti sono stati provati disponibili prima di essere referenziati. Vedi IntentionBFT per capire come quella prova viene formata e usata.È anche per questo che l’ammissione al mempool non equivale all’inclusione. Una transazione accettata, memorizzata e trasmessa è entrata in coda; non è stata ordinata. Nulla del destino di una transazione è deciso finché il consenso non conferma il blocco che la contiene.
Che cosa significa per un client
- Un rifiuto all’invio è informativo. È avvenuto prima che la transazione fosse memorizzata, e il motivo descrive qualcosa che il client può correggere.
- Il silenzio non è un rifiuto. Una transazione può essere parcheggiata dietro un buco creato dal client stesso. Tieni traccia di che cosa è stato inviato e di che cosa è stato confermato, invece di dare per scontato che un riscontro mancante significhi uno scarto.
- L’ordine dentro un conto conta; l’ordine tra conti diversi no. Due transazioni dello stesso mittente hanno una sequenza definita. Due transazioni di mittenti diversi sono ordinate dal consenso, non da chi ha inviato per primo.
- Nel mempool gli annullamenti non sono privilegiati. La priorità dell’annullamento è una proprietà dell’esecuzione del kernel, dove gli annullamenti vengono eseguiti prima delle immissioni aggressive nello stesso blocco — non dell’accodamento.