Topic: Su blocchi grandi (ma anche no), propagazione e chain orfane. (Read 1593 times)

Dipende dalle assunzioni che fai, in particolare mi pare che tu stia assumendo che il ricevente stia ricevendo un blocco pieno di tx che non ha mai visto prima, ma questo non è il caso tipico.

Nel caso tipico le tx sono già passate in rete in precedenza e quindi sono nella mempool dei vari nodi.
Un blocco al 99% include tx che ognuno ha già visto, e quindi già verificato. Il lavoro che resta da fare alla ricezione è solo di calcolare il merkle root e poco di più perchè le signature delle tx che include (e che sono le cose più lente da verificare) sono già state verificate potenzialmente molti minuti primi (e cachate).

Quindi il grosso del tempo è solo dovuto al trasferimento del blocco.

Ma il caso ancora più tipico è il fatto che i miner non usano (solo) la connessione alla rete bitcoin per ricevere i blocchi, ma anche il relay network, e questo ottimizza in maniera spettacolare la trasmissione di un blocco, riducendo la quantità di dati da trasmettere anche di 100/1000 volte.

Questo vuol dire che il blocco arriva in pochi decimi di secondo a chi è in ascolto sul relay network, e la validazione può essere effettuata in maniera rapidissima.

Domanda: ma se un nodo ha gia' tutte le transazioni che compaiono nel blocco da 8MByte non e' che per verificarlo impiega molto meno tempo? Il problema sarà nel trasmetterlo e a quel punto credo che 2 o 8 MByte non cambino di molto il tempo (sono 4X ma si dovrebbe parlare di secondi).
Per il fork ritengo verosimile che il nodo che ha minato il 2M continuerà a minare su quel ramo. Comunque propagando l'hash del blocco a 8M il nodo che mina il blocco da 2M credo che dopo pochi secondi dovrebbe smettere di minare il nodo errato. C'e' il problema dello spam che potrebbe distrarre i nodi ma creare un hash con queste difficoltà credo sia inutile se poi il nodo non è valido (verificare l'hash credo impieghi poco tempo, casomai verificare che tutte le transazioni siano corrette richiede tempo ... si va sulla fiducia per qualche secondo?).
Ritengo verosimile che in questo caso un nodo minerà un blocco vuoto fino a quando non ha verificato tutte le transazioni del nodo del quale conosce solo l'hash. Paradossalmente potrebbero quindi comparire blocchi vuoti.

Su blocchi orfani e propagazione, due righe in cui vorrei sentire i pareri, non so se questa cosa viene già fatta, non so che problemi possa portare, sicuramente non è una implementazione banale, ma:

Partiamo dai problemi che ho dedotto sull'incremento della dimensione dei blocchi, a parte l'aumento di dimensione della blockchain, che è un fatto inevitabile a fronte di un "certo" desiderio di scalabilità, opinabile o meno, è un fatto da accettare, nell'ottica di condividere almeno le premesse della visione di chi vuole l'aumento del blocco.

- Un problema tecnico importante riguarda la propagazione dei blocchi e la possibilità che si crei un maggiore numero di blocchi orfani, a fronte di tempi di propagazione dei blocchi più lunghi. Per capirci, verificare un blocco e decidere dunque di propagarlo richiederebbe, a fronte di un blocco da 8mb, anche fino a 30s, così a naso, per un computer di potenza media. I tempi di trasferimento dei dati anche, incrementando, causano un rallentamento generale della rete. Questo, su una rete distribuita, causa inevitabilmente la possibilità che si creino problemi di agreement.

La proposta in questione è una soluzione a questo problema, e prevede l'implementazione di una coda di block hashs. Inoltre prevede l'introduzione di uno step antecedente alla propagazione di un blocco: la propagazione del suo hash. L'hash di un blocco è irripetibile, e ovviamente non può essere predetto. Misura 32 bytes e si propaga agilmente, in maniera assai più equa di quanto non si propaghi invece un file di 8, 32 o, chissà, 128 megabytes.

Lo schema sarebbe dunque il seguente:


- Miner Bitcoin trova blocco. Fa immediatamente l'advertise del block hash, inizia a propagare il blocco. Stiamo parlando di un blocco da 8 megabytes.

- Nodi bitcoin connessi al nodo del miner ricevono l'hash del blocco. Lo inseriscono in una coda, iniziano la propagazione dell'hash da subito, iniziano a ricevere il blocco.

- Un altro miner Bitcoin, a pochi secondi di distanza, trova un blocco della dimensione di 2 megabytes, propaga l'hash del blocco, inizia a propagare il blocco.

- I nodi Bitcoin che avevano già ricevuto l'hash del blocco da 8 megabytes, e stavano ricevendo il blocco, ricevono l'hash del blocco da 2 megabytes. Inseriscono l'hash nella loro coda di verifica. Iniziano a ricevere il blocco da 2 megabytes.

- I nodi Bitcoin ricevono il blocco da 2 megabytes più rapidamente di quanto non abbiano fatto con quello da 8. Iniziano la verifica del blocco, a verifica terminata hanno ricevuto il blocco da 8 megabyte. Ricordiamo a questo punto che l'hash del blocco da 8 megabyte è stato propagato prima di quello del blocco da 2 megabyte. E questo i nodi lo ricordano.

- I nodi Bitcoin iniziano la verifica del blocco da 8 megabyte, e prima di smettere di propagare entrambi gli hash ed entrambi i blocchi, portano a termine la verifica del blocco da 8 megabyte.

- Il blocco da 8 megabyte è valido, i nodi Bitcoin cessano dunque di accettare relay per blocchi di quell'altezza, e iniziano ad accettare blocchi d'altezza successiva a quella salvata. A questo punto il blocco da 2 megabyte, nonostante sia stato propagato prima (ma minato dopo, verosimilmente) viene scartato, e a vincere la corsa è il miner che aveva lavorato un blocco da 8 megabyte, nonostante lo abbia propagato più lentamente.


Francamente non so se questo abbia senso, se funzioni già così, se non ponga soluzioni ad altri problemi che non mi sono presenti, o cosa. Per questo chiarimenti e pareri sono bene accetti.