Ключі на винос

TON має основну технологічну логіку, зосереджену навколо високошвидкісних додатків: TON походить від Telegram із транзакціями, які записуються безпосередньо в ланцюжку на основі повідомлень, підтримуючи одноранговий зв’язок.

1. Асинхронна доставка повідомлень: FunC, обраний як мова розробки, полегшує спілкування між вузлами TON шляхом обміну «повідомленнями». Однак, оскільки TON працює як асинхронний ланцюг, введення концепції логічного часу (It) має вирішальне значення для правильної синхронізації повідомлень між ланцюжками. Це досягається шляхом забезпечення того, що логічний час (lt) повідомлень строго виконується в хронологічному порядку, гарантуючи точне виконання інформації.
2. Механізм маршрутизації повідомлень Hypercube: TON використовує комбінацію звичайної маршрутизації та швидкої маршрутизації. Звичайна маршрутизація передає повідомлення між фрагментами через структуру гіперкуба, що включає суміжні вузли. Швидка маршрутизація включає докази Merkle, які можуть передавати повідомлення по краях гіперкуба, підвищуючи швидкість.
3. Консенсус PoS + BFT для розвитку екосистеми: POS уникає великих обчислень під час процесу генерації блоків, що призводить до підвищення ефективності, зниження витрат і покращення продуктивності мережі, що сприяє практичному впровадженню програм DAPP. Хоча DPOS швидший, його довірча швидкість нижча, ніж у систем BFT. Тому TON вибирає механізм консенсусу BFT.

Динамічна мультишардова архітектура TON полегшує масштабованість додатків: TON підвищує швидкість за допомогою паралельних запитів, покращує точність запитів за допомогою динамічного шардингу та підвищує розширюваність за допомогою структури клітинок.

1. Динамічна мультишардова архітектура: TON складається з трьох рівнів – одного головного ланцюга, кількох робочих ланцюжків і шардчейнів, які можуть динамічно збільшуватися, зменшуватися та розділятися. Кожен шардчейн — це набір різних ланцюжків облікових записів, і DAPP можуть автономно активувати певні шардчейни.
2. Швидко оновлюваний глобальний стан. Оновлення глобального стану включає структуру, подібну до DAG, яка називається «мішок клітин». Він швидко оновлюється, поєднуючи новий і старий набір клітинок, видаляючи старий корінь. Одночасно він використовує механізм відновлення вертикальних блоків для оновлення блоків.

TON продовжуватиме оптимізувати свою технічну структуру в майбутньому: завдяки паралельному розширенню, запровадженню інструментів сегментування ланцюгів і посиленню перевірок вузлів TON прагне зберегти свої переваги у швидкості та масштабованості.

Проблеми масштабування блокчейна

Масштабованість блокчейну є важливою технічною проблемою та ключовим рушієм для розвитку технології блокчейну: у міру зростання додатків блокчейну та збільшення кількості користувачів існуючі мережі блокчейну часто стикаються з проблемами недостатньої пропускної здатності та тривалого часу підтвердження транзакцій. Традиційні конструкції блокчейнів обмежують їх здатність обробляти великомасштабні транзакції та вимоги користувачів, що призводить до перевантаження мережі, високих транзакційних витрат і неефективності.

Проблеми масштабованості блокчейну в першу чергу виникають через розподілену архітектуру та механізми консенсусу: механізм консенсусу та розподілена природа блокчейну вимагають, щоб кожен вузол у мережі перевіряв і записував усі транзакції, що обмежує пропускну здатність мережі. Крім того, безпека та децентралізовані функції блокчейну вимагають, щоб усі вузли підтримували повні копії блокчейну, що збільшує навантаження на зберігання та передачу.

Щоб вирішити проблему масштабованості блокчейну, дослідники запропонували різні рішення для масштабування, такі як шардинг, бічні ланцюжки та рішення рівня 2: ці підходи спрямовані на підвищення пропускної здатності та продуктивності мережі шляхом поділу мережі на менші сегменти, впровадження незалежних блокчейнів або створення додаткових структур. на головному ланцюзі. Однак ці рішення створюють нові технічні проблеми та проблеми безпеки, такі як міжшардовий зв’язок, міжшардові передачі активів і конструкція механізму консенсусу.

1. Наприклад, шардинг передбачає поділ усієї мережі блокчейну на менші фрагменти або шарди, причому кожен шард незалежно обробляє частину транзакцій і даних. Незважаючи на те, що цей механізм може підвищити загальну пропускну здатність і продуктивність мережі, він все ще стикається з проблемами, пов’язаними з безпекою та узгодженістю міжшардового зв’язку та транзакцій між сегментами. Крім того, механізми шардингу повинні стосуватися розробки та впровадження механізмів консенсусу для забезпечення узгодженості та безпеки загальної мережі.
2. Технологія Sidechain передбачає створення та запуск незалежних блокчейнів, підключених до основного ланцюга в мережі блокчейнів. Сайдчейни полегшують двосторонню передачу активів з основним ланцюгом, маючи власні правила та функціональні можливості. Основний принцип технології бічного ланцюга полягає в обробці деяких транзакцій у бічному ланцюзі, звільняючи навантаження від основного ланцюга та забезпечуючи більшу масштабованість і гнучкість. Однак бічні ланцюги вимагають безпечних механізмів і протоколів для забезпечення безпеки активів і послідовності в двосторонніх передачах активів. Крім того, розробка та впровадження бічних ланцюгів повинні враховувати сумісність і взаємодію з основним ланцюгом.
3. З іншого боку, Rollup зберігає великий обсяг даних транзакцій поза ланцюгом у сайдчейні та передає зведену інформацію про ці транзакції в основний ланцюг для перевірки. Його перевага полягає в значному покращенні масштабованості та продуктивності мережі блокчейну завдяки зберіганню даних транзакцій поза ланцюгом і використанню основного ланцюга для перевірки. Однак із підходом Rollup існують проблеми щодо централізації та безпеки.
4. Нові механізми консенсусу, такі як Proof of History (POH) Solana, пов’язують мітки часу з кожною транзакцією, забезпечуючи перевірену послідовність часу для блокчейну. Ця часова послідовність може бути використана для перевірки порядку транзакції та часу, зменшуючи витрати на зв’язок і затримки в процесі консенсусу. У той час як Solana заявляє про TPS до 65 000, фактична пропускна здатність даних, враховуючи зв’язок між вузлами, становить близько 6-8 тис. TPS (щоденно близько 4-5 тис.).

TON blockchain, що походить від Telegram, був задуманий з ідеєю обслуговування величезної бази користувачів: Telegram є однією з найпопулярніших соціальних платформ у світі, яка може похвалитися понад 800 мільйонами активних користувачів щомісяця та щодня передає мільярди повідомлень через програмне забезпечення. TON, як набіг Telegram на web3, був розроблений із самого початку, щоб обслуговувати мільярди користувачів, а не лише невелику базу користувачів.

Технічна архітектура TON

Адаптивний нескінченний дизайн із кількома ланцюгами

Шардинг у TON є «знизу вгору». У той час як у звичайних схемах шардингу блокчейнів зазвичай використовується підхід «зверху вниз», спочатку встановлюючи єдиний блокчейн, а потім розбиваючи його на інтерактивні блокчейни для підвищення продуктивності, шардинг у TON використовує підхід «знизу вгору». Він організовує ці ланцюжки облікових записів у шардчейни, утворюючи Shardchain, де робочі ланцюжки існують виключно у віртуальній або логічній формі. TON забезпечує паралельну обробку транзакцій у кількох ланцюгах, що називають «блокчейном блокчейнів». Такий підхід ефективно підвищує продуктивність системи.

TON має динамічну архітектуру шардингу, яка складається з головного ланцюга, робочого ланцюга та сегментного ланцюга: головний ланцюг координує, тоді як фактична обробка транзакцій відбувається в різних робочих ланцюгах і сегментних ланцюгах. Крім того, сегментування TON є динамічним, коли кожен обліковий запис функціонує як шардчейн. Вони можуть адаптивно об’єднуватися у більші шардчейни на основі взаємодії між обліковими записами для задоволення потреб у динамічному розширенні.

1. Masterchain: існує лише один, що включає параметри протоколу, набори валідаторів, відповідні спільні ресурси та запис поточних активних робочих ланцюжків та їхніх підпорядкованих сегментів. Нижчі ланцюги передають останній хеш блоку в головний ланцюг, щоб забезпечити визначення останнього стану, коли потрібне отримання міжланцюжкового повідомлення.

Якщо шардинг досягає ліміту, кожен шардчейн зберігатиме лише один обліковий запис або смарт-контракт. Це призводить до появи численних «ланцюжків облікових записів», які описують стан і переходи окремих облікових записів, причому ці ланцюжки взаємно передають інформацію, утворюючи робочий ланцюжок через Shardchains.

1. Workchain: це віртуальна концепція, яка існує як колекція Shardchains, причому система підтримує до 2^32 Workchains. Кожен Workchain може гнучко налаштовувати правила, такі як типи транзакцій, типи токенів, смарт-контракти та формати адрес, за умови дотримання стандартів сумісності. Однак для ефективного обміну повідомленнями робочі ланцюги повинні використовувати однаковий формат черги повідомлень, що передбачає однакові гарантії безпеки для всіх робочих ланцюгів.
2. Shardchain: щоб підвищити ефективність обробки, Shardchains автоматично розділяються під час високих навантажень і зливаються під час знижених навантажень. Кожен робочий ланцюг далі ділиться на шард-ланцюги (до 2^60). Shardchains розподіляє роботу між усіма Shardchains, причому кожен обслуговує лише частину колекції облікових записів.

Механізми передачі інформації

Повідомлення: оскільки TON використовує функцію send_raw_message FunC для розробки своєї мови, повідомлення, що передаються вузлами TON, називаються «повідомленнями». Транзакція в TON складається з вхідного повідомлення, яке спочатку запускає її, і набору вихідних повідомлень, які надсилаються іншим контрактам;

Маршрутизація Hypercube: тривимірний структурований механізм обміну повідомленнями, який дозволяє повідомленням, створеним в одному блоці сегментованого ланцюга, швидко доставлятися та оброблятися до наступного блоку цільового сегментованого ланцюга.

Асинхронна доставка повідомлень

Асинхронні виклики створюють проблеми синхронізації: у синхронних блокчейнах транзакції можуть включати кілька викликів смарт-контракту. В асинхронних системах користувачі не можуть миттєво отримувати відповіді від цільового смарт-контракту в одній транзакції. Ця затримка пов’язана з тим, що для обробки контрактних викликів може знадобитися кілька блоків, а на цей процес впливає відстань маршрутизації між блоками джерела та призначення.

Щоб досягти нескінченного шардингу, важливо забезпечити повне розпаралелювання повідомлень, що призводить до введення концепції логічного часу: у TON кожна транзакція виконується виключно на одному смарт-контракті та обмінюється інформацією між контрактами за допомогою повідомлень. Це вводить концепцію логічного часу в асинхронних ланцюжках, уможливлюючи синхронізацію повідомлень між ланцюжками. Кожне повідомлення має свій логічний час або час Лампорта (надалі lt). Цей час використовується для відстеження зв’язків між подіями та визначення того, які події валідатори мають обробити першими.

Логіка виконання гарантується суворим дотриманням порядку виконання повідомлення lt: повідомлення, надіслані з облікового запису, і транзакції, що відбуваються в обліковому записі, строго впорядковані, причому lt згенерованих транзакцій перевищує lt повідомлень. Крім того, lt повідомлень, надісланих у транзакції, строго перевищує lt транзакції, яка ініціює повідомлення. У разі кількох повідомлень ті з нижчим значенням lt обробляються раніше.

Механізм маршрутизації повідомлень Hypercube

TON використовує паралельне виконання з швидкою маршрутизацією + повільною маршрутизацією:

Повільна маршрутизація: більш стабільний і традиційний метод обробки інформації між ланцюжками, де інформація упаковується в блок у вихідному ланцюжку, а потім передається з одного ланцюжка фрагментів до іншого через ретранслятор. Кілька проміжних ланцюжків фрагментів також можуть використовуватися для передачі. Усі ланцюжки сегментів утворюють граф «гіперкуб», і повідомлення поширюються по краях цього гіперкуба. Після перевірки валідаторами інформація упаковується в інший блок.

Перевага повільної маршрутизації полягає у вищій безпеці та децентралізації, оскільки вся інформація має пройти повний процес підтвердження блоку. Для мережі гіперкубів із ланцюгів фрагментів із масштабом N кількість переходів маршрутів = log16(N). Таким чином, лише 4 вузли маршрутизації необхідні для підтримки мільйона сегментів.

Швидка маршрутизація: у повільній маршрутизації повідомлення поширюються по краях гіперкуба. Щоб пришвидшити швидкість, Fast Routing дозволяє валідаторам цільового шардового ланцюжка заздалегідь обробити повідомлення, надати підтвердження Merkle та надіслати квитанцію, щоб знищити повідомлення, що передається.

Швидка маршрутизація є швидшою (вузли можуть знайти оптимальний шлях) і запобігає подвійній доставці. Однак він не може замінити повільну маршрутизацію, оскільки валідатори не караються за втрату квитанцій, що становить певний ризик для безпеки.

Глобальний стан шардованого блокчейну

«Пакет комірок»: набір комірок, оновлених у спосіб, подібний до спрямованого ациклічного графа (DAG). Це передбачає представлення нового стану як іншого «мішка клітин» із власним коренем, а потім об’єднання нових і старих наборів клітин з одночасним видаленням старого кореня.

Вертикальний ремонт блоків: у ланцюжках сегментів TON кожен блок — це не просто один блок, а ланцюжок. Коли необхідно виправити блок в помилковому ланцюжку шардів, новий блок буде подано в «вертикальний ланцюг блоків» для заміни блоку.

Консенсус

POS-мережа складається з трьох ролей:

1. Вузли перевірки: учасники підтримки безпеки мережі шляхом ставки 300 000 ТОН на виконання вимог до обладнання. Блоки створюються від 100 до 1000 вибраних вузлів, які обираються щомісяця. Під час свого перебування обрані вузли поділяються на кілька робочих груп для створення нових блоків. Кожен новий блок потребує підписів від понад 2/3 залучених вузлів у робочій групі, щоб вважатися успішно створеним. Зловмисна поведінка може призвести до покарання та дискваліфікації.
2. Рибалка: діє як наглядач, надсилаючи недійсні докази, щоб перевірити, чи вузли валідатора ретельно виконали свої завдання перевірки.
3. Номінатор: пропонує вузлам перевірки нові блоки-кандидати ланцюга сегментів. Якщо блок обирається, куратор отримує прибуток. Вони відповідають за перевірку стану ланцюга сегментів і сусідніх даних ланцюга сегментів і надсилання їх до вузлів перевірки.

BFT (Візантійська відмовостійкість): TON після зважування варіантів вибирає BFT замість DPOS через вищий рівень довіри та швидкість, незважаючи на те, що DPOS є швидшим.

Нова структура TON може підтримувати високошвидкісну передачу інформації TG

TON досягає високої швидкості та завершеності транзакцій завдяки динамічній мультишардовій архітектурі: кожен гаманець користувача в TON може мати власний ланцюжок, а теоретична основа для високого TPS включає паралельне обчислення сегментів, підтримку миттєвого міжшардового зв’язку та підтримку TVM асинхронне обчислення.

TON забезпечує більшу масштабованість завдяки механізму передачі інформації: у блокчейні TON виклики між смарт-контрактами є асинхронними, а не атомарними. Це означає, що коли один смарт-контракт викликає інший, виклик не виконується негайно, а обробляється в майбутньому блоці після завершення транзакції. Ця конструкція забезпечує більшу масштабованість, оскільки не вимагає завершення обробки всіх транзакцій в одному блоці.

TON продовжуватиме оптимізувати технічну структуру в майбутньому…

Технічна дорожня карта TON постійно покращуватиме швидкість і переваги масштабованості TON:

1. Розділення сортувальників і валідаторів.
2. Покращення масштабованості та швидкості: можливість паралельного розширення TON при обробці великої кількості транзакцій.
3. Посібники та інструменти для шардингу ланцюжків: упорядкування посібників і прикладів коду для обробки великих навантажень роботи TON на біржах, платіжних системах і службах TON.
4. Покращення координації між вузлами валідаторів: посилення та покращення виявлення та покарання валідаторів, які погано працюють.

Відмова від відповідальності:

1. Цю статтю передруковано з [community.tonup]. Усі авторські права належать оригінальному автору [Kiwi from PKU blockchain Association]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.