Runet maak nou al twee weke lank lawaai oor Telegram en die situasie met sy sinnelose en genadelose blokkering deur Roskomnadzor. Die rikochet het baie aanstoot gegee, maar al hierdie is onderwerpe vir plasings op Geektimes. Ek was verras deur iets anders - ek het nog nie 'n enkele ontleding op Habré gesien van die TON-netwerk wat beplan word om op die basis van Telegram - Telegram Open Network vrygestel te word nie. Ek wou vir hierdie tekortkoming opmaak, want daar is iets om daar te bestudeer – selfs ten spyte van die afwesigheid van amptelike verklarings daaroor.
Laat ek jou daaraan herinner dat daar gerugte is dat Telegram 'n baie grootskaalse geslote ICO bekendgestel het, nadat hulle reeds ongelooflike hoeveelhede daarin versamel het. Daar word aanvaar dat Gram se eie kripto-geldeenheid vanjaar bekendgestel sal word, en elke Telegram-gebruiker sal outomaties 'n beursie hê, wat op sigself 'n aansienlike voordeel bo ander kripto-geldeenhede skep.
Ongelukkig, aangesien daar geen amptelike verklarings is nie, kan ek maar voortgaan waaroor ek jou dadelik waarsku. Natuurlik kan dit 'n baie vaardige namaaksel blyk te wees, maar dit is ook moontlik dat dit die regte witskrif van die toekomstige stelsel is, geskryf deur Nikolai Durov (en waarskynlik deur een van die beleggers uitgelek). Maar selfs al is dit 'n nep, sal niemand ons verbied om dit te bestudeer en te bespreek nie, reg?
Wat sê hierdie dokument? Ek sal dit in my eie woorde probeer oorvertel, naby die teks, maar in Russies en 'n bietjie meer menslik (mag Nikolay my vergewe met sy neiging om in formele wiskunde in te gaan). Hou in gedagte dat selfs al is dit outentiek, dit 'n konsepbeskrywing van die stelsel is en dit sal waarskynlik verander teen die tyd van die publieke bekendstelling.
Ons leer dat daar benewens kriptokurrency, baie meer veronderstel is om te gebeur. Kom ons vat dit in volgorde.
- TON Blockchain. Dit is die basis van die hele stelsel. As jy nie regtig weet wat is nie - Ek beveel aan om uit te vind, want hier sal baie blokkettings wees. Geneste, feitlik gefragmenteerde en selfs "vertikale" blokkettings binne blokke van ander blokkettings. Daar sal ook 'n paar koel klinkende terme wees soos Onmiddellike Hypercube Routing и Oneindige Sharding Paradigma, maar later meer daaroor. En natuurlik bewys-van-aandeel en slim kontrakte.
- TON P2P-netwerk. 'n Eweknie-netwerk op grond waarvan die stelsel gebou sal word. Dit sal eerstens in hierdie deel van die verhaal bespreek word.
- TON Berging. 'n Lêerberging wat op die bogenoemde eweknie-netwerk gebou sal word, ongeag die blokketting. Kan vergelyk word met torrents.
- TON Proxy. Dit is 'n diens waarvan die doel is om die anonimiteit van netwerkdeelnemers te verhoog. Enige pakkie kan nie direk gestuur word nie, maar deur middel van tonnels met bykomende enkripsie - soos I2P of TOR.
- TON DHT. Verspreide hash-tabel vir die stoor van arbitrêre waardes. Dit is ook bo-op gebou TON Netwerk (maar dit word terselfdertyd deur hom gebruik) en help TON Berging vind "verspreidende" nodusse, en TON Proxy - intermediêre relais. Maar daar moet kennis geneem word dat, anders as die blokketting, hierdie hash-tabel nie 'n veilige berging is nie - jy kan nie belangrike inligting daarin stoor nie.
- TON Services. Platform vir arbitrêre dienste. Trouens, dit is 'n nuwe internet bo en behalwe alles wat hierbo beskryf is. Data-uitruiling - via TON Netwerk/TON Proxy, en die logika is in die slim kontrakte van die TON Blockchain. En 'n koppelvlak met redelik bekende URL's.
- TON DNS. Aangesien ons van die gewone URL's praat, benodig ons ook 'n omskakelaar van hulle na 256-bis-adresse - rekeninge, kontrakte, dienste en nodusse.
- TON Betalings. En dit is waar die geldkwessie ter sprake kom. En dit sal nie net nie gram - soos met eter, sal enige "tokens" moontlik wees; Grams sal net die "verstek" geldeenheid hier wees.
Dit is die eerste deel wat die "grond" vlak van TON beskryf - sy netwerk deel, gebou op die top van tradisionele protokolle. In die volgende deel sal ons praat oor die "pulp" - die blokketting, wat ondersteun sal word deur die stelsel wat hieronder beskryf word. My volgorde van hervertelling is dus ietwat anders as dié wat in bogenoemde dokument gebruik word (wat dadelik op die abstrakte vlak begin).
Basiese begrippe
TL (Tik Taal). Dit is 'n abstrakte binêre formaat vir arbitrêre datastrukture. Dit word in die Telegram-protokol gebruik en sal aktief in TON gebruik word. As jy meer daaroor wil leer - .
hasj (hash). 'n Funksie wat 'n onomkeerbare transformasie van 'n arbitrêre datastruktuur in 'n enkele getal van 'n vaste lengte uitvoer. Dwarsdeur die dokumentasie word daar baie oor die funksie gepraat .
Netwerk nodus (node). Die nodus is die sagteware wat die werking van die stelsel sal verseker. Daar word veral aanvaar dat elke Telegram-kliënttoepassing 'n TON-nodus sal insluit. Op 'n lae vlak het nodusse IPv4/IPv6-adresse en kommunikeer met behulp van die UDP-protokol, op 'n hoër vlak abstrakte adresse en implementeer die ADNL-protokol (sien hieronder vir abstrakte adresse en ADNL). As dit kom by die feit dat sommige dele van die stelsel iets doen of data stoor, word verstaan dat netwerknodusse dit doen.
Abstrakte adres (of eenvoudig adres, adres). Die adres van 'n nodus word bepaal deur sy publieke sleutel. Meer streng, dit is 'n 256-bis hash (SHA256) vanaf 'n datastruktuur wat 'n publieke sleutel bevat (die spesifieke kriptografiese algoritme word nie in hierdie geval gespesifiseer nie - elliptiese krommes en RSA-2048 word as 'n voorbeeld gegee). Om vir een nodus met 'n ander te kan kommunikeer, moet dit nie net die adres van daardie een ken nie, maar ook hierdie datastruktuur. Teoreties kan een fisiese nodus enige aantal adresse skep (wat ooreenstem met verskillende sleutels).
Verder word net so 'n bundel dikwels gebruik: 'n "voorbeeld" in die vorm van 'n TL-struktuur (wat byna enige data bevat), en 'n 256-bis-hash daaruit wat vir adressering gebruik word.
Blokketting (blockchain). Blockchain is 'n datastruktuur, elemente (blokke) wat in 'n "ketting" georden word, en elke volgende blok van die ketting bevat die hash van die vorige een. Sodoende word integriteit bereik – veranderinge kan slegs gemaak word deur nuwe blokke by te voeg.
Service (diens). Dienste binne TON kan van verskillende tipes wees, afhangende van of hulle die blokketting gebruik of nie. Byvoorbeeld, een (of baie) van die netwerknodusse kan sommige RPC-versoeke verwerk met behulp van die ADNL-protokol wat hieronder beskryf word, sonder om enige rekords in die blokketting te skep - soos tradisionele webbedieners. In die besonder word die moontlikheid oorweeg om HTTP oor ADNL te implementeer, sowel as die oorgang van die boodskapper self na hierdie protokol. In analogie met TOR of I2P, sal dit dit meer bestand maak teen verskeie blokkering.
Terselfdertyd impliseer 'n aantal dienste beide interaksie met die blokketting en verwerking van versoeke daarbuite. Byvoorbeeld, vir TON Storage - lêerberging - is dit nie baie redelik om die lêers self op die blokketting te stoor nie. Dit sal slegs lêer-hashes bevat (saam met 'n paar meta-inligting daaroor), en gespesialiseerde netwerknodusse sal as "lêerbedieners" optree, gereed om dit aan ander nodusse via ADNL te gee.
mis diens (mis diens). Ons praat van sommige dienste wat desentralisasie en openlike deelname daaraan behels. Byvoorbeeld, TON Proxy is 'n diens wat ondersteun kan word deur enige deelnemer wat hul nodus wil verskaf as 'n tussenganger (proxy) wat pakkies tussen ander nodusse aanstuur. As hy wil, kan hy 'n fooi hef wat deur hom daarvoor vasgestel is - deur die TON Payments-stelsel vir mikrobetalings te gebruik (wat op sy beurt ook 'n mistige diens is).
ADNL: Abstrakte Datagram-netwerklaag
Op die laagste vlak sal kommunikasie tussen nodusse via UDP geskied (hoewel ander opsies aanvaarbaar is).
Soos hierbo genoem, moet dit een van sy publieke sleutels ken (en dus die adres wat dit bepaal) sodat een nodus 'n pakkie na 'n ander kan stuur. Dit enkripteer die pakkie met hierdie sleutel en voeg 'n 256-bis bestemmingsadres by die begin van die pakkie - aangesien een nodus verskeie sulke adresse kan hê, sal dit dit toelaat om te bepaal watter sleutel om vir dekripsie te gebruik.
Daarbenewens, in plaas van die ontvanger se adres aan die begin van die datapakket, kan daar 'n sg. identifiseerder kanaal. In hierdie geval hang die verwerking van die pakkie reeds af van spesifieke ooreenkomste tussen die nodusse - byvoorbeeld, data wat na 'n sekere kanaal gestuur word, kan vir 'n ander nodus bestem word en moet daarna herlei word (dit is die diens TON Proxy). Nog 'n spesiale geval kan interaksie direk tussen nodusse wees, maar met enkripsie met behulp van 'n individuele sleutelpaar vir hierdie kanaal (voorheen gevorm deur die Diffie-Hellman-protokol).
Ten slotte, 'n spesiale geval is die "nul" kanaal - as die nodus nog nie die publieke sleutels van sy "bure" ken nie, kan dit vir hulle pakkies stuur sonder enkripsie enigsins. Dit is slegs vir inisialisering - sodra die nodusse inligting oor hul sleutels stuur, moet dit vir verdere interaksie gebruik word.
Die protokol hierbo beskryf (256 bisse van kanaal ID + pakkie inhoud) word ADNL genoem. Die dokumentasie noem die moontlikheid om 'n analoog van TCP bo-op dit te implementeer of sy eie byvoeging - RLDP (Reliable Large Datagram Protocol), maar gaan nie in besonderhede oor die implementering daarvan in nie.
TON DHT: Verspreide Hash-tabel
Soos in die geval van ander verspreide stelsels, behels TON die implementering van DHT - . Meer spesifiek, die tabel is . As jy nie vertroud is met hierdie soort hash-tabelle nie, moenie bekommerd wees nie, dan sal ek rofweg beskryf hoe hulle gerangskik is.
In 'n abstrakte sin karteer DHT 256-bis sleutels na binêre waardes van arbitrêre lengte. Terselfdertyd is die sleutels in die tabel hashes van 'n sekere TL-struktuur (die strukture self word ook saam met die DHT gestoor). Dit is baie soortgelyk aan die vorming van nodus-adresse - en hulle kan inderdaad in die DHT teenwoordig wees (so 'n sleutel kan byvoorbeeld die IP-adres van die nodus bevat wat ooreenstem met die gegewe abstrakte adresas dit dit nie verberg nie). Maar in die algemene geval, "voorafbeelde van sleutels" (hulle beskrywings, sleutelbeskrywings) is metadata wat die "eienaar" van 'n inskrywing in die hash-tabel aandui (dit is die publieke sleutel van een of ander nodus), die tipe waarde wat gestoor is, en die reëls waarvolgens hierdie inskrywing later verander kan word. Byvoorbeeld, 'n reël kan slegs die eienaar toelaat om die waarde te verander - of verbied om die waarde af te verander (om teen herhalingsaanvalle te beskerm).
Benewens 256-bis-sleutels, word die konsep van DHT-adresse bekendgestel. Die verskil met gewone gasheeradresse is dat 'n DHT-adres aan 'n IP-adres gebind is. As 'n nodus nie sy IP versteek nie, kan dit 'n gewone adres vir DHT gebruik. Maar meer dikwels sal 'n aparte, "semi-permanente" adres geskep word vir die behoeftes van DHT.
Bo sleutels en DHT-adresse word die konsep van afstand bekendgestel - alles val saam met tabelle in hierdie - die afstand tussen die sleutels is gelyk aan XOR (bitsgewys eksklusief OF) van hulle af. Soos met Kademlia-tabelle, moet die waarde wat ooreenstem met een of ander sleutel in gestoor word s nodusse wat die kleinste afstand na hierdie sleutel het (s hier is 'n relatief klein getal).
Om 'n DHT-nodus met ander sulke nodusse te laat kommunikeer, hou dit in die geheue DHT roetering tabel - DHT- en IP-adresse van die nodusse waarmee dit voorheen interaksie gehad het, gegroepeer volgens afstand na hulle. Daar is 256 sulke groepe (hulle stem ooreen met die mees beduidende bis wat in die afstandwaarde gestel is - dit wil sê, nodusse op 'n afstand van 0 tot 255 sal in een groep val, van 256 tot 65535 - in die volgende, ens.). Binne elke groep word 'n beperkte aantal "beste" nodusse gestoor (in terme van ping na hulle).
Elke nodus moet verskeie bewerkings ondersteun: die stoor van 'n waarde vir 'n sleutel, nodus soek и soek na waardes. Die soektog na nodusse impliseer die uitreiking deur 'n gegewe sleutel van die nodusse naaste daaraan vanaf die roeteringtabel; om waardes op te soek is dieselfde, behalwe wanneer die nodus die waarde vir die sleutel ken (in welke geval dit dit eenvoudig terugstuur). Gevolglik, as 'n nodus 'n waarde in die DHT deur 'n sleutel wil vind, stuur dit versoeke na 'n klein aantal nodusse naaste aan hierdie sleutel vanaf sy roeteringtabel. As daar onder hul antwoorde geen gewenste waarde is nie, maar daar is ander adresse van nodusse, dan word die versoek aan hulle herhaal.
TON DHT kan vir verskeie doeleindes gebruik word, byvoorbeeld om 'n torrent-agtige lêerberging te implementeer (sien. TON Berging); om die adresse te bepaal van nodusse wat sekere dienste implementeer; om inligting oor rekeninghouers in die blokketting te stoor. Maar die belangrikste toepassing is die ontdekking van nodusse deur hul abstrakte adresse. Om dit te doen, word die adres as 'n sleutel gebruik, waarvan die waarde gevind kan word. Die navraag sal óf die gasheer self vind (as die adres wat opgesoek word sy semi-permanente DHT-adres was), óf die waarde sal die IP-adres en poort wees om aan te koppel, of 'n ander adres om as die tussengangertonnel te gebruik.
Oorlê netwerke in TON
Die ADNL-protokol wat hierbo beskryf word, impliseer die vermoë vir enige nodusse om inligting met mekaar uit te ruil - hoewel nie noodwendig op optimale maniere nie. Ons kan sê dat danksy ADNL, alle nodusse 'n globale TON-grafiek vorm (ideaal gesproke verbind). Maar bykomend is dit moontlik om oorlegnetwerke te skep - subgrafieke binne hierdie grafiek.
Binne so 'n netwerk word interaksie slegs direk uitgevoer - deur vooraf gevormde skakels tussen netwerklid nodusse (via die ADNL-kanale hierbo beskryf). Die vorming van sulke verbindings tussen bure, die soektog na die bure self is 'n outomatiese proses wat poog om die konnektiwiteit van die oorlegnetwerk te handhaaf en vertragings in die uitruil van data daarin te verminder.
Boonop is daar 'n manier om vinnig groot uitsaaiopdaterings binne die netwerk te versprei - dit word in dele opgebreek, aangevul met foutkorreksiekode, en al hierdie dele word van een deelnemer na 'n ander gestuur. Die deelnemer hoef dus nie al die dele volledig te ontvang voordat hy dit verder op die netwerk aanstuur nie.
Oorlegnetwerke kan publiek of privaat wees. Om 'n lid van 'n publieke netwerk te word is nie moeilik nie - jy moet 'n TL-struktuur vind wat dit beskryf (dit kan publiek wees - of toeganklik deur 'n sekere sleutel in die DHT). In die geval van 'n private netwerk moet hierdie struktuur vooraf aan die nodus bekend wees.
Voortgesit moet word
Ek het besluit om die TON-oorsig in verskeie artikels te verdeel. Dit is waar hierdie afdeling eindig, Ek gaan oor na die oorweging van die struktuur van die blokketting (meer presies, blokkettings) waaruit TON sal bestaan.
Bron: will.com