Sedan två veckor tillbaka har Runet brustit om Telegram och situationen med dess meningslösa och skoningslösa blockering av Roskomnadzor. Rikoschetten förolämpade många människor, men alla dessa är ämnen för inlägg på Geektimes. Jag blev förvånad över något annat - jag har fortfarande inte sett en enda analys på Habré av TON-nätverket som planerats för release på basis av Telegram - Telegram Open Network. Jag ville kompensera för denna brist, för det finns något att studera där – även trots bristen på officiella uttalanden om det.
Låt mig påminna dig om att det finns rykten om att Telegram har lanserat en mycket storskalig sluten ICO, efter att redan ha samlat in otroliga mängder pengar. Det förväntas att Grams egen kryptovaluta kommer att lanseras i år – och varje Telegram-användare kommer automatiskt att ha en plånbok, vilket i sig skapar en betydande fördel gentemot andra kryptovalutor.
Tyvärr, eftersom det inte finns några officiella uttalanden, kan jag bara gå vidare från , vilket jag genast varnar dig för. Naturligtvis kan det visa sig vara en mycket skicklig bluff, men det är också möjligt att detta är en riktig whitepaper om det framtida systemet, skriven av Nikolai Durov (och troligen läckt av en av investerarna). Men även om det är falskt kommer ingen att förbjuda oss att studera och diskutera det, eller hur?
Vad säger detta dokument? Jag ska försöka återberätta det med mina egna ord, nära texten, men på ryska och lite mer humant (må Nikolai förlåta mig med hans benägenhet att gå in på formell matematik). Tänk på att även om detta är äkta så är detta ett utkast till beskrivning av systemet och kommer med stor sannolikhet att ändras vid offentlig lansering.
Vi lär oss att förutom kryptovaluta finns det mycket mer som förväntas. Låt oss ta det i ordning.
- TON Blockchain. Detta är grunden för hela systemet. Om du inte vet vad det är — Jag rekommenderar att ta reda på det, för det kommer att finnas många blockkedjor här. Kapslade i varandra, praktiskt taget fragmenterade och till och med "vertikala" blockkedjor inom block av andra blockkedjor. Det kommer också att finnas några coola termer som Instant Hypercube Routing и Infinite Sharding Paradigm, men mer om det senare. Och, naturligtvis, proof-of-stake och smarta kontrakt.
- TON P2P-nätverk. Peer-to-peer-nätverk som systemet kommer att byggas utifrån. Hon kommer att diskuteras först i den här delen av berättelsen.
- TON Förvaring. Fillagring, som, oavsett blockkedja, kommer att byggas på ovan nämnda peer-to-peer-nätverk. Kan jämföras med torrents.
- TON Proxy. Detta är en tjänst vars syfte är att öka anonymiteten för nätverksdeltagare. Alla paket kan skickas inte direkt, utan genom mellanliggande tunnlar med ytterligare kryptering - som I2P eller TOR.
- TON DHT. Distribuerad hashtabell för lagring av godtyckliga värden. Den är också byggd ovanpå TON nätverk (men samtidigt används den av honom) och hjälper TON Förvaring hitta "distribuerande" noder, och TON Proxy — mellanrepeterare. Men det bör noteras att, till skillnad från blockkedjan, är denna hashtabell inte en säker lagring - du kan inte lagra viktig information i den.
- TON tjänster. Plattform för anpassade tjänster. I huvudsak är detta ett nytt Internet utöver allt som beskrivs ovan. Datautbyte - via TON nätverk/TON Proxy, och logiken ligger i smarta kontrakt TON Blockchain. Och ett gränssnitt med ganska välbekanta webbadresser.
- TON DNS. Eftersom vi pratar om bekanta URL:er behöver vi också en omvandlare från dem till 256-bitars adresser - konton, kontrakt, tjänster och noder.
- TON Betalningar. Och det är här som pengafrågan spelar in. Och det blir det inte bara gram — som med eter kommer alla "tokens" att vara möjliga; Gram kommer bara att vara "standard" valuta här.
Detta är den första delen som beskriver det "jordade" lagret av TON - dess nätverksdel, byggd ovanpå traditionella protokoll. I nästa del kommer vi att prata om den "mjuka" - blockchain, som kommer att stödjas av systemet som beskrivs nedan. Således är min återberättandeordning något annorlunda än den som används i ovan nämnda dokument (som börjar omedelbart på abstrakt nivå).
Grundläggande begrepp
TL (Skriv språk). Det är ett abstrakt binärt format för godtyckliga datastrukturer. Det används i Telegram-protokollet och kommer att användas aktivt i TON. Om du vill bekanta dig med det i detalj - .
Hash (hash). En funktion som utför en irreversibel transformation av en godtycklig datastruktur till ett enda nummer med en fast längd. Genomgående i dokumentationen talar vi om funktionen .
Nätverksnod (nod). En nod är programvaran som säkerställer att systemet fungerar. I synnerhet antas det att varje Telegram-klientapplikation kommer att inkludera en TON-nod. På en låg nivå har noder IPv4/IPv6-adresser och kommunicerar med UDP-protokollet, på en högre nivå har de abstrakta adresser och implementera ADNL-protokollet (om abstrakta adresser och ADNL - se nedan). När det kommer till det faktum att vissa delar av systemet gör något eller lagrar en del data, är det underförstått att detta görs av nätverksnoder.
Abstrakt adress (eller bara адрес, adress). En nods adress bestäms av dess publika nyckel. Mer strikt är det en 256-bitars hash (SHA256) av datastrukturen som innehåller den publika nyckeln (den specifika kryptografiska algoritmen är inte specificerad - elliptiska kurvor och RSA-2048 ges som exempel). För att en nod ska kunna kommunicera med en annan behöver den inte bara känna till adressen till den, utan även denna datastruktur. I teorin kan en fysisk nod skapa valfritt antal adresser (motsvarande olika nycklar).
Vidare används just en sådan länk ofta: en "prototyp" i form av en TL-struktur (som innehåller nästan vilken data som helst), och en 256-bitars hash från den, som används för adressering.
Blockchain (blockchain). Blockchain är en datastruktur, element (block) som ordnas i en "kedja", och varje efterföljande block i kedjan innehåller hash för det föregående. På så sätt uppnås integritet – ändringar kan bara göras genom att lägga till nya block.
Tjänsten (service). Tjänster inom TON kan vara av olika slag, beroende på om de använder blockchain eller inte. Till exempel kan en (eller många) nätverksnoder behandla vissa RPC-förfrågningar med ADNL-protokollet som beskrivs nedan, utan att skapa några poster i blockkedjan - som traditionella webbservrar. Inklusive möjligheten att implementera HTTP över ADNL, samt övergången av själva budbäraren till detta protokoll. I analogi med TOR eller I2P kommer detta att göra den mer motståndskraftig mot olika blockering.
Samtidigt innebär ett antal tjänster både interaktion med blockkedjan och bearbetning av förfrågningar utanför den. Till exempel för TON Storage - fillagring - är det inte särskilt rimligt att lagra själva filerna på blockkedjan. Den kommer endast att innehålla filhashar (tillsammans med viss metainformation om dem), och specialiserade nätverksnoder kommer att fungera som "filservrar", redo att skicka dem till andra noder via ADNL.
Dimservice (dimtjänst). Vi talar om vissa tjänster som innebär decentralisering och öppet deltagande i dem. Till exempel är TON Proxy en tjänst som kan stödjas av alla deltagare som vill tillhandahålla sin nod som en mellanhand (proxy) vidarebefordra paket mellan andra noder. Om så önskas kan han ta ut en av honom fastställd avgift för detta - med hjälp av TON Payments-systemet för mikrobetalningar (som i sin tur också är en dimtjänst).
ADNL: Abstrakt Datagram Network Layer
På den lägsta nivån kommer kommunikation mellan noder att utföras med hjälp av UDP-protokollet (även om andra alternativ är acceptabla).
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 publika nycklar (och därför adressen den definierar). Den krypterar paketet med denna nyckel och lägger till 256-bitars destinationsadressen i början av paketet - eftersom en nod kan ha flera av dessa adresser, kommer detta att tillåta den att avgöra vilken nyckel som ska användas för dekryptering.
Dessutom, istället för mottagarens adress, kan början av datapaketet innehålla den sk. identifierare kanalen. I det här fallet beror behandlingen av paketet redan på specifika överenskommelser mellan noder - till exempel kan data som skickas till en viss kanal vara avsedd för en annan nod och måste vidarebefordras till den (detta är tjänsten TON Proxy). Ett annat specialfall kan vara interaktion direkt mellan noder, men med kryptering med ett individuellt nyckelpar för denna kanal (förgenererat med Diffie-Hellman-protokollet).
Slutligen, ett specialfall är "null"-kanalen - om en nod ännu inte känner till sina "grannars" publika nycklar, kan den skicka dem paket utan kryptering alls. Detta är endast avsett för initiering - när noderna skickar information om sina nycklar bör de användas för vidare kommunikation.
Protokollet som beskrivs ovan (256 bitar av kanalidentifierare + paketinnehåll) kallas ADNL. Dokumentationen nämner möjligheten att implementera en analog av TCP ovanpå den eller ett eget tillägg - RLDP (Reliable Large Datagram Protocol), men går inte in på detaljer om deras implementering.
TON DHT: Distribuerad hashtabell
Som är fallet med andra distribuerade system, involverar TON implementeringen av DHT - . Mer specifikt är tabellen . Om du inte är bekant med denna typ av hashtabell, oroa dig inte, nedan kommer jag att beskriva ungefär hur de fungerar.
I abstrakt mening mappar DHT 256-bitars nycklar till binära värden av godtycklig längd. I det här fallet är nycklarna i tabellen hash från en viss TL-struktur (strukturerna i sig lagras också tillsammans med DHT). Detta är mycket likt bildandet av nodadresser - och de kan verkligen finnas i DHT (till exempel genom att använda en sådan nyckel IP-adressen för en nod som motsvarar en given abstrakt adress, om han inte döljer det). Men i det allmänna fallet, "prototyper av nycklar" (deras beskrivningar, nyckelbeskrivningar) är metadata som indikerar "ägaren" till en post i en hashtabell (det vill säga den publika nyckeln för någon nod), vilken typ av värde som lagras och reglerna för vilka denna post kan ändras. Till exempel kan en regel tillåta endast ägaren att ändra värdet, eller förbjuda att ändra värdet nedåt (för att skydda mot reprisattacker).
Förutom 256-bitars nycklar introduceras konceptet med DHT-adresser. Skillnaden med vanliga värdadresser är att DHT-adressen nödvändigtvis är bunden till en IP-adress. Om en nod inte döljer sin IP kan den använda en vanlig adress för DHT. Men oftare kommer en separat, "semi-permanent" adress att skapas för DHT-behov.
Begreppet avstånd introduceras ovanför nycklarna och DHT-adresserna - i detta sammanfaller allt med tabellerna — avståndet mellan nycklarna är lika med XOR (bitvis exklusivt ELLER) för dem. Som i Kademlia-tabeller måste värdet som motsvarar en viss nyckel lagras på s noder som har det kortaste avståndet till denna nyckel (s här är ett relativt litet antal).
För att en DHT-nod ska kunna kommunicera med andra sådana noder lagras den i minnet DHT routingtabell — DHT- och IP-adresser för noder som den interagerat med tidigare, grupperade efter avstånd till dem. Det finns 256 sådana grupper (de motsvarar den mest signifikanta biten som är inställd i avståndsvärdet - det vill säga noder på ett avstånd från 0 till 255 kommer att falla in i en grupp, från 256 till 65535 - i nästa, etc.). Inom varje grupp lagras ett begränsat antal "bästa" noder (i form av ping till dem).
Varje nod måste stödja flera operationer: lagra ett värde för en nyckel, nodsökning и söka efter värden. Att söka efter noder innebär att, baserat på en given nyckel, utfärdar de noder som ligger närmast den från routingtabellen; att slå upp värden är detsamma, förutom när noden känner till värdet för nyckeln (då returnerar den det bara). Följaktligen, om en nod vill hitta ett värde genom nyckel i DHT, skickar den förfrågningar till ett litet antal noder närmast denna nyckel från dess routingtabell. Om det önskade värdet inte finns bland deras svar, men det finns andra nodadresser, upprepas begäran till dem.
TON DHT kan användas för olika ändamål, till exempel för att implementera en torrentliknande fillagring (se. TON Förvaring); att bestämma adresserna till noder som implementerar vissa tjänster; att lagra information om kontoägare på blockkedjan. Men den viktigaste tillämpningen är upptäckten av noder genom deras abstrakta adresser. För att göra detta används adressen som en nyckel vars värde måste hittas. Som ett resultat av begäran kommer antingen själva noden att hittas (om den sökta adressen var dess semipermanenta DHT-adress), eller så kommer värdet att vara IP-adressen och porten för anslutning - eller en annan adress som ska användas som en mellanliggande tunnel.
Överlägg nätverk i TON
ADNL-protokollet som beskrivs ovan innebär möjligheten för alla noder att utbyta information med varandra - även om det inte nödvändigtvis är på optimala sätt. Vi kan säga att tack vare ADNL bildar alla noder en global TON-graf (helst anslutna). Men det är dessutom möjligt att skapa överläggsnätverk - subgrafer i denna graf.
Inom ett sådant nätverk utförs interaktion endast direkt - genom förformade förbindelser mellan noder som deltar i nätverket (via ADNL-kanaler beskrivna ovan). Bildandet av sådana anslutningar mellan grannar, sökandet efter grannar själva, är en automatisk process som försöker upprätthålla anslutningen för överlagringsnätverket och minimera förseningar i utbytet av data i det.
Dessutom finns det ett sätt att snabbt distribuera stora sändningsuppdateringar inom nätverket - de bryts i bitar, kompletteras med felkorrigeringskod, och alla dessa bitar skickas från en deltagare till en annan. Således behöver deltagaren inte helt skaffa alla delar innan de skickas vidare längs nätverket.
Överlagringsnätverk kan vara offentliga eller privata. Att bli medlem i ett offentligt nätverk är inte svårt - du måste 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
Jag bestämde mig för att dela upp TON-recensionen i flera artiklar. Det är här den här delen slutar, och Jag går vidare med att överväga strukturen för blockkedjan (mer exakt blockkedjor) som TON kommer att bestå av.
Källa: will.com