TON: Telegram Open Network. Del 1: Introduktion, nätverksnivå, ADNL, DHT, överlagda nätverk

Under två veckor har Ryssland stått i centrum för diskussioner om Telegram och situationen med dess meningslösa och skoningslösa blockering av Roskomnadzor. Många människor har blivit påverkade, men allt detta är teman för inlägg på Geektimes. Det som förvånar mig är att jag fortfarande inte har sett något på Habrä om den planerade Telegram-baserade nätverket TON – Telegram Open Network. Jag ville fylla denna brist, eftersom det finns mycket att studera där – även utan officiella uttalanden om det.

Låt mig påminna om att det går rykten om att Telegram har lanserat en mycket storskalig sluten ICO som redan har samlat otroliga summor. Det antas att en egen kryptovaluta, Gram, kommer att lanseras redan i år – och varje Telegram-användare kommer automatiskt att få en plånbok, vilket i sig skapar en stor fördel jämfört med andra kryptovalutor.

Tyvärr, eftersom det inte finns några officiella uttalanden, kan jag endast utgå från ett dokument av okänt ursprung, vilket jag genast varnar er för. Självklart kan det visa sig vara en mycket skicklig förfalskning, men det är också möjligt att detta är ett verkligt whitepaper för det framtida systemet, skrivet av Nikolaj Durov (och läckt, troligtvis av någon av investerarna). Men även om det är en bluff, får ingen oss att förbjuda att studera och diskutera det, eller hur?

Vad sägs i detta dokument? Jag ska försöka återberätta det med mina egna ord, nära texten, men på svenska och något mer mänskligt (låt mig förlåta Nikolaj för hans benägenhet att gå in i formell matematik). Tänk på att även i händelse av dess äkthet är detta en grov skiss av systemet och det kommer med stor sannolikhet att förändras fram till den offentliga lanseringen.

Vi får veta att förutom kryptovalutan planeras det mycket mer. Låt oss gå igenom det i ordning.

• TON Blockchain. Detta är grunden för hela systemet. Om du helt och hållet inte vet vad en blockkedja är – då rekommenderar jag att du tar reda på det, eftersom det kommer att finnas många blockkedjor här. Inbäddade i varandra, virtuellt uppdelade och till och med "vertikala" blockkedjor inom andra blockkedjor. Dessutom kommer det att finnas flera häftiga termer som Instant Hypercube Routing och Infinite Sharding Paradigm, men mer om det senare. Och självklart, proof-of-stake och smarta kontrakt.
• TON P2P Network. Peer-to-peer-nätverk, på vilket systemet kommer att byggas. Detta kommer att diskuteras först i denna del av berättelsen.
• TON Storage. En filförvaring som oberoende av blockkedjan kommer att byggas på det ovan nämnda peer-to-peer-nätverket. Det kan liknas vid torrentfiler.
• TON Proxy. Detta är en tjänst vars syfte är att öka anonymiteten för nätverksdeltagarna. Varje paket kan skickas, inte direkt, utan genom tunnlar som agenter med ytterligare kryptering — liknande I2P eller TOR.
• TON DHT. En distribuerad hash-tabell för lagring av godtyckliga värden. Den är också byggd ovanpå TON Network (men används av den) och hjälper till att TON Storage hitta "delande" noder, och TON Proxy — mellanliggande retransmittanter. Men det är viktigt att notera att, till skillnad från blockkedjan, är denna hash-tabell inte ett säkert förråd — viktig information bör inte lagras i den.
• TON Services. En plattform för godtyckliga tjänster. I grund och botten är detta ett nytt internet ovanpå allt det ovanstående. Datautbyte — genom TON Network/TON Proxy, och logik — i smarta kontrakt av. TON Blockchain. Och gränssnittet med ganska vanliga URL:er.
• TON DNS. Eftersom vi talade om vanliga URL:er, behövs även en omvandlare från dem till 256-bitarsadresser — för konton, kontrakt, tjänster och noder.
• TON Payments. Här kommer vi bara in på den ekonomiska aspekten. Och detta kommer att vara inte bara gram — som med ether, alla typer av "tokens" kommer att vara möjliga; gram kommer här att vara endast valutan "som standard".

Detta är första delen som beskriver den "jordade" nivån av TON — dess nätverksdel som byggs ovanpå traditionella protokoll. I nästa del kommer vi att tala om "kärnan" — blockkedjan som kommer att stödas av det som beskrivs härnäst. Därmed skiljer sig min berättelse något från den som används i det ovan nämnda dokumentet (som börjar direkt med den abstrakta nivån).

Grundläggande begrepp

TL (Type Language). Detta är ett abstrakt binärt format för godtyckliga datastukturer. Det används i Telegram-protokollet och kommer att användas aktivt i TON. Om du vill bekanta dig med det i detalj — här är dess beskrivning.

Hash (hash). En funktion som producerar en oåterkallelig omvandling av en godtycklig datastruktur till ett enda tal av fast längd. Inom dokumentationen talas det ofta om funktionen SHA-256.

Nod i nätverket (node). En nod är en programvara som kommer att säkerställa att systemet fungerar. Det antas särskilt att varje Telegram-klientapplikation kommer att inkludera en TON-nod. På låg nivå har noder IPv4/IPv6-adresser och kommunicerar via UDP-protokollet, på en högre nivå har de abstrakta adresser och implementerar ADNL-protokollet (om abstrakta adresser och ADNL - se nedan). När vi talar om att vissa delar av systemet gör något eller lagrar viss data, avses det att detta sker av nätverksnoder.

Abstrakt adress (eller bara , lösenord, address). En nods adress definieras av dess offentliga nyckel. Mer strikt - det är en 256-bitars hash (SHA256) av en datastruktur som innehåller den offentliga nyckeln (den specifika kryptografiska algoritmen specificeras inte - exempelvis nämns elliptiska kurvor och RSA-2048). För att en nod ska kunna interagera med en annan behöver den veta inte bara adressen, utan även denna datastruktur. Teoretiskt kan en fysisk nod skapa ett obegränsat antal adresser (som motsvarar olika nycklar).

Dessutom används ofta just denna koppling: "urbilden" i form av TL-strukturen (som kan innehålla praktiskt taget vilken data som helst), och 256-bitars hashen av den, som används för adressering.

Blockchain (blockchain). Blockchain är en datastruktur vars element (block) är ordnade i en "kedja", och varje följande block i kedjan innehåller en hash av det föregående. På så sätt uppnås integritet - förändringar kan endast göras genom att lägga till nya block.

Tjänsten (service). Tjänster inom TON kan vara av olika typer - beroende på om de använder blockchain eller inte. Till exempel kan en (eller flera) av nätverkets noder behandla vissa RPC-förfrågningar enligt det protokoll som beskrivs nedan ADNL, utan att skapa några poster i blockchain - liknande traditionella webbservrar. Det övervägs även möjligheten till att implementera HTTP över ADNL, samt att själva meddelandetjänsten går över till detta protokoll. På liknande sätt som TOR eller I2P, kommer detta att göra den mer motståndskraftig mot olika blockeringsåtgärder.

Samtidigt förutsätter en del tjänster både interaktion med blockchain och bearbetning av förfrågningar utanför den. Till exempel, för TON Storage — filförvaringen — är det inte särskilt klokt att lagra själva filerna i blockchain. Där kommer endast filernas hash (tillsammans med viss metadata om dem) att bevaras, medan specialiserade noder i nätverket fungerar som "filservrar" som är redo att leverera dem till andra noder via ADNL.

Dimtjänst (fog service). Det handlar om vissa tjänster som förutsätter decentralisering och öppen delaktighet. Till exempel är TON Proxy en tjänst som alla deltagare kan stödja genom att erbjuda sin nod som en mellanhand (proxy) som skickar paket mellan andra noder. Om man så önskar kan man ta ut en avgift för detta — med systemet TON Payments för mikropayments (som i sin tur också är en dimtjänst).

ADNL: Abstract Datagram Network Layer

På den lägsta nivån kommer interaktionen mellan noder att ske via UDP-protokollet (andra alternativ är också tillåtna).

Som nämnts ovan, för att en nod ska kunna skicka ett paket till en annan, måste den känna till en av dess offentliga nycklar (och därmed adressen som definieras av den). Den krypterar paketet med denna nyckel och lägger till en 256-bitars adress för mottagaren i början av paketet — eftersom en nod kan ha flera sådana adresser kommer detta att göra det möjligt för den att avgöra vilken nyckel som ska användas för avkryptering.

Dessutom kan en så kallad identifierare kanal. I så fall beror bearbetningen av paketet redan på de specifika överenskommelserna mellan noderna — till exempel kan data som skickas till en viss kanal vara avsedda för en annan nod och måste vidarebefordras till den (detta är en tjänst TON Proxy). Ett annat särskilt fall kan vara interaktion direkt mellan noder, men med kryptering med ett individuellt par nycklar för denna kanal (som tidigare skapades enligt Diffie-Hellman-protokollet).

Till slut finns det ett speciellt fall som kallas "noll"-kanalen — om en nod ännu inte känner till sina "grannars" offentliga nycklar kan den skicka paket till dem utan kryptering alls. Detta är avsett endast för initiering — så snart noderna skickar information om sina nycklar bör dessa användas för fortsatt kommunikation.

Den ovan beskrivna protokollet (256 bitars kanalidentifierare + paketets innehåll) kallas ADNL. Dokumentationen nämner möjligheten att implementera en motsvarighet till TCP ovanför det eller en egen överbyggnad — RLDP (Reliable Large Datagram Protocol), men går inte in på detaljer om deras implementering.

TON DHT: Distribuerad hash-tabell

Precis som i andra distribuerade system förutsätter TON implementeringen av DHT — en distribuerad hash-tabell. Mer specifikt — tabellen är Kademlia-liknande. Om du inte är bekant med denna typ av hash-tabeller — oroa dig inte, nedan kommer jag att ungefärligen beskriva hur de är uppbyggda.

I abstrakt mening ger DHT en koppling mellan 256-bitsnycklar och vissa binära värden av godtycklig längd. Nycklarna i tabellen är hash-värden av en viss TL-struktur (själva strukturerna lagras också tillsammans med DHT). Detta liknar mycket bildandet av noders adresser — och de kan faktiskt förekomma i DHT (till exempel kan en IP-adress för en nod motsvara den angivna abstrakta adressen, om den inte döljer den). Men i allmänhet är "prototyper av nycklar" (deras beskrivningar, key descriptions) — detta är metadata som anger "ägaren" av posten i hash-tabellen (dvs. den offentliga nyckeln för någon nod), typ av det lagrade värdet och reglerna för hur detta post senare kan ändras. Till exempel kan en regel tillåta att ägaren endast får ändra värdet — eller förbjuda att värdet ändras nedåt (för att skydda sig mot replay-attacker).

Förutom 256-bitsnycklar introduceras begreppet DHT-adresser. Skillnaden från vanliga adresser för noder är att DHT-adressen alltid är kopplad till en IP-adress. Om en nod inte döljer sin IP kan den använda en vanlig adress för DHT. Men oftare för DHT:s behov skapas en separat, "halv-permanent" adress.

Över nycklar och DHT-adresser introduceras begreppet avstånd — här överensstämmer allt med tabellerna Kademlia — avståndet mellan nycklarna är XOR (bitvis exklusiv eller) mellan dem. Precis som i Kademlia-tabeller, bör värdet som motsvarar en viss nyckel lagras på s noder som har det minsta avståndet till denna nyckel (s här — ett relativt litet antal).

För att en DHT-nod ska kunna interagera med andra sådana noder, håller den i minnet DHT-routingtabelle — DHT- och IP-adresserna till de noder som den har interagerat med tidigare, grupperade efter avstånd till dem. Det finns 256 sådana grupper (de motsvarar den mest betydelsefulla uppställda biten i avståndsvärdet — det vill säga noder på avstånd från 0 till 255 hamnar i en grupp, från 256 till 65535 — i nästa, osv.). Inom varje grupp lagras ett begränsat antal "bästa" noder (vad gäller ping till dem).

Varje nod måste stödja flera operationer: spara värdet för en nyckel, söka noder och söka värden. Söka noder innebär att ge de närmaste noderna i routingtabellen kopplade till en given nyckel; söka värden — samma sak, med undantag för när noden känner till värdet för nyckeln (då återgår den helt enkelt med det). Därför, om en nod vill hitta ett värde i DHT baserat på en nyckel, skickar den förfrågningar till ett litet antal av de närmaste noderna till denna nyckel från sin routingtabell. Om det inte finns något begärt värde bland deras svar men det finns andra nodadresser, upprepas förfrågan till dem.

TON DHT kan användas för olika syften, till exempel — för att implementera en torrent-liknande filförvaring (se TON Storage); för att bestämma adresser till noder som implementerar vissa tjänster; för att lagra information om kontoinnehavares identiteter i blockkedjan. Men det viktigaste användningsområdet är att upptäcka noder via deras abstrakta adresser. För detta används adressen som nyckel, och det värde som skall hittas. Som ett resultat av förfrågan kan antingen noden själv hittas (om den sökta adressen var dess semi-permanenta DHT-adress), eller så är värdet en IP-adress och port för anslutning — eller en annan adress som ska användas som en tunnel-mellanhand.

Överliggande nätverk i TON

Protokollet ADNL som beskrivits ovan möjliggör för alla noder att utbyta information med varandra — även om det inte nödvändigtvis sker på optimala vägar. Man kan säga att genom ADNL bildar alla noder en global graf TON (i idealfallet — sammanhängande). Men det finns dessutom möjlighet att skapa överliggande nätverk — undergrafer inom denna graf.

Inom ett sådant nätverk sker interaktion enbart direkt — genom förhandsgjorda kopplingar mellan deltagande noder (via ADNL-kanalerna som beskrivits ovan). Bildandet av sådana kopplingar mellan grannar, samt sökandet efter medlemmar — är en automatiserad process som strävar efter att upprätthålla sammanlänkningen i det överliggande nätverket och minimera fördröjningar vid datakommunikation.

Dessutom finns det ett sätt att snabbt sprida stora sändningsuppdateringar inom nätverket — de delas upp i delar, kompletteras med felkorrektionskod, och alla dessa bitar vidarebefordras från en deltagare till en annan. Således behöver deltagaren inte helt få alla delar innan de kan skicka dem vidare i nätverket.

Överliggande nätverk kan vara offentliga och privata. Att bli medlem i ett offentligt nätverk är inte svårt — man måste bara hitta en TL-struktur som beskriver det (den kan vara offentlig — eller tillgänglig med en viss nyckel i DHT). I fallet med ett privat nätverk måste denna struktur vara känd för noden i förväg.

Fortsättning följer

Jag har beslutat att dela upp min översikt av TON i flera artiklar. Denna del avslutas här, och i nästa kommer jag att gå vidare till att granska strukturen av blockkedjan (eller rättare sagt blockkedjorna) som kommer att utgöra TON.

Källa: habr.com