Internettet i Rusland har i to uger været fyldt med snak om Telegram og situationen omkring den meningsløse og ubarmhjertige blokering fra Roskomnadzor. Mange har lidt skade, men alt dette er emner for indlæg på Geektimes. Jeg blev derimod overrasket over, at jeg stadig ikke har set nogen dybere analyse af det planlagte netværk baseret på Telegram, TON - Telegram Open Network - her på Habré. Jeg ønskede at udfylde dette hul, da der er meget at undersøge her, selv uden officielle erklæringer om det.
Lad mig minde om, at der er rygter om, at Telegram har startet et meget omfattende privat ICO, og allerede har indsamlet utrolige beløb. Det forventes, at der i år vil blive lanceret den egen kryptovaluta, Gram - og hver Telegram-bruger automatisk vil få en wallet, som i sig selv giver en betydelig fordel i forhold til andre kryptovalutaer.
Desværre, da der ikke er nogen officielle erklæringer, kan jeg kun basere mig på , hvilket jeg straks advarer jer om. Selvfølgelig kan det vise sig at være en meget kunstnerisk forfalskning, men det kan også være, at dette er et ægte whitepaper for det fremtidige system, skrevet af Nikolai Durov (og måske lækket af en af investorerne). Men selv hvis det er en falsk, kan ingen forbyde os at undersøge og diskutere det, ikke sandt?
Hvad står der i dette dokument? Jeg vil prøve at gengive det med mine egne ord, tæt på teksten, men på dansk og lidt mere menneskeligt (må Nikolai tilgive mig for hans tilbøjelighed til at gå ind i formel matematik). Husk, at selv i tilfælde af ægtheden, er dette et skitsebeskrivelse af systemet, og det vil meget sandsynligt ændre sig inden det offentlige launch.
Vi lærer, at der udover kryptovalutaen forventes også meget, meget mere. Lad os tage det trin for trin.
- TON Blockchain. Dette er grundlaget for hele systemet. Hvis du slet ikke ved, hvad er - anbefaler jeg at finde ud af det, for her vil der være mange blockchains. Indlejret i hinanden, virtuelt opdelt og endda "vertikale" blockchains inden i blokkene af andre blockchains. Og her vil også være flere spændende termer som Instant Hypercube Routing og Infinite Sharding Paradigm, men det vender vi tilbage til senere. Og selvfølgelig proof-of-stake og smart contracts.
- TON P2P Network. P2P-netværket, som systemet vil være bygget på. Det vil være i fokus i denne del af fortællingen.
- TON Storage. Et filopbevaringssystem, der uafhængigt af blockchainen vil blive bygget på det ovennævnte P2P-netværk. Det kan sammenlignes med torrent-filer.
- TON Proxy. En service, hvis formål er at øge anonymiteten for netværksdeltagerne. Enhver pakke kan sendes ikke direkte, men gennem mellemliggende tunneler med ekstra kryptering - ligesom I2P eller TOR.
- TON DHT. En distribueret hash-tabel til opbevaring af vilkårlige værdier. Den er også bygget ovenpå TON Network (men bruger denne selv) og hjælper TON Storage med at finde 'dele' noder, samt TON Proxy intermediære retransmittere. Det skal dog bemærkes, at denne hash-tabel, i modsætning til blockchainen, ikke er et sikkert opbevaringssted - det er ikke sikkert at opbevare vigtig information der.
- TON Services. En platform til vilkårlige tjenester. I bund og grund er det et nyt internet ovenpå alt det ovenfor beskrevne. Dataudveksling - via TON Network/TON Proxy, og logikken ligger i smart contracts af selve TON Blockchain. Og interface med ret velkendte URL'er.
- TON DNS. Da vi taler om velkendte URL'er, er der også behov for en konverter fra dem til 256-bit adresser - konti, kontrakter, tjenester og noder.
- TON Payments. Og her berøres pengespørgsmålet. Det vil ikke kun være gram — ligesom med Ether vil der være mulighed for vilkårlige 'tokens'; gram her vil blot være 'standardvalutaen'.
Dette er den første del, der beskriver den 'jordnære' del af TON - dens netværksdel, der er bygget ovenpå traditionelle protokoller. I den næste del vil vi tale om 'kernen' - blockchainen, som vil blive understøttet af det system, der beskrives nedenfor. Således skiller min måde at fortælle på sig fra den, der anvendes i det ovennævnte dokument (som begynder direkte på det abstrakte niveau).
Grundlæggende begreber
TL (Type Language). Det er et abstrakt binært format for vilkårlige datastrukturer. Det anvendes i Telegram-protokollen og vil blive aktivt brugt i TON. Hvis du vil læse mere om det - .
Hash (hash). En funktion, der producerer en irreversibel transformation af en vilkårlig datamodel til et enkelt tal af fast længde. I dokumentationen bliver der ofte talt om funktionen .
Netværksnode (node). En node er software, der sikrer systemets funktion. Hver Telegram-klient forventes at inkludere en TON-node. På lavt niveau har noder IPv4/IPv6-adresser og kommunikerer via UDP-protokollen; på et højere niveau har de abstrakte adresser og implementerer ADNL-protokollen (for mere information om abstrakte adresser og ADNL, se nedenfor). Når der tales om, at dele af systemet udfører opgaver eller gemmer data, menes der, at det er noderne i netværket, der gør det.
Abstrakt adresse (eller blot adresse, address). En nodes adresse defineres af dens offentlige nøgle. Mere specifikt er det en 256-bit hash (SHA256) af en datastruktur, der indeholder den offentlige nøgle (den specifikke kryptografiske algoritme nævnes ikke — eksempler inkluderer elliptiske kurver og RSA-2048). For at én node kan interagere med en anden, skal den vide ikke kun adressen, men også denne datastruktur. Teoretisk kan én fysisk node oprette et ubegribeligt antal adresser (som svarer til forskellige nøgler).
Der bruges ofte netop denne kombination: «forbillede» i form af TL-struktur (der indeholder næsten enhver form for data), og 256-bit hash af den, som bruges til adressering.
Blockchain (blockchain). Blockchain er en datastruktur, hvis elementer (blokke) er ordnet i en «kæde», og hver efterfølgende blok i kæden indeholder en hash af den forrige. Dette sikrer integriteten — ændringer kan kun ske ved at tilføje nye blokke.
Service (service). Tjenester inden for TON kan være af forskellige typer — afhængigt af om de bruger blockchain eller ej. For eksempel kan én (eller flere) af noderne i netværket behandle visse RPC-anmodninger via den senere beskrevne ADNL-protokol uden at oprette nogen optegnelser i blockchainen — ligesom traditionelle webservere. Der overvejes også muligheden for at implementere HTTP over ADNL samt en overgang for selve messenger-applikationen til denne protokol. På samme måde som TOR eller I2P vil dette gøre den mere modstandsdygtig over for forskellige blokeringer.
Samtidig indebærer en række tjenester både interaktion med blockchain og behandling af anmodninger uden for den. For eksempel er det ikke særlig fornuftigt at gemme selve filerne i blockchain for TON Storage - et fillager. Der vil kun være hashes af filerne (sammen med en slags metadata om dem) i det, mens specialiserede noder i netværket vil fungere som "filservere", der er klar til at levere dem til andre noder via ADNL.
Tågetjeneste (fog service). Det drejer sig om nogle tjenester, der indebærer decentralisering og åben deltagelse i dem. For eksempel er TON Proxy en tjeneste, som enhver deltager kan støtte, hvis de ønsker at tilbyde deres node som formidler (proxy), der videresender pakker mellem andre noder. Hvis de ønsker det, kan de opkræve et gebyr - ved at bruge systemet TON Payments til mikrotransaktioner (som også er en tågetjeneste).
ADNL: Abstract Datagram Network Layer
På det laveste niveau vil interaktionen mellem noder finde sted via UDP-protokollen (selvom andre muligheder også er tilladt).
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, der defineres af den). Den krypterer pakken med denne nøgle og tilføjer en 256-bit modtageradresse i begyndelsen af pakken - da en node kan have flere sådanne adresser, giver det mulighed for at bestemme, hvilken nøgle der skal bruges til dekryptering.
Derudover kan der i begyndelsen af pakken i stedet for modtagerens adresse befinde sig en såkaldt identifikator kanal. I så fald afhænger behandlingen af pakken allerede af de specifikke aftaler mellem noderne - for eksempel kan data sendt til en bestemt kanal være beregnet til en anden node og skal videresendes til denne (det er tjenesten TON Proxy). Et andet særligt tilfælde kan være direkte interaktion mellem noder, men med kryptering baseret på et individuelt nøglepar til denne kanal (forudgående oprettet ved hjælp af Diffie-Hellman-protokollen).
Endelig er der et specielt tilfælde, der kaldes den "nul" kanal - hvis noden endnu ikke kender de offentlige nøgler fra sine "naboer", kan den sende dem pakker uden kryptering overhovedet. Dette er kun beregnet til initialisering - så snart noderne sender information om deres nøgler, skal de bruges til yderligere interaktion.
Den ovenfor beskrevne protokol (256-bit kanalidentifikator + pakkeindhold) kaldes ADNL. Dokumentationen nævner muligheden for at implementere en TCP-lignende protokol oven på den eller en egen overbygning - RLDP (Reliable Large Datagram Protocol), men går ikke i detaljer om deres implementation.
TON DHT: Distribueret hash-tabel
Som i andre distribuerede systemer kræver TON implementeringen af DHT - . Mere specifikt er tabellen . Hvis du ikke er bekendt med denne type hash-tabeller - behøver du ikke bekymre dig, jeg vil senere beskrive, hvordan de fungerer.
I abstrakt forstand tildeler DHT 256-bit nøgler visse binære værdier af vilkårlig længde. I denne sammenhæng er nøglerne i tabellen hashes af en bestemt TL-struktur (disse strukturer opbevares også sammen med DHT). Dette ligner meget dannelsen af adressen for noder - og de kan faktisk være til stede i DHT (for eksempel kan en IP-adresse for en node svare til en given abstrakt adresse, hvis den ikke skjuler den). Men generelt er "prototyperne for nøgler" (deres beskrivelser, key descriptions) metadata, der peger på "ejeren" af posten i hash-tabellen (det vil sige den offentlige nøgle for en bestemt node), typen af den gemte værdi og reglerne for, hvordan denne post kan ændres senere. For eksempel kan reglen tillade, at kun ejeren må ændre værdien - eller forbyde ændring af værdien til et lavere beløb (for at beskytte mod replay-angreb).
Udover 256-bit nøgler introduceres begrebet DHT-adresser. Forskellen fra almindelige nodeadresser er, at DHT-adressen altid er knyttet til en IP-adresse. Hvis noden ikke skjuler sin IP, kan den bruge en almindelig adresse til DHT. Men oftere vil der blive oprettet en særskilt "halv-permanent" adresse til DHT.
Over nøglerne og DHT-adresserne indføres begrebet afstand - i dette er alt sammenfaldende med tabellerne — afstanden mellem nøglerne er lig med XOR (bitwise exclusive OR) imellem dem. Som i Kademlia-tabeller, skal værdien, der svarer til en given nøgle, opbevares på s noder, der har den mindste afstand til denne nøgle (s her — et relativt lille tal).
For at en DHT-node kan interagere med andre sådanne noder, holder den i hukommelsen en DHT-routingtabel — DHT- og IP-adresser på de noder, som den har interageret med tidligere, grupperet efter afstand til dem. Der er 256 sådanne grupper (de svarer til den mest signifikante udsendte bit i afstandsværdien — det vil sige noder på en afstand fra 0 til 255 vil være i én gruppe, fra 256 til 65535 i den næste, osv.). Inden for hver gruppe opbevares et begrænset antal "bedste" noder (i forhold til ping til dem).
Hver node skal understøtte flere operationer: opbevaring af værdi for nøgle, søgning efter noder og søgning efter værdier. Søgning efter noder indebærer at returnere de nærmeste noder til den givne nøgle fra routingtabellen; søgning efter værdier — det samme, bortset fra når noden kender værdien for nøglen (eller også returnerer den bare den). Derfor, hvis en node vil finde en værdi i DHT for en nøgle, sender den forespørgsler til et lille antal noder, der er tættest på denne nøgle fra sin routingtabel. Hvis der ikke er nogen søgte værdi blandt deres svar, men der er andre noders adresser, gentages forespørgslen til dem.
TON DHT kan bruges til forskellige formål, for eksempel — til realisering af en torrent-lignende filopbevaring (se TON Storage); til at bestemme adresserne på noder, der implementerer bestemte tjenester; til at opbevare information om ejerne af konti i blockchain. Men den vigtigste anvendelse er opdagelse af noder efter deres abstrakte adresser. Til dette bruges adressen som nøgle, hvis værdi skal findes. Som resultat af forespørgslen kan enten selve noden findes (hvis den søgte adresse var dens semi-permanente DHT-adresse), eller værdien kan være IP-adressen og porten til forbindelse — eller en anden adresse, der skal bruges som tunnelformidler.
Overlay-netværk i TON
Den ovenfor beskrevne ADNL-protokol muliggør, at enhver node kan udveksle information med andre — selvom det ikke nødvendigvis er på optimale måder. Man kan sige, at takket være ADNL danner alle noder et globalt TON-netværk (ideelt set — sammenhængende). Men der er også mulighed for at oprette overlay-netværk — undergrafer inden for dette graf.
Inden for et sådant netværk foregår interaktionen kun direkte — via foruddefinerede forbindelser mellem netværkets deltager-noder (gennem ADNL-kanalerne, der er beskrevet ovenfor). Oprettelsen af disse forbindelser mellem naboer og søgning efter naboer er en automatiseret proces, der tilstræber at bevare sammenhængen i overlay-netværket og minimere forsinkelser ved dataudveksling.
Derudover er der en metode til hurtigt at udbrede store broadcast-opdateringer inden for netværket — de opdeles i stykker, suppleres med fejlkorreksionskode, og alle disse stykker sendes fra én deltager til en anden. På denne måde behøver en deltager ikke at modtage alle stykker fuldt ud, før de sender dem videre i netværket.
Overlay-netværk kan være offentlige og private. Det er ikke svært at blive deltager i et offentligt netværk — man 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 for noden på forhånd.
Fortsættes
Jeg har besluttet at opdele gennemgangen af TON i flere artikler. Denne del slutter her, og går jeg videre med at undersøge blockchain-strukturen (mere præcist, blockchains), som TON vil bestå af.
Kilde: habr.com
