TON Blockchain Architecture

TON Blockchain Architecture система зберігання та управління даними в TON:

• організація даних як bag of cells;
• шардування на рівні облікових записів (ISP);
• умови консенсусу та валідації;
• masterchain координує всі шарди і параметри мережі.

Bag of Cells#

Всі дані TON представлені колекцією клітини (cells). Кожна клітина містить:

• до 1023 біт даних;
• до 4 посилання на інші ячейки (по SHA-256-хешам);
• 2 байти дескриптора + самі дані.

Ячейки організовані в дерева або DAG (Directed Acyclic Graph). Серіалізація по схемам TL-B (Type Language — Binary).

Infinite Sharding Paradigm (ISP)#

Кожний обліковий запис є окремим accountchainВіртуальні блоки accountchain групируються в блокчейн для ефективності.

Становлення шардчейна = стан всіх рахунків шарда. Блок шардчейна = колекція віртуальних блоків для деяких облікових записів.

У TON немає різниці між "смарт-контрактом" і "аккаунтом" - це одна суть.

Структура блоку шардчейна#

Розділяється на 2 частини:

Нерозділена (non-split)

Розділена (split)

Hashmap account_id → account_state. State акаунту:

• баланс в Grams;
• код смарт-контракту;
• постійні дані контракту;
• статистика використання сховища;
• опціональне формальне опис інтерфейсу;
• публічна інформація користувача.

Masterchain#

• Не поділяється і не об'єднує (single chain);
• Один попередник (крім нульового блоку з initial config);
• Має список всіх активних шардів і останніх блоків кожного;
• Зберігає конфігурувані параметри через спеціальний конфігураційний контракт.

Конфігураційні параметри

• Мінімальний взнос валідаторів;
• Максимальний розмір групи валідаторів;
• Максимальна кількість блоків, за які відповідає група;
• Процес вибору та покарання валідаторів;
• поточний і наступний набори валідаторів;
• Процес зміни параметрів.

Початкові значення та код фундаментальних смарт-контрактів в нульовий блок masterchain.

Умови консенсусу#

Гарантують правильність зміни даних тільки через дійсні транзакції.

Блок дійснийВідповідальність валідаторів генерація і перевірка.

Логічний час (LT)#

64-бітне невід'ємне ціле, призначається подіям:

• Залежне події LT має більше всіх своїх залежностей;
• Незалежна подія має LT = 0;
• Вихідні повідомлення успадкують LT з транзакції;
• Транзакція та блок мають часний інтервал, що фіксується в заголовку.

LT потрібен для упорядкування подій без глобальних годинників.

Загальний стан і видимість#

• Блок masterchain фіксує стан всіх шардів через хеш їх останніх блоків;
• Блок шардчейна містить хеш останнього блоку masterchain в заголовку;
• ** Видимі блоки** ті, що зазначені в цьому блоці masterchain + їх попередники;
• Блок шарда імпортує повідомлення з OutMsgQueue видимих сусідів; не може включити повідомлення з невидимих блоків.

Смарт-контракти#

Створення

Використовується для базового воркчейна і masterchain (інші ворхчеїни можуть мати свої механізми):

1. Повідомлення на раніше не згаданий адрес з значення → створює непочаткований обліковий запис з балансом, але без коду і даних;
2. Повідомлення конструктора містить initial code + data → створює смарт-контракт;
3. Constructor зазвичай несе значення для початкового балансу (мінімум залежить від storage-fee);
4. Смарт-контракти можуть створювати самостійно нові смарт-контракти для транзакцій.

Модифікація

• Постійні дані змінюються при виконанні коду в TVM;
• Якщо код не передбачає змін → дані незмінні;
• Сам код може бути змінено тільки якщо поточний код дозволяє це зробити.

Знищення і замороження

• Контракт не можна знищити, поки баланс > мінімум;
• При негативного балансу акаунт замерзає code + data замінюються на 32-байтовий хеш;
• Хеш зберігається деякий час → власник може відновити обліковий запис, перераховуючи кошти і відправляючи повідомлення з code + data.

Подібні статті#

• PoS
• Node
• Validators
• The Open Network