Основные выводы

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

1. Асинхронная доставка сообщений: FunC, выбранный в качестве языка разработки, облегчает общение между узлами TON посредством обмена "сообщениями". Однако, поскольку TON работает как асинхронная цепочка, введение понятия логического времени (It) имеет решающее значение для правильной синхронизации сообщений между цепочками. Это достигается за счет того, что логическое время (lt) сообщений выполняется строго в хронологическом порядке, гарантируя точное выполнение информации.
2. Механизм маршрутизации сообщений в гиперкубе: В TON используется комбинация обычной и быстрой маршрутизации. Обычная маршрутизация передает сообщения между осколками через гиперкубическую структуру, включающую соседние узлы. Быстрая маршрутизация включает в себя доказательства Меркла, которые могут передавать сообщения по ребрам гиперкуба, увеличивая скорость.
3. PoS + консенсус BFT для развития экосистемы: POS позволяет избежать обширных вычислений в процессе генерации блоков, что приводит к повышению эффективности, снижению затрат и улучшению производительности сети, а также способствует практической реализации DAPP-приложений. Хотя DPOS работает быстрее, ее скорость доверия ниже, чем у систем BFT. Поэтому TON выбирает механизм консенсуса BFT.

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

1. Динамическая многошардовая архитектура: TON включает в себя три уровня - единый мастерчейн, несколько рабочих цепочек и шарды, которые могут динамически увеличиваться, уменьшаться и разделяться. Каждый шардчейн представляет собой совокупность различных цепочек учетных записей, и DAPP могут автономно активировать определенные шардчейны.
2. Быстро обновляемое глобальное состояние: Обновление глобального состояния включает в себя структуру, похожую на DAG, называемую "мешком ячеек". Он быстро обновляется, объединяя новый и старый набор клеток, удаляя старый корень. Одновременно с этим он использует механизм вертикального восстановления блоков для их обновления.

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

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

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

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

Чтобы решить проблему масштабируемости блокчейна, исследователи предложили различные решения для масштабирования, такие как шардинг, сайдчейн и решения второго уровня: Эти подходы направлены на повышение пропускной способности и производительности сети за счет разделения сети на более мелкие сегменты, создания независимых блокчейнов или дополнительных структур на основной цепи. Однако эти решения порождают новые технические проблемы и вопросы безопасности, такие как межплатная связь, межплатная передача активов и разработка механизма консенсуса.

1. Шардинг, например, подразумевает разделение всей сети блокчейн на более мелкие фрагменты или шарды, при этом каждый шард независимо обрабатывает часть транзакций и данных. Хотя этот механизм может улучшить общую пропускную способность и производительность сети, он по-прежнему сталкивается с проблемами, связанными с безопасностью и согласованностью межплатных коммуникаций и межплатных транзакций. Кроме того, механизмы шардинга должны учитывать разработку и реализацию механизмов консенсуса для обеспечения согласованности и безопасности всей сети.
2. Технология сайдчейн подразумевает создание и запуск независимых блокчейнов, соединенных с основной цепью в рамках сети блокчейн. Сайдчейны способствуют двусторонней передаче активов с основной цепью, имея при этом свои собственные правила и функциональность. Основной принцип технологии сайдчейн заключается в том, чтобы обрабатывать некоторые транзакции на сайдчейне, снимая нагрузку с основной цепи и обеспечивая более высокую масштабируемость и гибкость. Однако сайдчейн требует безопасных механизмов и протоколов для обеспечения сохранности активов и последовательности двусторонней передачи активов. Кроме того, при разработке и внедрении побочных цепочек необходимо учитывать совместимость и взаимодействие с основной цепочкой.
3. Rollup, с другой стороны, хранит большой объем данных о транзакциях вне цепи в сайдчейне и передает сводную информацию об этих транзакциях в главную цепь для проверки. Его преимущество заключается в значительном повышении масштабируемости и производительности сети блокчейн за счет хранения данных о транзакциях вне цепи и использования основной цепи для проверки. Однако при использовании подхода Rollup возникают проблемы, связанные с централизацией и безопасностью.
4. Новые механизмы консенсуса, такие как Proof of History (POH) от Solana, связывают временные метки с каждой транзакцией, обеспечивая верифицируемую временную последовательность для блокчейна. Эта временная последовательность может быть использована для проверки порядка и времени транзакций, сокращая расходы на связь и задержки в процессе консенсуса. Хотя Solana заявляет, что TPS достигает 65 000, фактическая пропускная способность данных, с учетом связи между узлами, составляет около 6-8 тысяч TPS (ежедневно около 4-5 тысяч).

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

Техническая архитектура TON

Адаптивная многоцепочечная конструкция с бесконечным разделением

Шардинг в TON осуществляется по принципу "снизу вверх": В то время как обычные схемы шардинга блокчейна обычно используют подход "сверху вниз", сначала создавая единый блокчейн, а затем разбивая его на интерактивные блокчейны для повышения производительности, в шардинге TON используется подход "снизу вверх". Он организует эти цепочки аккаунтов в шард-цепочки, образуя шард-цепочку, где рабочие цепочки существуют исключительно в виртуальной или логической форме. TON обеспечивает параллельную обработку транзакций в нескольких цепочках, называемых "блокчейн из блокчейнов". Такой подход эффективно повышает производительность системы.

В TON реализована динамическая архитектура шардинга, состоящая из мастер-цепи, рабочей цепи и шард-цепи: Мастерчейн координирует работу, в то время как фактическая обработка транзакций происходит в различных рабочих цепях и шардчейнах. Кроме того, шардинг в TON динамический, каждый аккаунт функционирует как шардчейн. Они могут адаптивно объединяться в более крупные цепочки шардов на основе взаимодействия между аккаунтами для решения задач динамического расширения.

1. Мастерчейн: Существует только один, включающий в себя параметры протокола, наборы валидаторов, соответствующие доли, а также записывающий текущие активные рабочие цепочки и подчинённые им шард-цепочки. Нижние цепи передают хэш последнего блока в мастерчейн, чтобы обеспечить определение последнего состояния при необходимости поиска сообщений между цепями.

Если шардинг достигнет своего предела, каждый шардчейн будет хранить только одну учетную запись или смарт-контракт. В результате возникает множество "цепочек аккаунтов", описывающих состояние и переходы отдельных аккаунтов, причем эти цепочки взаимно передают информацию, образуя Workchain через Shardchains.

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

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

Сообщение: Поскольку TON использует функцию FunC send_raw_message для разработки своего языка, сообщения, передаваемые узлами TON, называются "сообщениями". Транзакция в TON состоит из входящего сообщения, которое первоначально запускает ее, и набора исходящих сообщений, которые отправляются другим контрактам;

Гиперкубическая маршрутизация: Трехмерный структурированный механизм обмена сообщениями, позволяющий быстро доставлять и обрабатывать сообщения, созданные в одном блоке черепной цепочки, в следующий блок целевой черепной цепочки.

Асинхронная доставка сообщений

Асинхронные вызовы создают проблемы с синхронизацией: В синхронных блокчейнах транзакции могут включать в себя несколько вызовов смарт-контрактов. В асинхронных системах пользователи не могут оперативно получать ответы от целевого смарт-контракта в той же транзакции. Эта задержка связана с тем, что обработка вызовов по контракту может занять несколько блоков, а расстояние маршрутизации между исходным и конечным блоками влияет на этот процесс.

Чтобы добиться бесконечного шардинга, необходимо обеспечить полное распараллеливание сообщений, что привело к введению понятия логического времени: В TON каждая транзакция выполняется исключительно на одном смарт-контракте, а связь между контрактами осуществляется с помощью сообщений. Это вводит концепцию логического времени в асинхронных цепочках, позволяя синхронизировать сообщения между цепочками. Каждое сообщение имеет свое логическое время или время Лампорта (далее lt). Это время используется для отслеживания взаимосвязей между событиями и определения того, какие события валидаторы должны обрабатывать в первую очередь.

Логика выполнения гарантируется строгим соблюдением порядка выполнения сообщений lt: Сообщения, отправленные со счета, и транзакции, происходящие на счете, строго упорядочены, причем lt сгенерированных транзакций больше, чем lt сообщений. Кроме того, lt сообщений, отправленных в транзакции, строго больше, чем lt транзакции, вызвавшей эти сообщения. В случае нескольких сообщений, те, у которых меньше lt, обрабатываются раньше.

Механизм маршрутизации с помощью гиперкуба сообщений

В TON используется параллельное выполнение с быстрой маршрутизацией + медленной маршрутизацией:

Медленная маршрутизация: Более стабильный и традиционный метод межцепочечной обработки информации, при котором информация упаковывается в блок на исходной цепочке, а затем передается из одной цепочки осколков в другую через ретранслятор. Для передачи также можно использовать несколько промежуточных цепочек шардов. Все цепочки шардов образуют граф "гиперкуб", и сообщения распространяются по ребрам этого гиперкуба. После проверки валидаторами информация упаковывается в другой блок.

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

Быстрая маршрутизация: При медленной маршрутизации сообщения распространяются по граням гиперкуба. Чтобы ускорить процесс, Fast Routing позволяет валидаторам цепочки шардов назначения заранее обработать сообщение, предоставить доказательство Меркла и отправить квитанцию, чтобы уничтожить передающее сообщение.

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

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

"Мешок ячеек": Набор ячеек, обновляемый подобно направленному ациклическому графу (Directed Acyclic Graph, DAG). Для этого нужно представить новое состояние как еще один "мешок ячеек" с собственным корнем, а затем объединить новый и старый наборы ячеек, одновременно удалив старый корень.

Вертикальный ремонт блоков: В цепочках шардов TON каждый блок - это не просто отдельный блок, а цепочка. Когда необходимо исправить блок в ошибочной цепочке шардов, в "вертикальную цепочку блоков" будет отправлен новый блок для замены.

Консенсус

POS-сеть состоит из трех ролей:

1. Узлы валидатора: Участвуют в поддержании безопасности сети, делая ставку в 300 000 TON при выполнении требований к оборудованию. Блоки создаются 100-1000 избранными узлами, избираемыми ежемесячно. На время работы избранные узлы делятся на несколько рабочих групп для создания новых блоков. Для того чтобы каждый новый блок считался успешно созданным, необходимо получить подписи более 2/3 узлов рабочей группы. Вредоносное поведение может привести к слэшингу и дисквалификации.
2. Fisherman: Действует как контролер, посылая недействительные доказательства, чтобы проверить, насколько тщательно узлы валидатора выполнили свои задачи по проверке.
3. Номинатор: Предлагает новые блоки-кандидаты в цепочке шардов узлам-валидаторам. Если блок избран, куратор получает прибыль. Они отвечают за проверку состояния цепочки шардов и соседних данных цепочки шардов и отправляют их узлам-валидаторам.

BFT (Byzantine Fault Tolerance): 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 из PKU blockchain Association]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.