Цей текст — продовження серії статей, у яких я розглядаю структуру (імовірно) розподіленої мережі Telegram Open Network (TON), яка готується до виходу цього року. У я описав її самий базовий рівень - спосіб взаємодії вузлів між собою.
Про всяк випадок нагадаю, що до розробки цієї мережі я не маю стосунків і весь матеріал почерпнуть з відкритого (хоч і неперевіреного) джерела. (Ще до нього є додається , що викладає коротко основні моменти), що з'явився наприкінці минулого року. Обсяг інформації в цьому документі, на мою думку, свідчить про його справжність, хоча жодних офіційних підтверджень тому немає.
Сьогодні подивимося на основний компонент TON – блокчейн.
базові поняття
Аккаунт (рахунок). Якийсь набір даних, що ідентифікується 256-бітовим числом Номер рахунку (найчастіше це публічний ключ власника облікового запису). У базовому випадку (див. нижче нульовий воркчейн), під цими даними мається на увазі баланс користувача. «Зайняти» конкретний Номер рахунку може будь-хто, але змінювати його значення можна лише за певними правилами.
Смарт-контракт (смарт-контракт). По суті — окремий випадок облікового запису, доповнений кодом смарт-контракту та сховищем його змінних. Якщо у випадку «гаманця» можна зараховувати та списувати гроші з нього за відносно простими і заздалегідь визначеними правилами, то у разі смарт-контракту ці правила записані у вигляді його коду (якоюсь Т'юрінг-повною мовою програмування).
Стан блокчейну (state of blockchain). Сукупність станів усіх облікових записів/смарт-контрактів (в абстрактному сенсі — хеш-таблиця, де ключами є ідентифікатори облікових записів, а значеннями — дані, що зберігаються в облікових записах).
Повідомлення (повідомлення). Вище я вжив вираз «зараховувати та списувати гроші» — це приватний приклад повідомлення («передати N грам з облікового запису рахунок_1 на обліковий запис рахунок_2»). Очевидно, надіслати таке повідомлення може тільки вузол, що володіє закритим ключем облікового запису рахунок_1 і здатний підтвердити це підписом. Результатом доставки таких повідомлень звичайному акаунту є збільшення його балансу, а смарт-контракту виконання його коду (який обробить прийом повідомлення). Зрозуміло, можливі інші повідомлення (переносять не грошові суми, а довільні дані між смарт-контрактами).
транзакція (угода). Факт доставки повідомлення називається транзакцією. Транзакції змінюють стан блокчейну. Саме з транзакцій (записів про доставку повідомлень) складаються блоки у блокчейні. У цьому плані можна уявляти стан блокчейна як інкрементальну базу даних — всі блоки є «диффами», які потрібно застосувати послідовно, щоб отримати поточний стан БД. Про конкретику упаковки цих «диффів» (і відновлення повного стану за ними) йтиметься у наступній статті.
Блокчейн у TON: що це й навіщо?
Як згадувалося у попередній статті, блокчейн - це структура даних, елементи (блоки) якої впорядковані в "ланцюг", і кожен наступний блок ланцюга містить у собі хеш попереднього. У коментарях запитали: а навіщо взагалі потрібна така структура даних, коли ми вже маємо DHT — розподілену хеш-таблицю? Очевидно, якісь дані можна зберігати і в DHT, але це підходить тільки для не дуже «чутливої» інформації. Баланси криптовалюти зберігати в DHT не можна — насамперед через відсутність перевірок на цілісність. Власне, вся складність структури блокчейна зростає задля запобігання втручанням у дані, що зберігаються в ньому.
Однак блокчейн у TON виглядає ще складніше, ніж у більшості інших розподілених систем – і на те є дві причини. Перша — прагнення мінімізувати потребу в форках. У традиційних криптовалютах всі параметри задані на початковому етапі та будь-яка спроба їх змінити призводить фактично до появи «альтернативного всесвіту криптовалюти». Друга причина - підтримка дроблення (шардингу, шардування) блокчейна. Блокчейн - структура, не здатна стати менше з часом; і зазвичай кожен вузол, який відповідає за працездатність мережі, змушений зберігати її повністю. У традиційних (централізованих) системах для вирішення подібних проблем застосовується шардування: частина записів у БД знаходиться на одному сервері, частина – на іншому, тощо. У випадку з криптовалютами така функціональність поки що досить рідкісна — зокрема через те, що складно додати шардування в систему, де воно не було заплановано спочатку.
Яким чином TON планує вирішити обидві вищеописані проблеми?
Вміст блокчейну. Воркчейни.
Насамперед, поговоримо про те, що планується зберігати в блокчейні. Зберігатися там стану акаунтів («гаманців» в базовому випадку) і смарт-контрактів (для простоти вважатимемо, що це те ж саме, що й акаунти). По суті, це буде звичайна хеш-таблиця – ключами у ній будуть ідентифікатори Номер рахунку, а значеннями - структури даних, що містять у собі такі речі, як:
- баланс;
- код смарт-контракту (тільки для смарт-контрактів);
- сховище даних смарт-контракту (тільки для смарт-контрактів);
- статистика;
- (опціонально) публічний ключ для перекладів з облікового запису, за замовчуванням account_id;
- черга вихідних повідомлень (сюди вони заносяться для пересилання одержувачу);
- список останніх доставлених до цього облікового запису повідомлень.
Як було зазначено вище, безпосередньо блоки складаються з транзакцій — повідомлень, доставлених різним акаунтам account_id. Однак крім account_id повідомлення містять також 32-бітове поле workchain_id - Ідентифікатор т.зв. воркчейна (робочий ланцюг, working blockchain). Це дозволяє мати кілька незалежних один від одного блокчейнів із різними конфігураціями. При цьому workchain_id = 0 вважається особливим випадком, нульовим воркчейном — саме баланси, що знаходяться в ньому, будуть відповідати криптовалюті TON (Grams). Найімовірніше, спочатку інших воркчейнів існувати не буде зовсім.
Шардчейни. Infinite Sharding Paradigm.
Але на цьому зростання кількості блокчейнів не зупиняється. Розберемося із шардингом. Уявімо, що кожному акаунту (account_id) виділено свій власний блокчейн - в ньому лежать всі повідомлення, що приходять йому, і стани всіх таких блокчейнів зберігаються на окремих вузлах.
Звичайно, це дуже марнотратно: швидше за все, у кожен із цих шардчейнів (shardchain, shard blockchain) транзакції надходитимуть дуже рідко, а потужних вузлів знадобиться багато (забігаючи вперед, зазначу, що йдеться не просто про клієнтів на мобільних телефонах — а про серйозні сервери).
Тому шардчейни об'єднують у собі облікові записи за двійковими префіксами їх ідентифікаторів: якщо шардчейн має префікс 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