Hierdie teks is 'n voortsetting van 'n reeks artikels waarin ek kyk na die struktuur van die (vermoedelik) verspreide netwerk Telegram Open Network (TON), wat voorberei word vir vrystelling vanjaar. IN Ek het sy mees basiese vlak beskryf - die manier waarop die nodusse met mekaar omgaan.
Net vir ingeval, laat ek jou herinner dat ek niks te doen het met die ontwikkeling van hierdie netwerk nie en al die materiaal is afkomstig van 'n oop (alhoewel ongeverifieerde) bron - (daar is ook 'n aangehegte , wat die hoofpunte opsom), wat aan die einde van verlede jaar verskyn het. Die hoeveelheid inligting in hierdie dokument dui na my mening op die egtheid daarvan, hoewel daar geen amptelike bevestiging hiervan is nie.
Vandag sal ons kyk na die hoofkomponent van TON - die blokketting.
Basiese begrippe
Rekening (rekening). 'n Stel data geïdentifiseer deur 'n 256-bis-nommer Rekening ID (dit is meestal die publieke sleutel van die rekeningeienaar). In die basisgeval (sien hieronder nul werkketting), beteken hierdie data die gebruiker se balans. "Beset" 'n spesifieke Rekening ID enigiemand kan, maar jy kan die waarde daarvan net volgens sekere reëls verander.
Slim kontrak (slim kontrak). Trouens, dit is 'n spesiale geval van 'n rekening, aangevul met 'n slim kontrakkode en 'n stoor van sy veranderlikes. As dit in die geval van 'n "beursie" moontlik is om te krediteer en geld daaruit te onttrek volgens relatief eenvoudige en voorafbepaalde reëls, dan word hierdie reëls in die geval van 'n slim kontrak in die vorm van sy kode geskryf (in sommige Turing -volledige programmeertaal).
Blockchain Staat (toestand van blockchain). Die stel toestande van alle rekeninge / slim kontrakte (in die abstrakte sin, 'n hash-tabel, waar die sleutels rekeningidentifiseerders is, en die waardes die data is wat in die rekeninge gestoor is).
Boodskap (boodskap). Hierbo het ek die uitdrukking "krediet en afskryf geld" gebruik - dit is 'n spesifieke voorbeeld van 'n boodskap ("oordrag N gram van rekening rekening_1 per rekening rekening_2"). Dit is duidelik dat slegs die nodus wat die private sleutel van die rekening besit, so 'n boodskap kan stuur. rekening_1 - en kan dit met 'n handtekening bevestig. Die resultaat van die lewering van sulke boodskappe aan 'n gewone rekening is 'n toename in sy saldo, en tot 'n slim kontrak - die uitvoering van sy kode (wat die ontvangs van die boodskap sal verwerk). Natuurlik is ander boodskappe ook moontlik (die oordrag van nie geldelike bedrae nie, maar arbitrêre data tussen slim kontrakte).
Transaksie (transaksie ). Die feit om 'n boodskap te lewer, word 'n transaksie genoem. Transaksies verander die toestand van die blokketting. Dit is uit transaksies (boodskapafleweringsrekords) wat die blokke in die blokketting bestaan. In hierdie verband kan jy aan die toestand van die blokketting dink as 'n inkrementele databasis - alle blokke is "diffs" wat opeenvolgend toegepas moet word om die huidige toestand van die databasis te kry. Die besonderhede van die verpakking van hierdie "diffs" (en die herstel van die volle toestand deur hulle te gebruik) sal in die volgende artikel bespreek word.
Blockchain in TON: wat is dit en hoekom?
Soos in die vorige artikel genoem, Blockchain is 'n datastruktuur, waarvan die elemente (blokke) in 'n "ketting" gerangskik is, en elke volgende blok van die ketting bevat 'n hash van die vorige een.. Die vraag is in die kommentaar gevra: hoekom het ons hoegenaamd so 'n datastruktuur nodig as ons reeds 'n DHT - 'n verspreide hash-tabel het? Uiteraard kan sommige data in DHT gestoor word, maar dit is slegs geskik vir nie te "sensitiewe" inligting nie. Cryptocurrency-saldo's kan nie in DHT gestoor word nie - hoofsaaklik as gevolg van die gebrek aan tjeks vir integriteit. Eintlik groei die hele kompleksiteit van die blokkettingstruktuur om inmenging met die data wat daarin gestoor is, te voorkom.
Die blokketting in TON lyk egter selfs meer ingewikkeld as in die meeste ander verspreide stelsels – en daar is twee redes hiervoor. Die eerste is die begeerte om die behoefte aan te verminder vurke. In tradisionele kriptogeldeenhede word alle parameters in die aanvanklike stadium gestel, en enige poging om dit te verander lei eintlik tot die ontstaan van 'n "alternatiewe kriptogeldeenheid-heelal". Die tweede rede is ondersteuning vir verplettering (skeuring, skeuring) blokketting. Blockchain is 'n struktuur wat nie mettertyd kleiner kan word nie; en gewoonlik word elke nodus wat verantwoordelik is vir die gesondheid van die netwerk gedwing om dit heeltemal te stoor. In tradisionele (gesentraliseerde) stelsels word sharding gebruik om sulke probleme op te los: sommige van die rekords in die databasis is op een bediener geleë, sommige op 'n ander, ensovoorts. In die geval van kripto-geldeenhede is sulke funksionaliteit nog redelik skaars - veral as gevolg van die feit dat dit moeilik is om sharding by 'n stelsel te voeg waar dit nie oorspronklik beplan is nie.
Hoe beplan TON om albei bogenoemde probleme op te los?
Blockchain-inhoud. Werkkettings.
Eerstens, kom ons praat oor wat beplan word om in die blokketting gestoor te word. Die toestande van rekeninge (“beursies” in die basisgeval) en slim kontrakte (vir eenvoud sal ons aanvaar dat dit dieselfde is as rekeninge) sal daar gestoor word. Trouens, dit sal 'n gewone hash-tabel wees - die sleutels daarin sal identifiseerders wees Rekening ID, en waardes is datastrukture wat dinge bevat soos:
- balans;
- slimkontrakkode (slegs vir slimkontrakte);
- slimkontrakdataberging (slegs vir slimkontrakte);
- statistieke;
- (opsioneel) publieke sleutel vir oordragte vanaf 'n rekening, rekening_id by verstek;
- tou van uitgaande boodskappe (hier word dit ingevoer vir aanstuur na die ontvanger);
- 'n lys van die jongste boodskappe wat by hierdie rekening afgelewer is.
Soos hierbo genoem, bestaan die blokke self uit transaksies - boodskappe wat aan verskeie rekening-ID-rekeninge afgelewer word. Benewens die rekening-ID bevat boodskappe egter ook 'n 32-bis-veld werksketting-id - identifiseerder van die sogenaamde. werksketting (werksketting, werkende blokketting). Dit laat jou toe om verskeie onafhanklike blokkettings met verskillende konfigurasies te hê. In hierdie geval word workchain_id = 0 as 'n spesiale geval beskou, nul werkketting - dit is die saldo's daarin wat sal ooreenstem met die TON (Grams) kripto-geldeenheid. Heel waarskynlik, aanvanklik sal ander werkkettings glad nie bestaan nie.
Skerfkettings. Oneindige Sharding Paradigma.
Maar die groei in die aantal blokkettings stop nie daar nie. Kom ons hanteer skeuring. Stel jou voor dat elke rekening (account_id) sy eie blokketting het - dit bevat al die boodskappe wat dit ontvang - en die toestande van al sulke blokkettings word op aparte nodusse gestoor.
Dit is natuurlik baie verkwistend: heel waarskynlik in elk hiervan skerwekettings (skerfketting, skerwe blokketting) transaksies sal baie selde ontvang word, en baie kragtige nodusse sal nodig wees (as ek vorentoe kyk, neem ek kennis dat ons nie net oor kliënte op selfone praat nie - maar oor ernstige bedieners).
Daarom kombineer shardchains rekeninge deur binêre voorvoegsels van hul identifiseerders: as 'n shardchain 'n voorvoegsel van 0110 het, sal transaksies van alle account_id wat met hierdie nommers begin, daarin val. Hierdie skerf_voorvoegsel kan 'n lengte van 0 tot 60 bisse hê - en die belangrikste is, dit kan dinamies verander.
Sodra te veel transaksies in een van die skerfkettings begin vloei, "verdeel" die nodusse wat daaraan werk, volgens voorafbepaalde reëls, dit in twee kindertjies - hul voorvoegsels sal 'n bietjie langer wees (en vir een van hulle hierdie bietjie sal 0 wees, en vir die ander - 1). Byvoorbeeld, skerf_voorvoegsel = 0110b verdeel in 01100b en 01101b. Op hul beurt, as twee "naburige" skerfkettings (vir 'n geruime tyd) op hul gemak genoeg begin voel, sal hulle weer saamsmelt.
Skepping word dus "van onder na bo" gedoen - ons neem aan dat elke rekening sy eie skerf het, maar hulle is - voorlopig - "gegom" deur voorvoegsels. Dit is wat dit beteken Oneindige Sharding Paradigma (oneindige versplintering paradigma).
Afsonderlik wil ek beklemtoon dat werkkettings net feitlik bestaan - trouens, werksketting-id dit is deel van die identifiseerder van 'n spesifieke skerfketting. In formele terme word elke skerfketting gedefinieer deur 'n paar getalle (werksketting-id, skerf_voorvoegsel).
Fout regstelling. Vertikale blokkettings.
Daar word tradisioneel geglo dat enige transaksie in die blokketting "in klip" is. In die geval van TON is dit egter moontlik om "geskiedenis te herskryf" - ingeval iemand (die sg. knoop - "visserman") sal bewys dat een van die blokke verkeerd geteken is. In hierdie geval word 'n spesiale regstellende blok by die ooreenstemmende shardchain gevoeg, wat die hash van die gekorrigeerde blok self bevat (en nie die laaste blok in die shardchain nie). Deur die skerfketting voor te stel as 'n ketting blokke wat horisontaal uitgelê is, kan ons sê dat die regstellende blok nie regs aan die foutiewe blok geheg is nie, maar van bo - daarom word dit beskou dat dit deel word van 'n klein "vertikale blokketting" . Daar kan dus gesê word dat shardchains is tweedimensionele blokkettings.
Indien, na 'n foutiewe blokkering, daaropvolgende blokke verwys het na die veranderinge wat daardeur gemaak is (d.w.s. nuwe transaksies is gemaak op grond van ongeldiges), word regstellendes ook by hierdie blokke gevoeg "van bo". As die blokke nie die "geaffekteerde" inligting beïnvloed het nie, is hierdie "regstellende golwe" nie op hulle van toepassing nie. Byvoorbeeld, in die illustrasie hierbo, is die transaksie van die eerste blok, wat die saldo van rekening C verhoog het, as verkeerd erken — daarom moet die transaksie wat die saldo van hierdie rekening in die derde blok verminder het, ook gekanselleer word, en 'n regstellende blok is oor die blok self gepleeg.
Daar moet kennis geneem word dat alhoewel die regstellende blokke uitgebeeld word as "bo" die oorspronklike, sal hulle in werklikheid aan die einde van die ooreenstemmende blokketting gevoeg word (waar hulle chronologies geleë moet wees). Die tweedimensionele rangskikking wys slegs aan watter punt in die blokketting hulle "gehaak" sal word (deur die hash van die oorspronklike blok wat daarin geleë is).
Jy kan apart filosofeer oor hoe goed die besluit is om "die verlede te verander". Dit wil voorkom asof as ons die moontlikheid van die voorkoms van 'n verkeerde blok in die skerfketting toelaat, ons nie die moontlikheid van die voorkoms van 'n foutiewe regstellende blok kan voorkom nie. Hier, sover ek kan sê, sal die verskil in die aantal nodusse wat 'n konsensus moet bereik oor nuwe blokke - relatief klein werk op elke skerfketting "werkgroep» nodusse (wat dikwels die samestelling daarvan verander), en die bekendstelling van regstellende blokke sal die toestemming van almal vereis valideerder nodusse. Ek sal valideerders, werkgroepe en ander nodusrolle in meer besonderhede in 'n toekomstige artikel dek.
Een blokketting om hulle almal te regeer
Bogenoemde lys baie inligting oor die verskillende tipes blokkettings, wat op sigself ook iewers gestoor behoort te word. In die besonder, ons praat oor die volgende inligting:
- oor die aantal en konfigurasies van werkkettings;
- oor die aantal skerfkettings en hul voorvoegsels;
- oor watter nodusse tans verantwoordelik is vir watter skerfkettings;
- hashes van die laaste blokke wat by alle shardchains gevoeg is.
Soos jy dalk geraai het, word al hierdie dinge in 'n ander blokkettingberging aangeteken - meesterketting (meesterketting, meester blokketting). As gevolg van die teenwoordigheid van hashes uit die blokke van alle skerfkettings in sy blokke, maak dit die stelsel hoogs verbind. Dit beteken onder andere dat die generering van 'n nuwe blok in die meesterketting onmiddellik na die generering van blokke in die skerfkettings sal plaasvind - daar word verwag dat blokke in die skerfkettings feitlik gelyktydig ongeveer elke 5 sekondes sal verskyn, en die volgende blok in die meesterketting - 'n sekonde daarna.
Maar wie sal verantwoordelik wees vir die implementering van al hierdie titaniese werk - om boodskappe te stuur, slim kontrakte uit te voer, blokke in skerfkettings en die meesterketting te vorm, en selfs blokke vir foute na te gaan? Sal die telefone van miljoene gebruikers met die Telegram-kliënt op hulle geïnstalleer, dit regtig alles op die planke doen? Of miskien sal die Durov-span die idees van desentralisasie laat vaar en hul bedieners sal dit op die outydse manier doen?
Trouens, nie die een óf die ander antwoord is korrek nie. Maar die velde van hierdie artikel eindig vinnig, so ons sal in die volgende deel praat oor die verskillende rolle van nodusse (jy het dalk al opgemerk dat sommige van hulle genoem is), sowel as die meganika van hul werk.
Bron: will.com