TON: Telegram Open Network. Osa 1: Sissejuhatus, võrgu tase, ADNL, DHT, ülekatted

Kaks nädalat on Ruunet rääkinud Telegramist ja olukorrast, kus Roskomnadzor on selle mõttetu ja julma blokeeringu rakendanud. Kaja on tabanud paljusid, kuid see kõik on teema postituste jaoks Geektimesis. Mind aga üllatas midagi muud – ma pole siiani näinud Habras ühtegi analüüsi Telegrami baasil välja tulevast TON — Telegram Open Network. Soovin selle puudujäägi täita, kuna seal on palju uurimistööd — isegi vaatamata sellele, et ametlikke avaldusi ei ole.

Kordan — räägitakse kuuldustest, et Telegram on käivitanud väga ulatusliku suletud ICO, kogudes juba seal uskumatuid summasid. Eeldatakse, et juba sel aastal käivitatakse oma krüptovaluuta Gram — ja igal Telegrami kasutajal tekib automaatselt ülekandekott, mis iseenesest loob väga palju eeliseid teiste krüptovaluutade ees.

Kahjuks, kuna ametlikke avaldusi ei ole, saan edaspidi tugineda ainult tundmatu päritoluga dokumendile, millest ma kohe teid hoiatama hakkan. Loomulikult võib see olla väga oskuslik vale, kuid ei ole välistatud, et see on tulevase süsteemi tõeline whitepaper, mille on kirjutanud Nikolai Durov (ja mis on tõenäoliselt lekitatud mõne investori poolt). Kuid isegi kui see on vale, ei saa keegi meid keelata seda uurimast ja arutamast, eks?

Mida siis selles dokumendis öeldakse? Proovin seda oma sõnadega edasi anda, lähedalt tekstile, kuid eesti keeles ja veidi inimlikumalt (palun andestage mulle, Nikolai, teie kalduvuse eest minna formaalse matemaatika juurde). Pidage meeles, et isegi kui see on tõeline, on see süsteemi mustandkirjeldus ja see tõenäoliselt muutub avaliku käivitamise ajaks.

Saame teada, et lisaks krüptovaluutale on oodata veel väga ja väga palju muud. Vaatame järjestikku.

• TON Blockchain. See on kogu süsteemi alus. Kui te ei tea, mis on blokchain — soovitan teada saada, sest siin on palju blokchaine. Üksteise sisse peidetud, virtuaalselt purustatud ja isegi 'vertikaalsed' blokchainid teiste blokchainide sees. Ja siin on veel mitmeid ägedalt kõlavad termineid, näiteks Instant Hypercube Routing ja Piiramatu jaotamise paradigma, kuid sellest hiljem. Ja muidugi, tõend-panik ja nutilepingud.
• TON P2P võrk. Peer-to-peer võrk, mille põhjal süsteem töötab. Sellel teemal räägitakse selle loo esimeses osas.
• TON salvestus. Failide salvestus, mis sõltumata plokiahelast ehitatakse eespool mainitud peer-to-peer võrgule. Seda on võimalik võrrelda torrentidega.
• TON Proxy. Teenus, mille eesmärk on suurendada võrguliikmete anonüümsust. Iga andmepakett saab saata mitte otse, vaid läbi vahetus-tunnelite koos täiendava krüptimisega — sarnaselt I2P või TOR-iga.
• TON DHT. Jagatud hash-tabel juhuslike väärtuste hoidmiseks. See on samuti üles ehitatud TON võrgule (kuid kasutab selle omadusi) ja aitab TON salvestus leida 'jagamise' sõlme, ja TON Proxy — vahepealseid edastajaid. Kuid tuleb märkida, et erinevalt plokiahelast ei ole see hash-tabel turvaline salvestus — seal ei tohi olulisi andmeid hoida.
• TON teenused. Platvorm, mis võimaldab mitmesuguseid teenuseid. Tegelikult on see uus Internet kõigi ülaltoodud põhimõtete põhjal. Andmevahetus toimub läbi TON võrgule/TON Proxy, samas logika on nutilepingutes ise. TON Blockchain. Ja liides üsna harjumuspäraste URL-idega.
• TON DNS. Kui juba juttu on harjumuspärastest URL-idest, siis on vaja ka konverterit, mis teisendab need 256-bitisteks aadressideks — konto, lepingute, teenuste ja sõlmede jaoks.
• TON Payments. Siin tõstatub rahaküsimus. Ja see ei piirdu mitte ainult gramiga — nagu eetri puhul, on kõik võimalikud „tokenid”; gramid on siin lihtsalt „vaikimisi” valuuta.

See on esimene osa, mis kirjeldab TON-i „maapealset” taset — selle võrguosa, mis ehitatakse traditsiooniliste protokollide peale. Järgmisel osal räägitakse „südamikust” — plokiahelast, mida toetab hiljem kirjeldatav süsteem. Seega, minu jutt erineb mõnevõrra ülalmainitud dokumendis kasutatud korrast (mis algab kohe abstraktselt).

Põhiteadmised

TL (Type Language). See on abstraktne binaarvorming, mida kasutatakse suvaliste andmestruktuuride jaoks. Seda kasutatakse Telegrami protokollis ja see leiab aktiivset kasutust TON-is. Kui soovite sellega põhjalikult tutvuda — siin on selle kirjeldus.

Hash (hash). Funktsioon, mis teostab pöördumatut muundamist suvalisest andmestruktuurist fikseeritud pikkusega numbriks. Dokumentatsioonis räägitakse laialdaselt funktsioonist SHA-256.

Võrgu sõlm (node). Sõlm on tarkvara, mis tagab süsteemi toimimise. Eelkõige eeldatakse, et iga Telegrami kliendirakendus sisaldab TON-i sõlme. Madalamal tasemel omavad sõlmed IPv4/IPv6 aadresse ja suhtlevad UDP protokolli kaudu, kõrgemal tasemel omavad nad abstraktseid aadresse ja rakendavad ADNL protokolli (abstraktsete aadresside ja ADNL kohta - vt allpool). Kui räägitakse, et osad süsteemist teevad midagi või salvestavad andmeid, eeldatakse, et seda teevad võrgu sõlmed.

Abstraktne aadress (või lihtsalt aadress, address). Künode aadress määratakse tema avaliku võtme järgi. Täpsemalt öeldes on see 256-bitine räsi (SHA256) andmestruktuurist, mis sisaldab avalikku võtmet. Konkreetne krüptograafiline algoritm ei ole selgelt määratletud - näiteks tuuakse välja elliptilised kõverad ja RSA-2048. Selleks, et üks sõlm saaks omavahel suhelda, peab ta teadma mitte ainult teise aadressi, vaid ka seda andmestruktuuri. Teoreetiliselt võib üks füüsiline sõlm luua suvalise arvu aadresse (mis vastavad erinevatele võtmetele).

Järgnevalt kasutatakse sageli just sellist kombinatsiooni: „prototüüp” TL-struktuuri näol (mis sisaldab praktiliselt igasuguseid andmeid) ja 256-bitine räsi sellest, mida kasutatakse adresseerimiseks.

Plokiahel (plokiahel). Plokiahel on andmestruktuur, mille elemendid (plokid) on korraldatud „ahelas”, ning iga järgmine ahel bloke sisaldab eelneva räsi. Nii saavutatakse terviklikkus - muudatusi saab teha ainult uute plokkide lisamisega.

Teenuse (teenus). TONi raames teenuseid on erinevaid tüüpe — olenevalt sellest, kas need kasutavad plokiahelat või mitte. Näiteks võib üks (või mitu) võrgu sõlme töödelda teatud RPC-päringuid allpool kirjeldatud ADNL-protokolli kaudu, luues samas plokiahelas mingeid kirjeid — nagu traditsioonilised veebiserverid. Samuti kaalutakse võimalust rakendada HTTP-d ADNL-i peal ning üle minna ka ise suhtlusrakendusele selle protokolli peale. Sarnaselt TOR-i või I2P-ga, teeb see selle erinevate blokeeringute suhtes vastupidavamaks.

Samas hõlmavad mitmed teenused nii plokiahela kui plokiahelast väljaspool toimuva suhtlemise. Näiteks TON Storage'i — failide hoidla — puhul pole mõistlik faile plokiahelas hoida. Seal sisaldatakse vaid failide räsisid (koos mingite metaandmetega nende kohta), samas kui „failiserveritena“ toimivad spetsialiseeritud võrgu sõlmed, mis on valmis neid teistele sõlmedele ADNL-i kaudu edastama.

Udu teenus (fog service). Räägime teenustest, mis hõlmavad detsentraliseerimist ja avatud osalemist. Näiteks TON Proxy on teenus, mida toetada saab iga liige, kes soovib pakkuda oma sõlme vahendajana (proxy), edastades pakette teiste sõlmede vahel. Ta võib küsida selle eest kehtestatud tasu — kasutades TON Paymentsi mikromaksete süsteemi (mis omakorda on samuti hajutatud teenus).

ADNL: Abstraktne Datagrammi Võrgukiht

Madalaimal tasemel toimub suhtlemine sõlmede vahel UDP-protokolli kaudu (kuigi on lubatud ka teised variandid).

Nagu eelnevalt mainitud, peab üks sõlm saatma paberi teisele, teadma ühte tema avalikest võtmetest (ja seega ka aadressi, mille see määrab). Ta krüpteerib paketi selle võtmega ja lisab paketi algusesse 256-bitise saaja aadressi — kuna ühel sõlmel võib olla mitu sellist aadressi, võimaldab see tal kindlaks teha, millist võtit kasutada dekrüpteerimiseks.

Lisaks võib andmepaketi alguses saaja aadressi asemel olla nn identifikaator kanal. Sel juhul sõltub paketi töötlemine konkreetsest kokkuleppest sõlmede vahel - näiteks võivad teatud kanalisse saadetud andmed olla mõeldud teisele sõlmele ja need peavad olema talle edasi suunatud (see on teenus. TON Proxy). Teine erijuhtum võib olla otsene suhtlemine sõlmede vahel, kuid sel juhul tuleb selle kanali jaoks kasutada individuaalset võtmepaariga krüptimist (eelnevalt loodud Diffie-Hellmani protokolli järgi).

Lõpuks on erijuhuks 'null' kanal - kui sõlm ei tea veel oma 'naabrite' avalikke võtmeid, võib ta saata neile pakette täiesti krüptimata. See on mõeldud ainult initsialiseerimiseks - niipea kui sõlmed saadavad teavet oma võtmete kohta, tuleb neid kasutada edasiseks suhtlemiseks.

Ülaltoodud protokolli (256-bitine kanalituvastus + paketi sisu) nimetatakse ADNL-ks. Dokumentatsioon mainib, et selle üle võiks rakendada TCP analooge või oma ülesehitust - RLDP (Reliable Large Datagram Protocol), kuid ei lähe detailidesse nende rakendamise osas.

TON DHT: Jaotatud hash-tabel

Nagu teiste jaotatud süsteemide puhul, eeldab TON DHT elluviimist — jaotatud räsitabeli. Täpsemalt öeldes — tabel on Kademlia-tüüpi. Kui te ei ole sellise räsitabeli tüübiga tuttav — ärge muretsege, ma selgitan edaspidi lühidalt, kuidas need toimivad.

Abstraktselt öeldes seondab DHT 256-bitiseid võtmeid teatud binaarsete väärtustega, mille pikkus on suvaline. Samuti on võtmed tabelis räsid kindla TL-struktuuri (need struktuurid salvestatakse samuti koos DHT-ga). See sarnaneb tõeliselt sõlmede aadresside loomisega — ja need võivad tõepoolest DHT-s esineda (näiteks võib sellise võtme all asuda vastava sõlme IP-aadress antud abstraktse aadressi, kui see ei varja seda). Aga üldiselt öeldes, "võtmete proovid" (nende kirjeldused, key descriptions) — need metaandmed, mis näitavad registreerimise "omanikku" (st mingi sõlme avalikku võtit), salvestatud väärtuse tüüpi ja reegleid, mille alusel seda kirjet hiljem muudetakse. Näiteks võib reegel lubada väärtuse muutmist ainult omanikule või keelata väärtuse vähendamise (kaitseks replay-rünnakute eest).

Lisaks 256-bitistele võtmetele tutvustatakse DHT-aadresse. Erinevus tavalistest sõlme aadressidest on see, et DHT-aadress on tingimata seotud IP-aadressiga. Kui sõlm ei peida oma IP-d, võib ta DHT jaoks kasutada tavapärast aadressi. Kuid sagedamini luuakse DHT jaoks eraldi, "pool-püsiv" aadress.

Võtmete ja DHT-aadresside puhul tutvustatakse kauguse mõistet — selles osas kattub see tabelitega Kademlia — võtmete vahelise kauguse väärtus on XOR (bitihommik välistav OR) neist. Nagu Kademlia tabelites, peab väärtus, mis vastab teatud võtmele, olema talletatud s sõlmedes, mille kaugus selle võtme suhtes on kõige väiksem (s siin — suhteliselt väike number).

Kuna DHT sõlm peab suhtlema teiste selliste sõlmedega, hoiab ta meeles DHT marsruuditabelit — DHT- ja IP-aadressid sõlmedest, millega ta varem suheldud, gruppeeritakse nende kauguse alusel. Selliseid gruppe on 256 (need vastavad kauguse väärtuse kõrgeima seadistatud bitile — st sõlmed, mis on kaugusel 0 kuni 255, kuuluvad ühte gruppi, 256 kuni 65535 — järgmisse jne.). Igas grupis hoitakse piiratud arvu „parimaid“ sõlmi (põhinedes nendele pingele).

Iga sõlm peab toetama mitmeid operatsioone: võtme väärtuse salvestamine, sõlmede otsimine ja väärtuste otsimine. Sõlmede otsimine tähendab, et antud võtme alusel saadakse lähimad sõlmed marsruuditi tabelist; väärtuste otsimine on sama, välja arvatud juhul, kui sõlm teab võtme väärtust (siis tagastab ta lihtsalt selle). Vastavalt, kui sõlm soovib DHT-s leida väärtuse võtme alusel, saadab ta päringud väikesele hulgale lähimatele sõlmedele oma marsruuditi tabelist. Kui nende vastustes ei ole soovitud väärtust, kuid on teisi sõlmi, siis päringut korratakse nende poole.

TON DHT-d saab kasutada erinevate eesmärkide jaoks, näiteks — failide torrent-tüüpi salvestamiseks (vt. TON salvestus); teenuste rakenduste sõlmede aadresside määramiseks; konto omanike teabe säilitamiseks plokiahelas. Kuid kõige olulisem rakendus on sõlmede tuvastamine nende abstraktsete aadresside järgi. Selleks kasutatakse aadressit võtmena, mille väärtust tuleb leida. Taotluse tulemusena kas leitakse sõlm (kui otsitav aadress oli selle poolpüsiv DHT-aadress) või on väärtuseks IP-aadress ja port ühendamiseks — või mõni muu aadress, mida tuleks kasutada tunnelina-vahendajana.

TON-i ülekandevõrgud

Ülaltoodud ADNL-protokoll võimaldab igal sõlmel omavahel teavet vahetada - tõsi, mitte tingimata optimaalsel teel. Võib öelda, et ADNL-i abil moodustavad kõik sõlmed globaalset TON-i graafi (ideaalis - ühendatud). Kuid lisaks on ette nähtud ka ülekandevõrkude loomise võimalus - alagraafikud selle graafi sees.

Sellistes võrkudes toimub suhtlemine ainult otseselt - eelnevalt loodud sidemete kaudu võrgupunktide vahel (ADNL-kanalite kaudu, nagu eespool kirjeldatud). Selliste suhete loomine naabrite vahel ja naabrite otsimine on automaatne protsess, mille eesmärk on säilitada overlay-võrgu ühendus ja vähendada andmevahetuse viivitusi.

Lisaks on välja töötatud viis suurte laiaulatuslike värskenduste kiiremaks levitamiseks võrgus - need jagatakse osadeks, täiendatakse vigade parandamise koodiga ja kõik need tükid saadetakse ühe osaleja poolt teisele. Seega ei pea osaleja täielikult saama kõiki osi enne, kui saadab need võrgus edasi.

Overlay-võrgud võivad olla avalikud ja privaatsed. Avaliku võrgu liikmeks saamine ei ole keeruline - tuleb leida TL-struktuur, mis seda kirjeldab (see võib olla avalik - või kättesaadav teatud võtme kaudu DHT-s). Privaatsuse korral peaks see struktuur olema sõlmele eelnevalt teada.

Jätkub

Otsustasin jagada TONi ülevaate mitmeks artikliks. Selle osa lõpetan nüüd ja järgmises lähen blockchain'i (täpsemalt, blockchain'ide) struktuuri arutamisele, millest TON koosneb.

Allikas: habr.com