Ez a szöveg a Telegram Open Network (TON) várhatóan idén megjelenő elosztott hálózatáról szóló cikkek sorozatának folytatása. Leírtam az alapvető szintjét — a csomópontok közötti interakció módját.
Csak emlékeztetőül, a hálózat fejlesztéséhez nincs közöm, és az anyag teljes mértékben nyílt (bár nem ellenőrzött) forrásból származik — (tartozik hozzá egy , amely röviden összefoglalja a lényeges pontokat), amely tavaly év végén jelent meg. Az információ mennyisége a dokumentumban véleményem szerint a hitelességét jelzi, bár hivatalos megerősítések nincsenek erről.
Ma a TON fő összetevőjére, a blokkláncra fogunk nézni.
Basic Concepts
Fiók (account). Egy adatcsomag, amelyet egy 256 bites szám azonosít, account_id (többnyire ez a fiók tulajdonosának nyilvános kulcsa). Az alapvető esetben (lásd lentebb nulla munkalánc), ez alatt az adatok alatt a felhasználó egyenlegét értjük. A konkrét "kölcsönzést" bárki kérheti, de az érték módosítása csak meghatározott szabályok szerint lehetséges. account_id A "Smart Contract"
smart-contract (). Lényegében — egy fiók külön esete, kiegészítve a smart contract kódjával és a változói tárolójával. Ha a "tárca" esetében a pénz be- és kifizetését viszonylag egyszerű, előre meghatározott szabályok szerint lehet végrehajtani, a smart contract esetében ezek a szabályok a kódjában vannak rögzítve (valamilyen Turing-teljes programozási nyelven).A blokklánc állapota
state of blockchain (). Az összes fiók/smart contract állapotainak összessége (abstrakt értelemben — hash-tábla, ahol a kulcsok a fiók azonosítók, az értékek pedig a fiókokban tárolt adatok).). Feljebb használtam a "be- és kifizetések" kifejezést — ez egy konkrét példa az üzenetküldéshez ("átutalni
Üzenet (üzenetN grammot a fiókból account_1 fiókra account_2 "). Nyilvánvaló, hogy ilyen üzenetet csak az a csomópont küldhet el, amely rendelkezik a fiók privát kulcsával— és képes ezt aláírásával megerősíteni. Az üzenetek a rendes fiókhoz való eljuttatása növeli a fiók egyenlegét, a smart contract esetében pedig a kódja végrehajtását eredményezi (ami feldolgozza az üzenet fogadását). Nyilván más üzenetek is lehetségesek (amelyek nem pénzösszegeket, hanem tetszőleges adatokat hordoznak a smart contractok között). fiókra transaction
A tranzakció (transaction). A szállítási üzenet ténye tranzakciónak nevezik. A tranzakciók megváltoztatják a blokklánc állapotát. A blokkok a blokkláncban valójában tranzakciókból (üzenetkézbesítési feljegyzésekből) állnak. Ebben az értelemben a blokklánc állapotát egy inkrementális adatbázisként lehet elképzelni — minden blokk egy „diff”, amelyet sorban kell alkalmazni a jelenlegi adatbázis állapotának eléréséhez. Az ezen „diffek” csomagolásának és a teljes állapot helyreállításának részleteiről a következő cikkben lesz szó.
Blokklánc a TON-ban: mi ez és miért fontos?
Ahogy az előző cikkben említettem, a blokklánc egy adatstruktúra, amelynek elemei (blokkok) „láncba” vannak rendezve, és minden következő blokk tartalmazza az előző blokk hash-ét. A hozzászólások között felmerült a kérdés: miért van egyáltalán szükség ilyen adatstruktúrára, amikor már van DHT — elosztott hash-tábla? Nyilvánvaló, hogy bizonyos adatokat tárolni lehet DHT-ben, de ez csak a nem túl „érzékeny” információk számára alkalmas. A kriptovaluta egyenlegét DHT-ben tárolni nem lehet — elsősorban a hiányzó integritás-ellenőrzések. Az egész blokklánc struktúrájának összetettsége az adatokban való beavatkozások megakadályozásáért alakult ki.
Mindazonáltal a TON blokklánc még bonyolultabbnak tűnik, mint sok más elosztott rendszer — ennek két oka van. Az első — a hardforkok szükségességének minimalizálására irányuló törekvés. . A hagyományos kriptovaluták esetében minden paraméter a kezdeti szakaszban van meghatározva, és bármilyen változtatási kísérlet tulajdonképpen egy „alternatív kriptovaluta univerzum” létrejöttéhez vezet. A második ok — a blokklánc fragmentálásának (sharding) a támogatása. A blokklánc egy olyan struktúra, amely nem képes kicsinyülni az idő múlásával; és általában minden csomópont, amely a hálózat működéséért felelős, kénytelen azt teljes egészében tárolni. A hagyományos (centralizált) rendszerekben ilyen problémák megoldására sharding-ot alkalmaznak: az adatbázis egy része egy szerveren található, a másik része pedig egy másikon, stb. A kriptovaluták esetében ez a funkció egyelőre meglehetősen ritka — részben azért, mert nehéz sharding-ot hozzáadni egy olyan rendszerhez, amelynek bevezetése eredetileg nem volt tervezett., Hogyan tervezi a TON megoldani a fenti két problémát?) блокчейна. Блокчейн — структура, не способная стать меньше с течением времени; и обычно каждый узел, отвечающий за работоспособность сети, вынужден хранить её полностью. В традиционных (централизованных) системах для решения подобных проблем применяется шардирование: часть записей в БД находится на одном сервере, часть — на другом, и т.д. В случае с криптовалютами такая функциональность пока что довольно редка — в частности, из-за того, что сложно добавить шардирование в систему, где оно не было запланировано изначально.
Каким же образом TON планирует решить обе вышеописанных проблемы?
A blokklánc tartalma. Workchain-ek.
Először is beszéljünk arról, hogy mi lesz tárolva a blokkláncban. A blokkláncban az egyes fiókok (a legegyszerűbb esetben „pénztárcák”) és okosszerződések állapotai fognak tárolódni (egyszerűsítésként tegyük fel, hogy ezek megegyeznek a fiókokkal). Gyakorlatilag ez egy szabványos hash-tábla lesz — a kulcsok az azonosítók account_id, az értékek pedig azok a struktúrák, amelyek az alábbiakat tartalmazzák:
- egyenleg;
- okosszerződés kódja (csak okosszerződések esetén);
- okosszerződés adatainak tárolója (csak okosszerződések esetén);
- statisztika;
- (opcionális) nyilvános kulcs az fiókból történő átutalásokhoz, alapértelmezett érték account_id;
- kimenő üzenetek sora (ide kerülnek az üzenetek a címzettnek való továbbításra);
- a fiókhoz legutóbb kézbesített üzenetek listája.
Mint már említettük, a blokkok valójában tranzakciókból állnak — üzenetekből, amelyeket a különböző fiókok account_id kapnak. Az account_id mellett az üzenetek tartalmaznak egy 32 bites mezőt workchain_id — az úgynevezett workchain (workchain, munkablokklánc). Ez lehetővé teszi, hogy több független blokklánc létezzen eltérő konfigurációkkal. Ezzel együtt a workchain_id = 0 különleges esetnek számít, nulla workchain — a benne található egyenlegek a TON kriptovalutához (Grams) kapcsolódnak. Valószínű, hogy kezdetben más workchain-ek nem fognak egyáltalán létezni.
Shard láncok. Végtelen Sharding Paradigma.
De ezen a ponton a blokkláncok számának növekedése még nem áll meg. Nézzük meg a shardingot. Képzeljük el, hogy minden egyes fióknak (account_id) saját blokklánca van — ezen találhatóak az összes beérkező üzenet — és az ilyen blokkláncok állapotát külön csomópontokon tárolják.
Természetesen ez meglehetősen pazarló: valószínű, hogy ezekbe az shard láncokba (shardchain, shard blokkláncba) a tranzakciók nagyon ritkán érkeznek, és sok erőforrással rendelkező csomópontra lesz szükség (előreugorva megjegyzem, hogy itt nem egyszerűen mobiltelefonos kliensekről beszélünk, hanem komoly szerverekről).
Ezért a shard láncok a fiókokat a kulcsaik bináris előtagjai szerint csoportosítják: ha a shard lánc előtagja 0110, akkor minden account_id, ami ezekkel a számokkal kezdődik, tranzakciói be fognak kerülni. Ez a shard_prefix hossza 0 és 60 bit között változhat — és a legfontosabb, hogy dinamikusan változhat.
Amikor egy shardchain-re túl sok tranzakció érkezik, a rajta dolgozó csomópontok előre meghatározott szabályok szerint "elosztják" azt két utódra — a prefixeik egy bitnyivel hosszabbak lesznek (és az egyikük esetében ez a bit 0, a másiknál 1). Például, shard_prefix = 0110a b elágazik 01100b-re és 01101b-re. Ezzel szemben, ha két "szomszédos" shardchain elég kényelmesen érzi magát (egy idő után), újból összeolvadnak.
Így a sharding "alulról felfelé" történik - feltételezzük, hogy minden fióknak van egy saját shardja, de ezek - egy ideig - a prefixek mentén "összeragasztva" vannak. Ez magában foglalja Infinite Sharding Paradigm (a végtelen sharding paradigmáját.).
Külön szeretném kiemelni, hogy a workchain-ek csak virtuálisan léteznek - valójában, workchain_id ez a konkrét shardchain azonosítója. Formális nyelven fogalmazva, minden shardchain egy szám párja által van definiálva (workchain_id, shard_prefix).
Hibajavítás. Függőleges blokkláncok.
Hagyományosan úgy tekintik, hogy bármely tranzakció a blokkláncon "kőbe vésett". Azonban a TON esetében lehetőség van a "történet újraírására" - ha valaki (úgynevezett "halász" csomópont) bizonyítja, hogy az egyik blokk hibásan lett aláírva. Ebben az esetben egy speciális korrekciós blokk kerül a megfelelő shardchainbe, amely a kijavítandó blokk hash-ét tartalmazza (nem a shardchain utolsó blokkját). Ha a shardchain-t egy vízszintes blokk láncként képzeljük el, azt lehet mondani, hogy a korrekciós blokk nem jobbra, hanem fölül kapcsolódik a hibás blokkhoz - ezért úgy tekintjük, hogy a kis "függőleges blokklánc" részévé válik. Így kijelenthetjük, hogy a shardchain-ek két dimenziós blokkláncok..
Ha egy hibás blokkra hivatkoztak a későbbi blokkok (azaz, új tranzakciók történtek érvénytelen adatok alapján), akkor a korrekciós blokkok is hozzáadásra kerülnek a hibás blokk fölé. Ha a blokkok nem érintették a "megsérült" információt, akkor ezek a "korrekciós hullámok" nem terjednek ki rájuk. Például a fent említett illusztrációban az első blokk tranzakciója lett érvénytelen, amely növelte a C fiók egyenlegét — ezért a harmadik blokkban a fiók egyenlegét csökkentő tranzakciót is érvényteleníteni kell, és a blokk fölé egy korrigáló blokkot kell commitálni.
Érdemes megjegyezni — bár a korrekciós blokkok úgy tűnnek, hogy "a" eredeti blokkok felett helyezkednek el, valójában a megfelelő blokklánc végére lesznek felírva (ott, ahol kronológiailag helyezkednek el). A két dimenziós elhelyezkedés csak azt mutatja, hogy melyik ponthoz fognak "csatlakozni" a blokkláncban (az eredeti blokk hash-én keresztül).
Lehet különféle filozófiai kérdéseket feltenni arról, hogy mennyire jó ötlet a "múlt megváltoztatása". Úgy tűnik, hogy ha megengedjük egy érvénytelen blokk megjelenését a shard láncon, akkor nem hagyhatjuk figyelmen kívül egy téves korrekciós blokk megjelenésének lehetőségét sem. Itt, ahogy tudom, a különbség a csomópontok számában rejlik, amelynek konszenzusra kell jutnia az új blokkokkal kapcsolatban — egy shard láncon viszonylag kicsi "munkacsoport" csomópont dolgozik (amely gyakran változtathatja összetételét), de a korrekciós blokkok hozzáadásához minden validáló csomópontegyetértésére van szükség. A validátorokról, munkacsoportokról és más csomóponti szerepekről a következő cikkemben fogok mesélni.
Egy blokklánc, hogy mindent szabályozzon
A fenti információk alapján sokféle blokk láncról van szó, amit külön is tárolni érdemes. Különösen a következő információk tekintetében:
- a munkaláncok számáról és konfigurációjáról;
- a shard láncokról és azok prefixeiről;
- arról, hogy mely csomópontok felelősek a shard láncokért;
- a legutóbb hozzáadott blokkok hash-ei minden shard láncra.
Ahogy már kitalálhatták, mindezek az adatok egy másik tároló blokk láncban kerülnek rögzítésre — masterchain (masterchain, master blockchain). Az összes shard blokkjának hash-ének megléténél fogva a rendszer erősen összekapcsolódik. Ez azt is jelenti, hogy az új blokk generálása a masterchain-en közvetlenül a shard chain-ek blokkjainak generálása után fog megtörténni - várhatóan a shard chain-ek blokkjai szinte egyszerre fognak megjelenni, körülbelül 5 másodpercenként, míg a következő blokk a masterchain-en ennek másodperce után fog következni.
De ki lesz felelős az egész óriási munka megvalósításáért - az üzenetek továbbításáért, a okos szerződések végrehajtásáért, a blokkok létrehozásáért a shard chain-ekben és a masterchain-en, nem is beszélve a blokkok hibáinak ellenőrzéséről? Vajon mindezt csendesen el fogják végezni a felhasználók millióinak telefonjai, amelyeken a Telegram kliens van telepítve? Vagy talán a Durov csapat feladja a decentralizáció gondolatát és a régi módszerrel fogják végezni a szervereik?
Valójában egyik válasz sem helyes. De ennek a cikknek az oldala gyorsan fogyni kezd, ezért a csomópontok eltérő szerepeiről (már észlelhette néhányat a megemlítések közül), valamint a működésük mechanizmusáról már a következő részben fogunk beszélni.
Forrás: habr.com
