Már két hete zörög az orosz internet a Telegram és az Oroszországi Távközlési Felügyelet általi értelmetlen és könyörtelen blokkolásával kapcsolatban. Sokakat érintett a dolog, de ezek mind Geektimes posztok témái. Engem viszont más dolog lepte meg - eddig még egyetlen elemzést sem láttam a Habr-on a Telegram alapú TON - Telegram Open Network várható megjelenéséről. Szeretném pótolni ezt a hiányosságot, mert van mit tanulmányozni - még ha az igazán hivatalos nyilatkozatok hiányzanak is.
Emlékeztetnék - pletykák szerint a Telegram nagyon nagy léptékű zárt ICO-t indított, és már elképesztő összegeket gyűjtött össze benne. Feltételezzük, hogy idén elindul a saját kriptovalutája, a Gram - és minden Telegram felhasználónak automatikusan lesz egy pénztárcája, ami önmagában is jelentős előny a többi kriptovalutával szemben.
Sajnos, mivel nincsenek hivatalos nyilatkozatok, csak a , amiről azonnal figyelmeztetlek. Természetesen lehet, hogy ez egy nagyon ügyes hamisítvány, de az sem kizárt, hogy egy valós whitepaper a jövő rendszeréről, amelyet Nikolai Durov írt (és valószínűleg egy befektető juttatott el hozzánk). De még ha hamis is, senki sem tilthatja meg, hogy tanulmányozzuk és megbeszéljük, igaz?
Mit is mond ez a dokumentum? Megpróbálom a saját szavaimmal, a szöveghez közel, de magyarul és egy kicsit emberibben (bocsáss meg, Nikolai, hogy hajlamos vagy a formai matematikára). Ne feledjétek, hogy még ha az eredeti is, ez a rendszer vázlatos leírása, és valószínűleg változni fog a nyilvános indulásra.
Megtudjuk, hogy a kriptovaluta mellett még nagyon-nagyon sok minden vár ránk. Nézzük sorjában.
- TON Blockchain. Ez a rendszer alapja. Ha egyáltalán nem tudod, mi az a , ajánlom, hogy nézd meg, mert itt sok blokklánc fog szerepelni. Egymásba ágyazott, virtuálisan darabolt, sőt más blokkláncok blokkjain belüli "vertikális" blokkláncok. Ráadásul itt lesznek olyan menő kifejezések, mint az Instant Hypercube Routing és Infinite Sharding Paradigm, de erről később. És természetesen proof-of-stake és okos szerződések.
- TON P2P Network. A peer-to-peer network on which the system will operate. This will be discussed first in this part of the narrative.
- TON Storage. A file storage system that will be built on the aforementioned peer-to-peer network, independent of the blockchain. It can be compared to torrents.
- TON Proxy. This is a service aimed at increasing the anonymity of network participants. Any packet can be sent not directly, but through intermediary tunnels with additional encryption—similar to I2P or TOR.
- TON DHT. A distributed hash table for storing arbitrary values. It is also built on top of TON Network (while using it) and helps TON Storage find 'distributing' nodes and TON Proxy —intermediate relays. However, it should be noted that, unlike the blockchain, this hash table is not a secure storage—important information should not be stored in it.
- TON Services. A platform for arbitrary services. Essentially, this is a new internet built on top of everything described above. Data exchange is through TON Network/TON Proxy, and the logic is in the smart contracts of TON Blockchain. And the interface with quite familiar URLs.
- TON DNS. Since we've mentioned familiar URLs, a converter from them to 256-bit addresses for accounts, contracts, services, and nodes is also needed.
- TON Payments. Here we touch upon the financial aspect. It will not be restricted to only gram —just like with Ether, any 'tokens' will be possible; grams here will merely serve as the 'default' currency.
This is the first part, describing the 'grounded' level of TON—the network part that is being built on top of traditional protocols. The next part will discuss the 'core'—the blockchain that will be supported by the system described below. Thus, my order of narration differs somewhat from that used in the aforementioned document (which starts immediately with the abstract level).
Basic Concepts
TL (Type Language). This is an abstract binary format for arbitrary data structures. It is used in the Telegram protocol and will be actively utilized in TON. If you want to familiarize yourself with it in detail— .
Hash (hash). A function that performs an irreversible transformation of an arbitrary data structure into a single fixed-length number. The documentation frequently mentions the function .
Network Node (node). A csomópont egy olyan szoftver, amely a rendszer működését biztosítja. Különösen feltételezhető, hogy minden Telegram kliensalkalmazás tartalmazni fog egy TON csomópontot. Alacsony szinten a csomópontok IPv4/IPv6 címmel rendelkeznek és UDP protokollon keresztül kommunikálnak, magasabb szinten pedig rendelkeznek absztrakt címekkel és megvalósítják az ADNL protokollt (az absztrakt címekről és az ADNL-ről – lásd lent). Amikor arról van szó, hogy a rendszer bizonyos részei valamit csinálnak vagy adatokat tárolnak – ez azt jelenti, hogy ezt a hálózat csomópontjai végzik.
Absztrakt cím (vagy egyszerűen csak cím, address). A csomópont címe a nyilvános kulcsával van meghatározva. Szigorúbb értelemben ez egy 256-bites hash (SHA256) az adatstruktúráról, amely a nyilvános kulcsot tartalmazza (a konkrét kriptográfiai algoritmust nem pontosítják – példaként említhetők az elliptikus görbék és az RSA-2048). Ahhoz, hogy egy csomópont kapcsolatba léphessen egy másikkal, nemcsak annak a címét kell ismernie, hanem ezt az adatstruktúrát is. Elméletileg egy fizikai csomópont bármennyi címet létrehozhat (különböző kulcsokhoz tartozóan).
Gyakran használják ezt a kombinációt: a TL-structúra „előképeként” (mely szinte bármilyen adatot tartalmaz), és annak 256-bites hash-je, amely címezésre használható.
Blokklánc (blockchain). A blokklánc egy adatstruktúra, amelynek elemei (blokkok) láncban vannak rendezve, és minden egyes következő blokk tartalmazza az előző blokk hash-jét. Így biztosítható az integritás – a változtatások csak új blokkok hozzáadásával végezhetők el.
Szolgáltatás (a SystemD inicializálási rendszer számára:). A TON keretein belül a szolgáltatások különböző típusúak lehetnek – attól függően, hogy használják-e a blokkláncot vagy sem. Például egy (vagy több) a hálózat csomópontjai közül feldolgozhat bizonyos RPC-kéréseket a későbbiekben leírt ADNL protokoll szerint, anélkül, hogy bármilyen bejegyzést készítenének a blokkláncban – hasonlóan a hagyományos webkiszolgálókhoz. A HTTP ADNL fölötti megvalósításának lehetősége is felmerül, valamint a maga üzenetküldő átkapcsolása erre a protokollra. A TOR-hoz vagy I2P-hez hasonlóan ez növeli a különböző blokkolásokkal szembeni ellenállóságát.
Eközben számos szolgáltatás magában foglalja a blokklánccal való interakciót és a blokkláncotól független kérések feldolgozását. Például a TON Storage esetében — fájl tárolóra — nem igazán ésszerű az összes fájlt a blokkláncon tárolni. Csak a fájlok hash-ét (valamint a hozzájuk tartozó metaadatokat) tárolják a blokkláncon, míg a fájlok „fájl kiszolgálóiként” specializált csomópontok szolgálnak a hálózaton, amelyek készen állnak arra, hogy más csomópontok számára szolgáltassák azokat ADNL-en keresztül.
Köd szolgáltatás (köd szolgáltatás). Arról van szó, hogy bizonyos szolgáltatások decentralizációt és nyílt részvételt feltételeznek. Például a TON Proxy egy olyan szolgáltatás, amelyet bármely résztvevő támogathat, aki hajlandó a saját csomópontját közvetítő (proxy) csomópontként működtetni, amely csomagokat továbbít más csomópontok között. Szándék szerint díjat kérhet érte — a TON Payments rendszer használatával mikrofizetésekhez (amely szintén köd szolgáltatás).
ADNL: Absztrakt Datagram Hálózati Réteg
A legalsó szinten a csomópontok közötti kommunikáció UDP protokollon keresztül fog megtörténni (bár más lehetőségek is megengedettek).
Ahogy korábban említettük, ahhoz, hogy egy csomópont csomagot tudjon küldeni egy másiknak, ismernie kell annak egy nyilvános kulcsát (és ezáltal a címét, amelyet ez meghatároz). A csomagot ezzel a kulccsal titkosítja, és a csomag elejére hozzáad egy 256 bites címzett címet — mivel egy csomópontnak több ilyen címe is lehet, ez lehetővé teszi számára, hogy meghatározza, melyik kulcsot használja a dekódolásra.
Ezen kívül a címzett címe helyett a csomag elején elhelyezhető a úgynevezett azonosító csatorna. Ilyen esetben a csomag feldolgozása már a csomópontok közötti konkrét megállapodásoktól függ — például a bizonyos csatornába küldött adatok másik csomópontnak szólhatnak, és neki kell őket továbbítani (ez a szolgáltatás TON Proxy). Egy másik speciális eset lehet a közvetlen csomópontok közötti interakció, de a csatorna egyedi kulcspárral történő titkosításával (a Diffie-Hellman protokoll alapján előre létrehozva).
Végül, egy különleges eset a „nullás” csatorna - ha a csomópont még nem ismeri „szomszédai” nyilvános kulcsait, akkor elküldhet nekik titkosítatlan csomagokat. Ez kizárólag inicializálásra szolgál - amint a csomópontok információt küldenek kulcsaikról, azokat a további kommunikációhoz fel kell használni.
A fent leírt protokoll (256 bites csatornaazonosító + csomag tartalma) ADNL néven ismert. A dokumentáció említi egy TCP analóg megvalósításának lehetőségét rajta, vagy saját kiegészítésének - RLDP (Reliable Large Datagram Protocol), de nem tér ki a megvalósításuk részleteire.
TON DHT: Elosztott hash-tábla
Mint más elosztott rendszerek esetében, a TON is DHT megvalósítást feltételez - . Konkrétabban - a tábla . Ha nem ismerős e hash-táblák egy típusa - ne aggódj, később körülbelül leírom, hogyan működnek.
Absztrakt értelemben a DHT 256 bites kulcsokhoz bizonyos bináris, tetszőleges hosszúságú értékeket rendel. E kulcsok a táblában a megadott TL-struktúrákból származó hash-ek (maguk a struktúrák is a DHT-val együtt tárolódnak). Ez nagyon hasonlít a csomópontok címzésére - és valóban megjelenhetnek a DHT-ben (például egy ilyen kulcs alapján a csomópont IP-címe található a megadott absztrakt címhez, ha azt nem rejti el). De általános esetben a „kulcsok prototípusa” (azok leírásai, kulcs leírások) - ezek olyan metainformációk, amelyek a hash-táblában a bejegyzés „tulajdonosára” mutatnak (vagyis egy csomópont nyilvános kulcsa), a tárolt érték típusára és a szabályokra, amelyek alapján ez a bejegyzés később módosítható. Például egy szabály engedheti a tulajdonosnak, hogy módosítson csak a saját értékén - vagy megtilthatja az érték csökkentését (a replay-támadások ellen védekezve).
A 256 bites kulcsok mellett bevezetésre kerül a DHT-cím fogalma. Az eltérés a szokásos csomóponti címektől abban rejlik, hogy a DHT-cím kötelezően kötődik egy IP-címhez. Ha a csomópont nem rejti el az IP-jét, akkor használhatja a szokásos címet a DHT-hoz. De gyakrabban a DHT céljaira hoznak létre külön „fél-állandó” címet.
A kulcsok és a DHT-címek felett bevezetésre kerül a távolság fogalma - ez mindenben megegyezik a — a kulcsok közötti távolság az XOR (bitenkénti kizáró vagy) értékük. Hasonlóan a Kademlia táblákhoz, a kulcshoz tartozó értéket a s legkisebb távolsággal rendelkező csomópontokon kell tárolni (s ez itt egy viszonylag kis szám).
Ahhoz, hogy a DHT csomópont más ilyen csomópontokkal kapcsolatba léphessen, memóriában tartja a DHT útválasztó táblát — a DHT- és IP-címeket azokról a csomópontokról, amelyekkel eddig interakcióba lépett, távolság szerint csoportosítva. Összesen 256 ilyen csoport van (ezek megfelelnek a távolság legmagasabb beállított bitének — tehát a 0-tól 255-ig terjedő távolságú csomópontok egy csoportba, 256-tól 65535-ig a következőbe stb. kerülnek). Minden csoporton belül korlátozott számú „legjobb” csomópont tárolódik (a ping szempontjából).
Minden csomópontnak több műveletet kell támogatnia: érték tárolása a kulcshoz, csomópontok keresése és értékek keresése. A csomópontok keresése azt jelenti, hogy a megadott kulcs alapján a legközelebbi csomópontokat adják vissza az útválasztó táblából; az értékek keresése ugyanez, kivéve, ha a csomópont tudja a kulcs értékét (ebben az esetben egyszerűen visszaadja azt). Ennek megfelelően, ha a csomópont DHT-ban szeretne egy értéket találni a kulcshoz, akkor néhány legközelebbi csomópontot kérdez meg az útválasztó táblájából. Ha a válaszok között nincs keresett érték, de vannak más csomópontok címei, akkor a keresést már ezekhez irányítja.
A TON DHT különböző célokra használható, például fájlok torrent-szerű tárolásának megvalósítására (lásd: TON Storage); a csomópontok címeinek meghatározására, amelyek bizonyos szolgáltatásokat nyújtanak; a blokkláncon lévő fióktulajdonosok információinak tárolására. De a legfontosabb alkalmazás az, hogy a csomópontokat absztrakt címeik alapján fedezzük fel. Ehhez a cím kulcsként szolgál, amelynek az értékét meg kell találni. A lekérdezés eredményeként vagy magát a csomópontot találjuk meg (ha a keresett cím a félig állandó DHT-címe volt), vagy az érték egy IP-cím és port a kapcsolódáshoz — vagy egy másik cím, amelyet közvetítő alagutként kell használni.
A TON fölé épített hálózatok
A fent említett ADNL protokoll lehetővé teszi, hogy bármely csomópont információt cseréljen egymással — igaz, nem feltétlenül optimális utakon. Mondhatjuk, hogy az ADNL segítségével minden csomópont globális TON gráfot alkot (ideálisan — összefüggőt). De emellett egy átjáró hálózatok — algráfok létrehozásának lehetősége is rendelkezésre áll ezen gráfon belül.
Ilyen hálózaton belül a kölcsönhatások csak közvetlenül történnek — előre kialakított kapcsolatok alapján a csomópontok résztvevői között (az előbb említett ADNL csatornákon keresztül). Az ilyen kapcsolatok képezése a szomszédok között, valamint a szomszédok keresése — automatikus folyamat, amely arra törekszik, hogy megőrizze az átjáró hálózat összefüggőségét és minimalizálja a késleltetéseket az adatcserében.
Ezen kívül van egy módja a nagy méretű széleskörű frissítések gyors terjesztésére a hálózaton belül — ezek darabokra vannak osztva, hibajavító kóddal vannak kiegészítve, és mindezeket a részeket egyik résztvevőtől a másikig továbbítják. Így a résztvevőnek nem szükséges teljesen megkapnia az összes részt, mielőtt továbbítaná őket a hálózaton.
Az átjáró hálózatok lehetnek nyilvánosak és privátok. Nyilvános hálózatra csatlakozni nem nehéz — meg kell találni a TL-struktúrát, amely leírja azt (ez nyilvános lehet — vagy egy bizonyos kulccsal hozzáférhető a DHT-n). Privát hálózat esetén ez a struktúra előre ismert kell, hogy legyen a csomópont számára.
Folytatás következik
Úgy döntöttem, hogy a TON áttekintését több cikkre osztom. Ezzel a rész zárul, és a blokklánc (pontosabban a blokkláncok) felépítésének vizsgálatára lépek, amelyekből a TON állni fog.
Forrás: habr.com
