quasi ho saltato la sezione Arma BFT la prima volta che l'ho letta e onestamente è stato un errore, come ho fatto errori nel trading di ETHEREUM e PIPPIN, quindi ho trascorso gli ultimi due giorni a correggere 😂
la maggior parte delle persone guarda alla cifra di 100.000 transazioni al secondo e passa oltre. Ho fatto la stessa cosa inizialmente. Ma il numero non è la parte interessante. La parte interessante è la decisione architettonica che la produce. E all'interno di quella decisione c'è una domanda a cui continuo a tornare e che la documentazione non risponde completamente.
Come funziona realmente la macchina:
Arma BFT non è un singolo motore di consenso. è composto da quattro componenti distinte che operano in sequenza, ciascuna responsabile di una funzione separata.
il router riceve le transazioni in arrivo e gestisce la validazione iniziale e il routing. il batcher prende quelle transazioni validate e le raggruppa in batch. il livello di consenso poi opera esclusivamente su attestazioni batch compatte, non sui dati di transazione completi.
l'assemblatore prende le attestazioni batch ordinate dal consenso e costruisce i blocchi finali.
quella separazione è l'intuizione architettonica che sblocca il numero di prestazioni. il consenso è la parte lenta di qualsiasi sistema distribuito perché richiede coordinamento tra più nodi. riducendo il consenso a operare solo su piccole attestazioni piuttosto che su dati di transazione completi, il collo di bottiglia si riduce drasticamente.
maggiore throughput per turno di consenso perché ogni turno sta svolgendo meno lavoro per transazione.
e la banca centrale controlla direttamente i nodi di consenso. questo è il design di governance. l'autorità di ordinazione appartiene all'operatore sovrano, non a un insieme di validatori distribuiti.
Cosa mi ha veramente impressionato:
il grafo delle dipendenze delle transazioni è la parte che mi ha preso più tempo per apprezzare completamente. validazione parallela attraverso più blocchi simultaneamente. le transazioni che non condividono input vengono validate contemporaneamente piuttosto che sequenzialmente. l'assunzione tradizionale della blockchain che valida il blocco N prima di iniziare il blocco N+1 è deliberatamente infranta.
per un sistema che mira ai volumi di pagamento nazionali, questo è il design giusto.
e la separazione della validazione delle transazioni dall'ordinamento del consenso ha un reale beneficio oltre le prestazioni. i validatori e il livello di consenso hanno ruoli distinti senza sovrapposizioni. il componente che verifica se una transazione è valida non è lo stesso componente che decide l'ordine in cui le transazioni vengono elaborate. quelle sono funzioni genuinamente diverse e mantenerle separate è architettonicamente pulito.
Dove continuavo a bloccarmi però:
il batcher si trova tra il router e il livello di consenso. il suo compito è raggruppare le transazioni validate in batch prima che il consenso le veda. il consenso quindi ordina quei batch. l'assemblatore costruisce blocchi dai risultati ordinati.
ecco la parte che continuava a tormentarmi.
il consenso opera su attestazioni batch. non vede singole transazioni. vede gruppi di transazioni che il batcher ha già assemblato. il che significa che la decisione su quali transazioni vengano raggruppate insieme e quali transazioni vengano escluse completamente da un batch, avviene al batcher prima che il livello di consenso abbia qualsiasi visibilità.
il whitepaper descrive il livello di consenso come fornitore di resistenza alla censura attraverso l'ordinamento deterministico. l'ordinamento deterministico significa che una volta che un batch raggiunge il consenso, l'ordinamento all'interno di quel batch è garantito e resistente alla manomissione.
ma l'ordinamento deterministico al livello di consenso non dice nulla su cosa sia successo al livello di batching prima che il batch fosse formato. una transazione che non entra mai in un batch non raggiunge mai il consenso.
non può beneficiare delle garanzie di resistenza alla censura fornite dal consenso.
la banca centrale controlla i nodi di consenso. la documentazione non specifica chi controlla i nodi batcher, quali regole governano le decisioni di inclusione dei batch, o se esiste qualche meccanismo per un submitter di transazione per verificare che una transazione inviata sia stata inclusa in un batch piuttosto che silenziosamente scartata prima che il consenso la vedesse.
per un protocollo DeFi privato questo sarebbe un compromesso conosciuto accettabile. per un'infrastruttura sovrana che elabora pagamenti per il benessere dei cittadini e distribuzioni di benefici, la domanda su cosa succede a una transazione che il batcher esclude non è un caso limite teorico.
è un requisito operativo che l'architettura attualmente non soddisfa.
onestamente non so se la separazione del batcher è puramente un'ottimizzazione delle prestazioni con garanzie di inclusione che non sono semplicemente documentate a questo livello o se crea una superficie di censura che si trova sopra il livello di consenso dove le garanzie di resistenza dei protocolli non possono raggiungere?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN
