Dupa cum va spuneam anterior, fiecare block valid (imprimat in ledger) din reteaua Bitcoin contine un timestamp (Epoch Time, Unix Time). Acest timestamp este destul de important pentru retea chiar daca multi considera ca timpul in sine nu este atat de important intr-un astfel de sistem.

Multi dintre cei care au adoptat Bitcoin considera ca daca block-urile au o ordine secventiala dat fiind faptul ca fiecare hash al unui block nou se refera la hash-ul block-ului anterior plus ca block-urile contin tranzactii (inputs si outputs) plus ca Merkle Tree-ul din headerul block-ului si hash-ul block-ului sunt folosite la POW reprezinta conditii suficiente pentru un sistem de tranzactionare si consens.

Testeaza BRAVE si sustine revista noastra!

Privind de departe este adevarat, dar odata ce luam in calcul ajustarea dificultatii, proces care permite retelei sa „curga” intr-un ritm cat de cat stabil, cu alte cuvinte sa nu se accelereze (block-urile sa survina prea repede) cand prea multi „mineri” intra in retea si sa nu functioneze prea incet atunci cand „minerii” o parasesc (block-urile sa fie gasite prea greu), apare o problema.

Cum rezolvam problema?

Pentru a rezolva aceasta problema, odata la 2016 block-uri (aproximativ 2 saptamani) dificultatea se ajusteaza spre o tinta de 10 minute intre fiecare block. Pentru a calcula aceste 10 minute sau acele 2 saptamani cu exactitate, dezvoltatorul/ii codului Bitcoin au adaugat in regulile de consens conceptul de TIMP. Asadar, este o conditie esentiala ca block-urile gasite de mineri sa continue un timestamp numit evident „Block Timestamp” pentru usurinta.

Inca un motiv in plus pentru a privi Bitcoin ca primul ceas electronic descentralizat.

Cand un block este produs sunt implicate 2 variatii ale timpului:

  1. Timestamp-ul din header (pus acolo de catre miner dupa regulile de consens)
  2. Timpul real la care block-ul a fost gasit

Ar fi ideal ca cele 2 variatii sa fie egale, lucru perfect natural, dar se pare ca nu este mereu asa.

Va vorbeam in articolul trecut despre unul din motivele care ar face minerii sa „minta” despre ora la care au gasit un block valid, respectiv despre masurile luate prin softfork.

Satoshi a luat initial masuri pentru a nu permite ca minciuna sa fie „prea mare” pentru a afecta reteaua.

Sa consideram urmatorul scenariu

Minerii care gasesc block-uri valide se decid ca fiecare timestamp imprimat in block sa fie cu 5 minute mai mare decat timpul real la care acel block a fost gasit. Lucru perfect valid si permis de regulile de retea. Daca acest tipar este continuat pentru o perioada de 2016 block-uri, cand survine ajustarea dificultatii, reteaua va vedea durata fiecarui block gasit ca fiind cu 5 minute mai mare decat acea reala, ajustand dificultatea catre tinta de 10 minute, lucru foarte favorabil pentru mineri. Binenteles ca un astfel de proces continuat ar decala timpul retelei foarte mult fata de timpul acceptat ca fiind real.

Pentru a rezolva aceasta „aberatie a timpului” aplicatia Bitcoin are 2 mecanisme de aparare impotriva manipularii timpului (despre care am vorbit si in articolul trecut).

Timpul Mediu (Median Past Time -MPT)

Regula care spune ca Timpul Imprimat intr-un block de miner trebuie sa fie „in viitor” fata de timpul mediu al ultimelor 11 block-uri.

*Curiozitate: De ce 11 block-uri? – Media de timp al ultimelor 11 block-uri este aleasa prin implicatia faptului ca reorganizarea ultimelor 6 block-uri nu face ca timpul median al retelei sa se miste „inapoi. Exemplul cel mai bun, demonstreaza ca sunt necesare 6 confirmari (6 block-uri) pentru a minimiza sub 0.1% a ratei de succes (reorg/doublespend) a unui atacator care detine 10% din puterea de „minare”.

Timpul imprimat intr-un block in viitor 

Regula care spune ca timpul imprimat intr-un block nu poate fi mai mare cu 2 ore decat timpul median al nodurilor interconectate cu nodul minerului care a gasit block-ul valid. Nodul minerului nu poate avea un timp diferit cu mai mult de 90 de minute fata de nodurile cu care este interconectat (un alt sistem de protectie al retelei). De mentionat faptul ca aceasta regula nu este o regula de consens, block-urile cu un timestamp prea „in viitor” nu sunt considerate invalid, ele putand deveni valide odata cu trecerea timpului in retea.

Iata cum, folosind 2 reguli simple, reteaua se asigura ca inainteaza in timp (regula 1) dar si ca nu inainteaza prea repede (regula 2)

Aceste reguli sunt departe de a fi perfecte. Minerii pot sa se foloseasca de timestamp pentru a desincroniza timpul retelei fata de cel real, inspre viitor, dar nu ar avea consecinte notabile de unde rezulta ca acestea s-au dovedit a fi suficiente.

Bitcoin 101

Timestampul imprimat in block ajuta atat la variatia hash-ului block-ului cat si la cresterea dificultatii pentru un atacator de a manipula reteaua. Timpul unui block poate fi considerat cu o eroare de 1-2 ore.

Un ceas descentralizat poate merge in ambele directii, fapt destul de ciudat pentru un CEAS. Va prezint unul dintre primele evenimente de calatorie in trecut: