Текстът представлява продължение на серия от статии, в които разглеждам структурата на готовещата се за излизане тази година разпределена мрежа Telegram Open Network (TON). В описах нейното най-основно ниво — начина на взаимодействие между възлите.
За всеки случай напомням, че нямам никаква връзка с разработването на тази мрежа и целият материал е извлечен от открит (въпреки че непроверен) източник — (има и прилагана , която накратко изложава основните моменти), появила се в края на миналата година. Обемът на информацията в този документ, според мен, свидетелства за неговата автентичност, макар че няма официални потвърждения за това.
Днес ще разгледаме основния компонент на TON — блокчейн.
Основни понятия
Акаунт (сметки). Някакъв набор от данни, идентифициран с 256-битово число account_id (най-често това е публичният ключ на собственика на акаунта). В основния случай (вижте по-долу нулев блокчейн), под тези данни се подразбира балансът на потребителя. „Да заеме“ конкретен account_id може всеки, но да променя стойността му може само по определени правила.
Смарт-контракт (smart-contract). По същество — частен случай на акаунт, допълнен с кода на смарт-контракт и хранилището на неговите променливи. Ако в случая на „портфейла“ може да се внасят и изтеглят пари от него по относително прости и предварително определени правила, то в случая на смарт-контракта тези правила са записани под формата на неговия код (на известен Тюринг-пълен език за програмиране).
Състоянието на блокчейна (състояние на блокчейна). Съвкупност от състояния на всички акаунти/смарт-контракти (в абстрактен смисъл — хеш-таблица, където ключовете са идентификатори на акаунти, а стойностите — данните, съхранявани в акаунтите).
Съобщение (message). По-горе употребих израза „да внасям и изтеглям пари“ — това е частен пример за съобщение („да предам N грама от акаунт account_1 на акаунт account_2“). Очевидно, такова съобщение може да изпрати само възел, притежаващ частния ключ на акаунта account_1 — и способен да потвърди това с подпис. Резултатът от доставката на такива съобщения на обикновен акаунт е увеличаването на неговия баланс, а на смарт-контракта — изпълнението на неговия код (който ще обработи получаването на съобщението). Разбира се, възможни са и други съобщения (прехвърлящи не парични суми, а произволни данни между смарт-контрактите).
Транзакция (транзакция). Фактът на доставката на съобщение се нарича транзакция. Транзакциите променят състоянието на блокчейна. Всъщност транзакциите (записите за доставка на съобщения) образуват блоковете в блокчейна. В това отношение може да се разглежда състоянието на блокчейна като инкрементална база данни — всички блокове са «дифове», които трябва да се прилагат последователно, за да се получи текущото състояние на БД. За конкретиката на опаковането на тези «дифове» (и възстановяването на пълното състояние от тях) ще става дума в следващата статия.
Блокчейн в TON: какво е това и за какво служи?
Както беше споменато в предишната статия, блокчейнът е структура от данни, чиито елементи (блокове) са подредени в «верига», и всеки следващ блок в веригата съдържа хеш на предишния. В коментарите беше зададен въпрос: а защо всъщност е нужна такава структура от данни, когато вече имаме DHT — разпределена хеш-таблица? Очевидно е, че някои данни могат да се съхраняват и в DHT, но това е подходящо само за не твърде «чувствителна» информация. Балансите на криптовалутите не могат да се съхраняват в DHT — предимно заради липсата на проверки за цялостност. Всъщност, сложността на структурата на блокчейна нараства заради предотвратяването на намеси в съхраняваните в него данни.
Все пак блокчейнът в TON изглежда дори по-сложен, отколкото в повечето други разпределени системи — и за това има две причини. Първата е стремежът да се минимизира необходимостта от форкове. В традиционните криптовалути всички параметри са зададени в началния етап и всяко опит за тяхното изменение всъщност води до появата на «алтернативна вселена на криптовалутата». Втората причина е поддръжката на разпределение (шардинг, разпределеност) на блокчейна. Блокчейнът е структура, която не може да се свие с времето; обикновено всеки възел, отговорен за функционирането на мрежата, е принуден да я съхранява напълно. В традиционните (централизирани) системи за решаване на подобни проблеми се прилага разпределение: част от записите в БД се намират на един сървър, част — на друг и т.н. В случая с криптовалутите такава функционалност все още е доста рядка — по-специално, защото е трудно да се добави разпределение в система, в която то не е било планирано първоначално.
Как ще реши TON двете по-горе описани проблеми?
Съдържание на блокчейна. Воркчейни.
Първо, нека поговорим за това, какво ще се съхранява в блокчейна. В него ще се съхраняват състояния на акаунти ("портфейли" в основния случай) и смарт-контрактите (за простота ще считаме, че те са същите като акаунтите). Всъщност, това ще представлява обикновена хеш-таблица — ключовете в нея ще бъдат идентификаторите account_id, а стойностите — структури от данни, съдържащи такива неща, като:
- баланс;
- код на смарт-контракта (само за смарт-контракти);
- съхранение на данни на смарт-контракт (само за смарт-контракти);
- статистика;
- (по избор) публичен ключ за преводи от акаунта, по подразбиране account_id;
- опашка за изходящи съобщения (тук те се записват за изпращане на получателя);
- списък на последните доставени съобщения на този акаунт.
Както бе споменато по-горе, самите блокове се състоят от транзакции — съобщения, доставени на различни акаунти account_id. Въпреки това, освен account_id, съобщенията съдържат и 32-битово поле workchain_id — идентификатор на т.н. воркчейн (workchain, работещ блокчейн). Това позволява да има няколко независими един от друг блокчейна с различни конфигурации. При това workchain_id = 0 се счита за специален случай, нула воркчейн — именно баланса, които се намират в него, ще отговарят на криптовалутата TON (Grams). Най-вероятно в началото няма да съществуват други воркчейни.
Шардчейни. Безкрайна шардниг парадигма.
Но на това растежът на количеството блокчейни не спира. Нека да разгледаме шардинга. Да си представим, че всеки акаунт (account_id) има собствен блокчейн — в него се съхраняват всички получени от него съобщения — и състоянията на всички такива блокчейни се съхраняват на отделни възли.
Разбира се, това е доста разточително: най-вероятно, в всеки от тези шардчейни (shardchain, шард блокчейн) транзакции ще се получават много рядко, а мощни възли ще са необходими много (в предвид, че не става дума просто за клиенти на мобилни телефони — а за сериозни сървъри).
Затова шардчейните обединяват акаунти по двоични префикси на техните идентификатори: ако шардчейнът има префикс 0110, то в него ще попаднат транзакции на всички account_id, които започват с тези цифри. Този shard_prefix може да има дължина от 0 до 60 бита — и най-важното е, че той може да се променя динамично.
Когато един от шардчейнов започне да получава твърде много транзакции, работещите по него възли по предварително определени правила "разделят" шардчейна на два дъщерни — техните префикси ще бъдат с един бит по-дълги (и за единия от тях този бит ще бъде 0, а за другия — 1). Например, shard_prefix = 0110b ще се раздели на 01100b и 01101b. От своя страна, ако два "съседни" шардчейна започнат да се чувстват достатъчно комфортно (в продължение на известно време), те отново ще се слеят.
По този начин, шардироването се извършва "отдолу нагоре" — ние предполагаме, че всеки акаунт разполага със свой собствен шард, но те — до определено време — са "залепени" по префиксите. Това подчертава. Infinite Sharding Paradigm (парадигмата на безкрайното шардирование.).
Отделно трябва да подчертаем, че воркчейните съществуват само виртуално — на практика, workchain_id това е част от идентификатора на конкретния шардчейн. Говорейки на формален език, всеки шардчейн се определя от двойка числа (workchain_id, shard_prefix).
Корекция на грешки. Вертикални блокчейни.
Традиционно се приема, че всяка транзакция в блокчейна е "изсечена в камъка". Въпреки това, в случая с TON е предвидена възможността "да се пренапише историята" — ако някой (т.н. възел-"рибак") докаже, че един от блоковете е бил подписан неправилно. В този случай в съответния шардчейн се добавя специален коригиращ блок, съдържащ хаша на самия коригиран блок (а не последния блок в шардчейна). Представяйки шардчейна като веригата от блокове, подредена хоризонтално, може да се каже, че коригиращият блок се свързва с грешния блок не вдясно, а отгоре — поради това се счита, че той става част от малък "вертикален блокчейн". По този начин може да се каже, че шардчейните са двумерни блокчейни..
В случай че след грешен блок на внесените промени се позовават последващи блокове (т.е., съществуват нови транзакции на базата на невалидни), на тези блокове също така се добавят коригиращи. Ако блоковете не засягат "поразената" информация, на тях тези "коригиращи вълни" не се разпространяват. Например, в горната илюстрация транзакцията на първия блок, която увеличава баланса на акаунт C, е призната за некоректна — затова транзакцията, която намалява баланса на този акаунт в третия блок, също трябва да бъде анулирана, а над самия блок да се добави коригиращ блок.
Трябва да се отбележи — въпреки че коригиращите блокове се изобразяват разположени "над" оригиналните, всъщност те ще бъдат добавени в края на съответния блокчейн (там, където трябва да се намират хронологически). Двумерното разположение само показва, до коя точка в блокчейна ще бъдат "прикачени" (чрез хеша на оригиналния блок, който се съдържа в тях).
Може да се разгледа философски въпросът колко добро е решението "да променяме миналото". Изглежда, че ако допуснем възможността за поява на некоректен блок в шардчейна, не можем да изключим и възможността за поява на грешен коригиращ блок. Тук, доколкото мога да съдя, разликата е в броя на възлите, които трябва да достигнат консенсус относно новите блокове — над всеки шардчейн ще работи сравнително малка "работна група" възли (доста често променящи състава си), а добавянето на коригиращи блокове ще изисква съгласието на всички възли-валидатори. Повече информация за валидаторите, работните групи и други роли на възлите ще предоставя в следващата статия.
Един блокчейн, за да управлява всички
По-горе е посочена много информация за различните видове блокчейни, която също трябва някъде да се съхранява. В частност, става въпрос за следните данни:
- за броя и конфигурациите на работните вериги;
- за броя шардчейни и техните префикси;
- за това, кои възли в момента са отговорни за които шардчейни;
- хешове на последно добавените блокове във всички шардчейни.
Както вече можете да предположите, всичките тези неща се записват в още едно хранилище-блокчейн — мастърчейн (masterchain, master blockchain). Благодарение на наличието на хешове от блоковете на всичките шардчейнове в неговите блокове, системата става силно свързана. Това също така означава, че генерирането на нов блок в мастерчейна ще се извършва непосредствено след генерирането на блоковете в шардчейновете — очаква се блоковете в шардчейновете да се появяват почти едновременно на всеки 5 секунди, а следващият блок в мастерчейна — една секунда след това.
Но кой ще бъде отговорен за реализирането на цялата тази титанична работа — за изпращането на съобщения, изпълнението на смартконтрактите, образуването на блокове в шардчейновете и мастерчейна, а също и за проверката на блоковете за грешки? Наистина ли всичко това ще се извършва потайно от телефоните на милиони потребители с инсталиран клиент на Телеграм? Или, възможно ли е екипът на Дуров да се откаже от идеите за децентрализация и това да се прави от техните сървъри по-старомодния начин?
Всъщност, нито един от двата отговора не е правилен. Но пространствата в тази статия бързо свършват, затова разговорът за различните роли на възлите (може би вече сте забелязали споменаването на някои от тях), както и за механиката на тяхната работа, ще продължи в следващата част.
Източник: habr.com
