Автор: @Web3Mario
Введение: С запуском Notcoin, крупнейшей игры в экосистеме TON, на Binance и огромным эффектом богатства, вызванным экономической моделью токенов полного обращения, TON за короткий период времени привлек большое внимание. Пообщавшись с другом, я узнал, что технический порог TON относительно высок, а парадигма разработки DApp сильно отличается от основных протоколов публичной сети, поэтому я потратил некоторое время на углубленное исследование связанных тем и поделился с вами некоторыми идеями. Короче говоря, основная концепция проекта TON заключается в реконструкции традиционного протокола блокчейна «снизу вверх» и достижении высокого уровня параллелизма и высокой масштабируемости за счет совместимости.
Основная идея дизайна TON — высокий параллелизм и высокая масштабируемость.
Можно сказать, что цель всех сложных выборов технологий в TON исходит из стремления к высокому параллелизму и высокой масштабируемости. Конечно, нам нетрудно понять это на фоне его зарождения. TON, или Открытая сеть, — это децентрализованная вычислительная сеть, содержащая блокчейн 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.
Таким образом, поскольку он спроектирован как децентрализованная среда выполнения Telegram, ему, естественно, приходится сталкиваться с двумя проблемами: большим количеством одновременных запросов и большими объемами данных. Мы знаем, что с развитием технологий к настоящему времени Solana, известная как самая высокая TPS, имеет самый высокий показатель TPS. Самый высокий измеренный показатель TPS составляет всего 65 000, что явно недостаточно для поддержки экосистемы Telegram, которой требуются миллионы TPS. В то же время, благодаря масштабному применению Telegram, объем генерируемых им данных уже превысил небо. Будучи чрезвычайно избыточной распределенной системой, блокчейн требует, чтобы каждый узел в сети сохранял полную копию данных. тоже нереально.
Поэтому, чтобы решить две вышеупомянутые проблемы, TON провел две оптимизации основных протоколов блокчейна:
Используя «парадигму бесконечного сегментирования» для разработки системы, мы решаем проблему избыточности данных, чтобы она могла переносить большие данные, и устраняем проблему узких мест в производительности;
За счет внедрения полностью параллельной среды выполнения на основе модели актеров значительно улучшается TPS сети;
Создайте цепочку блокчейнов — благодаря неограниченным возможностям сегментирования каждая учетная запись имеет эксклюзивную цепочку учетных записей.
Теперь мы знаем, что сегментирование стало основным решением для большинства протоколов блокчейна, направленным на повышение производительности и снижение затрат, и TON довел это до крайности и предложил парадигму бесконечного сегментирования, так называемую парадигму бесконечного сегментирования. динамически увеличивать или уменьшать количество шардов в зависимости от нагрузки сети. Эта парадигма позволяет TON обрабатывать крупномасштабные транзакции и операции смарт-контрактов, сохраняя при этом высокую производительность. Теоретически TON может создать эксклюзивную цепочку учетных записей для каждой учетной записи и обеспечить совместимость между этими цепочками посредством определенных правил.
Если абстрактно это понять, в TON есть четыре уровня структуры цепочки:
Цепочка учетных записей: эта цепочка слоев представляет собой цепочку, состоящую из серии транзакций, связанных с учетной записью. Причина, по которой транзакции могут образовывать цепную структуру, заключается в том, что для конечного автомата, пока правила выполнения последовательны, конечный автомат будет результаты, полученные после получения инструкций в одной и той же последовательности, согласованы. Поэтому цепное упорядочение транзакций требуется во всех распределенных системах блокчейна, и TON не является исключением. Цепочка учетных записей является самой базовой компонентной единицей в сети TON. Обычно цепочка учетных записей представляет собой виртуальную концепцию, и маловероятно, что независимая цепочка учетных записей действительно существует.
Цепочка сегментов. В большинстве случаев цепочка сегментов является фактической компонентной единицей TON. Так называемая цепочка сегментов представляет собой совокупность цепочек учетных записей.
WorkChain: его также можно назвать набором цепочек сегментирования с настраиваемыми правилами, такими как создание рабочей цепочки на основе EVM и запуск на ней смарт-контрактов Solidity. Теоретически каждый член сообщества может создать свою собственную рабочую цепочку. На самом деле, ее создание — довольно сложная задача, которой предшествует оплата (дорогой) комиссии за ее создание и получение 2/3 голосов валидаторов для одобрения создания вашей рабочей цепочки.
Основная цепочка (MasterChain). Наконец, в TON есть специальная цепочка, называемая основной цепочкой, которая отвечает за завершение всех цепочек шардов. Как только хеш блока цепочки сегментов объединяется с блоком основной цепочки, этот блок цепочки сегментов и все его родительские блоки считаются окончательными, то есть их можно считать фиксированными и неразрушимыми. На измененное содержимое ссылаются последующие блоки всего шарда. цепи.
Приняв такую парадигму, сеть TON имеет следующие три характеристики:
Динамическое сегментирование: TON может автоматически разделять и объединять цепочки сегментов, чтобы адаптироваться к изменениям нагрузки. Это означает, что новые блоки всегда генерируются быстро, а транзакции не требуют длительного ожидания.
Высокая масштабируемость: благодаря парадигме бесконечного сегментирования TON может поддерживать практически неограниченное количество сегментов и теоретически может достигать значений от 2 до 60-й степени рабочих цепочек.
Адаптивность: когда нагрузка на часть сети увеличивается, эту часть можно разделить на большее количество сегментов для обработки возросшего объема транзакций. И наоборот, когда нагрузка снижается, сегменты можно объединить для повышения эффективности.
Тогда первое, с чем должна столкнуться такая многоцепная система, — это проблема межцепочечного взаимодействия, особенно из-за возможности неограниченного шардирования. Когда количество шардов в сети достигает определенного уровня, происходит маршрутизация информации между цепочками. станет трудным делом. Представьте, что в сети есть 4 узла. Каждый узел отвечает за поддержание независимой рабочей цепочки. Отношения связи указывают, что помимо ответственности за сортировку транзакций в своей собственной рабочей цепочке, узел также должен отслеживать и обрабатывать состояние. изменения в целевой цепочке, реализованные в TON специально за счёт мониторинга сообщений в очереди вывода.
Предположим, учетная запись A в рабочей цепочке 1 хочет отправить сообщение учетной записи C в рабочей цепочке 3. Вам необходимо спроектировать задачу маршрутизации сообщений. В этом примере есть два пути маршрутизации: рабочая цепочка 1 -> рабочая цепочка 2 -> рабочая цепочка 3 и рабочая цепочка 1 -> рабочая цепочка 4 -> рабочая цепочка 3.
При возникновении более сложных ситуаций необходим эффективный и недорогой алгоритм маршрутизации для быстрого завершения передачи сообщений. TON выбрала так называемый «алгоритм маршрутизации гиперкуба» для реализации обнаружения маршрута передачи сообщений между цепочками. Так называемая структура гиперкуба относится к специальной сетевой топологии. n-мерный гиперкуб состоит из 2^n вершин, и каждая вершина может быть однозначно идентифицирована n-битным двоичным числом. В этой структуре любые две вершины являются смежными, если в двоичном представлении они отличаются всего на один бит. Например, в трехмерном гиперкубе вершина 000 и вершина 001 являются соседними, поскольку они различаются только последним битом. Приведенный выше пример представляет собой двумерный гиперкуб.
В протоколе маршрутизации гиперкуба процесс маршрутизации сообщения из исходной рабочей цепочки в целевую рабочую цепочку выполняется путем сравнения двоичных представлений адресов исходной рабочей цепочки и целевой рабочей цепочки. Алгоритм маршрутизации находит минимальное расстояние (т. е. количество различных битов в двоичном представлении) между этими двумя адресами и постепенно пересылает информацию через соседние рабочие цепочки, пока не будет достигнута целевая рабочая цепочка. Этот метод гарантирует, что пакеты данных передаются по кратчайшему пути, тем самым повышая эффективность связи в сети.
Конечно, чтобы упростить этот процесс, TON также предложил оптимистичное техническое решение, когда пользователь может предоставить достоверное доказательство определенного пути маршрутизации, которым обычно является корень дерева Меркла, узел может напрямую распознать достоверность сообщения. представленные пользователем свойства, это также известно как мгновенная маршрутизация гиперкуба.
Таким образом, мы видим, что существуют очевидные различия между адресами в TON и других протоколах блокчейна. Большинство других основных протоколов блокчейна используют в качестве адреса хэш, соответствующий открытому ключу в открытом и закрытом ключах, сгенерированный алгоритмом эллиптического шифрования. адрес используется только как уникальный адрес. Ему не требуется выполнять функцию адресации маршрутизации, а адрес в TON состоит из двух частей (workchain_id, account_id), где workchain_id кодируется в соответствии с адресом алгоритма маршрутизации гиперкуба, который здесь не будет подробно рассмотрено.
Есть еще один момент, который легко вызвать сомнения. Возможно, вы заметили, что основная цепочка имеет связь с каждой рабочей цепочкой, поэтому не достаточно ли просто передавать всю межцепочечную информацию через основную цепочку. как Космос. В концепции дизайна TON основная цепочка используется только для решения наиболее важных задач, то есть для поддержания завершенности многих рабочих цепочек. Маршрутизировать сообщения через основную цепочку не невозможно, но в результате плата за обработку будет очень высокой. .
Наконец, давайте кратко упомянем его алгоритм консенсуса, который использует метод BFT+PoS, то есть любой стейкер имеет возможность участвовать в упаковке блоков. Контракт на управление выборами TON будет случайным образом выбирать верификатора упаковки из всех стейкеров через определенные промежутки времени. кластере узлы, выбранные в качестве валидаторов, будут упакованы и созданы с помощью алгоритма BFT. Если они упаковывают неверную информацию или совершают зло, их поставленные токены будут конфискованы, а в противном случае они получат вознаграждение за блок. По сути, это распространенный выбор, поэтому я не буду о нем здесь рассказывать.
Смарт-контракты и полностью параллельная среда исполнения на основе модели актера
Еще одним моментом в TON, который отличается от основных протоколов блокчейна, является среда выполнения смарт-контрактов. Чтобы преодолеть ограничения основного протокола блокчейна TPS, TON приняла идею проектирования «снизу вверх» и использовала модель актеров для реконструкции смарт-контрактов и методов их выполнения, давая им возможность полностью распараллеливаться.
Мы знаем, что большинство основных протоколов блокчейна используют однопоточную среду последовательного выполнения. Если взять в качестве примера Ethereum, то его среда исполнения EVM представляет собой конечный автомат с транзакциями на входе. Когда узел, производящий блок, завершает транзакцию, упаковывая блок после сортировки. , транзакции будут выполняться через EVM в этом порядке. Весь процесс является полностью последовательным и однопоточным, то есть в определенное время может быть выполнена только одна транзакция. подтверждено, результат выполнения будет иметь согласованность в широком диапазоне распределенных кластеров. В то же время, поскольку одновременно выполняется только одна транзакция, это означает, что в процессе выполнения другие транзакции не могут выполняться. изменить определенные данные состояния, к которым необходимо получить доступ, чтобы обеспечить совместимость между смарт-контрактами. Например, мы используем USDT для покупки ETH через Uniswap. Когда транзакция выполняется, распределение LP в торговой паре имеет определенное значение. Таким образом, соответствующий результат может быть получен с помощью определенных математических моделей, но при условии, что это так. Это не тот случай, если при расчете определенной кривой облигаций другие LP добавляют новую ликвидность, результат расчета будет устаревшим, что явно неприемлемо.
Но эта архитектура также имеет очевидные ограничения, которые являются узким местом TPS, и это узкое место выглядит очень старым для современных многоядерных процессоров. Точно так же, как если бы вы использовали новейший ПК для игры в некоторые старые компьютерные игры, такие как Red Alert, When the. количество боевых единиц достигнет определенного уровня, вы все равно обнаружите, что оно застряло. Это проблема архитектуры программного обеспечения.
Вы можете услышать, что некоторые протоколы уже обращают внимание на эту проблему и предлагают свои собственные параллельные решения. Взять, к примеру, Solana, которая на данный момент претендует на самый высокий TPS, она также имеет возможность выполняться параллельно. Однако его идея дизайна отличается от TON. В Solana его основная идея состоит в том, чтобы разделить все транзакции на несколько групп в соответствии с зависимостями выполнения, и никакие данные о состоянии не передаются между различными группами. То есть нет одинаковых зависимостей, поэтому транзакции в разных группах могут выполняться параллельно, не беспокоясь о конфликтах, в то время как транзакции внутри одной группы по-прежнему выполняются традиционным последовательным образом.
В TON полностью отказывается от архитектуры последовательного выполнения и вместо этого принимает парадигму разработки, специально разработанную для параллелизма, модель актеров, чтобы реконструировать среду выполнения. Так называемая модель актера была впервые предложена Карлом Хьюиттом в 1973 году для решения сложности общего состояния в традиционных параллельных программах посредством передачи сообщений. Каждый актер имеет свое собственное состояние и поведение и не передает никакой информации о состоянии другим актерам. Модель актера — это модель параллельных вычислений, которая реализует параллельные вычисления посредством передачи сообщений. В этой модели «Актер» — это базовая единица работы, способная обрабатывать полученные сообщения, создавать новых Актеров, отправлять больше сообщений и решать, как реагировать на последующие сообщения. Модель Актера должна иметь следующие характеристики:
Инкапсуляция и независимость: каждый актер полностью независим при обработке сообщений и может обрабатывать сообщения параллельно, не мешая друг другу.
Передача сообщений. Актеры взаимодействуют друг с другом только путем отправки и получения сообщений, а передача сообщений является асинхронной.
Динамическая структура: актеры могут создавать больше актеров во время выполнения. Такая динамическая природа позволяет модели актеров расширять систему по мере необходимости.
TON использует эту архитектуру для разработки моделей смарт-контрактов. Это означает, что в TON каждый смарт-контракт представляет собой модель актера с полностью независимым пространством хранения. Потому что он не опирается ни на какие внешние данные. Кроме того, вызовы одного и того же смарт-контракта по-прежнему выполняются в соответствии с порядком сообщений в очереди приема, поэтому транзакции в TON можно эффективно выполнять параллельно, не беспокоясь о конфликтах.
Однако такая схема проектирования также приносит некоторые новые последствия. Для разработчиков DApp привычная парадигма разработки будет нарушена следующим образом:
1. Асинхронные вызовы между смарт-контрактами. Невозможно атомарно вызывать внешние контракты или получать доступ к данным внешних контрактов в смарт-контрактах TON. Мы знаем, что в Solidity функция 1 контракта A вызывает функцию 2 контракта B или через функцию только для чтения. 3 контракта C имеет доступ к определенным данным состояния. Весь процесс является атомарным и выполняется в транзакции. Однако в TON это будет невозможно, и любое взаимодействие с внешним интеллектом будет выполняться асинхронно. путем упаковки новых транзакций. Такие транзакции, инициированные смарт-контрактами, также называются внутренними сообщениями. И его нельзя заблокировать во время выполнения для получения результатов выполнения.
Например, если мы разрабатываем DEX, если мы принимаем общую парадигму в EVM, обычно будет использоваться единый контракт маршрутизатора, используемый для управления маршрутизацией транзакций, и каждый пул независимо управляет данными LP, связанными с определенной торговой парой. Предположим, что это так. В настоящее время существует два пула: USDT-DAI и DAI-ETH. Когда пользователь хочет приобрести ETH напрямую через USDT, он или она может последовательно запросить эти два пула в одной транзакции через контракт маршрутизатора для завершения атомарной транзакции. Однако в TON это не так-то просто реализовать. Нам нужно подумать о новой парадигме разработки. Если мы еще раз воспользуемся этой парадигмой, то информационный поток может быть таким. Этот запрос будет сопровождаться внешним сообщением, инициированным пользователем. и три внутренних сообщения завершены (обратите внимание, что это используется для иллюстрации разницы. В реальной разработке даже парадигма ERC20 должна быть переработана).
2. Необходимо тщательно продумать процесс обработки ошибок исполнения при вызове между контрактами и спроектировать соответствующие функции возврата для каждого межконтрактного вызова. Мы знаем, что в основной EVM, когда во время выполнения транзакции возникает проблема, вся транзакция будет откачена, то есть сброшена в исходное состояние выполнения. Это легко понять на серийной однопоточной модели. Однако в TON, поскольку вызовы между контрактами выполняются асинхронно, даже если в последующей ссылке возникает ошибка, поскольку ранее успешно выполненная транзакция уже была выполнена и подтверждена, это может вызвать проблемы. Поэтому в TON настроен специальный тип сообщения, называемый сообщением о возврате. То есть, когда в последующем процессе выполнения, вызванном внутренним сообщением, возникает ошибка, сработавший контракт может вызвать определенное сообщение в контракте через функцию возврата. зарезервировано триггерным контрактом. Некоторые состояния сбрасываются.
3. В некоторых сложных ситуациях транзакция, полученная первой, может не выполняться первой, поэтому это соотношение времени не может быть задано заранее. В такой системе асинхронных и параллельных вызовов смарт-контрактов определение порядка обработки операций может оказаться затруднительным. Именно поэтому каждое сообщение в TON имеет свое логическое время — время Лампорта (далее — lt). Он используется, чтобы понять, какое событие вызвало другое и что валидатору необходимо обработать в первую очередь. В простой модели транзакция, полученная первой, должна быть выполнена первой.
В этой модели A и B представляют два смарт-контракта соответственно, и существует такая временная связь, что если msg1_lt < msg2_lt, то tx1_lt < tx2_lt.
Однако в более сложных ситуациях это правило нарушается. В официальной документации есть пример. Предположим, у нас есть три контракта A, B и C. В транзакции A отправляет два внутренних сообщения msg1 и msg2: одно B, а другое C. Хотя они создаются в точном порядке (сначала msg1, затем msg2), мы не можем быть уверены, что msg1 будет обработано раньше msg2. Это связано с тем, что маршруты от A до B и от A до C могут отличаться по длине и набору валидаторов. Если эти контракты находятся в разных цепочках сегментов, одному из сообщений может потребоваться несколько блоков, чтобы достичь целевого контракта. То есть у нас есть два возможных пути торговли, как показано на рисунке.
4. В TON постоянное хранилище его смарт-контрактов использует направленный ациклический граф с ячейкой в качестве структуры данных. Данные будут компактно сжиматься в ячейку в соответствии с правилами кодирования и в то же время в соответствии с правилами кодирования. направленный ациклический граф. Способ расширяется вниз, что отличается от структурной организации данных о состоянии на основе хэш-карт в EVM. Из-за разных алгоритмов запроса данных TON устанавливает разные цены на газ для разной глубины обработки данных. , чем больше Gas требуется. Чем выше, тем в TON существует парадигма DOS-атаки, то есть некоторые злоумышленники занимают все мелкие ячейки в определенном смарт-контракте, рассылая большое количество спам-сообщений, а это означает, что стоимость хранения честных пользователей будет становиться все дороже. В EVM, поскольку сложность запроса хеш-карты равна o(1), он имеет тот же Gas и подобных проблем не возникнет. Поэтому разработчикам TON Dapp следует стараться избегать неограниченных типов данных в смарт-контрактах. При появлении неограниченных типов данных их следует разбивать посредством шардирования.
5. Есть также некоторые менее особенные функции, такие как смарт-контракты, за хранение которых необходимо платить арендную плату, смарт-контракты в TON, естественно, можно обновлять, а также собственные абстрактные функции учетной записи, то есть все адреса кошельков в TON являются смарт-контрактами. просто не инициализирован и т. д. Это требует от разработчиков пристального внимания.
Выше приведены некоторые из моих опытов изучения технологий, связанных с TON, за этот период. Я хотел бы поделиться ими с вами. Надеюсь, вы сможете меня поправить, если я допущу какие-либо ошибки. В то же время я думаю, что с учетом огромного трафика Telegram. ресурсы, экосистема TON определенно предоставит платформу для Web3. Друзья, заинтересованные в разработке TON DApp, также могут связаться со мной и обсудить с нами.
X-ссылки: https://x.com/web3_mario
