Введение: После того, как 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 Введение полностью параллельной среды выполнения, основанной на модели акторов, значительно улучшает сетевой TPS;

Создание Блокчейн цепочек - предоставление каждому аккаунту собственной выделенной цепочки с помощью бесконечного Шардинг

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

По сути, структура цепи TON состоит из четырех слоев

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

ShardChain: В большинстве контекстов ShardChain является фактической единицей в TON. ShardChain — это, по сути, коллекция AccountChains.

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-битным двоичным числом. В этой структуре любые две вершины являются смежными, если их двоичные представления отличаются всего на один бит. Например, в 3-мерном гиперкубе вершины 000 и 001 соседние, так как отличаются только последним битом. Приведенный выше пример представляет собой 2-мерный гиперкуб.

В протоколе маршрутизации гиперкуба маршрутизация сообщения от исходного WorkChain к целевому WorkChain выполняется путем сравнения их двоичных адресов. Алгоритм находит минимальное расстояние между этими адресами (т.е. количество различающихся битов) и пересылает сообщение через соседние WorkChains, пока оно не достигнет места назначения. Это гарантирует, что пакет данных будет следовать кратчайшему пути, повышая эффективность сетевого взаимодействия. Чтобы упростить этот процесс, TON также предлагает оптимистичное решение. Если пользователь может предоставить действительное доказательство пути маршрутизации, обычно корневого корня Меркла, узел может немедленно проверить подлинность сообщения. Это называется мгновенной маршрутизацией гиперкуба. В результате адреса TON значительно отличаются от адресов в других блокчейн-протоколах. Большинство протоколов блокчейна используют хеш открытого ключа, сгенерированного эллиптическими алгоритмами шифрования, в качестве адреса, уделяя особое внимание уникальности без необходимости в функциях маршрутизации. В TON адреса состоят из двух частей: (workchain_id, счет_id), причем workchain_id кодируется в соответствии с алгоритмом маршрутизации гиперкуба. Кто-то может задаться вопросом, почему бы не передавать всю кроссчейн-информацию через MasterChain, аналогично Cosmos. В дизайне TON MasterChain выполняет только самую важную задачу по поддержанию окончательности WorkChains. Несмотря на то, что можно направлять сообщения через MasterChain, связанные с этим комиссии будут непомерно высокими.

Наконец, давайте кратко обсудим его алгоритм консенсуса. TON использует комбинацию BFT (толерантность византийцев) и PoS (доказательство стейкинга). Это означает, что любой стейкер может участвовать в создании блока. Контракт управления выборами TON периодически выбирает группу валидаторов случайным образом из всех стейкеров. Эти выбранные валидаторы затем используют алгоритм BFT для создания блоков. Если валидатор создает недействительные блоки или действует злонамеренно, его токены в стейкинге конфисковываются. И наоборот, они получают вознаграждение за успешное создание валидных блоков. Этот способ довольно распространен, поэтому мы не будем вдаваться в подробности.

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

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

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

Однако эта архитектура также имеет явные ограничения, в частности, узкое место TPS, которое кажется устаревшим для современных многоядерных процессоров. Это похоже на игру в старые компьютерные игры, такие как Red Alert, на новеньком ПК; Когда количество боевых единиц достигает определенного уровня, вы все равно сталкиваетесь со значительным отставанием. Это связано с проблемами архитектуры программного обеспечения.

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

В отличие от этого, TON полностью отказывается от архитектуры последовательного выполнения и принимает парадигму разработки, специально разработанную для параллелизма, используя модель акторов для реконструкции своей среды выполнения. Модель акторов, впервые предложенная Карлом Хьюиттом в 1973 году, направлена на решение проблемы общих состояний в традиционных параллельных программах путем передачи сообщений. Каждый субъект имеет свое собственное частное состояние и поведение и не делится информацией о состоянии с другими субъектами. Модель акторов — это вычислительная модель параллелизма, которая обеспечивает параллельную обработку посредством передачи сообщений. В этой модели «Субъект» является базовой единицей, которая может обрабатывать полученные сообщения, создавать новых Акторов, отправлять дополнительные сообщения и решать, как реагировать на последующие сообщения. Модель актора должна обладать следующими характеристиками:

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

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

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

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

1. Асинхронные вызовы смарт-контрактов: в TON невозможно атомарно вызывать внешние контракты или получать доступ к данным внешних контрактов в рамках смарт-контрактов. В Solidity, например, функция контракта A1 может вызвать функцию контракта B2 или получить доступ к определенным данным состояния через функцию контракта C, доступную только для чтения3, и все это в одной транзакции. Однако в TON этого добиться невозможно. Любое взаимодействие с внешними смарт-контрактами будет выполняться асинхронно путем создания новых транзакций, называемых внутренними сообщениями, инициированными смарт-контрактами. Процесс выполнения не может быть заблокирован в ожидании результата.

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

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

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

В этой модели A и B представляют собой два смарт-контракта. Если msg1_lt < msg2_lt, то tx1_lt < tx2_lt с точки зрения последовательности.

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

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. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.