I to uger nu har Runet larmet om Telegram og situationen med dens meningsløse og nådesløse blokering af Roskomnadzor. Ricochetten stødte mange, men alle disse er emner for indlæg på Geektimes. Jeg blev overrasket over noget andet - jeg har stadig ikke set på Habré en eneste analyse af TON-netværket, der er planlagt til at blive frigivet på basis af Telegram - Telegram Open Network. Jeg ønskede at råde bod på denne mangel, for der er noget at studere der - selv på trods af fraværet af officielle udtalelser om det.
Lad mig minde dig om, at der er rygter om, at Telegram lancerede en meget storstilet lukket ICO, der allerede har samlet utrolige mængder i den. Det antages, at Grams egen kryptovaluta vil blive lanceret i år, og hver Telegram-bruger vil automatisk have en pung, hvilket i sig selv skaber en betydelig fordel i forhold til andre kryptovalutaer.
Da der ikke er nogen officielle udtalelser, kan jeg desværre kun gå ud fra som jeg straks advarer dig om. Selvfølgelig kan det vise sig at være en meget dygtig forfalskning, men det er også muligt, at dette er fremtidens systems egentlige hvidbog, skrevet af Nikolai Durov (og sandsynligvis lækket af en af investorerne). Men selvom dette er en falsk, vil ingen forbyde os at studere og diskutere det, ikke?
Hvad siger dette dokument? Jeg vil forsøge at genfortælle det med mine egne ord, tæt på teksten, men på russisk og lidt mere menneskeligt (må Nikolay tilgive mig med hans tendens til at gå ind i formel matematik). Husk, at selvom det er autentisk, er dette et udkast til en beskrivelse af systemet, og det er meget sandsynligt, at det ændrer sig på tidspunktet for den offentlige lancering.
Vi lærer, at der foruden kryptovaluta, skal der ske meget mere. Lad os tage det i rækkefølge.
- TON Blockchain. Dette er grundlaget for hele systemet. Hvis du ikke rigtig ved hvad er - Det anbefaler jeg at finde ud af, for her vil der være rigtig mange blockchains. Indlejrede, praktisk talt fragmenterede og endda "lodrette" blockchains inden for blokke af andre blockchains. Der vil også være nogle cool-klingende udtryk som Øjeblikkelig Hypercube Routing и Infinite Sharding-paradigme, men mere om det senere. Og selvfølgelig proof-of-stake og smarte kontrakter.
- TON P2P netværk. Et peer-to-peer netværk, som systemet skal bygges ud fra. Det vil først og fremmest blive diskuteret i denne del af historien.
- TON opbevaring. Et fillager, der vil blive bygget på det førnævnte peer-to-peer-netværk uanset blockchain. Kan sammenlignes med torrents.
- TON Proxy. Dette er en tjeneste, hvis formål er at øge netværksdeltagernes anonymitet. Enhver pakke kan sendes ikke direkte, men gennem mellemliggende tunneler med ekstra kryptering - som I2P eller TOR.
- TON DHT. Distribueret hash-tabel til lagring af vilkårlige værdier. Den er også bygget ovenpå TON netværk (men samtidig bruges det af ham) og hjælper TON opbevaring finde "distribuerende" noder, og TON Proxy - mellemrelæer. Men det skal bemærkes, at i modsætning til blockchain er denne hash-tabel ikke en sikker lagring - du kan ikke gemme vigtig information i den.
- TON Services. Platform for vilkårlige tjenester. Faktisk er dette et nyt internet oven i alt beskrevet ovenfor. Dataudveksling - via TON netværk/TON Proxy, og logikken ligger i de smarte kontrakter TON Blockchain. Og en grænseflade med ret velkendte URL'er.
- TON DNS. Da vi taler om de sædvanlige URL'er, har vi også brug for en konverter fra dem til 256-bit adresser - konti, kontrakter, tjenester og noder.
- TON Betalinger. Og det er her, pengespørgsmålet spiller ind. Og det vil det ikke kun gram - som med ether vil alle "tokens" være mulige; Gram vil kun være "standard" valuta her.
Dette er den første del, der beskriver "jordniveauet" af TON - dets netværksdel, bygget oven på traditionelle protokoller. I den næste del vil vi tale om "pulpen" - blockchainen, som vil blive understøttet af systemet beskrevet nedenfor. Min genfortælling er således noget anderledes end den, der er brugt i ovenstående dokument (som starter umiddelbart på det abstrakte niveau).
Grundlæggende koncepter
TL (Skriv sprog). Det er et abstrakt binært format til vilkårlige datastrukturer. Det bruges i Telegram-protokollen og vil blive brugt aktivt i TON. Hvis du vil lære mere om det - .
hash (hash). En funktion, der udfører en irreversibel transformation af en vilkårlig datastruktur til et enkelt tal med en fast længde. Gennem hele dokumentationen bliver der talt meget om funktionen .
Netværksknude (node). Noden er den software, der skal sikre driften af systemet. Det antages især, at hver Telegram-klientapplikation vil indeholde en TON-node. På et lavt niveau har noder IPv4/IPv6-adresser og kommunikerer ved hjælp af UDP-protokollen, på et højere niveau har de abstrakte adresser og implementere ADNL-protokollen (se nedenfor for abstrakte adresser og ADNL). Når det kommer til det faktum, at nogle dele af systemet gør noget eller gemmer nogle data, er det underforstået, at netværksnoder gør dette.
Abstrakt adresse (eller simpelthen adresse, adresse). Adressen på en node bestemmes af dens offentlige nøgle. Mere strengt er dette en 256-bit hash (SHA256) fra en datastruktur, der indeholder en offentlig nøgle (den specifikke kryptografiske algoritme er ikke specificeret i dette tilfælde - elliptiske kurver og RSA-2048 er givet som et eksempel). For at en node kan kommunikere med en anden, skal den kende ikke kun adressen på den pågældende, men også denne datastruktur. Teoretisk set kan en fysisk node oprette et hvilket som helst antal adresser (svarende til forskellige nøgler).
Yderligere bruges netop sådan en bundle ofte: et "preimage" i form af en TL-struktur (indeholder næsten alle data) og en 256-bit hash fra den, der bruges til adressering.
Blockchain (blockchain). Blockchain er en datastruktur, elementer (blokke) som er ordnet i en "kæde", og hver næste blok i kæden indeholder hashen fra den forrige. På denne måde opnås integritet - ændringer kan kun foretages ved at tilføje nye blokke.
Service (tjeneste). Tjenester indenfor TON kan være af forskellige typer, alt efter om de bruger blockchain eller ej. For eksempel kan en (eller mange) af netværksknuderne behandle nogle RPC-anmodninger ved hjælp af ADNL-protokollen beskrevet nedenfor, uden at oprette nogen poster i blockchain - ligesom traditionelle webservere. Specielt overvejes muligheden for at implementere HTTP over ADNL, samt overgangen af selve messengeren til denne protokol. Analogt med TOR eller I2P vil dette gøre det mere modstandsdygtigt over for forskellige blokeringer.
Samtidig indebærer en række tjenester både interaktion med blockchain og behandling af anmodninger uden for den. For for eksempel TON Storage - fillagring - er det ikke særlig rimeligt at gemme selve filerne på blockchain. Det vil kun indeholde fil-hashes (sammen med nogle metaoplysninger om dem), og specialiserede netværksknuder vil fungere som "filservere", klar til at give dem til andre noder via ADNL.
tågeservice (tågeservice). Vi taler om nogle tjenester, der involverer decentralisering og åben deltagelse i dem. For eksempel er TON Proxy en tjeneste, der kan understøttes af enhver deltager, der ønsker at levere deres node som en mellemmand (proxy), der videresender pakker mellem andre noder. Hvis det ønskes, kan han opkræve et gebyr fastsat af ham for dette - ved hjælp af TON Payments-systemet til mikrobetalinger (som til gengæld også er en tåget tjeneste).
ADNL: Abstrakt Datagram Network Layer
På det laveste niveau vil kommunikation mellem noder foregå via UDP (selvom andre muligheder er acceptable).
Som nævnt ovenfor, for at en node kan sende en pakke til en anden, skal den kende en af dens offentlige nøgler (og dermed den adresse, den bestemmer). Den krypterer pakken med denne nøgle og tilføjer en 256-bit destinationsadresse til begyndelsen af pakken - da en node kan have flere sådanne adresser, vil dette tillade den at bestemme, hvilken nøgle der skal bruges til dekryptering.
Derudover kan der i stedet for modtagerens adresse i begyndelsen af datapakken være en såkaldt. identifikator kanal. I dette tilfælde afhænger behandlingen af pakken allerede af specifikke aftaler mellem noderne - for eksempel kan data sendt til en bestemt kanal være bestemt til en anden node og skal omdirigeres til den (dette er tjenesten TON Proxy). Et andet særligt tilfælde kan være interaktion direkte mellem noder, men med kryptering ved hjælp af et individuelt nøglepar til denne kanal (tidligere dannet ved hjælp af Diffie-Hellman-protokollen).
Endelig er et særligt tilfælde "nul"-kanalen - hvis noden endnu ikke kender de offentlige nøgler til sine "naboer", kan den sende dem pakker uden kryptering overhovedet. Dette er kun til initialisering - så snart noderne sender information om deres nøgler, skal de bruges til yderligere interaktion.
Protokollen beskrevet ovenfor (256 bit kanal-ID + pakkeindhold) kaldes ADNL. Dokumentationen nævner muligheden for at implementere en analog af TCP oven på den eller sin egen tilføjelse - RLDP (Reliable Large Datagram Protocol), men går ikke i detaljer om deres implementering.
TON DHT: Distribueret Hash-tabel
Som i tilfældet med andre distribuerede systemer involverer TON implementeringen af DHT - . Mere specifikt er tabellen . Hvis du ikke er bekendt med denne slags hash-tabeller, så bare rolig, så vil jeg groft beskrive, hvordan de er arrangeret.
I abstrakt forstand kortlægger DHT 256-bit nøgler til binære værdier af vilkårlig længde. Samtidig er nøglerne i tabellen hashes fra en bestemt TL-struktur (selve strukturerne er også gemt sammen med DHT). Dette minder meget om dannelsen af nodeadresser - og de kan faktisk være til stede i DHT (for eksempel kan en sådan nøgle indeholde IP-adressen på noden svarende til den givne abstrakt adressehvis det ikke skjuler det). Men i det generelle tilfælde, "forbilleder af nøgler" (deres beskrivelser, nøglebeskrivelser) er metadata, der angiver "ejeren" af en post i hash-tabellen (det vil sige den offentlige nøgle for en eller anden node), typen af værdi, der er gemt, og reglerne for, hvordan denne post efterfølgende kan ændres. For eksempel kan en regel kun tillade ejeren at ændre værdien - eller forbyde at ændre værdien ned (for at beskytte mod gentagelsesangreb).
Ud over 256-bit nøgler introduceres konceptet med DHT-adresser. Forskellen med almindelige værtsadresser er, at en DHT-adresse er bundet til en IP-adresse. Hvis en node ikke skjuler sin IP, kan den bruge en almindelig adresse til DHT. Men oftere vil der blive oprettet en separat, "semi-permanent" adresse til DHTs behov.
Ovenfor taster og DHT-adresser introduceres begrebet afstand - alt falder sammen med tabeller i denne - afstanden mellem tasterne er lig med XOR (bitwise exclusive OR) fra dem. Som med Kademlia-tabeller skal værdien, der svarer til en eller anden nøgle, gemmes i s noder, der har den mindste afstand til denne nøgle (s her er et relativt lille antal).
For at en DHT-node kan kommunikere med andre sådanne noder, gemmer den i hukommelsen DHT routing tabel - DHT- og IP-adresser på de noder, som den interagerede med før, grupperet efter afstand til dem. Der er 256 sådanne grupper (de svarer til den mest signifikante bit sat i afstandsværdien - det vil sige, knudepunkter i en afstand fra 0 til 255 vil falde i én gruppe, fra 256 til 65535 - i den næste osv.). Inden for hver gruppe er et begrænset antal "bedste" noder gemt (i form af ping til dem).
Hver node skal understøtte flere operationer: lagring af en værdi for en nøgle, nodesøgning и søge efter værdier. Søgningen efter noder indebærer udstedelse af en given nøgle af noderne tættest på den fra routingtabellen; at slå op på værdier er det samme, undtagen når noden kender værdien for nøglen (i hvilket tilfælde den blot returnerer den). Følgelig, hvis en node ønsker at finde en værdi i DHT ved hjælp af en nøgle, sender den anmodninger til et lille antal noder tættest på denne nøgle fra dens routingtabel. Hvis der blandt deres svar ikke er nogen ønsket værdi, men der er andre adresser på noder, gentages anmodningen til dem.
TON DHT kan bruges til forskellige formål, for eksempel til at implementere en torrent-lignende fillagring (se. TON opbevaring); at bestemme adresserne på noder, der implementerer visse tjenester; at gemme oplysninger om kontohavere i blockchain. Men den vigtigste applikation er opdagelsen af noder ved deres abstrakte adresser. For at gøre dette bruges adressen som en nøgle, hvis værdi skal findes. Forespørgslen finder enten selve værten (hvis den adresse, der blev slået op, var dens semi-permanente DHT-adresse), eller værdien vil være IP-adressen og porten, der skal oprettes forbindelse til, eller en anden adresse, der skal bruges som den mellemliggende tunnel.
Overlay netværk i TON
ADNL-protokollen beskrevet ovenfor indebærer evnen for enhver noder til at udveksle information med hinanden - dog ikke nødvendigvis på optimale måder. Vi kan sige, at takket være ADNL danner alle noder en global TON-graf (ideelt set forbundet). Men derudover er det muligt at oprette overlejringsnetværk - undergrafer inde i denne graf.
Inden for et sådant netværk udføres interaktion kun direkte - gennem forudformede links mellem netværksmedlemsknudepunkter (via ADNL-kanalerne beskrevet ovenfor). Dannelsen af sådanne forbindelser mellem naboer, søgningen efter naboerne selv er en automatisk proces, der søger at opretholde forbindelsen til overlejringsnetværket og minimere forsinkelser i udvekslingen af data i det.
Derudover er der en måde at hurtigt distribuere store broadcast-opdateringer inden for netværket - de er opdelt i dele, suppleret med fejlrettelseskode, og alle disse dele sendes fra en deltager til en anden. Deltageren skal således ikke fuldt ud modtage alle delene, før de sendes videre på netværket.
Overlejringsnetværk kan være offentlige eller private. At blive medlem af et offentligt netværk er ikke svært - du skal finde en TL-struktur, der beskriver det (den kan være offentlig - eller tilgængelig med en bestemt nøgle i DHT). I tilfælde af et privat netværk skal denne struktur være kendt af noden på forhånd.
Fortsættes
Jeg besluttede at opdele TON-anmeldelsen i flere artikler. Det er her dette afsnit slutter, Jeg vender mig til overvejelsen af strukturen af den blockchain (mere præcist, blockchains), som TON vil bestå af.
Kilde: www.habr.com