gdassori (OP)
|
|
August 28, 2015, 06:09:33 PM |
|
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.
|