Quote from: Wrib on Today at 08:55:51 AM

Quote from: gbianchi on March 10, 2025, 01:08:14 PM

La risposta te la sei gia' scritta.

Non e' una vera regola di consenso, ma e' solo una regola per la scrittura del prossimo blocco.

Le regole di consenso possono essere ricalcolate da chiunque in qualsiasi momento e desunte dai soli dati della blockachain.

Questa invece e' logicamente simile al campo timelock, ossia una regola che non permette di scrivere il blocco prima di un certo momento, ma poi non viene piu' riverificata da nessuno.

Da un punto di vista formale non e' elegantissimo, perche' introduce implicitamente due livelli di controllo di consenso:
uno "hard", ossia il consenso verificabile sempre e comunque da tutti, e uno "soft", ossia verificabile sono in sede di
trasferimento del prossimo blocco dalla mempool alla blockchain.

Ma direi che la comodita' che introduce e' superiore alla perdita di eleganza.

Grazie per la risposta.

C'è una cosa che non mi è chiara.

La mempool è un buffer di richieste di transazioni, il miner sceglie tra questo buffer quali transazioni utilizzare per la costruzione del prossimo blocco. Se il miner è il primo a costruire un blocco valido quindi lo invia alla rete. Come si realizza, per il resto dei nodi, la discriminante informatica tra "nodi già validati per i quali non applico la regola del local time + 2 ore" e ultimo nodo appena minato per il quale "applico la regola del local time + 2 ore"?

Interessante domanda....

immagino che sul blocco piu' recente (AKA quello con l'altezza massima nella catena che sto controllando, quindi l'ultimo)
si applica il controllo e su tutti gli altri no, poi magari c'e' pure un controllo incrociato con la mempool.

Oppure che se sono nello stato "not synch" con il resto della rete il controllo non si applica, e invece se sono synch si applica (sempre sull'ultimo blocco)

Pero' per la risposta certa dovremmo guardare nel codice.