Ez a szöveg annak a cikksorozatnak a folytatása, amelyben az idei megjelenésre készülő (vélhetően) elosztott hálózat Telegram Open Network (TON) felépítését vizsgálom. BAN BEN Leírtam a legalapvetőbb szintjét - azt, ahogyan a csomópontok kölcsönhatásba lépnek egymással.
Minden esetre hadd emlékeztesselek arra, hogy semmi közöm ennek a hálózatnak a fejlesztéséhez, és az összes anyagot nyílt (bár ellenőrizetlen) forrásból szedtem össze. (Van egy kísérő is , röviden felvázolva a főbb pontokat), amely tavaly év végén jelent meg. A dokumentumban található információ mennyisége véleményem szerint a hitelességét jelzi, bár erre nincs hivatalos megerősítés.
Ma megvizsgáljuk a TON fő összetevőjét - a blokkláncot.
Alapfogalmak
Account (fiók). 256 bites számmal azonosított adathalmaz felhasználónév (leggyakrabban ez a fióktulajdonos nyilvános kulcsa). Alapesetben (lásd lent nulla munkalánc), ezek az adatok a felhasználó egyenlegére vonatkoznak. "Foglalni" konkrét felhasználónév bárki megteheti, de értéke csak bizonyos szabályok szerint változtatható.
Okos szerződés (okos-szerződés). Lényegében egy fiók speciális esetéről van szó, kiegészítve intelligens szerződéskóddal és változóinak tárolásával. Ha egy „pénztárcánál” viszonylag egyszerű és előre meghatározott szabályok szerint lehet pénzt be- és kivenni belőle, akkor egy intelligens szerződés esetén ezek a szabályok a kódja formájában vannak megírva (egy bizonyos Turing-komplettben programozási nyelv).
Blockchain állam (blokklánc állapota). Az összes számla/intelligens szerződés állapotainak halmaza (absztrakt értelemben egy hash tábla, ahol a kulcsok számlaazonosítók, az értékek pedig a számlákban tárolt adatok).
üzenet (üzenet). Fent használtam a „hitel és betéti pénz” kifejezést – ez egy sajátos példa egy üzenetre („átutalás N gramm fiókból account_1 tart valaminek, tekint valaminek account_2"). Nyilvánvaló, hogy csak az a csomópont, amelyik rendelkezik a fiók privát kulcsával, küldhet ilyen üzenetet account_1 - és ezt aláírásával tudja megerősíteni. Az ilyen üzenetek normál számlára történő kézbesítésének eredménye annak egyenlegének növekedése, az intelligens szerződés eredménye pedig a kódjának végrehajtása (amely feldolgozza az üzenet fogadását). Természetesen más üzenetek is lehetségesek (nem pénzösszeg, hanem tetszőleges adatok átvitele okosszerződések között).
Tranzakció (tranzakció). Az üzenet kézbesítésének tényét tranzakciónak nevezzük. A tranzakciók megváltoztatják a blokklánc állapotát. A tranzakciók (üzenetkézbesítési rekordok) alkotják a blokkokat a blokkláncban. Ebben a tekintetben a blokklánc állapotát növekményes adatbázisnak tekintheti - minden blokk „diff”, amelyeket szekvenciálisan kell alkalmazni, hogy megkapjuk az adatbázis aktuális állapotát. Ezen „diffek” csomagolásának (és a teljes állapot visszaállításának) sajátosságairól a következő cikkben lesz szó.
Blockchain a TON-ban: mi ez és miért?
Ahogy az előző cikkben említettük, A blokklánc olyan adatstruktúra, amelynek elemei (blokkjai) egy „láncba” vannak rendezve, és a lánc minden következő blokkja tartalmazza az előző hash-ét.. A kommentek feltették a kérdést: miért van egyáltalán szükségünk ilyen adatszerkezetre, amikor már van DHT - elosztott hash tábla? Nyilvánvalóan néhány adat tárolható a DHT-ban, de ez csak nem túl „érzékeny” információkra alkalmas. A kriptovaluta egyenlegeket nem lehet DHT-ban tárolni – elsősorban az ellenőrzések hiánya miatt sértetlenség. Valójában a blokklánc szerkezetének teljes összetettsége nő annak érdekében, hogy megakadályozzák a benne tárolt adatokkal való interferenciát.
A TON blokklánca azonban még bonyolultabbnak tűnik, mint a legtöbb más elosztott rendszerben – és ennek két oka van. Az első a szükségesség minimalizálásának vágya villák. A hagyományos kriptovalutákban minden paramétert a kezdeti szakaszban állítanak be, és minden változtatási kísérlet valójában egy „alternatív kriptovaluta univerzum” kialakulásához vezet. A második ok a zúzás támogatása (szilánkos, szilánkos) blokklánc. A blokklánc olyan struktúra, amely idővel nem lehet kisebb; és általában minden, a hálózat működéséért felelős csomópont kénytelen azt teljes mértékben tárolni. A hagyományos (centralizált) rendszerekben az ilyen problémák megoldására a shardingot használják: az adatbázis rekordjainak egy része az egyik szerveren, egy része a másikon stb. A kriptovaluták esetében az ilyen funkcionalitás még mindig meglehetősen ritka – különösen amiatt, hogy nehéz shardingot hozzáadni egy olyan rendszerhez, ahol azt eredetileg nem tervezték.
Hogyan tervezi a TON mindkét fenti probléma megoldását?
Blockchain tartalom. Munkaláncok.
Először is beszéljünk arról, hogy mit tervezünk a blokkláncban tárolni. A számlák (alapesetben „pénztárcák”) és az intelligens szerződések állapotai ott lesznek tárolva (az egyszerűség kedvéért feltételezzük, hogy ez megegyezik a számlákkal). Lényegében ez egy normál hash tábla lesz - a benne lévő kulcsok azonosítók lesznek felhasználónév, és az értékek olyan adatstruktúrák, amelyek például:
- egyensúly;
- intelligens szerződés kódja (csak intelligens szerződéseknél);
- intelligens szerződéses adattárolás (csak intelligens szerződésekhez);
- statisztika;
- (választható) nyilvános kulcs a számláról történő átutaláshoz, alapértelmezés szerint account_id;
- a kimenő üzenetek sora (itt a címzettnek történő továbbításhoz kerülnek be);
- az ehhez a fiókhoz eljuttatott legutóbbi üzenetek listája.
Amint fentebb említettük, maguk a blokkok tranzakciókból állnak – különböző account_id számlákhoz eljuttatott üzenetekből. Az account_id mellett azonban az üzenetek 32 bites mezőt is tartalmaznak workchain_id — úgynevezett azonosító munkalánc (munkalánc, működő blokklánc). Ez lehetővé teszi több, egymástól független blokklánc létrehozását, különböző konfigurációkkal. Ebben az esetben a workchain_id = 0 speciális esetnek számít, nulla munkalánc — a benne lévő egyenlegek fognak megfelelni a TON (gramm) kriptovalutának. Valószínűleg eleinte más munkaláncok egyáltalán nem fognak létezni.
Szilánkláncok. Végtelen felosztási paradigma.
A blokkláncok számának növekedése azonban nem áll meg itt. Foglalkozzunk a szaggatással. Képzeljük el, hogy minden fiókhoz (account_id) hozzá van rendelve a saját blokklánca - ez tartalmazza az összes hozzá érkező üzenetet -, és az összes ilyen blokklánc állapotát külön csomópontokon tárolják.
Természetesen ez nagyon pazarló: valószínűleg mindegyikben szilánkláncok (szilánklánc, szilánkos blokklánc) tranzakciók nagyon ritkán érkeznek, és sok erős csomópontra lesz szükség (előre tekintve megjegyzem, nem csak mobiltelefonos kliensekről beszélünk - hanem komoly szerverekről).
Ezért a shardchain a fiókokat az azonosítóik bináris előtagjaival kombinálja: ha egy shardchain előtagja 0110, akkor az összes fiókazonosító tranzakcióit tartalmazza, amelyek ezekkel a számokkal kezdődnek. Ez shard_prefix 0 és 60 bit közötti hosszúságú lehet - és a lényeg az, hogy dinamikusan tud változni.
Amint az egyik szilánklánc túl sok tranzakciót kezd kapni, a rajta dolgozó csomópontok előre meghatározott szabályok szerint „felosztják” két gyermekre - az előtagjaik egy kicsit hosszabbak lesznek (és az egyiknél ez a bit egyenlő 0, a másik pedig 1). Például, shard_prefix = 0110b részre oszlik 01100b és 01101b. Ha viszont két „szomszédos” szilánklánc (egy ideig) elég nyugodtnak érzi magát, akkor újra összeolvadnak.
Így a szilánkolás „alulról felfelé” történik - feltételezzük, hogy minden fióknak megvan a maga szilánkja, de egyelőre előtagokkal vannak „összeragasztva”. Ezt jelenti Végtelen felosztási paradigma (végtelen felosztási paradigma).
Külön szeretném hangsúlyozni, hogy a munkaláncok csak virtuálisan léteznek - sőt, workchain_id egy adott szilánklánc azonosítójának része. Formális értelemben minden szilánkláncot egy számpár határoz meg (workchain_id, shard_prefix).
Hibajavítás. Függőleges blokkláncok.
Hagyományosan a blokkláncon végrehajtott bármely tranzakció „kőbe vésettnek” minősül. A TON esetében azonban lehetőség van „történelem átírására” – hátha valaki (az ún. halász csomó) bizonyítja, hogy az egyik blokkot hibásan írták alá. Ebben az esetben egy speciális korrekciós blokk kerül hozzáadásra a megfelelő shardchainhez, amely magának a javítandó blokknak a hash-jét tartalmazza (és nem a shardchain utolsó blokkját). Ha a szilánkláncot vízszintesen elhelyezett blokkok láncának tekintjük, akkor azt mondhatjuk, hogy a javító blokk nem jobbról, hanem felülről csatlakozik a hibás blokkhoz - tehát úgy tekintjük, hogy egy kis „függőleges blokklánc” részévé válik. . Így azt mondhatjuk, hogy a szilánkláncok azok kétdimenziós blokkláncok.
Ha egy hibás blokk után az általa végrehajtott változtatásokra a következő blokkok hivatkoztak (vagyis új tranzakciók történtek érvénytelenek alapján), akkor ezekhez a blokkokhoz „felül” is bekerülnek a javító tranzakciók. Ha a blokkok nem befolyásolták az „érintett” információt, ezek a „korrekciós hullámok” nem vonatkoznak rájuk. Például a fenti ábrán az első blokk, a C számla egyenlegét növelő tranzakciója hibásnak lett felismerve - ezért a harmadik blokkban a számla egyenlegét csökkentő tranzakciót is törölni kell, és javítani kell magán a blokkon kell végrehajtani.
Meg kell jegyezni, hogy bár a korrekciós blokkok az eredeti blokkok „felett” vannak ábrázolva, valójában a megfelelő blokklánc végére kerülnek (ahol időrendi sorrendben kell lenniük). A kétdimenziós hely csak azt mutatja meg, hogy a blokklánc melyik pontjához lesznek „kapcsolva” (a bennük található eredeti blokk hashén keresztül).
Külön filozofálhatsz arról, hogy milyen jó döntés a „múlt megváltoztatása”. Úgy tűnik, hogy ha elismerjük egy helytelen blokk megjelenésének lehetőségét a szilánkláncban, akkor nem kerülhetjük el a hibás korrekciós blokk megjelenésének lehetőségét. Itt, amennyire meg tudom ítélni, a különbség azon csomópontok számában van, amelyeknek konszenzusra kell jutniuk az új blokkokkal kapcsolatban – viszonylag kevés ember dolgozik majd minden egyes szilánkláncon."munkacsoport» csomópontok (amely meglehetősen gyakran változtatja összetételét), és a korrekciós blokkok bevezetéséhez mindenki beleegyezése szükséges érvényesítő csomópontok. Az érvényesítőkről, munkacsoportokról és egyéb csomóponti szerepkörökről a következő cikkben fogok többet beszélni.
Egy blokklánc, amely mindegyiket uralja
Rengeteg információ található fent a különböző típusú blokkláncokról, amelyeket magát is el kell tárolni valahol. Különösen a következő információkról beszélünk:
- a munkaláncok számáról és konfigurációjáról;
- a szilánkláncok számáról és előtagjaikról;
- arról, hogy mely csomópontok jelenleg melyik szilánkláncokért felelősek;
- az összes shardchainhez hozzáadott utolsó blokkok hash-ei.
Ahogy azt sejteni lehetett, mindezek a dolgok egy másik blokklánc tárolóban vannak rögzítve - mesterlánc (mesterlánc, mester blokklánc). A blokkjaiban lévő összes shardchain blokkjából származó hashek jelenléte miatt a rendszert erősen összekapcsolttá teszi. Ez többek között azt jelenti, hogy egy új blokk generálása a mesterláncban azonnal megtörténik a shardchain blokkok generálása után - várhatóan a shardchain blokkjai szinte egyszerre jelennek meg körülbelül 5 másodpercenként, és a következő blokk a shardchainben. masterchain – egy másodperccel ezután.
De ki lesz a felelős ennek a titáni munkának a megvalósításáért - az üzenetek küldéséért, az intelligens szerződések végrehajtásáért, a shardchain-ben és a masterchain-ben blokkok kialakításáért, sőt a blokkok hibáinak ellenőrzéséért is? Vajon mindezt titokban több millió felhasználó telefonja fogja megtenni, amelyekre telepítve van a Telegram kliens? Vagy talán a Durov-csapat felhagy a decentralizáció gondolatával, és a szervereik a régimódi módon teszik ezt?
Valójában sem az egyik, sem a másik válasz nem helyes. De ennek a cikknek a margója gyorsan elfogy, ezért a csomópontok különféle szerepeiről (lehet, hogy már észrevett néhány említést), valamint munkájuk mechanikájáról a következő részben fogunk beszélni.
Forrás: will.com