TON: Telegram Open Network. Osa 1: Sissejuhatus, võrgutasand, ADNL, DHT, overlay-võrgud

Juba kaks nädalat on Runet segaduses Telegrami ja selle mõttetuks ja jõhkraks blokeerimiseks Roskomnadzori poolt. Paljusid on see kaha tabanud, aga need on teemasid Geektimesi postitusteks. Mind üllatas midagi muud - ma ei ole siiani näinud Habras ühtegi ülevaadet TON-i, mis põhineb Telegrami võrgul - Telegram Open Network, lähenemisest. Soovisin selle puudujäägi täita, sest seal on palju uurimist - isegi hoolimata ametlike avalduste puudumisest.

Küsimus on selles - on kõlanud kuulujutud, et Telegram on alustanud väga suurt suletud ICO-d, kogudes juba uskumatuid summasid. Eeldatakse, et juba sel aastal käivitab oma krüptoraha Gram - ja iga Telegrami kasutajal tekib automaatselt rahakott, mis iseenesest loob märkimisväärse eelise teiste krüptovaluutade ees.

Kahjuks, kuna ametlikke avaldusi ei ole, saan ma edasi liikuda ainult alusel tundmatu päritoluga dokumendile, millest ma teid kohe hoiatama pean. Loomulikult võib see osutuda väga kunstlikuks valeväljaandeks, aga ei saa välistada, et see on tulevase süsteemi tegelik valge raamat, mille on kirjutanud Nikolai Durov (ja ilmselt lekitanud keegi investoritest). Kuid isegi kui see on vale, ei tohi keegi meilt seda uurida ja arutada, eks?

Mis siis selles dokumendis öeldakse? Proovin seda oma sõnadega edasi anda, tekstile lähedal, aga eesti keeles ja veidi inimlikumalt (kui Nikolai, kellel on kalduvus minna formaalse matemaatika peale, mind andeks annab). Pange tähele, et isegi juhul, kui see on autentne, on see süsteemi eelnõu, ja see muutub tõenäoliselt avaliku käivitamise ajaks.

Saame teada, et lisaks krüptorahale on plaanis veel väga palju muud. Alustame järjest.

• TON Blockchain. See on kogu süsteemi alus. Kui te ei tea, mis on blockchain , soovitan selle kohta rohkem teada saada, sest siin on palju plokke. Üksteise sisse paigutatud, virtuaalselt purustatud ja isegi "vertikaalsed" plokiahelad teiste plokikahelate sees. Ja siin on ka mitmeid ägedaid termineid nagu Instant Hypercube Routing ja Infinite Sharding Paradigm, aga sellest hiljem. Ja muidugi, proof-of-stake ja nutikad lepingud.
• TON P2P Network. P2P võrgustik, mille alusel töötab süsteem. Sellest räägitakse antud jutus esmajärjekorras.
• TON Storage. Failihaldus, mis on sõltumatu plokiahelast, põhineb ülalmainitud P2P-võrgul. Seda saab võrrelda torrentidega.
• TON Proxy. See on teenus, mille eesmärk on suurendada võrgu osalejate anonüümsust. Iga pakett saab saata mitte otse, vaid tunnelite-keskmike kaudu koos täiendava krüpteeringuga - sarnaselt I2P või TOR-iga.
• TON DHT. Jagatud hash-tabel juhuslike väärtuste hoiustamiseks. See on samuti rajatud TON Network (kuid kasutab seda ise) ning aitab TON Storage leidma "jagamiskohti" ja TON Proxy — vahepealseid edastajaid. Tuleb märkida, et erinevalt plokiahlast ei ole see hash-tabel kaitstud hoiustamisruum — oluline teave ei tohiks seal asuda.
• TON Services. Platvorm erinevate teenuste jaoks. Sisuliselt on see uus internet eelnevalt kirjeldatud kõige põhjal. TON Network/TON Proxy, andmete vahetamine toimub läbi TON Blockchain. ja loogika on nutilepingutes, mis kuuluvad
• . Ja liides üsna tuttavate URLidega.. Kuna rääkisime tuttavatest URL-idest, on vajalik ka nende teisendaja 256-bitisteks aadressideks - kontode, lepingute, teenuste ja sõlmede jaoks.
• TON Payments. Siin tatsatakse alles rahaküsimuste juurde. Ja see ei ole ainult gram — nagu eetri puhul, võivad kõik "tokenid" olla võimalikud; grammid on siin vaid "vaikimisi" valuuta.

See on esimene osa, mis kirjeldab TON-i "maapiirkonda" — selle võrgu osa, mis on ehitatud traditsiooniliste protokollide peale. Järgmises osas räägitakse "südamest" - plokiahelast, mida toetab allpool kirjeldatud süsteem. Seega minu jutu kordamine erineb veidi ülalmainitud dokumendis kasutatud korrast (mis algab kohe abstraktsest tasemest).

Põhidokumendid

TL (Type Language). See on abstraktne binaariformaat juhuslike andmestruktuuride jaoks. Seda kasutatakse Telegrami protokollis ja seda hakatakse aktiivselt kasutama TON-is. Kui soovite sellega üksikasjalikult tutvuda - siin on selle kirjeldus.

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

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

Abstraktne aadress (või lihtsalt aadress, aadress). Sõlme aadress määratakse tema avaliku võtme järgi. Täpsemalt on see 256-bitine hash (SHA256) andmestruktuurilt, mis sisaldab avalikku võtit (konkreetset krüptograafilist algoritmi ei määratleta — näiteks tuuakse välja elliptilised kõrved ja RSA-2048). Et üks sõlm saaks suhelda teisega, peab ta teadma mitte ainult selle aadressi, vaid ka seda andmestruktuuri. Teoreetiliselt võib üks füüsiline sõlm luua suvalise arvu aadresse (mis vastavad erinevatele võtmetele).

Edasi kasutatakse sageli just sellist kombinatsiooni: "kuju" TL-struktuurina (mis sisaldab praktiliselt mingeid andmeid) ja 256-bitine hash sellest, mida kasutatakse aadressimiseks.

Plokiahel (blockchain). Plokiahel on andmestruktuur, mille elemendid (plokid) on järjestatud "ahelas" ja iga järgmine plokk ahelas sisaldab eelneva hash’i. Nii saavutatakse terviklikkus — muudatusi saab teha ainult uute plokkide lisamisega.

Teenuseid (teenus). TON-i raames võivad teenused olla erinevat tüüpi — olenevalt sellest, kas nad kasutavad plokiahelat või mitte. Näiteks võib üks (või mitu) võrgu sõlmest töödelda teatud RPC-päringuid allpool kirjeldatud ADNL-protokolli kaudu, luues plokiahelas mingeid registreid — sarnaselt traditsioonilistele veebiserveritele. Samuti kaalutakse võimalust rakendada HTTP ADNL-i kohal, samuti messaadžeri üleminekut sellele protokollile. Sarnaselt TOR-ile või I2P-le teeks see selle erinevatele blokeerimisele vastupidavamaks.

Samas, mõned teenused hõlmavad ka suhtlemist plokiahelaga ja päringute töötlemist selle väliselt. Näiteks ei tundu TON Storage'i — failide salvestamise teenuse — puhul mõistlik hoida faile plokiahelas. See sisaldab ainult failide hashe (koos nende metainformatsiooniga), samal ajal kui «failiserveritena» teenivad spetsialiseeritud võrgu sõlmed, mis on valmis andma neid teistele sõlmedele ADNL-i kaudu.

Uduteenus (fog service). Räägime mõnedest teenustest, mis eeldavad detsentraliseerimist ja avatud osalemist. Näiteks TON Proxy — see on teenus, mida võib toetada iga liige, kes soovib pakkuda oma sõlme kui vahendajat (proxy), mis edastab pakette teiste sõlmede vahel. Soovi korral võib ta selle eest nõuda kehtestatud tasu — kasutades TON Payments'i mikrotransaktsioonide süsteemi (mis omakorda on ka uduteenus).

ADNL: Abstract Datagram Network Layer

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

Nagu eespool mainitud, peab üks sõlm, et saata pakette teisele, teadma üht tema avalikku võtme (ja seega ka aadressi, millega see on määratletud). Ta krüpteerib paki selle võtmega ja lisab paki algusesse 256-bitise saaja aadressi — kuna ühel sõlmel võib olla mitu sellist aadressi, aitab see tal määrata, millist võtit kasutada dekrüpteerimiseks.

Lisaks võib andmepaki alguses saaja aadressi asemel olla nn identifikaator kanali. Sellisel juhul sõltub paketi töötlemine juba konkreetsest kokkuleppest sõlmede vahel — näiteks kanali kaudu saadetud andmed võivad olla mõeldud teisele sõlmele ja tuleb neile edastada (see on teenus TON Proxy). Teine erijuht võib olla sõlmede vaheline otsekohene suhtlemine, kuid krüpteerimisega isikliku võtme paariga selle kanali jaoks (eelnevalt loodud Diffie-Hellmani protokolli järgi).

Lõpuks on erijuhtumiks "nullkanal" - kui sõlm ei tea veel oma "naabrite" avalikke võtmeid, saab ta saata neile pakette krüpteerimata. See on mõeldud ainult initsialiseerimiseks - niipea kui sõlmed saadavad teavet oma võtmete kohta, tuleb neid edasi suhtlemiseks kasutada.

Ülaltoodud protokoll (256-bitine kanalite identifikaator + paketi sisu) nimetatakse ADNL-iks. Dokumentatsioon mainib võimalust rakendada selle peal TCP analooge või oma lisandit - RLDP (Reliable Large Datagram Protocol), kuid ei lähe nende rakendusse detailidesse.

TON DHT: Jaotatud rämpsutabel

Nagu teiste jaotatud süsteemide puhul, eeldab TON DHT rakendamist - jaotatud rämpsutabel. Täpsemalt öeldes on tabel Kademlia-sarnane. Kui te ei ole selliste rämpsutabelite tüüpidega tuttav, siis ärge muretsege, kirjeldan edasi umbkaudu, kuidas need töötavad.

Abstraktses mõttes seab DHT 256-bitised võtmed vastavusse teatud binaarsete väärtustega, mille pikkus on suvaline. Samas on tabelis võtmed kindlatest TL-struktuuridest saadud hash’id (need struktuurid hakatakse samuti DHT-s hoidma). See on väga sarnane sõlmede aadresside loomisega - ja need võivad tõeliselt DHT-s olemas olla (näiteks võib sellise võtme all asuda vastava antud abstraktse aadressi, kui ta ei varja seda). Kuid üldiselt on "võtmete prototüübid" (nende kirjeldused, key descriptions) metaandmed, mis näitavad "omanikku" rämpsutabelis (st mõne sõlme avalike võtme), salvestatava väärtuse tüübi ja reeglid, mille alusel seda väärtust hiljem muuta saab. Näiteks võib reegel lubada väärtuse muutmise ainult omanikule - või keelduda väärtuse vähendamisest (kaitseks replay-rünnakute eest).

Lisaks 256-bitistele võtmetele on tutvustatud DHT-aadresse. Erinevus tavaliste sõlmede aadressidega on see, et DHT-aadress on tingimata seotud IP-aadressiga. Kui sõlm ei varja oma IP-d, võib ta DHT jaoks kasutada tavalist aadressi. Kuid sagedamini luuakse DHT vajaduste jaoks eraldi, "pool-püsiv" aadress.

Võtmete ja DHT-aadresside kohal tutvustatakse kauguse mõistet - selles osas läheb kõik Kademlia tabelitega kokku. Kademlia — võtmete vaheline kaugus on XOR (bitipõhine erandlik või) nende vahel. Nagu Kademlia tabelites, peaks võtmega seotud väärtus olema salvestatud s sõlmedes, mille kaugus sellele võtmele on kõige väiksem (s siin — suhteliselt väike number).

Selleks, et DHT sõlm saaks suhelda teiste selliste sõlmedega, hoiab ta mälu DHT marsruuditabelit — DHT- ja IP-aadressid sõlmedest, millega ta on varem suhelnud, rühmitatuna kauguse järgi. Selliseid gruppe on 256 (need vastavad kauguse väärtuse kõige kõrgemale seadistatud bitile — st sõlmed, mille kaugus on 0 kuni 255, kuuluvad ühte gruppi, 256 kuni 65535 — järgmisse jne). Igas grupis hoitakse piiratud arvu 'parimaid' sõlmi (pingeaegade osas).

Iga sõlm peab toetama mitmeid operatsioone: võtme väärtuse salvestamine, sõlmede otsimine ja väärtuste otsimine. Sõlmede otsimine tähendab lähimate sõlmede andmist marsruuditabelist antud võtme põhjal; väärtuste otsimine on sama, välja arvatud juhul, kui sõlm teab võtme väärtust (siis tagastab ta lihtsalt selle). Vastavalt sellele, kui sõlm soovib DHT-s leida väärtust võtme põhjal, saadab ta päringud väikesele hulgale lähimatele sõlmedele oma marsruuditabelist. Kui nende vastustes pole otsitud väärtust, kuid on teisi sõlmpunkte, siis kordatakse päringut nende poole.

TON DHT-d saab kasutada erinevatel eesmärkidel, näiteks — torrent-taolise failide salvestuse rakendamiseks (vt TON Storage); teatud teenuste rakendavate sõlmede aadresside määramiseks; konto omanike teabe salvestamiseks plokiahelas. Kuid kõige olulisem rakendus on sõlmede avastamine nende abstraktsete aadresside põhjal. Selleks kasutatakse aadressi võtmena, mille põhjal tuleb leida vajaliku väärtus. Tulemusena kas leitakse sõlm ise (kui otsitud aadress oli tema poolpüsiv DHT-aadress) või on väärtuseks IP-aadress ja port ühenduse loomiseks — või mõni muu aadress, mida tuleks kasutada tunnel-mediatorina.

TON-i ülekandevõrgud

Üksikasjalikult kirjeldatud ADNL-protokoll võimaldab igal sõlmel omavahel teavet vahetada — tõsi, mitte tingimata optimaalsel viisil. Võib öelda, et tänu ADNL-ile moodustavad kõik sõlmed globaalse graafiku TON (ideaalis - seotud). Kuid lisaks on ette nähtud võimalus luua ülevõrguvõrke - alagraafe selle graafiku sees.

Sellise võrgu sees toimib suhtlus ainult otse - eelnevalt moodustatud ühenduste kaudu osalevate sõlmede vahel (ülemineku kanalite kaudu, nagu eespool kirjeldatud). Selliste ühenduste loomine naabrite vahel ja nende otsimine on automaatne protsess, mis püüdleb ülevõrguvõrgu sidususe säilitamise ja edastusviivituste minimeerimise poole.

Lisaks on ettenähtud meetod suurte mitmeadressiliste värskenduste kiireks levitamiseks võrgus - need jagatakse osadeks, täiendatakse vea parandamise koodiga ja kõik need tükid saadetakse ühe osaleja poolt teisele. Seega ei pea osaleja enne nende edastamise hõlbustamiseks täielikult kõiki osi saama.

Ülevõrguvõrgud võivad olla avalikud ja erasfäärilised. Avaliku võrgu osaliseks saamine ei ole keeruline - tuleb leida TL-struktuur, mis seda kirjeldab (see võib olla avalik või kergesti juurdepääsetav teatud võtme kaudu DHT-s). Erasfäärse võrgu korral peab see struktuur olema sõlmele eelnevalt tuntud.

Jätkub

Otsustasin jagada TON-i ülevaate mitmeks artikliks. Sellega see osa lõppeb, ja järgmises räägin blokahelate (täpsemalt blokahelate) struktuurist, millest TON koosneb.

Allikas: habr.com