Tämä teksti on jatkoa artikkelisarjalle, jossa tutkin (oletettavasti) hajautetun verkon Telegram Open Network (TON) rakennetta, jota valmistellaan julkaistavaksi tänä vuonna. SISÄÄN Kuvasin sen alkeellisinta tasoa - tapaa, jolla solmut ovat vuorovaikutuksessa toistensa kanssa.
Varmuudeksi muistutan, että minulla ei ole mitään tekemistä tämän verkon kehittämisen kanssa ja kaikki materiaali on poimittu avoimesta (tosin todentamattomasta) lähteestä - (on myös mukana , jossa esitetään lyhyesti pääkohdat), joka ilmestyi viime vuoden lopussa. Tässä asiakirjassa olevien tietojen määrä osoittaa mielestäni sen aitouden, vaikka tälle ei ole virallista vahvistusta.
Tänään tarkastelemme TONin pääkomponenttia - lohkoketjua.
Peruskonseptit
tili (tili). Tietojoukko, joka tunnistetaan 256-bittisellä numerolla Tilin tunnus (useimmiten tämä on tilin omistajan julkinen avain). Perustapauksessa (katso alla nolla työketjua), nämä tiedot viittaavat käyttäjän saldoon. "Occupy" erityinen Tilin tunnus kuka tahansa voi, mutta sen arvoa voidaan muuttaa vain tiettyjen sääntöjen mukaisesti.
Älykäs sopimus (älykäs sopimus). Pohjimmiltaan se on tilin erikoistapaus, jota on täydennetty älykkäällä sopimuskoodilla ja sen muuttujien tallennuksella. Jos "lompakon" tapauksessa voit tallettaa ja nostaa siitä rahaa suhteellisen yksinkertaisten ja ennalta määrättyjen sääntöjen mukaisesti, niin älykkään sopimuksen tapauksessa nämä säännöt kirjoitetaan sen koodin muodossa (tietyssä Turing-täydellisessä muodossa ohjelmointikieli).
Lohkoketjun osavaltio (lohkoketjun tila). Kaikkien tilien/älykkäiden sopimusten tilojen joukko (abstraktissa mielessä hash-taulukko, jossa avaimet ovat tilitunnisteita ja arvot tileille tallennettuja tietoja).
Viesti (viesti). Yllä käytin ilmaisua "luotto- ja veloitusrahat" - tämä on erityinen esimerkki viestistä ("siirto N grammaa tililtä tili_1 tilille tili_2"). Ilmeisesti vain solmu, joka omistaa tilin yksityisen avaimen, voi lähettää tällaisen viestin tili_1 - ja voi vahvistaa tämän allekirjoituksella. Tällaisten viestien toimittaminen tavalliselle tilille johtaa sen saldon kasvuun, ja älykkään sopimuksen seurauksena sen koodi (joka käsittelee viestin vastaanottamisen) suoritetaan. Tietysti myös muut viestit ovat mahdollisia (ei rahasummien, vaan mielivaltaisten tietojen siirtäminen älykkäiden sopimusten välillä).
Tapahtuma (kauppa). Tosiasia, että viesti toimitetaan, kutsutaan tapahtumaksi. Tapahtumat muuttavat lohkoketjun tilaa. Tapahtumat (viestien toimitustietueet) muodostavat lohkot lohkoketjussa. Tässä suhteessa voit ajatella lohkoketjun tilaa inkrementaalisena tietokantana - kaikki lohkot ovat "diffejä", joita on käytettävä peräkkäin tietokannan nykyisen tilan saamiseksi. Näiden "erojen" pakkaamisen (ja täyden tilan palauttamisen niistä) yksityiskohtia käsitellään seuraavassa artikkelissa.
Blockchain in TON: mikä se on ja miksi?
Kuten edellisessä artikkelissa mainittiin, lohkoketju on tietorakenne, jonka elementit (lohkot) on järjestetty "ketjuksi" ja jokainen seuraava ketjun lohko sisältää edellisen tiivisteen. Kommenteissa kysyttiin: miksi ylipäänsä tarvitsemme tällaista tietorakennetta, kun meillä on jo DHT - hajautettu hash-taulukko? Tietysti jotkin tiedot voidaan tallentaa DHT:hen, mutta tämä sopii vain ei liian "arkaluonteisille" tiedoille. Kryptovaluutan saldoja ei voida tallentaa DHT:hen - ensisijaisesti tarkistusten puutteen vuoksi eheys. Itse asiassa lohkoketjurakenteen koko monimutkaisuus kasvaa, jotta vältetään häiriöt siihen tallennettuihin tietoihin.
TONin lohkoketju näyttää kuitenkin vieläkin monimutkaisemmalta kuin useimmissa muissa hajautetuissa järjestelmissä - ja kahdesta syystä. Ensimmäinen on halu minimoida tarve haarukat. Perinteisissä kryptovaluutoissa kaikki parametrit asetetaan alkuvaiheessa ja jokainen yritys muuttaa niitä johtaa itse asiassa "vaihtoehtoisen kryptovaluuttauniversumin" syntymiseen. Toinen syy on murskaustuki (sirpalointia, sirpalointia) lohkoketju. Blockchain on rakenne, joka ei voi pienentyä ajan myötä; ja yleensä jokainen verkon toiminnasta vastaava solmu pakotetaan tallentamaan se kokonaan. Perinteisissä (keskitetyissä) järjestelmissä tällaisten ongelmien ratkaisemiseen käytetään sirpalointia: osa tietokannan tietueista sijaitsee yhdellä palvelimella, osa toisella jne. Kryptovaluuttojen tapauksessa tällainen toiminnallisuus on edelleen melko harvinaista - varsinkin johtuen siitä, että shardingin lisääminen järjestelmään on vaikeaa, jos sitä ei alun perin suunniteltu.
Miten TON aikoo ratkaista molemmat yllä olevat ongelmat?
Blockchain-sisältö. Työketjut.
Ensinnäkin puhutaan siitä, mitä on tarkoitus tallentaa lohkoketjuun. Tilien tilat (perustapauksessa "lompakot") ja älykkäät sopimukset tallennetaan sinne (yksinkertaisuuden vuoksi oletetaan, että tämä on sama kuin tilit). Pohjimmiltaan tämä on tavallinen hash-taulukko - sen avaimet ovat tunnisteita Tilin tunnus, ja arvot ovat tietorakenteita, jotka sisältävät muun muassa:
- saldo;
- älykäs sopimuskoodi (vain älykkäille sopimuksille);
- älykkäiden sopimusten tietojen tallennus (vain älykkäille sopimuksille);
- tilastot;
- (valinnainen) julkinen avain tilisiirroille, oletuksena account_id;
- lähtevien viestien jono (tähän ne syötetään edelleenlähetettäväksi vastaanottajalle);
- luettelo viimeisimmistä tälle tilille toimitetuista viesteistä.
Kuten edellä mainittiin, itse lohkot koostuvat tapahtumista - viesteistä, jotka toimitetaan eri account_id-tileille. Viestit sisältävät kuitenkin tunnuksen account_id lisäksi myös 32-bittisen kentän workchain_id — niin sanottu tunniste työketju (työketju, toimiva lohkoketju). Tämän ansiosta sinulla on useita toisistaan riippumattomia lohkoketjuja eri kokoonpanoilla. Tässä tapauksessa workchain_id = 0 katsotaan erikoistapaukseksi, nolla työketjua - siinä olevat saldot vastaavat kryptovaluuttaa TON (grammaa). Todennäköisesti aluksi muita työketjuja ei ole ollenkaan.
Sirpaketjut. Infinite Sharding Paradigma.
Mutta lohkoketjujen määrän kasvu ei pysähdy tähän. Käsitellään sirpalointia. Kuvitellaan, että jokaiselle tilille (account_id) on varattu oma lohkoketjunsa - se sisältää kaikki sille tulevat viestit - ja kaikkien tällaisten lohkoketjujen tilat tallennetaan erillisiin solmuihin.
Tietenkin tämä on erittäin tuhlausta: todennäköisesti kaikissa näissä sirpaleita (sirpaleketju, sirpale lohkoketju) -tapahtumat saapuvat hyvin harvoin, ja tarvitaan paljon tehokkaita solmuja (tulevaisuudessa huomaan, että emme puhu vain matkapuhelimissa olevista asiakkaista - vaan vakavista palvelimista).
Siksi shardchains yhdistävät tilit tunnisteidensa binäärietuliitteillä: jos sirpaleketjun etuliite on 0110, se sisältää kaikkien tilitunnusten tapahtumat, jotka alkavat näillä numeroilla. Tämä shard_etuliite voi olla pituudeltaan 0 - 60 bittiä - ja tärkeintä on, että se voi muuttua dynaamisesti.
Heti kun yksi sirpaleketjuista alkaa vastaanottaa liian monta tapahtumaa, sen parissa työskentelevät solmut "jakavat" sen kahdeksi lapseksi - niiden etuliitteet ovat hieman pidempiä (ja yhdelle heistä tämä bitti on yhtä suuri kuin 0 ja toiselle - 1). Esimerkiksi, shard_etuliite = 0110b jakautuu 01100b ja 01101b. Jos taas kaksi "naapuriketjua" alkavat tuntea olonsa riittävän tyytyväiseksi (jonkin aikaa), ne sulautuvat uudelleen.
Siten sirpalointi tapahtuu "alhaalta ylöspäin" - oletamme, että jokaisella tilillä on oma sirpaleensa, mutta toistaiseksi ne on "liimattu yhteen" etuliitteillä. Tätä se tarkoittaa Infinite Sharding Paradigma (ääretön sharding paradigma).
Erikseen haluan korostaa, että työketjut ovat olemassa vain virtuaalisesti - itse asiassa, workchain_id se on osa tietyn sirpaleketjun tunnistetta. Muodollisesti jokainen sirpaleketju määritellään numeroparilla (workchain_id, shard_etuliite).
Virheen korjaus. Pystysuorat lohkoketjut.
Perinteisesti kaikki lohkoketjun tapahtumat katsotaan "kiveen hakattuiksi". TONin tapauksessa on kuitenkin mahdollista "kirjoittaa historiaa uudelleen" - jos joku (ns. kalastajan solmu) todistaa, että yksi lohkoista on allekirjoitettu väärin. Tässä tapauksessa vastaavaan shardchainiin lisätään erityinen korjauslohko, joka sisältää itse korjattavan lohkon tiivisteen (eikä shardchainin viimeistä lohkoa). Ajatellessa sirpaleketjua vaakasuoraan asetettuna lohkojen ketjuna, voidaan sanoa, että korjaava lohko on kiinnitetty virheelliseen lohkoon ei oikealta, vaan ylhäältä - joten sen katsotaan muuttuvan osaksi pientä "pystysuoraa lohkoketjua". . Siten voimme sanoa, että sirpaleet ovat kaksiulotteiset lohkoketjut.
Jos virheellisen lohkon jälkeen sen tekemiin muutoksiin viitattiin myöhemmissä lohkoissa (eli uusia tapahtumia tehtiin virheellisten tapahtumien perusteella), myös korjaavia lisätään näihin lohkoihin "päälle". Jos lohkot eivät vaikuttaneet "vaikuttaviin" tietoihin, nämä "korjaavat aallot" eivät koske niitä. Esimerkiksi yllä olevassa kuvassa ensimmäisen lohkon tapahtuma, joka lisää tilin C saldoa, tunnistettiin virheelliseksi - siksi myös tämän tilin saldoa pienentävä tapahtuma kolmannessa lohkossa tulisi peruuttaa ja korjaava lohko tulisi sitoutua itse lohkon päälle.
On huomattava, että vaikka korjaavat lohkot on kuvattu sijaitsevina "alkuperäisten" yläpuolella, itse asiassa ne lisätään vastaavan lohkoketjun loppuun (missä niiden tulisi olla kronologisesti). Kaksiulotteinen sijainti näyttää vain, mihin kohtaan lohkoketjussa ne "linkitetään" (niissä olevan alkuperäisen lohkon hashin kautta).
Voit erikseen filosofoida siitä, kuinka hyvä päätös "muuttaa menneisyyttä" on. Vaikuttaa siltä, että jos myönnämme mahdollisen virheellisen lohkon ilmestymisen sirpaleketjuun, emme voi välttää virheellisen korjauslohkon ilmaantumista. Tässä, sikäli kuin voin kertoa, ero on niiden solmujen määrässä, joiden on päästävä yksimielisyyteen uusista lohkoista - jokaisella sirpaleketjulla työskentelee suhteellisen pieni määrä ihmisiä."työryhmä» solmut (joka muuttaa koostumustaan melko usein), ja korjaavien lohkojen käyttöönotto vaatii kaikkien suostumuksen validaattorisolmut. Puhun lisää validaattoreista, työryhmistä ja muista solmun rooleista seuraavassa artikkelissa.
Yksi lohkoketju hallitsee niitä kaikkia
Yllä on lueteltu paljon tietoa erityyppisistä lohkoketjuista, jotka sinänsä pitäisi myös tallentaa jonnekin. Puhumme erityisesti seuraavista tiedoista:
- työketjujen lukumäärästä ja kokoonpanoista;
- shardchainien ja niiden etuliitteiden lukumäärästä;
- siitä, mitkä solmut ovat tällä hetkellä vastuussa mistäkin sirpaleketjuista;
- viimeisten lohkojen tiivisteet lisätty kaikkiin shardchaineihin.
Kuten saatat arvata, kaikki nämä asiat on tallennettu toiseen lohkoketjun tallennustilaan - mestariketju (pääketju, päälohkoketju). Koska sen lohkoissa on tiivisteitä kaikkien shardchainien lohkoista, se tekee järjestelmästä erittäin yhdistetyn. Tämä tarkoittaa muun muassa sitä, että uuden lohkon generointi masterchainissa tapahtuu välittömästi lohkojen luomisen jälkeen sirpaketjuissa - on odotettavissa, että sirpaleiden lohkot ilmestyvät lähes samanaikaisesti noin 5 sekunnin välein, ja seuraava lohko masterchain - sekunti sen jälkeen.
Mutta kuka on vastuussa kaiken tämän titaanisen työn toteuttamisesta - viestien lähettämisestä, älykkäiden sopimusten toteuttamisesta, lohkojen muodostamisesta sirpaleisiin ja masterchainiin ja jopa lohkojen virheiden tarkistamisesta? Tekevätkö tämän kaiken salaa miljoonien käyttäjien puhelimilla, joihin on asennettu Telegram-asiakas? Tai kenties Durov-tiimi hylkää hajautuksen ideat ja heidän palvelimensa tekevät sen vanhanaikaisesti?
Itse asiassa kumpikaan vastaus ei ole oikea. Mutta tämän artikkelin marginaalit ovat nopeasti loppumassa, joten puhumme seuraavassa osassa solmujen eri rooleista (olet ehkä jo huomannut mainintoja joistakin niistä), sekä heidän työn mekaniikasta.
Lähde: will.com