A Runet immár két hete zajong a Telegramról és a helyzetről a Roszkomnadzor értelmetlen és könyörtelen blokkolásával. A ricochet sokakat megbántott, de ezek mind a Geektimes bejegyzéseinek témái. Máson is meglepődtem - még mindig nem láttam a Habrén egyetlen elemzést sem a Telegram - Telegram Open Network alapján tervezett TON hálózatról. Ezt a hiányosságot szerettem volna pótolni, mert van ott mit tanulni – még annak ellenére is, hogy erről nincs hivatalos nyilatkozat.
Hadd emlékeztesselek arra, hogy pletykák szerint a Telegram egy igen nagyszabású zárt ICO-t indított útjára, máris hihetetlen összegeket gyűjtött be benne. Feltételezik, hogy a Gram saját kriptovalutája még ebben az évben piacra kerül, és minden Telegram-felhasználónak automatikusan lesz pénztárcája, ami önmagában is jelentős előnyt jelent más kriptovalutákkal szemben.
Sajnos, mivel nincsenek hivatalos nyilatkozatok, csak abból tudok kiindulni amiről azonnal figyelmeztetlek. Persze kiderülhet, hogy egy nagyon ügyes hamisítvány, de az is lehet, hogy ez a leendő rendszer igazi whitepaperje, amit Nyikolaj Durov írt (és valószínűleg az egyik befektető szivárogtatta ki). De még ha ez hamisítvány is, senki nem fogja megtiltani, hogy tanulmányozzuk és megbeszéljük, igaz?
Mit mond ez a dokumentum? Megpróbálom újra elmondani a saját szavaimmal, közel a szöveghez, de oroszul és kicsit emberibben (Nikolaj bocsásson meg a formális matematikára való hajlamáért). Ne feledje, hogy még ha hiteles is, ez a rendszer leírásának vázlata, és nagy valószínűséggel megváltozik a nyilvános bevezetés idejére.
Megtudjuk, hogy a kriptovalutákon kívül még sok mindennek kell történnie. Vegyük sorba.
- TON Blockchain. Ez az egész rendszer alapja. Ha nem igazán tudod, mi az - Javaslom tájékozódni, mert sok blokklánc lesz itt. Beágyazott, gyakorlatilag töredezett, sőt „függőleges” blokkláncok más blokkláncok blokkjai között. Lesznek olyan jól hangzó kifejezések is, mint pl Azonnali Hypercube Routing и Végtelen felosztási paradigma, de erről később. És természetesen a tét igazolása és az okos szerződések.
- TON P2P hálózat. Peer-to-peer hálózat, amelyre a rendszer épül. A történetnek ebben a részében mindenekelőtt erről lesz szó.
- TON tárolás. Fájltároló, amely a blokklánctól függetlenül a fent említett peer-to-peer hálózatra épül. Összehasonlítható a torrentekkel.
- TON proxy. Ez egy olyan szolgáltatás, amelynek célja a hálózati résztvevők anonimitásának növelése. Bármely csomag nem közvetlenül, hanem közvetítő alagutakon keresztül továbbítható további titkosítással - például I2P vagy TOR.
- TON DHT. Elosztott hash tábla tetszőleges értékek tárolására. A tetejére is épül TON hálózat (de egyben ő is használja), és segít TON tárolás keresse meg az "elosztó" csomópontokat, és TON proxy - közbenső relék. De meg kell jegyezni, hogy a blokklánccal ellentétben ez a hash tábla nem biztonságos tároló - nem tárolhat fontos információkat.
- TON szolgáltatások. Platform tetszőleges szolgáltatásokhoz. Valójában ez egy új internet a fent leírtakon felül. Adatcsere - keresztül TON hálózat/TON proxy, és a logika az intelligens szerződésekben rejlik TON Blockchain. És egy felület elég ismerős URL-ekkel.
- TON DNS. Mivel a szokásos URL-ekről beszélünk, szükségünk van egy konvertálóra is ezekről 256 bites címekre - fiókokra, szerződésekre, szolgáltatásokra és csomópontokra.
- TON fizetések. És itt jön képbe a pénzkérdés. És nem csak gramm - az éterhez hasonlóan bármilyen "token" lehetséges lesz; A gramm itt csak az „alapértelmezett” pénznem lesz.
Ez az első rész, amely leírja a TON "földi" szintjét - hálózati részét, amely a hagyományos protokollokra épül. A következő részben a "pulpról" - a blokkláncról - lesz szó, amelyet az alább leírt rendszer támogat majd. Így az én újramondási sorrendem némileg eltér a fenti dokumentumban használttól (ami rögtön az absztrakt szinten kezdődik).
Alapfogalmak
TL (Típusnyelv). Ez egy absztrakt bináris formátum tetszőleges adatszerkezetekhez. A Telegram protokollban használatos, és a TON-ban is aktívan használni fogják. Ha többet szeretne megtudni róla - .
hash (hash). Olyan függvény, amely egy tetszőleges adatstruktúra visszafordíthatatlan átalakítását hajtja végre egyetlen, rögzített hosszúságú számmá. A dokumentációban sok szó esik a funkcióról .
Hálózati csomópont (csomópont). A csomópont az a szoftver, amely biztosítja a rendszer működését. Feltételezhető, hogy minden Telegram kliens alkalmazás tartalmazni fog egy TON csomópontot. Alacsony szinten a csomópontok IPv4/IPv6 címmel rendelkeznek, és az UDP protokoll használatával kommunikálnak, magasabb szinten pedig absztrakt címek és implementálja az ADNL protokollt (lásd alább az absztrakt címeket és az ADNL-t). Amikor arról van szó, hogy a rendszer egyes részei csinálnak valamit vagy tárolnak adatokat, akkor érthető, hogy ezt a hálózati csomópontok teszik meg.
Absztrakt cím (vagy egyszerűen cím, cím). Egy csomópont címét a nyilvános kulcsa határozza meg. Szigorúbban ez egy 256 bites hash (SHA256) egy nyilvános kulcsot tartalmazó adatszerkezetből (az adott kriptográfiai algoritmus ebben az esetben nincs megadva - példaként az elliptikus görbék és az RSA-2048 szerepel). Ahhoz, hogy az egyik csomópont kommunikálhasson a másikkal, nem csak az adott csomópont címét kell ismernie, hanem ezt az adatstruktúrát is. Elméletileg egy fizikai csomópont tetszőleges számú (különböző kulcsoknak megfelelő) címet hozhat létre.
Továbbá gyakran használnak egy ilyen köteget: egy „előképet” TL-struktúra formájában (amely szinte bármilyen adatot tartalmaz), és egy 256 bites hash-t a címzésre.
Blockchain (blockchain). A blokklánc egy adatstruktúra, elemek (blokkok) amelyek egy "láncba" vannak rendezve, és a lánc minden következő blokkja tartalmazza az előző hash-ét. Ily módon az integritás érhető el – változtatásokat csak új blokkok hozzáadásával lehet végrehajtani.
Szolgáltatás (szolgáltatás). A TON-on belüli szolgáltatások különféle típusúak lehetnek, attól függően, hogy használják-e a blokkláncot vagy sem. Például a hálózati csomópontok egyike (vagy több) képes feldolgozni néhány RPC-kérést az alább ismertetett ADNL-protokoll használatával anélkül, hogy rekordokat hozna létre a blokkláncban – a hagyományos webszerverekhez hasonlóan. Különösen a HTTP ADNL-en keresztüli megvalósításának lehetőségét fontolgatják, valamint magának a messengernek az átállását erre a protokollra. A TOR-hoz vagy az I2P-hez hasonlóan ez ellenállóbbá teszi a különféle blokkolásokkal szemben.
Ugyanakkor számos szolgáltatás magában foglalja a blokklánccal való interakciót és azon kívüli kérések feldolgozását. Például a TON Storage - fájltároló - esetében nem túl ésszerű magát a fájlokat a blokkláncon tárolni. Csak fájlkivonatokat fog tartalmazni (egyes metainformációkkal együtt), és a speciális hálózati csomópontok "fájlszerverként" működnek, készen arra, hogy ADNL-en keresztül átadják őket más csomópontoknak.
ködszerviz (ködszerviz). Néhány szolgáltatásról beszélünk, amelyek decentralizációt és az azokban való nyitott részvételt foglalják magukban. Például a TON Proxy egy olyan szolgáltatás, amelyet bármely résztvevő támogathat, aki közvetítőként (proxy) kívánja biztosítani a csomópontját, amely csomagokat továbbít más csomópontok között. Igény szerint erre az általa meghatározott díjat számíthat fel - a TON Payments rendszer segítségével mikrofizetésekhez (ami viszont szintén ködös szolgáltatás).
ADNL: Absztrakt Datagram hálózati réteg
A legalacsonyabb szinten a csomópontok közötti kommunikáció UDP-n keresztül történik (bár más lehetőségek is elfogadhatók).
Ahogy fentebb említettük, ahhoz, hogy az egyik csomópont csomagot küldhessen a másiknak, ismernie kell az egyik nyilvános kulcsát (és így az általa meghatározott címet). Ezzel a kulccsal titkosítja a csomagot, és egy 256 bites célcímet ad hozzá a csomag elejéhez - mivel egy csomópontnak több ilyen címe lehet, ez lehetővé teszi, hogy meghatározza, melyik kulcsot használja a visszafejtéshez.
Emellett az adatcsomag elején a címzett címe helyett ún. azonosító csatorna. Ebben az esetben a csomag feldolgozása már a csomópontok közötti konkrét megállapodásoktól függ - például egy bizonyos csatornára küldött adatok egy másik csomóponthoz rendelhetők és oda kell átirányítani (ez a szolgáltatás TON proxy). Egy másik speciális eset lehet a csomópontok közötti közvetlen interakció, de az ehhez a csatornához tartozó egyedi kulcspárt használó titkosítás (korábban a Diffie-Hellman protokoll segítségével).
Végül egy speciális eset a "null" csatorna - ha a csomópont még nem ismeri "szomszédai" nyilvános kulcsait, akkor titkosítás nélkül is küldhet nekik csomagokat. Ez csak inicializálásra szolgál – amint a csomópontok információt küldenek a kulcsaikról, azokat további interakcióhoz kell használni.
A fent leírt protokollt (256 bit csatornaazonosító + csomagtartalom) ADNL-nek hívják. A dokumentáció említi a TCP analógjának megvalósításának lehetőségét, vagy saját kiegészítőjét - RLDP-t (Reliable Large Datagram Protocol), de nem tér ki a megvalósítás részleteire.
TON DHT: Elosztott hash-tábla
Más elosztott rendszerekhez hasonlóan a TON is magában foglalja a DHT megvalósítását - . Pontosabban a táblázat az . Ha nem ismeri az ilyen hash táblákat, ne aggódjon, akkor leírom nagyjából, hogyan vannak elrendezve.
Absztrakt értelemben a DHT a 256 bites kulcsokat tetszőleges hosszúságú bináris értékekre képezi le. Ugyanakkor a táblázat kulcsai egy bizonyos TL-struktúrából származó hash-ek (magukat a struktúrákat is a DHT-vel együtt tároljuk). Ez nagyon hasonlít a csomóponti címek képzéséhez - és ezek valóban jelen lehetnek a DHT-ban (például egy ilyen kulcs tartalmazhatja az adott csomópont IP-címét absztrakt címha nem rejti el). De általános esetben a "kulcsok előképei" (a billentyűik leírások, kulcsfontosságú leírások) egy olyan metaadat, amely jelzi a hash táblában lévő bejegyzés „tulajdonosát” (vagyis valamely csomópont nyilvános kulcsát), a tárolt érték típusát és azokat a szabályokat, amelyekkel ez a bejegyzés később módosítható. Például egy szabály megengedheti, hogy csak a tulajdonos módosítsa az értéket – vagy tiltsa le az érték lefelé történő módosítását (az újrajátszási támadások elleni védelem érdekében).
A 256 bites kulcsok mellett bevezetik a DHT-címek fogalmát. A különbség a szokásos gazdagépcímekkel szemben az, hogy a DHT-cím egy IP-címhez van kötve. Ha egy csomópont nem rejti el az IP-címét, használhat normál címet a DHT-hoz. De gyakrabban külön, „félig állandó” cím jön létre a DHT igényeihez.
A kulcsok és a DHT-címek fölött megjelenik a távolság fogalma - ebben minden egybeesik a táblázatokkal - a kulcsok közötti távolság egyenlő az XOR-val (bitenkénti exkluzív VAGY) tőlük. A Kademlia táblákhoz hasonlóan a kulcsnak megfelelő értéket el kell tárolni s csomópontok, amelyek a legkisebb távolságra vannak ettől a kulcstól (s itt viszonylag kis szám).
Ahhoz, hogy egy DHT csomópont kommunikálhasson más ilyen csomópontokkal, a memóriában marad DHT útválasztó táblázat - Azon csomópontok DHT- és IP-címei, amelyekkel korábban kölcsönhatásba léptek, a hozzájuk való távolság szerint csoportosítva. 256 ilyen csoport van (ezek a távolságértékben beállított legjelentősebb bitnek felelnek meg - vagyis a 0 és 255 közötti távolságban lévő csomópontok az egyik csoportba, 256 és 65535 között a következőbe esnek, stb.). Az egyes csoportokon belül korlátozott számú "legjobb" csomópont van tárolva (a rájuk küldött ping szempontjából).
Minden csomópontnak több műveletet is támogatnia kell: egy kulcs értékének tárolása, csomópont keresés и értékek keresése. A csomópontok keresése magában foglalja a hozzá legközelebbi csomópontok adott kulcs általi kiadását az útválasztási táblából; Az értékek keresése ugyanaz, kivéve, ha a csomópont ismeri a kulcs értékét (ebben az esetben egyszerűen visszaadja). Ennek megfelelően, ha egy csomópont egy kulcs segítségével szeretne értéket találni a DHT-ban, akkor kéréseket küld a kulcshoz legközelebbi csomópontok számára az útválasztási táblájából. Ha a válaszaik között nincs kívánt érték, de vannak más csomópontok címei, akkor a kérés megismétlődik nekik.
A TON DHT különféle célokra használható, például torrentszerű fájltárolás megvalósítására (lásd. TON tárolás); bizonyos szolgáltatásokat megvalósító csomópontok címének meghatározása; a számlatulajdonosok információinak tárolására a blokkláncban. De a legfontosabb alkalmazás a csomópontok felfedezése absztrakt címeik alapján. Ehhez a címet kulcsként használjuk, melynek értéke megkeresendő. A lekérdezés eredménye vagy maga a csomópont lesz (ha a keresett cím annak félig állandó DHT-címe volt), vagy az érték lesz az IP-cím és a port, amelyhez csatlakozni kell - vagy egy másik cím, amelyet közbenső alagút.
Átfedő hálózatok TON-ban
A fent leírt ADNL-protokoll azt jelenti, hogy bármely csomópont képes információt cserélni egymással – bár nem feltétlenül optimális módon. Elmondhatjuk, hogy az ADNL-nek köszönhetően minden csomópont egy globális TON gráfot alkot (ideális esetben összekapcsolt). De emellett lehetőség van átfedő hálózatok - részgráfok létrehozására a grafikonon belül.
Egy ilyen hálózaton belül az interakció csak közvetlenül - a hálózati tag csomópontok közötti előre kialakított kapcsolatokon keresztül (a fent leírt ADNL csatornákon keresztül) valósul meg. Az ilyen kapcsolatok kialakítása a szomszédok között, maguknak a szomszédoknak a keresése egy automatikus folyamat, amely az átfedő hálózat összekapcsolhatóságát igyekszik fenntartani, és minimalizálni az adatcsere késedelmeit.
Ezenkívül lehetőség van a nagy sugárzott frissítések gyors elosztására a hálózaton belül - részekre bontják, hibajavító kóddal egészítik ki, és ezeket a részeket egyik résztvevőtől a másikhoz küldik. Így a résztvevőnek nem kell teljes mértékben megkapnia az összes részt, mielőtt továbbküldi azokat a hálózaton.
Az átfedő hálózatok lehetnek nyilvánosak vagy privátak. Nyilvános hálózat tagjává válni nem nehéz - meg kell találni egy TL struktúrát, amely leírja (lehet nyilvános - vagy elérhető egy bizonyos kulccsal a DHT-ban). Privát hálózat esetén ezt a struktúrát a csomópontnak előre ismernie kell.
Ahhoz, hogy továbbra is
Úgy döntöttem, hogy a TON áttekintést több cikkre osztom. Itt ér véget ez a szakasz, Rátérek annak a blokkláncnak (pontosabban a blokkláncoknak) a felépítésére, amelyből a TON fog állni.
Forrás: will.com