ТОН: Отворена мрежа на Телеграма. Дел 2: Blockchains, Sharding

Овој текст е продолжение на серијата написи во кои ја испитувам структурата на (веројатно) дистрибуираната мрежа Telegram Open Network (TON), која се подготвува за објавување оваа година. ВО претходниот дел Го опишав неговото најосновно ниво - начинот на кој јазлите комуницираат едни со други.

За секој случај, да ве потсетам дека немам никаква врска со развојот на оваа мрежа и целиот материјал е собран од отворен (иако непроверен) извор - документ (има и придружна брошура, накратко наведувајќи ги главните точки), кои се појавија на крајот на минатата година. Количината на информации во овој документ, според мое мислење, укажува на неговата автентичност, иако нема официјална потврда за тоа.

Денес ќе ја разгледаме главната компонента на TON - блокчејнот.

Основни концепти

Сметка (Сметка). Збир на податоци идентификувани со 256-битен број account_id (најчесто ова е јавниот клуч на сопственикот на сметката). Во основниот случај (види подолу нула работен синџир), овие податоци се однесуваат на билансот на корисникот. „Окупирај“ специфично account_id секој може, но неговата вредност може да се промени само според одредени правила.

Паметен договор (паметен договор). Во суштина, тоа е посебен случај на сметка, дополнет со паметен код за договор и складирање на неговите променливи. Ако во случај на „паричник“ можете да депонирате и повлечете пари од него според релативно едноставни и однапред одредени правила, тогаш во случај на паметен договор овие правила се напишани во форма на неговиот код (во одреден Туринг-комплет програмски јазик).

Состојба на блокчејн (состојба на блокчејн). Збир на состојби на сите сметки/паметни договори (во апстрактна смисла, хеш табела, каде што клучевите се идентификатори на сметката, а вредностите се податоците зачувани во сметките).

Порака (порака). Погоре го користев изразот „кредитни и дебитни пари“ - ова е посебен пример за порака („пренос N грама од сметката сметка_1 на сметка сметка_2"). Очигледно, само јазолот што го поседува приватниот клуч на сметката може да испрати таква порака сметка_1 - и може да го потврди ова со потпис. Резултатот од доставувањето на такви пораки на редовна сметка е зголемување на нејзиното салдо, а резултатот од паметниот договор е извршувањето на неговиот код (кој ќе го обработи приемот на пораката). Секако, можни се и други пораки (пренесување не парични суми, туку произволни податоци помеѓу паметните договори).

Трансакција (трансакција). Фактот дека пораката е испорачана се нарекува трансакција. Трансакциите ја менуваат состојбата на блокчејнот. Тоа се трансакции (записи за испорака на пораки) кои ги сочинуваат блоковите во блокчејнот. Во овој поглед, можете да ја замислите состојбата на блокчејнот како зголемена база на податоци - сите блокови се „разлики“ кои треба да се применуваат последователно за да се добие моменталната состојба на базата на податоци. Спецификите на пакувањето на овие „разлики“ (и враќањето на целосната состојба од нив) ќе бидат разгледани во следната статија.

Блокчејн во ТОН: што е тоа и зошто?

Како што беше споменато во претходната статија, блокчејн е структура на податоци, чии елементи (блокови) се наредени во „синџир“, а секој следен блок од ланецот содржи хаш од претходниот. Коментарите го поставија прашањето: зошто воопшто ни е потребна таква структура на податоци кога веќе имаме DHT - дистрибуирана хеш-табела? Очигледно, некои податоци може да се складираат во DHT, но ова е погодно само за не премногу „чувствителни“ информации. Салдото на криптовалутите не може да се складира во DHT - првенствено поради недостатокот на проверки на интегритет. Всушност, целата сложеност на блокчејн структурата расте со цел да се спречи мешање со податоците складирани во неа.

Сепак, блокчејнот во TON изгледа уште покомплексен отколку во повеќето други дистрибуирани системи - и тоа од две причини. Првата е желбата да се минимизира потребата за вилушки. Во традиционалните криптовалути, сите параметри се поставени во почетната фаза и секој обид за нивна промена всушност води до појава на „алтернативен универзум на криптовалути“. Втората причина е поддршката за дробење (делење, делење) блокчејн. Блокчејн е структура која не може да стане помала со текот на времето; и обично секој јазол одговорен за работата на мрежата е принуден целосно да го складира. Во традиционалните (централизирани) системи, шердинг се користи за решавање на вакви проблеми: некои од записите во базата на податоци се наоѓаат на еден сервер, некои на друг, итн. Во случајот на криптовалутите, таквата функционалност е сè уште доста ретка - особено поради фактот што е тешко да се додаде хардинг во систем каде што првично не беше планирано.

Како ТОН планира да ги реши двата горенаведени проблеми?

Содржина на блокчејн. Работни синџири.

Пред сè, да разговараме за тоа што се планира да се складира во блокчејнот. Таму ќе се складираат состојбите на сметките („паричници“ во основниот случај) и паметните договори (за едноставност, ќе претпоставиме дека ова е исто како и сметките). Во суштина, ова ќе биде редовна табела за хаш - клучевите во неа ќе бидат идентификатори account_id, а вредностите се структури на податоци што содржат такви работи како што се:

• рамнотежа;
• код за паметен договор (само за паметни договори);
• Складирање податоци за паметни договори (само за паметни договори);
• статистика;
• (опционално) јавен клуч за трансфери од сметката, стандардно account_id;
• редица на појдовни пораки (тука се внесуваат за препраќање до примачот);
• список со најновите пораки доставени до оваа сметка.

Како што споменавме погоре, самите блокови се состојат од трансакции - пораки доставени до различни сметки account_id. Меѓутоа, освен account_id, пораките содржат и 32-битно поле workchain_id — таканаречен идентификатор работен синџир (работен синџир, работен блокчејн). Ова ви овозможува да имате неколку блокчејнови независни еден од друг со различни конфигурации. Во овој случај, workchain_id = 0 се смета за посебен случај, нула работен синџир — салдото во него е што ќе одговара на криптовалутата ТОН (грамови). Најверојатно, на почетокот, други работни синџири воопшто нема да постојат.

Синџирчиња од риболов. Парадигма за бесконечно штркање.

Но, растот на бројот на блокчејн не застанува тука. Ајде да се справиме со сечењето. Ајде да замислиме дека на секоја сметка (account_id) ѝ е доделен сопствен блокчејн - ги содржи сите пораки што доаѓаат до неа - и состојбите на сите такви блокчејнови се зачувани на посебни јазли.

Се разбира, ова е многу расипничко: најверојатно, во секое од овие остри синџири (острина, парче блокчејн) трансакциите ќе пристигнуваат многу ретко и ќе бидат потребни многу моќни јазли (гледајќи напред, забележувам дека не зборуваме само за клиенти на мобилни телефони - туку за сериозни сервери).

Според тоа, шипките ги комбинираат сметките според бинарните префикси на нивните идентификатори: ако чемерниот синџир има префикс 0110, тогаш ќе ги вклучи трансакциите на сите account_ids кои започнуваат со овие броеви. Ова скршено_префикс може да има должина од 0 до 60 бита - а главната работа е што може динамично да се менува.

Штом еден од мрсните синџири ќе почне да прима премногу трансакции, јазлите што работат на него, според однапред одредени правила, го „поделуваат“ на две деца - нивните префикси ќе бидат за малку подолги (а за еден од нив овој бит ќе биде еднакво на 0, а за другиот - 1). На пример, скршено_префикс = 0110b ќе се подели на 01100б и 01101б. За возврат, ако два „соседни“ шипки почнат да се чувствуваат доволно спокојни (по одредено време), тие повторно ќе се спојат.

Така, делењето се врши „од дното нагоре“ - претпоставуваме дека секоја сметка има свој фрагмент, но засега тие се „залепени“ со префикси. Ова е она што значи Парадигма за бесконечно штркање (бесконечна парадигма на сердинг).

Одделно, би сакал да нагласам дека работните синџири постојат само виртуелно - всушност, workchain_id тој е дел од идентификаторот на специфичен шилест синџир. Во формална смисла, секој ритам е дефиниран со пар броеви (workchain_id, скршено_префикс).

Корекција на грешка. Вертикални блокчејни.

Традиционално, секоја трансакција на блокчејн се смета за „поставена во камен“. Меѓутоа, во случајот со ТОН, можно е да се „препише историјата“ - во случај некој (т.н. рибарски јазол) ќе докаже дека еден од блоковите е погрешно потпишан. Во овој случај, специјален блок за корекција се додава на соодветниот стригав синџир, кој го содржи хашот на самиот блок што се коригира (а не последниот блок во стрингот). Размислувајќи за шипката како синџир од блокови поставени хоризонтално, можеме да кажеме дека корективниот блок е прикачен на погрешниот блок не десно, туку одозгора - така што се смета дека станува дел од мала „вертикална блокчејн“ . Така, можеме да кажеме дека shardchains се дводимензионални блокчејнери.

Ако, по погрешен блок, промените направени од него беа референцирани од следните блокови (т.е. нови трансакции беа направени врз основа на неважечки), корективните се додаваат и на овие блокови „на врвот“. Ако блоковите не влијаеле на „погодените“ информации, овие „корективни бранови“ не важат за нив. На пример, на илустрацијата погоре, трансакцијата на првиот блок, зголемување на салдото на сметката В, беше препознаена како неточна - затоа, трансакцијата што го намалува салдото на оваа сметка во третиот блок, исто така, треба да се откаже и корективен блок треба да се стави на врвот на самиот блок.

Треба да се забележи дека иако корективните блокови се прикажани како лоцирани „над“ оригиналните, всушност тие ќе бидат додадени на крајот на соодветниот блокчејн (каде што треба да бидат хронолошки). Дводимензионалната локација покажува само до која точка во блокчејнот ќе бидат „поврзани“ (преку хашот на оригиналниот блок што се наоѓа во нив).

Можете одделно да филозофирате за тоа колку е добра одлуката за „промена на минатото“. Се чини дека ако ја признаеме можноста за појава на погрешен блок во чемерниот синџир, тогаш не можеме да ја избегнеме можноста за појава на погрешен корективен блок. Овде, колку што можам да кажам, разликата е во бројот на јазли кои мора да постигнат консензус за новите блокови - ќе има релативно мал број луѓе кои работат на секој скршен синџир“.работна група» јазли (кој го менува својот состав доста често), а воведувањето на корективни блокови ќе бара согласност од сите валидаторски јазли. Ќе зборувам повеќе за валидаторите, работните групи и другите улоги на јазли во следната статија.

Еден блокчејн за да владее со сите нив

Има многу информации наведени погоре за различните типови на блокчејн, кои и самите треба да се складираат некаде. Конкретно, зборуваме за следните информации:

• за бројот и конфигурациите на работните синџири;
• за бројот на остри синџири и нивните префикси;
• за кои јазли во моментов се одговорни за кои шилести синџири;
• хашови од последните блокови додадени на сите шипки.

Како што може да претпоставите, сите овие работи се снимени во друга блокчејн складирање - мајсторски синџир (мајстор, господар на блокчејн). Поради присуството на хашови од блоковите на сите шипки во неговите блокови, го прави системот високо поврзан. Ова, меѓу другото, значи дека генерирањето на нов блок во главниот синџир ќе се случи веднаш по генерирањето на блокови во шипките синџири - се очекува дека блоковите во четните синџири ќе се појавуваат речиси истовремено приближно на секои 5 секунди, а следниот блок во masterchain - секунда после тоа.

Но, кој ќе биде одговорен за спроведувањето на сета оваа титанска работа - за испраќање пораки, извршување на паметни договори, формирање блокови во скршените синџири и главниот синџир, па дури и проверка на блоковите за грешки? Дали сето тоа тајно ќе го прават телефоните на милиони корисници со инсталиран клиентот Telegram на нив? Или, можеби, тимот на Дуров ќе ги напушти идеите за децентрализација и нивните сервери ќе го направат тоа на старомоден начин?

Всушност, ниту едниот ниту другиот одговор не се точни. Но, маргините на оваа статија брзо се трошат, па ќе зборуваме за различните улоги на јазлите (можеби веќе сте забележале спомнување на некои од нив), како и механиката на нивната работа, во следниот дел.

Извор: www.habr.com