Al twee weken is de RuNet in rep en roer over Telegram en de situatie met de zinloze en genadeloze blokkade door Roskomnadzor. Veel mensen zijn erdoor geraakt, maar dat zijn allemaal onderwerpen voor berichten op Geektimes. Wat mij echter verbaasde, is dat ik tot nu toe op Habra geen enkele analyse heb gezien van het geplande Telegram-gebaseerde netwerk TON — Telegram Open Network. Ik wilde dit tekort aanvullen, want er is daar genoeg te onderzoeken — zelfs ondanks het ontbreken van officiële verklaringen erover.
Ter herinnering — er gaan geruchten dat Telegram een zeer grootschalige gesloten ICO heeft gelanceerd, waarbij het al ongelooflijke sommen heeft verzameld. Men verwacht dat dit jaar de eigen cryptocurrency Gram wordt gelanceerd — en dat elke gebruiker van Telegram automatisch een portemonnee krijgt, wat op zichzelf al een groot voordeel biedt ten opzichte van andere cryptocurrencies.
Helaas, aangezien er geen officiële verklaringen zijn, kan ik verder alleen vertrekken van , waarover ik jullie meteen waarschuw. Natuurlijk kan het een zeer verfijnde vervalsing zijn, maar het is ook mogelijk dat dit het echte whitepaper is van het toekomstige systeem, geschreven door Nikolai Durov (en waarschijnlijk gelekt door iemand van de investeerders). Maar zelfs als dit een vervalsing is, kan niemand ons verbieden het te bestuderen en te bespreken, toch?
Wat zegt dit document? Ik zal proberen het in mijn woorden samen te vatten, dicht bij de tekst, maar dan in het Nederlands en iets menselijker (vergeef me, Nikolai, voor je neiging om in formele wiskunde te vervallen). Houd er rekening mee dat, zelfs als het authentiek is, dit een ruwe beschrijving van het systeem is en het vermoedelijk zal veranderen tegen de tijd dat het publiekelijk wordt gelanceerd.
We leren dat naast de cryptocurrency ook nog veel en veel meer wordt verwacht. Laten we dit stap voor stap doornemen.
- TON Blockchain. Dit is de basis van het hele systeem. Als je helemaal niet weet wat is — raad ik je aan om het te leren, want hier zullen veel blockchains zijn. In elkaar geneste, virtueel opgesplitste en zelfs 'verticale' blockchains binnen de blokken van andere blockchains. En er zullen ook een aantal geweldig klinkende termen zijn zoals Instant Hypercube Routing en Infinite Sharding Paradigm, maar daarover later meer. En natuurlijk proof-of-stake en smart contracts.
- TON P2P Network. Een peer-to-peer netwerk dat de basis zal vormen voor het functioneren van het systeem. Dit is hetgeen waar in deze sectie als eerste over gesproken zal worden.
- TON Storage. Een bestandssysteem dat onafhankelijk van de blockchain is en zal worden gebouwd op het eerder genoemde peer-to-peer netwerk. Het kan worden vergeleken met torrents.
- TON Proxy. Dit is een service die als doel heeft de anonimiteit van de deelnemers aan het netwerk te verhogen. Elke datapakket kan niet rechtstreeks worden verzonden, maar via tussenliggende tunnels met extra encryptie — vergelijkbaar met I2P of TOR.
- TON DHT. Een gedistribueerde hash-tabel voor het opslaan van willekeurige waarden. Deze is ook gebouwd bovenop TON Network (maar maakt er gebruik van) en helpt TON Storage de 'seed' knooppunten te vinden, evenals TON Proxy tussenliggende retransmitters. Maar het is belangrijk op te merken dat, in tegenstelling tot de blockchain, deze hash-tabel geen beveiligde opslag is — belangrijke informatie mag hier niet worden opgeslagen.
- TON Services. Een platform voor willekeurige services. In wezen is het een nieuw internet bovenop alles wat hierboven is beschreven. Gegevensuitwisseling gebeurt via TON Network/TON Proxy, terwijl de logica in smart contracts van TON Blockchain. En de interface met vrij bekende URL's.
- TON DNS. Nu we het over bekende URL's hebben, is er ook een converter van deze naar 256-bits adressen — voor accounts, contracts, services en knooppunten.
- TON Payments. En hier komt de financiële kwestie aan bod. En dat zullen niet alleen gram zijn — net als bij ether zullen er allerlei 'tokens' mogelijk zijn; grammen zijn hier slechts de 'standaard' valuta.
Dit is het eerste deel dat het 'aardedel' niveau van TON beschrijft — zijn netwerkcomponent, die bovenop traditionele protocollen is opgebouwd. In het volgende deel zullen we het hebben over de 'kern' — de blockchain die zal worden ondersteund door het hierna beschreven systeem. Op deze manier verschilt mijn volgorde van vertellen enigszins van die in het eerder genoemde document (dat meteen met het abstracte niveau begint).
Basisconcepten
TL (Type Language). Dit is een abstract binair formaat voor willekeurige datastructuren. Het wordt gebruikt in het Telegram protocol en zal actief worden gebruikt in TON. Als je er gedetailleerd kennis van wilt nemen — .
Hash (hash). Een functie die een onomkeerbare transformatie uitvoert van een willekeurige datastructuur naar een enkel getal van vaste lengte. Binnen de documentatie wordt overal gesproken over de functie .
Netwerk knooppunt (node). Een knoop is software die de werking van het systeem verzorgt. In het bijzonder wordt verondersteld dat elke clientapplicatie van Telegram een knoop van TON bevat. Op laag niveau hebben knopen IPv4/IPv6-adressen en communiceren ze via het UDP-protocol; op hoger niveau hebben ze abstracte adressen en implementeren ze het ADNL-protocol (over abstracte adressen en ADNL — zie hieronder). Wanneer gesproken wordt over delen van het systeem die iets doen of bepaalde gegevens opslaan, wordt verondersteld dat dit door de knopen van het netwerk gebeurt.
Abstract adres (of gewoon , wachtwoord, address). Het adres van een knoop wordt gedefinieerd door zijn openbare sleutel. Strikter gezegd is dit een 256-bits hash (SHA256) van de datastructuur die de openbare sleutel bevat (de specifieke cryptografische algoritme wordt daarbij niet gespecificeerd — als voorbeeld worden elliptische krommen en RSA-2048 genoemd). Om een knoop met een andere te laten communiceren, moet deze niet alleen het adres van die andere knoop kennen, maar ook deze datastructuur. Theoretisch kan één fysieke knoop een onbeperkt aantal adressen creëren (die overeenkomen met verschillende sleutels).
Hierna wordt vaak precies deze combinatie gebruikt: een 'model' in de vorm van een TL-structuur (die praktisch alle gegevens kan bevatten), en de 256-bits hash daarvan, die gebruikt wordt voor adressering.
Blockchain (blockchain). Blockchain is een datastructuur waarvan de elementen (blokken) in een 'keten' zijn geordend, en elk volgend blok in de keten bevat de hash van het vorige blok. Op deze manier wordt integriteit gegarandeerd — wijzigingen kunnen alleen worden aangebracht door nieuwe blokken toe te voegen.
Dienst (voor het SystemD-initiesysteem:). Diensten binnen TON kunnen van verschillende typen zijn, afhankelijk van het feit of ze blockchain gebruiken of niet. Bijvoorbeeld, een (of meerdere) knopen van het netwerk kunnen bepaalde RPC-verzoeken verwerken volgens het hieronder beschreven ADNL-protocol, zonder enige records in de blockchain te creëren — vergelijkbaar met traditionele webservers. Ook wordt de mogelijkheid overwogen om HTTP bovenop ADNL te implementeren, evenals de overgang van de messenger naar dit protocol. Vergelijkbaar met TOR of I2P zal dit het meer bestand maken tegen verschillende blokkades.
Tegelijkertijd impliceren verschillende diensten zowel interactie met de blockchain als verwerking van verzoeken buiten de blockchain. Voor TON Storage, bijvoorbeeld, een bestandopslagservice, is het niet erg verstandig om de bestanden zelf op de blockchain op te slaan. Alleen de hashes van de bestanden (samen met bepaalde metadata over deze bestanden) worden hierin opgeslagen, terwijl gespecialiseerde knooppunten van het netwerk als 'bestandsservers' optreden, die bereid zijn deze aan andere knooppunten via ADNL te leveren.
Mistservice (fog service). Het gaat om bepaalde diensten die decentralisatie en open deelname impliceren. TON Proxy, bijvoorbeeld, is een dienst die door elke deelnemer kan worden ondersteund die zijn knooppunt als tussenpersoon (proxy) wil aanbieden, dat pakketten tussen andere knooppunten doorstuurt. Als iemand dat wil, kan hij hiervoor een door hem vastgesteld bedrag in rekening brengen — gebruikmakend van het TON Payments-systeem voor microbetalingen (wat op zijn beurt ook een mistservice is).
ADNL: Abstract Datagram Network Layer
Op het laagste niveau zal de interactie tussen knooppunten plaatsvinden via het UDP-protocol (hoewel andere varianten ook zijn toegestaan).
Zoals hierboven vermeld, om een knooppunt een pakket naar een ander te kunnen sturen, moet het een van zijn publieke sleutels kennen (en dus het adres dat door deze sleutel wordt bepaald). Het versleutelt het pakket met deze sleutel en voegt aan het begin van het pakket een 256-bits adres van de ontvanger toe — aangezien een knooppunt meerdere van dergelijke adressen kan hebben, kan dit hem helpen te bepalen welke sleutel voor decryptie moet worden gebruikt.
Bovendien kan in plaats van het adres van de ontvanger aan het begin van het gegevenspakket de zogenaamde identificator staan kanaal. In dat geval hangt de verwerking van het pakket al af van specifieke afspraken tussen de knooppunten — bijvoorbeeld, gegevens die naar een bepaald kanaal worden verzonden, kunnen bestemd zijn voor een ander knooppunt en moeten naar dat knooppunt worden doorgestuurd (dit is de dienst TON Proxy). Een andere specifieke situatie kan directe interactie tussen knooppunten zijn, maar met encryptie op basis van een individuele paar sleutels voor dit kanaal (vooraf gevormd volgens het Diffie-Hellman-protocol).
Ten slotte is er een bijzondere 'nul'-kanaal: als een knooppunt nog niet op de hoogte is van de publieke sleutels van zijn 'buren', kan het pakketten zonder enige encryptie naar hen versturen. Dit is alleen bedoeld voor initiële communicatie - zodra de knooppunten informatie over hun sleutels hebben verzonden, moeten deze worden gebruikt voor verdere interactie.
Het protocol beschreven hierboven (256-bits kanaalidentificatie + pakketinhoud) wordt ADNL genoemd. De documentatie vermeldt de mogelijkheid om een TCP-achtig protocol bovenop te implementeren of een eigen bovengelaagde variant - RLDP (Reliable Large Datagram Protocol), maar gaat niet in detail over hun implementatie.
TON DHT: Gedistribueerde hash-tabel
Zoals in andere gedistribueerde systemen, stelt TON de implementatie van een DHT voor - . Concreet is de tabel . Als je niet bekend bent met deze soort hash-tabellen - maak je geen zorgen, ik zal kort uitleggen hoe ze werken.
In abstracte zin koppelt een DHT 256-bits sleutels aan bepaalde binaire waarden van willekeurige lengte. Deze sleutels in de tabel zijn hashes van een bepaalde TL-structuur (de structuren zelf worden ook samen met de DHT opgeslagen). Dit lijkt veel op het vormen van knooppuntadressen - en ze kunnen ook echt in de DHT aanwezig zijn (bijvoorbeeld, op zo'n sleutel kan het IP-adres van het knooppunt dat aan het bepaalde abstracte adres, zolang dit niet verborgen is, worden weergegeven). Maar in het algemeen zijn de 'afgeleiden sleutels' (hun beschrijvingen, key descriptions) metadata die naar de 'eigenaar' van de vermelding in de hash-tabel verwijzen (d.w.z. de publieke sleutel van een bepaald knooppunt), het type opgeslagen waarde en de regels volgens welke deze vermelding later kan worden gewijzigd. Bijvoorbeeld, een regel kan de eigenaar toestaan om de waarde te wijzigen - of verbieden om de waarde te verlagen (om zich te beschermen tegen herhaling-aanvallen).
Naast de 256-bits sleutels wordt het concept van DHT-adressen geïntroduceerd. Het verschil met normale knooppuntadressen is dat een DHT-adres noodzakelijkerwijs aan een IP-adres is gekoppeld. Als een knooppunt zijn IP niet verbergt, kan het het normale adres voor de DHT gebruiken. Maar vaker zal er voor DHT-doeleinden een apart, 'half-permanent' adres worden ingesteld.
Over de sleutels en DHT-adressen wordt het concept van afstand geïntroduceerd - hierin komt alles overeen met tabellen. — de afstand tussen de sleutels is gelijk aan de XOR (exclusieve of) van hen. Net als in Kademlia-tabellen moet de waarde die overeenkomt met een bepaalde sleutel worden opgeslagen op str1 != str2 knopen die de kortste afstand tot deze sleutel hebben (str1 != str2 deze is relatief klein).
Om ervoor te zorgen dat een DHT-knoop kan communiceren met andere soortgelijke knopen, houdt deze een DHT-routeringstabel bij — DHT- en IP-adressen van knopen waarmee deze eerder heeft gecommuniceerd, gegroepeerd op afstand tot hen. Er zijn 256 van zulke groepen (ze komen overeen met de meest significante ingestelde bit in de afstandswaarde — dat wil zeggen, knopen op een afstand van 0 tot 255 vallen in één groep, van 256 tot 65535 in de volgende, enzovoort). Binnen elke groep wordt een beperkt aantal 'beste' knopen opgeslagen (met betrekking tot de ping naar hen).
Elke knoop moet verschillende operaties ondersteunen: opslag van een waarde voor een sleutel, zoeken naar knopen en zoeken naar waarden. Het zoeken naar knopen houdt in dat de dichtstbijzijnde knopen aan de routeringstabel voor een gegeven sleutel worden weergegeven; het zoeken naar waarden is hetzelfde, behalve wanneer de knoop al een waarde voor de sleutel kent (dan retourneert deze die gewoon). Dus als een knoop een waarde in de DHT wil vinden op basis van een sleutel, stuurt deze verzoeken naar een klein aantal knopen die het dichtst bij die sleutel in zijn routeringstabel staan. Als er in hun antwoorden geen gevraagde waarde is, maar er zijn andere adressen van knopen, dan wordt het verzoek opnieuw naar hen herhaald.
TON DHT kan voor verschillende doeleinden worden gebruikt, bijvoorbeeld — voor het realiseren van een torrent-achtige opslag voor bestanden (zie TON Storage); voor het bepalen van de adressen van knopen die specifieke diensten implementeren; voor het opslaan van informatie over eigenaren van accounts in de blockchain. Maar de belangrijkste toepassing is het detecteren van knopen op hun abstracte adressen. Hiervoor wordt het adres als sleutel gebruikt, waarvan de waarde moet worden gevonden. Als resultaat van het verzoek wordt ofwel de knoop zelf gevonden (als het gevraagde adres zijn semi-permanente DHT-adres was), of is de waarde het IP-adres en poort voor verbinding — of een ander adres dat moet worden gebruikt als een tussenliggende tunnel.
Overlay-netwerken in TON
Het hierboven beschreven ADNL-protocol biedt de mogelijkheid voor knooppunten om informatie met elkaar uit te wisselen — hoewel niet noodzakelijkerwijs via de meest optimale routes. Men kan zeggen dat dankzij ADNL alle knooppunten een wereldwijd TON-netwerk vormen (idealiter — aaneengeschakeld). Daarnaast is er de mogelijkheid om overlay-netwerken te creëren — sub-grafen binnen dit netwerk.
Binnen zo'n netwerk vindt de interactie alleen rechtstreeks plaats — volgens vooraf gevormde verbindingen tussen de deelnemende knooppunten (via de hierboven genoemde ADNL-kanalen). Het vormen van dergelijke verbindingen tussen buren en het zoeken naar deze buren is een automatisch proces, dat zich richt op het behouden van de samenhang binnen het overlay-netwerk en het minimaliseren van vertragingen bij gegevensuitwisseling.
Bovendien is er een methode voorzien om grote broadcast-updates snel binnen het netwerk te verspreiden — deze worden opgedeeld in delen, aangevuld met foutcorrectiecode, en al deze stukken worden van de ene deelnemer naar de andere verzonden. Hierdoor hoeft een deelnemer niet alle delen volledig te ontvangen voordat hij ze verder het netwerk in verzendt.
Overlay-netwerken kunnen openbaar of privé zijn. Deelnemen aan een openbaar netwerk is eenvoudig — men moet een TL-structuur vinden die dit beschrijft (dit kan openbaar zijn — of toegankelijk met een bepaalde sleutel in de DHT). In het geval van een privé-netwerk moet deze structuur vooraf aan het knooppunt bekend zijn.
To be continued
Ik heb besloten om het overzicht van TON op te splitsen in verschillende artikelen. Dit deel eindigt hier, en zal ik de structuur van de blockchain (meer bepaald de blockchains) bespreken waaruit TON zal bestaan.
Bron: habr.com
