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