I to uker nå har Runet bråket om Telegram og situasjonen med sin meningsløse og nådeløse blokkering av Roskomnadzor. Rikosjetten fornærmet mange mennesker, men alle disse er emner for innlegg på Geektimes. Jeg ble overrasket over noe annet - jeg har fortsatt ikke sett en eneste analyse på Habré av TON-nettverket som er planlagt utgitt på grunnlag av Telegram - Telegram Open Network. Jeg ønsket å bøte på denne mangelen, for det er noe å studere der - selv til tross for mangelen på offisielle uttalelser om det.
La meg minne deg på at det går rykter om at Telegram har lansert en veldig storstilt lukket ICO, etter å ha samlet inn utrolige mengder penger. Det er forventet at Grams egen kryptovaluta vil bli lansert i år – og hver Telegram-bruker vil automatisk ha en lommebok, noe som i seg selv skaper en betydelig fordel i forhold til andre kryptovalutaer.
Dessverre, siden det ikke er noen offisielle uttalelser, kan jeg bare gå videre fra , som jeg umiddelbart advarer deg om. Selvfølgelig kan det vise seg å være en veldig dyktig forfalskning, men det er også mulig at dette er en ekte whitepaper om fremtidens system, skrevet av Nikolai Durov (og lekket, sannsynligvis, av en av investorene). Men selv om det er falskt, vil ingen forby oss å studere og diskutere det, ikke sant?
Hva sier dette dokumentet? Jeg skal prøve å gjenfortelle det med mine egne ord, nær teksten, men på russisk og litt mer humant (kan Nikolai tilgi meg med hans tendens til å gå inn i formell matematikk). Husk at selv om dette er ekte, er dette et utkast til beskrivelse av systemet og vil sannsynligvis endres ved offentlig lansering.
Vi lærer at i tillegg til kryptovaluta er det mye mer som forventes. La oss ta det i rekkefølge.
- TON Blockchain. Dette er grunnlaget for hele systemet. Hvis du ikke vet hva det er — Jeg anbefaler å finne ut av det, for her blir det mye blokkjeder. Nestet inne i hverandre, praktisk talt fragmenterte og til og med "vertikale" blokkjeder innenfor blokker av andre blokkkjeder. Det vil også være noen kule begreper som Instant Hypercube Routing и Infinite Sharding Paradigm, men mer om det senere. Og selvfølgelig bevis-på-innsats og smarte kontrakter.
- TON P2P-nettverk. Peer-to-peer-nettverk som systemet skal bygges ut fra. Hun vil først bli diskutert i denne delen av historien.
- TON Lagring. Fillagring, som, uavhengig av blokkjeden, vil bygges på det ovennevnte peer-to-peer-nettverket. Kan sammenlignes med torrents.
- TON Proxy. Dette er en tjeneste som har som formål å øke anonymiteten til nettverksdeltakere. Enhver pakke kan sendes ikke direkte, men gjennom mellomliggende tunneler med ekstra kryptering - som I2P eller TOR.
- TONN DHT. Distribuert hashtabell for lagring av vilkårlige verdier. Den er også bygget på toppen TON-nettverk (men samtidig brukes den av ham) og hjelper TON Lagring finne "distribuerende" noder, og TON Proxy — mellomrepetere. Men det skal bemerkes at, i motsetning til blokkjeden, er ikke denne hashtabellen en sikker lagring - du kan ikke lagre viktig informasjon i den.
- TON Services. Plattform for tilpassede tjenester. I hovedsak er dette et nytt Internett på toppen av alt beskrevet ovenfor. Datautveksling - via TON-nettverk/TON Proxy, og logikken ligger i de smarte kontraktene til TON Blockchain. Og et grensesnitt med ganske kjente URL-er.
- TONN DNS. Siden vi snakker om kjente URL-er, trenger vi også en omformer fra dem til 256-biters adresser – kontoer, kontrakter, tjenester og noder.
- TON Betalinger. Og det er her pengespørsmålet spiller inn. Og det blir det ikke bare gram — som med eter, vil alle "tokens" være mulig; Gram vil bare være "standard" valuta her.
Dette er den første delen som beskriver det "jordede" laget av TON - nettverksdelen, bygget på toppen av tradisjonelle protokoller. I neste del vil vi snakke om den "myke" - blokkjeden, som vil bli støttet av systemet beskrevet nedenfor. Dermed er min gjenfortellingsrekkefølge noe forskjellig fra den som ble brukt i det ovennevnte dokumentet (som starter umiddelbart på abstrakt nivå).
Enkle konsepter
TL (Skriv språk). Det er et abstrakt binært format for vilkårlige datastrukturer. Den brukes i Telegram-protokollen og vil bli aktivt brukt i TON. Hvis du ønsker å bli kjent med det i detalj - .
Hash (hash). En funksjon som utfører en irreversibel transformasjon av en vilkårlig datastruktur til et enkelt tall med fast lengde. Gjennom hele dokumentasjonen snakker vi om funksjonen .
Nettverksnode (node). En node er programvaren som skal sikre at systemet fungerer. Spesielt antas det at hver Telegram-klientapplikasjon vil inkludere en TON-node. På et lavt nivå har noder IPv4/IPv6-adresser og kommuniserer ved hjelp av UDP-protokollen; på et høyere nivå har de abstrakte adresser og implementere ADNL-protokollen (om abstrakte adresser og ADNL - se nedenfor). Når det kommer til det faktum at noen deler av systemet gjør noe eller lagrer noen data, er det underforstått at dette gjøres av nettverksnoder.
Abstrakt adresse (eller rett og slett adresse, adresse). En nodes adresse bestemmes av dens offentlige nøkkel. Mer strengt er det en 256-bits hash (SHA256) av datastrukturen som inneholder den offentlige nøkkelen (den spesifikke kryptografiske algoritmen er ikke spesifisert - elliptiske kurver og RSA-2048 er gitt som eksempler). For at en node skal kunne kommunisere med en annen, må den ikke bare kjenne adressen til den, men også denne datastrukturen. I teorien kan en fysisk node opprette et hvilket som helst antall adresser (tilsvarende forskjellige nøkler).
Videre blir nettopp en slik kobling ofte brukt: en "prototype" i form av en TL-struktur (som inneholder nesten alle data), og en 256-bits hash fra den, brukt til adressering.
Blockchain (blockchain). Blockchain er en datastruktur, elementer (blokker) som er ordnet i en "kjede", og hver påfølgende blokk i kjeden inneholder hashen til den forrige. På denne måten oppnås integritet – endringer kan kun gjøres ved å legge til nye blokker.
Verktøy (tjeneste). Tjenester innenfor TON kan være av ulike typer, avhengig av om de bruker blockchain eller ikke. For eksempel kan én (eller mange) nettverksnoder behandle visse RPC-forespørsler ved å bruke ADNL-protokollen beskrevet nedenfor, uten å opprette noen poster i blokkjeden – som tradisjonelle webservere. Inkludert muligheten for å implementere HTTP over ADNL, samt overgangen av selve messengeren til denne protokollen. I analogi med TOR eller I2P vil dette gjøre den mer motstandsdyktig mot ulike blokkeringer.
Samtidig innebærer en rekke tjenester både interaksjon med blokkjeden og behandling av forespørsler utenfor denne. For eksempel, for TON Storage – fillagring – er det lite rimelig å lagre selve filene på blokkjeden. Den vil kun inneholde fil-hasher (sammen med litt metainformasjon om dem), og spesialiserte nettverksnoder vil fungere som "filservere", klare til å sende dem til andre noder via ADNL.
Tåketjeneste (tåketjeneste). Vi snakker om noen tjenester som innebærer desentralisering og åpen deltakelse i dem. For eksempel er TON Proxy en tjeneste som kan støttes av enhver deltaker som ønsker å gi sin node som en mellomledd (proxy) videresending av pakker mellom andre noder. Om ønskelig kan han kreve et gebyr fastsatt av ham for dette - ved å bruke TON Payments-systemet for mikrobetalinger (som igjen også er en tåketjeneste).
ADNL: Abstrakt Datagram Network Layer
På det laveste nivået vil kommunikasjon mellom noder utføres ved hjelp av UDP-protokollen (selv om andre alternativer er akseptable).
Som nevnt ovenfor, for at en node skal kunne sende en pakke til en annen, må den kjenne en av dens offentlige nøkler (og derfor adressen den definerer). Den krypterer pakken med denne nøkkelen og legger til 256-bits destinasjonsadressen til begynnelsen av pakken - siden en node kan ha flere av disse adressene, vil dette tillate den å bestemme hvilken nøkkel som skal brukes til dekryptering.
I tillegg, i stedet for mottakerens adresse, kan begynnelsen av datapakken inneholde den såkalte. identifikator kanal. I dette tilfellet avhenger behandlingen av pakken allerede av spesifikke avtaler mellom noder - for eksempel kan data sendt til en bestemt kanal være ment for en annen node og må videresendes til den (dette er tjenesten TON Proxy). Et annet spesialtilfelle kan være interaksjon direkte mellom noder, men med kryptering ved bruk av et individuelt nøkkelpar for denne kanalen (forhåndsgenerert ved hjelp av Diffie-Hellman-protokollen).
Til slutt, et spesielt tilfelle er "null"-kanalen - hvis en node ennå ikke kjenner de offentlige nøklene til sine "naboer", kan den sende dem pakker uten kryptering i det hele tatt. Dette er kun ment for initialisering - når nodene sender informasjon om nøklene sine, bør de brukes til videre kommunikasjon.
Protokollen beskrevet ovenfor (256 biter med kanalidentifikator + pakkeinnhold) kalles ADNL. Dokumentasjonen nevner muligheten for å implementere en analog av TCP på toppen av den eller sin egen add-on - RLDP (Reliable Large Datagram Protocol), men går ikke inn på detaljer om implementeringen.
TON DHT: Distribuert hasjtabell
Som tilfellet er med andre distribuerte systemer, involverer TON implementering av DHT - . Mer spesifikt er tabellen . Hvis du ikke er kjent med denne typen hash-tabeller, ikke bekymre deg, nedenfor vil jeg grovt beskrive hvordan de fungerer.
I abstrakt forstand kartlegger DHT 256-biters nøkler til binære verdier av vilkårlig lengde. I dette tilfellet er nøklene i tabellen hashes fra en bestemt TL-struktur (strukturene i seg selv er også lagret sammen med DHT). Dette ligner veldig på dannelsen av nodeadresser - og de kan faktisk være tilstede i DHT (for eksempel ved å bruke en slik nøkkel IP-adressen til en node som tilsvarer en gitt abstrakt adresse, hvis han ikke skjuler det). Men i det generelle tilfellet, "prototyper av nøkler" (deres beskrivelser, nøkkelbeskrivelser) er metadata som indikerer "eieren" av en oppføring i en hash-tabell (det vil si den offentlige nøkkelen til en node), typen verdi som er lagret, og reglene som denne oppføringen kan endres etter. For eksempel kan en regel bare tillate eieren å endre verdien, eller forby å endre verdien nedover (for å beskytte mot gjentatte angrep).
I tillegg til 256-bits nøkler, introduseres konseptet med DHT-adresser. Forskjellen med vanlige vertsadresser er at DHT-adressen nødvendigvis er knyttet til en IP-adresse. Hvis en node ikke skjuler sin IP, kan den bruke en vanlig adresse for DHT. Men oftere vil det opprettes en egen, "semi-permanent" adresse for DHT-behov.
Avstandsbegrepet er introdusert over tastene og DHT-adressene - i dette faller alt sammen med tabellene — avstanden mellom tastene er lik XOR (bitvis eksklusiv OR) av dem. Som i Kademlia-tabeller, må verdien som tilsvarer en bestemt nøkkel lagres på s noder som har kortest avstand til denne nøkkelen (s her er et relativt lite antall).
For at en DHT-node skal kunne kommunisere med andre slike noder, lagres den i minnet DHT-rutingstabell — DHT- og IP-adresser til noder den samhandlet med før, gruppert etter avstand til dem. Det er 256 slike grupper (de tilsvarer den mest signifikante biten satt i avstandsverdien - det vil si at noder i en avstand fra 0 til 255 vil falle inn i en gruppe, fra 256 til 65535 - i den neste, etc.). Innenfor hver gruppe er et begrenset antall "beste" noder lagret (med hensyn til ping til dem).
Hver node må støtte flere operasjoner: lagre en verdi for en nøkkel, nodesøk и søke etter verdier. Å søke etter noder innebærer å utstede, basert på en gitt nøkkel, nodene nærmest den fra rutingtabellen; å slå opp verdier er det samme, bortsett fra når noden vet verdien for nøkkelen (da returnerer den den bare). Følgelig, hvis en node ønsker å finne en verdi etter nøkkel i DHT, sender den forespørsler til et lite antall noder nærmest denne nøkkelen fra rutetabellen. Hvis den nødvendige verdien ikke er blant svarene deres, men det er andre nodeadresser, gjentas forespørselen til dem.
TON DHT kan brukes til forskjellige formål, for eksempel for å implementere en torrent-lignende fillagring (se. TON Lagring); å bestemme adressene til noder som implementerer visse tjenester; å lagre informasjon om kontoeiere i blokkjeden. Men den viktigste applikasjonen er oppdagelsen av noder ved deres abstrakte adresser. For å gjøre dette brukes adressen som en nøkkel hvis verdi må finnes. Som et resultat av forespørselen vil enten selve noden bli funnet (hvis den søkte adressen var dens semi-permanente DHT-adresse), eller verdien vil være IP-adressen og porten for tilkobling - eller en annen adresse som bør brukes som en mellomliggende tunnel.
Overlegg nettverk i TON
ADNL-protokollen beskrevet ovenfor innebærer muligheten for alle noder til å utveksle informasjon med hverandre - men ikke nødvendigvis på optimale måter. Vi kan si at takket være ADNL danner alle noder en global TON-graf (ideelt sett sammen). Men det er i tillegg mulig å lage overleggsnettverk - undergrafer i denne grafen.
Innenfor et slikt nettverk utføres interaksjon kun direkte - gjennom forhåndsformede forbindelser mellom noder som deltar i nettverket (via ADNL-kanaler beskrevet ovenfor). Dannelsen av slike forbindelser mellom naboer, søket etter naboer selv, er en automatisk prosess som søker å opprettholde tilkoblingen til overleggsnettverket og minimere forsinkelser i utvekslingen av data i det.
I tillegg er det en måte å raskt distribuere store kringkastingsoppdateringer innenfor nettverket - de er delt i biter, supplert med feilrettingskode, og alle disse brikkene sendes fra en deltaker til en annen. Dermed trenger ikke deltakeren å skaffe alle delene fullt ut før de sendes videre langs nettverket.
Overleggsnettverk kan være offentlige eller private. Å bli medlem av et offentlig nettverk er ikke vanskelig - du må finne en TL-struktur som beskriver det (den kan være offentlig eller tilgjengelig med en bestemt nøkkel i DHT). Ved et privat nettverk må denne strukturen være kjent for noden på forhånd.
Skal videreføres
Jeg bestemte meg for å dele TON-anmeldelsen i flere artikler. Det er her denne delen slutter, og Jeg går videre til å vurdere strukturen til blokkjeden (mer presist, blokkjeder) som TON vil bestå av.
Kilde: www.habr.com