Ovaj tekst je nastavak serije članaka u kojima istražujem strukturu (vjerovatno) distribuirane mreže Telegram Open Network (TON), koja se priprema za puštanje ove godine. IN Opisao sam njen najosnovniji nivo - način na koji čvorovi međusobno komuniciraju.
Za svaki slučaj, da vas podsjetim da nemam nikakve veze sa razvojem ove mreže i sav materijal je preuzet iz otvorenog (doduše neprovjerenog) izvora - (postoji i prateća , ukratko izlažući glavne tačke), koji se pojavio krajem prošle godine. Količina informacija u ovom dokumentu, po mom mišljenju, ukazuje na njegovu autentičnost, iako za to nema zvanične potvrde.
Danas ćemo pogledati glavnu komponentu TON-a - blockchain.
Osnovni pojmovi
račun (račun). Skup podataka identificiranih 256-bitnim brojem account_id (najčešće je to javni ključ vlasnika naloga). U osnovnom slučaju (pogledajte dolje zero workchain), ovi podaci se odnose na stanje korisnika. Specifično "okupiraj". account_id svako može, ali se njegova vrijednost može mijenjati samo prema određenim pravilima.
Pametan ugovor (pametni ugovor). U suštini, to je poseban slučaj naloga, dopunjen kodom pametnog ugovora i skladištenjem njegovih varijabli. Ako u slučaju “novčanika” možete uplatiti i povući novac iz njega prema relativno jednostavnim i unaprijed određenim pravilima, onda su u slučaju pametnog ugovora ta pravila napisana u obliku njegovog koda (u određenom Turing-complete programski jezik).
Blockchain State (stanje blockchaina). Skup stanja svih računa/pametnih ugovora (u apstraktnom smislu, hash tablica, gdje su ključevi identifikatori računa, a vrijednosti podaci pohranjeni u računima).
Poruka (poruka). Gore sam koristio izraz „kreditni i debitni novac” - ovo je poseban primjer poruke („transfer N grama sa računa account_1 po računu account_2"). Očigledno, samo čvor koji posjeduje privatni ključ naloga može poslati takvu poruku account_1 - i mogu to potvrditi svojim potpisom. Rezultat dostave takvih poruka na redovni račun je povećanje njegovog stanja, a rezultat pametnog ugovora je izvršenje njegovog koda (koji će obraditi prijem poruke). Naravno, moguće su i druge poruke (prenošenje ne novčanih iznosa, već proizvoljnih podataka između pametnih ugovora).
Transakcija (transakcija). Činjenica da je poruka isporučena naziva se transakcija. Transakcije mijenjaju stanje blockchaina. Transakcije (zapisi o isporuci poruka) čine blokove u blockchainu. S tim u vezi, možete zamisliti stanje blockchaina kao inkrementalnu bazu podataka – svi blokovi su “diffs” koje je potrebno primijeniti uzastopno da bi se dobilo trenutno stanje baze podataka. Specifičnosti pakovanja ovih „diffs“-a (i vraćanja punog stanja iz njih) će biti razmatrane u sledećem članku.
Blockchain u TON-u: šta je to i zašto?
Kao što je spomenuto u prethodnom članku, blockchain je struktura podataka čiji su elementi (blokovi) poređani u "lanac", a svaki sljedeći blok lanca sadrži hash prethodnog. Komentari su postavljali pitanje: zašto nam je uopće potrebna takva struktura podataka kada već imamo DHT - distribuiranu hash tablicu? Očigledno, neki podaci se mogu pohraniti u DHT, ali ovo je pogodno samo za ne previše “osjetljive” informacije. Saldo kriptovaluta ne može se pohraniti u DHT - prvenstveno zbog nedostatka provjera integritet. Zapravo, cjelokupna složenost blockchain strukture raste kako bi se spriječilo ometanje podataka pohranjenih u njoj.
Međutim, blockchain u TON-u izgleda još složenije nego u većini drugih distribuiranih sistema – i to iz dva razloga. Prvi je želja da se minimizira potreba za viljuške. U tradicionalnim kriptovalutama svi parametri se postavljaju u početnoj fazi i svaki pokušaj njihove promjene zapravo dovodi do pojave “alternativnog univerzuma kriptovaluta”. Drugi razlog je podrška za drobljenje (shading, shading) blockchain. Blockchain je struktura koja s vremenom ne može postati manja; i obično je svaki čvor odgovoran za rad mreže primoran da ga potpuno pohrani. U tradicionalnim (centralizovanim) sistemima se za rešavanje ovakvih problema koristi šardiranje: neki zapisi u bazi podataka se nalaze na jednom serveru, neki na drugom itd. U slučaju kriptovaluta, takva funkcionalnost je još uvijek prilično rijetka - posebno zbog činjenice da je teško dodati sharding sistemu gdje to nije prvobitno planirano.
Kako TON planira riješiti oba gore navedena problema?
Blockchain sadržaj. Radni lanci.
Prije svega, hajde da razgovaramo o tome šta se planira pohraniti u blockchain. Stanja računa („novčanici“ u osnovnom slučaju) i pametni ugovori će biti pohranjeni tamo (radi jednostavnosti, pretpostavit ćemo da je to isto kao i računi). U suštini, ovo će biti obična heš tabela - ključevi u njoj će biti identifikatori account_id, a vrijednosti su strukture podataka koje sadrže takve stvari kao što su:
- ravnoteža;
- šifra pametnog ugovora (samo za pametne ugovore);
- pohrana podataka o pametnim ugovorima (samo za pametne ugovore);
- statistika;
- (opciono) javni ključ za transfere sa računa, podrazumevano account_id;
- red odlaznih poruka (ovdje se unose za prosljeđivanje primaocu);
- lista najnovijih poruka isporučenih na ovaj račun.
Kao što je gore spomenuto, sami blokovi se sastoje od transakcija - poruka koje se isporučuju na različite account_id račune. Međutim, pored account_id, poruke sadrže i 32-bitno polje workchain_id — takozvani identifikator radni lanac (radni lanac, radni blockchain). Ovo vam omogućava da imate nekoliko blockchaina neovisnih jedan od drugog s različitim konfiguracijama. U ovom slučaju, workchain_id = 0 se smatra posebnim slučajem, zero workchain — bilansi u njemu će odgovarati kriptovaluti TON (Grams). Najvjerovatnije, u početku, drugi radni lanci uopće neće postojati.
Shardchains. Paradigma beskonačnog šardinga.
Ali rast broja blockchaina tu ne staje. Pozabavimo se shardingom. Zamislimo da je svakom računu (account_id) dodijeljen vlastiti blockchain – on sadrži sve poruke koje mu dolaze – a stanja svih takvih blockchaina su pohranjena na odvojenim čvorovima.
Naravno, ovo je veoma rasipno: najvjerovatnije u svakom od ovih shardchains (shardchain, shard blockchain) transakcije će stizati vrlo retko i biće potrebno mnogo moćnih čvorova (gledajući unapred, napominjem da ne govorimo samo o klijentima na mobilnim telefonima – već o ozbiljnim serverima).
Stoga, shardchain kombinuje račune prema binarnim prefiksima svojih identifikatora: ako shardchain ima prefiks 0110, tada će uključivati transakcije svih account_idova koji počinju ovim brojevima. Ovo shard_prefix može imati dužinu od 0 do 60 bita - a glavna stvar je da se može dinamički mijenjati.
Čim jedan od shardchain-ova počne primati previše transakcija, čvorovi koji rade na njemu, prema unaprijed određenim pravilima, ga "podijele" na dva djeteta - njihovi prefiksi će biti jedan malo duži (a za jednog od njih ovaj bit će biti jednako 0, a za drugi - 1). Na primjer, shard_prefix = 0110b će se podijeliti na 01100b i 01101b. Zauzvrat, ako se dva "susjedna" shardchaina počnu osjećati dovoljno opušteno (neko vrijeme), oni će se ponovo spojiti.
Dakle, šardiranje se vrši "odozdo prema gore" - pretpostavljamo da svaki račun ima svoj shard, ali su za sada "slijepljeni" prefiksima. To je ono što to znači Paradigma beskonačnog šardinga (paradigma beskonačnog šardinga).
Zasebno, želio bih naglasiti da radni lanci postoje samo virtualno – zapravo, workchain_id dio je identifikatora specifičnog shardchaina. U formalnom smislu, svaki shardchain je definiran parom brojeva (workchain_id, shard_prefix).
Ispravljanje greške. Vertikalni blockchains.
Tradicionalno, svaka transakcija na blockchainu se smatra „uklesanom“. Međutim, u slučaju TON-a moguće je „prepisati istoriju“ - u slučaju da neko (tzv. ribarski čvor) će dokazati da je jedan od blokova pogrešno potpisan. U ovom slučaju, poseban blok korekcije se dodaje u odgovarajući shardchain, koji sadrži hash samog bloka koji se ispravlja (a ne posljednjeg bloka u shardchainu). Razmišljajući o shardchain-u kao o lancu blokova postavljenih horizontalno, možemo reći da je korektivni blok pričvršćen za pogrešni blok ne desno, već odozgo - pa se smatra da postaje dio malog „vertikalnog blockchaina“ . Dakle, možemo reći da shardchains jesu dvodimenzionalni blockchains.
Ako su nakon pogrešnog bloka promjene koje je izvršio referencirale naredni blokovi (tj. nove transakcije su napravljene na osnovu nevažećih), ispravne se također dodaju ovim blokovima "na vrh". Ako blokovi nisu uticali na „pogođene“ informacije, ovi „korektivni talasi“ se ne odnose na njih. Na primjer, na gornjoj ilustraciji, transakcija prvog bloka, povećavajući stanje računa C, prepoznata je kao neispravna - dakle, transakciju kojom se smanjuje stanje ovog računa u trećem bloku također treba poništiti, a korektivni blok treba biti urezan na vrhu samog bloka.
Treba napomenuti da iako su korektivni blokovi prikazani kao locirani "iznad" originalnih, oni će zapravo biti dodati na kraj odgovarajućeg blockchaina (gdje bi trebali biti hronološki). Dvodimenzionalna lokacija samo pokazuje na koju tačku u blockchainu će biti "povezani" (preko heša originalnog bloka koji se nalazi u njima).
Možete zasebno filozofirati o tome koliko je dobra odluka da se „promijeni prošlost“. Čini se da ako dopustimo mogućnost pojave pogrešnog bloka u shardchainu, onda ne možemo izbjeći mogućnost pojave pogrešnog korektivnog bloka. Ovdje je, koliko mogu zaključiti, razlika u broju čvorova koji moraju postići konsenzus o novim blokovima - bit će relativno mali broj ljudi koji će raditi na svakom shardchainu."radna grupa» čvorovi (koji prilično često mijenja svoj sastav), a za uvođenje korektivnih blokova bit će potrebna saglasnost svih validator čvorovi. Više ću govoriti o validatorima, radnim grupama i drugim ulogama čvorova u sljedećem članku.
Jedan blockchain da vlada njima svima
Postoji mnogo gore navedenih informacija o različitim tipovima blok-čejnova, koji bi također trebali biti negdje pohranjeni. Konkretno, govorimo o sljedećim informacijama:
- o broju i konfiguracijama radnih lanaca;
- o broju shardchain-ova i njihovih prefiksa;
- o tome koji su čvorovi trenutno odgovorni za koje šardlanove;
- hashovi posljednjih blokova dodani svim shardchainovima.
Kao što ste mogli pretpostaviti, sve ove stvari su snimljene u drugom blockchain skladištu - masterchain (masterchain, master blockchain). Zbog prisustva hashova iz blokova svih shardchain-ova u svojim blokovima, čini sistem visoko povezanim. To, između ostalog, znači da će se generiranje novog bloka u masterchain-u dogoditi odmah nakon generiranja blokova u shardchain-ovima - očekuje se da će se blokovi u shardchain-ovima pojaviti gotovo istovremeno otprilike svakih 5 sekundi, a sljedeći blok u shardchain-u masterchain - sekundu nakon toga.
Ali ko će biti odgovoran za implementaciju celog ovog titanskog posla - za slanje poruka, izvršavanje pametnih ugovora, formiranje blokova u shardchain-u i masterchainu, pa čak i provjeru blokova na greške? Hoće li sve to tajno raditi telefoni miliona korisnika na kojima je instaliran Telegram klijent? Ili će, možda, tim Durova odustati od ideje decentralizacije i njihovi serveri će to učiniti na staromodan način?
Zapravo, ni jedan ni drugi odgovor nije tačan. Ali margine ovog članka brzo ponestaju, pa ćemo o različitim ulogama čvorova (možda ste već primijetili da se spominju neki od njih), kao i o mehanici njihovog rada, govoriti u sljedećem dijelu.
izvor: www.habr.com