Вступ: Після того, як Binance запустила Notcoin, найбільшу гру в екосистемі TON, і її повністю циркулююча економіка токенів створила величезний ефект багатства, TON швидко привернула багато уваги. Спілкуючись з друзями, я з'ясував, що TON має високий технічний бар'єр і його модель розробки DApp сильно відрізняється від основних блокчейн-протоколів. Отже, я витратив деякий час на глибоке дослідження цієї теми і маю поділитися з вами деякими ідеями. У шорт році основна філософія дизайну TON полягає в тому, щоб перебудувати традиційні блокчейн-протоколи з нуля, зосередившись на досягненні високого рівня паралелізму та масштабованості, навіть якщо це означає пожертвувати сумісністю.

TON Основні принципи проектування - високий паралелізм і масштабованість

Можна сказати, що мета всіх складних технологічних виборів у TON походить від прагнення до високого паралелізму та високої масштабованості. Звичайно, нам не складно зрозуміти це на тлі його народження. TON, або The Open Network, — це децентралізована обчислювальна мережа, яка включає блокчейн L1 і кілька компонентів. TON спочатку був розроблений засновником Telegram Миколою Дуровим та його командою, а зараз підтримується та підтримується глобальною спільнотою незалежних авторів. Його народження датується 2017 роком, коли команда Telegram почала досліджувати блокчейн-рішення для себе. Оскільки жоден існуючий на той час блокчейн L1 не міг підтримка дев'ятизначну базу користувачів Telegram, вони вирішили розробити власний блокчейн, який тоді називався Telegram Open Network. Час настав у 2018 році. У ордер, щоб отримати ресурси, необхідні для реалізації TON, Telegram запустив продаж токенів Gram (пізніше перейменованих в Toncoin) в першому кварталі 2018 року. У 2020 році команда Telegram вийшла з проєкту TON через регуляторні проблеми. Згодом невелика група розробників з відкритим вихідним кодом і переможців конкурсу Telegram взяла на себе кодову базу TON, перейменувала проект в The Open Network і продовжує активно розвивати блокчейн донині, дотримуючись принципів, викладених в оригінальній TON білій книзі.

Оскільки TON був розроблений як децентралізоване середовище виконання Telegram, він повинен був вирішити дві основні проблеми: велику кількість одночасних запитів і масив даних. Навіть найвища перевірена TPS (транзакцій в секунду) Solana, яка претендує на звання найшвидшої, становить лише 65 000, що набагато шорт мільйонного TPS рівня, необхідного для Telegram. Крім того, величезною кількістю даних, що генеруються Telegram, не можна керувати блокчейном, де кожен вузол зберігає повну копію даних.

Щоб вирішити ці проблеми, TON оптимізував основні блокчейн-протоколи двома способами:

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

l Завдяки впровадженню повністю паралельного середовища виконання, заснованого на моделі Actor, значно покращується мережевий TPS;

Побудова Блокчейн ланцюжків - надання кожному обліковому запису власного виділеного ланцюга через Infinite Шардинг

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

По суті, ланцюгова структура TON складається з чотирьох шарів

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

ShardChain: У більшості контекстів ShardChain є фактичною одиницею в TON. ShardChain — це, по суті, набір ланцюжків облікових записів.

WorkChain: також відомий як набір ланцюгів сегментів даних із користувацькими правилами, такими як створення WorkChain на основі EVM для запуску Solidity смартконтракти. Теоретично, будь-хто в спільноті може створити свій власний WorkChain. Однак його будівництво є досить складним і вимагає сплати (високої) плати за створення та отримання схвалення від 2/3 валідатори.

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

Ця парадигма наділяє TON мережу трьома ключовими особливостями:

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

Висока масштабованість: Завдяки нескінченній парадигмі шардингу TON може підтримка майже необмежену кількість шардів, теоретично до 2^60 WorkChains.

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

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

Припустимо, обліковий запис A в WorkChain 1 хоче надіслати повідомлення до облікового запису C у WorkChain 3. Для цього потрібно розробити рішення для маршрутизації повідомлень. У цьому прикладі є два шляхи маршрутизації: WorkChain 1 -> WorkChain 2 -> WorkChain 3 і WorkChain 1 -> WorkChain 4 -> WorkChain 3.

У більш складних сценаріях для швидкої передачі повідомлень необхідний ефективний і недорогий алгоритм маршрутизації. TON використовує «алгоритм маршрутизації гіперкуба» для виявлення маршрутизації крос-ланцюг повідомлень. Гіперкубічна структура — це особлива топологія мережі, де n-вимірний гіперкуб має 2^n вершин, кожна з яких однозначно ідентифікується n-бітним двійковим числом. У цій структурі будь-які дві вершини є суміжними, якщо їх бінарні представлення відрізняються лише на один біт. Наприклад, у тривимірному гіперкубі вершини 000 і вершини 001 є суміжними, оскільки вони відрізняються лише останнім бітом. Наведений вище приклад є 2-вимірним гіперкубом.

У протокол маршрутизації гіперкуба маршрутизація повідомлення від вихідного WorkChain до цільового WorkChain здійснюється шляхом порівняння їх двійкових адрес. Алгоритм знаходить мінімальну відстань між цими адресами (тобто кількість різних бітів) і пересилає повідомлення через сусідні робочі ланцюжки, доки воно не досягне місця призначення. Це гарантує, що пакет даних йде найкоротшим шляхом, підвищуючи ефективність мережевого зв'язку. Щоб спростити цей процес, TON також пропонує оптимістичне рішення. Якщо користувач може надати дійсний доказ шляху маршрутизації, як правило, корінь спроби Меркла, вузол може негайно перевірити справжність повідомлення. Це називається миттєвою гіперкубовою маршрутизацією. В результаті адреси TON значно відрізняються від адрес в інших блокчейн-протоколах. Більшість блокчейн-протоколів використовують хеш відкритого ключа, згенерованого еліптичними алгоритмами шифрування, як адресу, зосереджуючись на унікальності, не потребуючи функцій маршрутизації. У TON адреси складаються з двох частин: (workchain_id, рахунок_id), причому workchain_id закодовані відповідно до алгоритму маршрутизації гіперкуба. Можна задатися питанням, чому б не передати всю крос-ланцюг інформацію через MasterChain, подібно до Cosmos. У дизайні TON MasterChain справляється лише з найважливішим завданням підтримки завершеності WorkChains. Хоча можна маршрутизувати повідомлення через MasterChain, пов'язані з цим комісії будуть непомірно високими.

Наостанок коротко обговоримо його алгоритм консенсусу. TON використовує комбінацію BFT (Помилка Візантійців толерантність) і PoS (Доказ стейкінгу). Це означає, що будь-який стейкер може брати участь у створенні блоку. Контракт TON управління виборами періодично вибирає групу валідатори випадковим чином з усіх стейкерів. Ці вибрані валідатори потім використовують алгоритм BFT для створення блоків. Якщо валідатор створює недійсні блоки або діє зловмисно, його токени стейкінгу конфіскуються. І навпаки, вони отримують винагороду за успішне створення валідних блоків. Цей метод досить поширений, тому ми не будемо тут вдаватися в подробиці.

Смарт-контракти, що використовують модель Actor у повністю паралельному середовищі виконання

Ще однією ключовою відмінністю TON порівняно з основними протоколами блокчейну є середовище виконання смарт-контрактів. Щоб подолати TPS обмеження, з якими стикаються основні блокчейн-протоколи, TON використовує підхід проектування «знизу-вгору» та використовує модель Actor для реконструкції смартконтракти та їх виконання, забезпечуючи повністю паралельні можливості виконання.

Більшість основних блокчейн-протоколів використовують однопотокове послідовне середовище виконання. Наприклад, середовище виконання Ethereum, EVM, працює як машина-стан, яка обробляє транзакції послідовно. Після того, як блок сформований і впорядковані транзакції, вони виконуються одна за одною через EVM. Цей повністю послідовний, однопотоковий процес означає, що в будь-який момент часу обробляється лише одна транзакція. Перевага полягає в тому, що після встановлення ордер транзакції результати виконання залишаються незмінними в розподіленій мережі. Крім того, оскільки одночасно виконується лише одна транзакція, жодні інші транзакції не можуть змінити стан даних, до яких здійснюється доступ, забезпечуючи сумісність між смартконтракти. Наприклад, при використанні Uniswap для покупки ETH за USDT розподіл пул ліквідності є фіксованим значенням під час виконання. Це дозволяє математичним моделям визначати точний результат. І навпаки, якби інші постачальники ліквідності додали ліквідність під час розрахунку крива зв'язку, результати були б застарілими, що явно неприпустимо.

Однак ця архітектура також має чіткі обмеження, зокрема вузьке місце TPS, яке здається застарілим із сучасними багатоядерними процесорами. Це схоже на гру в старі комп'ютерні ігри, такі як Red Alert, на абсолютно новому комп'ютері; Коли кількість бойових одиниць досягає певного рівня, ви все одно стикаєтеся зі значним відставанням. Це пов'язано з проблемами архітектури програмного забезпечення.

Деякі протоколи вирішують цю проблему і запропонували свої паралельні рішення. Наприклад, Solana, який претендує на найвищий TPS, також підтримує паралельне виконання. Однак дизайн Solana відрізняється від TON. Основна ідея Solana полягає в тому, щоб згрупувати всі транзакції на основі їх залежностей виконання, гарантуючи, що різні групи не обмінюються жодними даними стану. Це означає, що немає спільних залежностей, що дозволяє транзакціям у різних групах виконуватися паралельно без конфліктів. Транзакції в межах однієї групи, як і раніше, виконуються послідовно.

На противагу цьому, TON повністю відмовляється від послідовної архітектури виконання і приймає парадигму розробки, спеціально розроблену для паралелізму, використовуючи модель Actor для реконструкції середовища виконання. Акторська модель, вперше запропонована Карлом Г'юїттом у 1973 році, має на меті вирішити складність спільних станів у традиційних паралельних програмах за допомогою передачі повідомлень. Кожен Актор має свій власний приватний стан і поведінку і не ділиться інформацією про стан з іншими Суб'єктами. Модель Actor — це модель паралелізму обчислень, яка забезпечує паралельну обробку за допомогою передачі повідомлень. У цій моделі «Актор» є базовою одиницею, яка може обробляти отримані повідомлення, створювати нових акторів, надсилати додаткові повідомлення та вирішувати, як відповідати на наступні повідомлення. Модель Actor повинна володіти наступними характеристиками:

Інкапсуляція та незалежність: Кожен суб'єкт працює абсолютно незалежно під час обробки повідомлень, забезпечуючи паралельну обробку повідомлень без перешкод.

Передача повідомлень: Актори взаємодіють виключно за допомогою надсилання та отримання повідомлень, при цьому передача повідомлень є асинхронною.

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

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

1. Асинхронні виклики Смарт-контракт: У TON році неможливо атомарно викликати зовнішні контракти або отримати доступ до даних зовнішніх контрактів протягом смартконтракти. У Solidity, наприклад, функція контракту A1 може викликати функцію контракту B2 або отримати доступ до певних даних стану через функцію лише для читання контракту C3, і все це в одній транзакції. Однак у TON цього досягти не вдається. Будь-яка взаємодія із зовнішніми смартконтракти буде виконуватися асинхронно шляхом створення нових транзакцій, які називаються внутрішніми повідомленнями, ініційованими смартконтракти. Процес виконання не можна заблокувати, щоб дочекатися результату.

Наприклад, якщо ми розробляємо DEX і дотримуємося загальної парадигми EVM, у нас зазвичай є уніфікований контракт маршрутизатора для управління маршрутизацією транзакцій, в той час як кожен пул самостійно управляє даними LP для конкретних торгових пар. Припустимо, у нас є два басейни: USDT-DAI і DAI-ETH. Коли користувач хоче купити ETH безпосередньо за USDT, він може використовувати контракт маршрутизатора для послідовної взаємодії з цими двома пулами в одній атомарній транзакції. Однак у TON цей процес не такий простий і вимагає іншого підходу до розробки. Якщо ми спробуємо повторно використовувати цю парадигму EVM, то інформаційний потік буде включати зовнішнє повідомлення, ініційоване користувачем, і три внутрішні повідомлення для завершення транзакції (зауважте, що цей приклад призначений для того, щоб підкреслити відмінності; в реальній розробці навіть парадигма ERC20 повинна бути перероблена).

1. Необхідно ретельно враховувати обробку помилок у міжконтрактних викликах, розробляючи відповідні функції відмов для кожної міжконтрактної взаємодії. У основних системах EVM, якщо під час виконання транзакції виникає помилка, вся транзакція відкочується до початкового стану. У серійній однопотоковій моделі це просто. Однак у TON році, оскільки міжконтрактні виклики виконуються асинхронно, якщо помилка виникає на більш пізньому етапі, раніше успішно виконані транзакції вже підтверджені, що потенційно може спричинити проблеми. Тому TON ввела спеціальний тип повідомлення, який називається повідомленням про відмову. Якщо під час подальшого виконання внутрішнього повідомлення виникає помилка, тригерний контракт може використовувати функцію відскоку, зарезервовану в контракті, що запускає, для скидання певних станів у контракті, що запускає.

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

У цій моделі А і В представляють два смартконтракти. Якщо msg1_lt < msg2_lt, то tx1_lt < tx2_lt з точки зору послідовності.

Однак в більш складних ситуаціях це правило можна порушити. В офіційній документації наведено приклад: припустимо, що у нас є три контракти: А, В і С. В одній транзакції A надсилає два внутрішні повідомлення, msg1 і msg2, одне до B, а інше до C. Незважаючи на те, що вони створюються в певному ордер (спочатку msg1, потім msg2), ми не можемо бути впевнені, що msg1 буде оброблено до msg2. Ця невизначеність виникає через те, що маршрути від А до В і від А до С можуть відрізнятися за довжиною та наборами валідаторів. Якщо ці контракти знаходяться в різних шард-ланцюжках, одному повідомленню може знадобитися кілька блоків, щоб досягти цільового контракту. Таким чином, існує два можливі шляхи транзакцій, як показано на малюнку.

1. У TON персистентне сховище для смартконтракти використовує структуру орієнтований ациклічний граф (DAG) з осередками як одиницями. Дані компактно стискаються в комірку відповідно до певних правил кодування і DAG простягаються вниз. Це контрастує зі структурою на основі хеш-карт, яка використовується в EVM для державних даних. У зв'язку з різними алгоритмами доступу до даних, TON призначає різну газ ціни на обробку даних на різній глибині; Більш глибока обробка клітинних даних вимагає більше газ. Отже, TON стикається з типом DOS-атаки, коли зловмисники наповнюють смарт-контракт великою кількістю небажаних повідомлень, заповнюючи всі неглибокі комірки. Це збільшує витрати на зберігання для чесних користувачів. На противагу цьому, хеш-карта EVM має складність запиту O(1), що забезпечує узгодженість витрат на газ та уникає подібних проблем. Тому розробникам TON Dapp слід уникати використання необмежених типів даних у смартконтракти. Коли необхідні необмежені типи даних, їх слід розбити на розділи за допомогою шардингу.

1. Деякі функції менш унікальні, наприклад, вимога до смартконтракти платити орендну плату за зберігання. У TON смартконтракти за своєю суттю можна оновлювати та поставляти з нативними абстрактними функціями рахунок, що означає, що всі адреси гаманців у TON смартконтракти, просто неініціалізовані. Розробникам потрібно звернути пильну увагу на ці аспекти.

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

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