De Runet maakt nu al twee weken lawaai over Telegram en de situatie met zijn zinloze en genadeloze blokkering door Roskomnadzor. Het afketsen beledigde veel mensen, maar dit zijn allemaal onderwerpen voor berichten op Geektimes. Ik was verrast door iets anders: ik heb nog steeds geen enkele analyse gezien op Habré van het TON-netwerk dat gepland is voor release op basis van Telegram - Telegram Open Network. Ik wilde dit tekort goedmaken, omdat daar iets te studeren valt - ondanks het ontbreken van officiële verklaringen daarover.
Laat me je eraan herinneren dat er geruchten gaan dat Telegram een zeer grootschalige gesloten ICO heeft gelanceerd, nadat hij al ongelooflijke hoeveelheden geld heeft ingezameld. De verwachting is dat Gram’s eigen cryptocurrency dit jaar wordt gelanceerd – en elke Telegram-gebruiker automatisch een portemonnee zal hebben, wat op zichzelf een aanzienlijk voordeel oplevert ten opzichte van andere cryptocurrencies.
Helaas kan ik, aangezien er geen officiële verklaringen zijn, alleen maar verder gaan , waarvoor ik u onmiddellijk waarschuw. Het kan natuurlijk een zeer bekwame nep blijken te zijn, maar het is ook mogelijk dat dit een echt witboek is van het toekomstige systeem, geschreven door Nikolai Durov (en waarschijnlijk gelekt door een van de investeerders). Maar zelfs als het nep is, zal niemand ons verbieden het te bestuderen en te bespreken, toch?
Wat zegt dit document? Ik zal proberen het in mijn eigen woorden opnieuw te vertellen, dicht bij de tekst, maar in het Russisch en een beetje menselijker (moge Nikolai mij vergeven met zijn neiging om zich in de formele wiskunde te verdiepen). Houd er rekening mee dat, zelfs als dit echt is, dit een conceptbeschrijving van het systeem is en zeer waarschijnlijk zal veranderen tegen de tijd dat het openbaar wordt gelanceerd.
We leren dat er naast cryptocurrency nog veel meer wordt verwacht. Laten we het in volgorde nemen.
- TON Blockchain. Dit is de basis van het hele systeem. Als je niet weet wat het is – Ik raad aan om dit uit te zoeken, omdat er hier veel blockchains zullen zijn. In elkaar geneste, vrijwel gefragmenteerde en zelfs “verticale” blockchains binnen blokken van andere blockchains. Er zullen ook enkele cool klinkende termen zijn, zoals Directe Hypercube-routering и Oneindige Sharding-paradigma, maar daarover later meer. En natuurlijk proof-of-stake en slimme contracten.
- TON P2P-netwerk. Peer-to-peer netwerk op basis waarvan het systeem zal worden gebouwd. Zij zal in dit deel van het verhaal als eerste worden besproken.
- TON Opslag. Bestandsopslag, die ongeacht de blockchain gebouwd zal worden op het bovengenoemde peer-to-peer netwerk. Je kunt het vergelijken met torrents.
- TON-proxy. Dit is een dienst die tot doel heeft de anonimiteit van netwerkdeelnemers te vergroten. Elk pakket kan niet rechtstreeks worden verzonden, maar via tussenliggende tunnels met extra codering, zoals I2P of TOR.
- TON DHT. Gedistribueerde hashtabel voor het opslaan van willekeurige waarden. Er wordt ook bovenop gebouwd TON Netwerk (maar tegelijkertijd wordt het door hem gebruikt) en helpt TON Opslag vind “distribuerende” knooppunten, en TON-proxy — tussenliggende repeaters. Maar het moet worden opgemerkt dat deze hashtabel, in tegenstelling tot de blockchain, geen veilige opslag is: je kunt er geen belangrijke informatie in opslaan.
- TON Services. Platform voor dienstverlening op maat. In wezen is dit een nieuw internet bovenop alles wat hierboven is beschreven. Gegevensuitwisseling - via TON Netwerk/TON-proxy, en de logica zit in de slimme contracten van de TON Blockchain. En een interface met redelijk bekende URL's.
- TON DNS. Omdat we het over bekende URL's hebben, hebben we ook een converter nodig van deze naar 256-bits adressen: accounts, contracten, services en knooppunten.
- TON betalingen. En hier komt de geldkwestie om de hoek kijken. En dat zal niet alleen zo zijn gram – net als bij ether zullen alle “tokens” mogelijk zijn; Grammen zullen hier slechts de “standaard” valuta zijn.
Dit is het eerste deel dat de “geaarde” laag van TON beschrijft: het netwerkgedeelte, gebouwd bovenop traditionele protocollen. In het volgende deel zullen we het hebben over de “zachte” blockchain, die zal worden ondersteund door het hieronder beschreven systeem. Mijn volgorde van hervertelling wijkt dus enigszins af van de volgorde die in het bovengenoemde document wordt gebruikt (dat onmiddellijk op abstract niveau begint).
Basisconcepten
TL (Typtaal). Het 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 in detail kennis mee wilt maken - .
Hasj (hachee). Een functie die een onomkeerbare transformatie uitvoert van een willekeurige gegevensstructuur naar een enkel getal met een vaste lengte. In de documentatie praten we over de functie .
Netwerk knooppunt (knooppunt). Een knooppunt is de software die ervoor zorgt dat het systeem functioneert. In het bijzonder wordt aangenomen dat elke Telegram-clienttoepassing een TON-knooppunt zal bevatten. Op een laag niveau hebben knooppunten IPv4/IPv6-adressen en communiceren ze via het UDP-protocol; op een hoger niveau hebben ze abstracte adressen en implementeer het ADNL-protocol (over abstracte adressen en ADNL - zie hieronder). Als het gaat om het feit dat sommige delen van het systeem iets doen of gegevens opslaan, wordt begrepen dat dit wordt gedaan door netwerkknooppunten.
Abstract adres (of gewoon adres, adres). Het adres van een knooppunt wordt bepaald door zijn publieke sleutel. Strikt genomen is het een 256-bit hash (SHA256) van de datastructuur die de publieke sleutel bevat (het specifieke cryptografische algoritme is niet gespecificeerd - elliptische curven en RSA-2048 worden als voorbeelden gegeven). Om het ene knooppunt met het andere te laten communiceren, moet het niet alleen het adres van dat knooppunt kennen, maar ook deze gegevensstructuur. In theorie kan één fysiek knooppunt een willekeurig aantal adressen creëren (overeenkomend met verschillende sleutels).
Verder wordt vaak zo'n link gebruikt: een "prototype" in de vorm van een TL-structuur (die vrijwel alle gegevens bevat), en een 256-bits hash daarvan, gebruikt voor adressering.
Blockchain (blockchain). Blockchain is een datastructuur, elementen (blokken) die in een “keten” zijn geordend, en elk volgend blok van de keten bevat de hash van het vorige. Op deze manier wordt integriteit bereikt: veranderingen kunnen alleen worden aangebracht door nieuwe blokken toe te voegen.
Dienst (service). Diensten binnen TON kunnen van verschillende typen zijn, afhankelijk van of er gebruik wordt gemaakt van blockchain of niet. Eén (of meerdere) netwerkknooppunten kunnen bijvoorbeeld bepaalde RPC-verzoeken verwerken met behulp van het hieronder beschreven ADNL-protocol, zonder dat er records in de blockchain worden aangemaakt, zoals traditionele webservers. Inclusief de mogelijkheid om HTTP over ADNL te implementeren, evenals de overgang van de messenger zelf naar dit protocol. Naar analogie met TOR of I2P zal dit het beter bestand maken tegen verschillende blokkeringen.
Tegelijkertijd omvat een aantal diensten zowel interactie met de blockchain als het verwerken van verzoeken daarbuiten. Voor TON Storage – bestandsopslag – is het bijvoorbeeld niet erg redelijk om de bestanden zelf op de blockchain op te slaan. Het zal alleen bestandshashes bevatten (samen met wat meta-informatie daarover), en gespecialiseerde netwerkknooppunten zullen fungeren als “bestandsservers”, klaar om ze via ADNL naar andere knooppunten te sturen.
Mist service (mist dienst). We hebben het over een aantal diensten die decentralisatie en open deelname daaraan impliceren. TON Proxy is bijvoorbeeld een dienst die kan worden ondersteund door elke deelnemer die zijn knooppunt wil aanbieden als intermediair (proxy) voor het doorsturen van pakketten tussen andere knooppunten. Desgewenst kan hij hiervoor een door hem vast te stellen vergoeding in rekening brengen – via het systeem van TON Payments voor microbetalingen (wat op zijn beurt ook een mistdienst is).
ADNL: abstracte datagramnetwerklaag
Op het laagste niveau zal de communicatie tussen knooppunten worden uitgevoerd met behulp van het UDP-protocol (hoewel andere opties acceptabel zijn).
Zoals hierboven vermeld, moet het ene knooppunt, voordat het een pakket naar het andere kan sturen, een van zijn publieke sleutels kennen (en dus het adres dat het definieert). Het codeert het pakket met deze sleutel en voegt het 256-bits bestemmingsadres toe aan het begin van het pakket. Omdat één knooppunt meerdere van deze adressen kan hebben, kan het knooppunt hierdoor bepalen welke sleutel moet worden gebruikt voor decodering.
Bovendien kan het begin van het datapakket in plaats van het adres van de ontvanger het zogenaamde. identificatie het kanaal. In dit geval is de verwerking van het pakket al afhankelijk van specifieke overeenkomsten tussen knooppunten - gegevens die naar een bepaald kanaal worden verzonden, kunnen bijvoorbeeld bedoeld zijn voor een ander knooppunt en moeten daarheen worden doorgestuurd (dit is de dienst TON-proxy). Een ander speciaal geval kan de directe interactie tussen knooppunten zijn, maar met codering met behulp van een individueel sleutelpaar voor dit kanaal (vooraf gegenereerd met behulp van het Diffie-Hellman-protocol).
Een speciaal geval tenslotte is het “nul”-kanaal: als een knooppunt de publieke sleutels van zijn “buren” nog niet kent, kan het hen pakketten sturen zonder enige codering. Dit is alleen bedoeld voor initialisatie - zodra de knooppunten informatie over hun sleutels verzenden, moeten ze worden gebruikt voor verdere communicatie.
Het hierboven beschreven protocol (256 bits kanaalidentificatie + pakketinhoud) wordt ADNL genoemd. De documentatie vermeldt de mogelijkheid om er een analoog van TCP bovenop te implementeren of een eigen add-on - RLDP (Reliable Large Datagram Protocol), maar gaat niet in op details over de implementatie ervan.
TON DHT: Gedistribueerde hashtabel
Zoals het geval is met andere gedistribueerde systemen, omvat TON de implementatie van DHT - . Meer specifiek, de tafel is . Als je niet bekend bent met dit soort hashtabellen, maak je geen zorgen, hieronder zal ik grofweg beschrijven hoe ze werken.
In abstracte zin wijst DHT 256-bit sleutels toe aan binaire waarden van willekeurige lengte. In dit geval zijn de sleutels in de tabel hashes van een bepaalde TL-structuur (de structuren zelf worden ook samen met de DHT opgeslagen). Dit lijkt sterk op de vorming van knooppuntadressen - en deze kunnen inderdaad aanwezig zijn in de DHT (door bijvoorbeeld een dergelijke sleutel te gebruiken wordt het IP-adres van een knooppunt dat overeenkomt met een gegeven abstract adres, als hij het niet verbergt). Maar in het algemene geval zullen “prototypes van sleutels” (hun beschrijvingen, sleutelbeschrijvingen) zijn metagegevens die de “eigenaar” van een item in een hashtabel aangeven (dat wil zeggen de publieke sleutel van een bepaald knooppunt), het type opgeslagen waarde en de regels waarmee dit item vervolgens kan worden gewijzigd. Een regel kan bijvoorbeeld alleen de eigenaar toestaan de waarde te wijzigen, of verbieden de waarde naar beneden te wijzigen (ter bescherming tegen replay-aanvallen).
Naast 256-bit sleutels wordt het concept van DHT-adressen geïntroduceerd. Het verschil met reguliere hostadressen is dat het DHT-adres noodzakelijkerwijs aan een IP-adres is gekoppeld. Als een knooppunt zijn IP-adres niet verbergt, kan het een normaal adres voor DHT gebruiken. Maar vaker zal er een apart, “semi-permanent” adres worden gecreëerd voor DHT-behoeften.
Het concept van afstand wordt geïntroduceerd boven de sleutels en DHT-adressen - hierin valt alles samen met de tabellen — de afstand tussen de sleutels is gelijk aan de XOR (bitwise exclusive OR) ervan. Net als in Kademlia-tabellen moet de waarde die overeenkomt met een bepaalde sleutel worden opgeslagen s knooppunten die de kortste afstand tot deze sleutel hebben (s hier is een relatief klein aantal).
Om ervoor te zorgen dat een DHT-knooppunt met andere soortgelijke knooppunten kan communiceren, wordt het in het geheugen bewaard DHT-routeringstabel — DHT- en IP-adressen van knooppunten waarmee het eerder interactie heeft gehad, gegroepeerd op afstand tot hen. Er zijn 256 van dergelijke groepen (ze komen overeen met de meest significante bit die is ingesteld in de afstandswaarde - dat wil zeggen dat knooppunten op een afstand van 0 tot 255 in de ene groep zullen vallen, van 256 tot 65535 - in de volgende, enz.). Binnen elke groep wordt een beperkt aantal “beste” knooppunten opgeslagen (in termen van ping ernaartoe).
Elk knooppunt moet verschillende bewerkingen ondersteunen: het opslaan van een waarde voor een sleutel, knooppunt zoeken и zoeken naar waarden. Het zoeken naar knooppunten houdt in dat op basis van een bepaalde sleutel de knooppunten die zich er het dichtst bij bevinden uit de routeringstabel worden uitgegeven; waarden opzoeken is hetzelfde, behalve wanneer het knooppunt de waarde voor de sleutel kent (dan retourneert het deze gewoon). Dienovereenkomstig, als een knooppunt een waarde per sleutel in de DHT wil vinden, stuurt het vanuit zijn routeringstabel verzoeken naar een klein aantal knooppunten die zich het dichtst bij deze sleutel bevinden. Als de vereiste waarde niet tussen hun antwoorden staat, maar er zijn andere knooppuntadressen, wordt het verzoek aan hen herhaald.
TON DHT kan voor verschillende doeleinden worden gebruikt, bijvoorbeeld om een torrent-achtige bestandsopslag te implementeren (zie. TON Opslag); om de adressen te bepalen van knooppunten die bepaalde diensten implementeren; om informatie over accounteigenaren op te slaan in de blockchain. Maar de belangrijkste toepassing is de ontdekking van knooppunten aan de hand van hun abstracte adressen. Om dit te doen, wordt het adres gebruikt als een sleutel waarvan de waarde moet worden gevonden. Als resultaat van het verzoek zal ofwel het knooppunt zelf worden gevonden (als het gezochte adres het semi-permanente DHT-adres was), ofwel zal de waarde het IP-adres en de poort voor verbinding zijn - of een ander adres dat als een tussentunnel.
Overlay-netwerken in TON
Het hierboven beschreven ADNL-protocol impliceert de mogelijkheid voor alle knooppunten om informatie met elkaar uit te wisselen - hoewel niet noodzakelijkerwijs op optimale manieren. We kunnen zeggen dat dankzij ADNL alle knooppunten een globale TON-grafiek vormen (idealiter verbonden). Maar het is bovendien mogelijk om overlay-netwerken te creëren: subgrafieken binnen deze grafiek.
Binnen een dergelijk netwerk vindt de interactie alleen rechtstreeks plaats - via vooraf gevormde verbindingen tussen knooppunten die aan het netwerk deelnemen (via de hierboven beschreven ADNL-kanalen). De vorming van dergelijke verbindingen tussen buren, het zoeken naar buren zelf, is een automatisch proces dat probeert de connectiviteit van het overlay-netwerk te behouden en vertragingen in de uitwisseling van gegevens daarin te minimaliseren.
Bovendien is er een manier om snel grote uitzendingsupdates binnen het netwerk te verspreiden: ze worden in stukjes gebroken, aangevuld met foutcorrectiecode, en al deze stukjes worden van de ene deelnemer naar de andere verzonden. De deelnemer hoeft dus niet alle onderdelen volledig te verkrijgen voordat hij deze verder over het netwerk verzendt.
Overlay-netwerken kunnen openbaar of privé zijn. Lid worden van een openbaar netwerk is niet moeilijk - je moet een TL-structuur vinden die het beschrijft (deze kan openbaar zijn of toegankelijk via een bepaalde sleutel in DHT). Bij een particulier netwerk moet deze structuur vooraf bekend zijn bij het knooppunt.
Wordt vervolgd
Ik besloot de TON-recensie op te splitsen in verschillende artikelen. Dit is waar dit deel eindigt, en Ik ga verder met het overwegen van de structuur van de blockchain (meer precies, blockchains) waaruit TON zal bestaan.
Bron: www.habr.com