31 октября 2023 года TON (ранее Telegram Open Network) установил новый мировой рекорд, достигнув ошеломляющего пика в 104 715 транзакций в секунду в своем первом публичном тесте производительности в реальном времени, выполнив в общей сложности 107 652 545 транзакций за 25 минут. Проверенная и подтвержденная Certik, эта производительность делает TON самым быстрым и масштабируемым блокчейном в мире, превосходящим скорость обработки всех блокчейнов L1 и известных централизованных платежных сетей, таких как PayPal, Visa и Mastercard.
TON, несомненно, замечательный проект. В этой статье мы подробно рассмотрим whitepaper TON, расскажем о его уникальных технических особенностях и инновациях, а также о том, почему TON является самым быстрым блокчейном в мире.
Масштабируемость была огромной проблемой при разработке технологии блокчейн. Основной целью схемы масштабирования блокчейна является увеличение пропускной способности системы и снижение комиссий за транзакции, чтобы сеть блокчейн могла обрабатывать больше транзакций и лучше адаптироваться к крупномасштабным приложениям. Несмотря на то, что различные публичные сети продолжают пробовать новые проекты консенсуса и архитектуры, текущие результаты по-прежнему неудовлетворительны и стали узким местом для продвижения блокчейна к крупномасштабному применению, что трудно воплотить в жизнь наше видение TG миллиардов пользователей. В настоящее время основные решения для масштабирования можно разделить на следующие категории:
Шардинг: Разделение сети на более мелкие части, каждая из которых способна обрабатывать транзакции и смарт-контракты параллельно, значительно увеличивая пропускную способность сети. Но шардинг сопряжен с потенциальными проблемами безопасности, поскольку каждый шард может быть менее безопасным, чем вся сеть. Кроме того, взаимодействие между сегментами представляет собой техническую проблему. Показательные примеры: протоколы Ethereum 2.0 и NEAR.
Сайдчейны: Сайдчейн — это тип блокчейна, который работает независимо от основной цепи и может иметь свой собственный механизм консенсуса и параметры блока. С помощью сайдчейнов пользователи могут переводить активы между двумя цепочками, разгружая основную цепочку. Репрезентативный пример: Polygon
Решения уровня 2: Создавая еще один уровень поверх основной цепочки, L2 может обеспечить более быстрое время подтверждения транзакций и более низкие комиссии за транзакции. Возьмем, к примеру, более известные L2s, Optimism и Arbitrum: оба из них являются решениями для масштабирования, разработанными специально для Ethereum. В результате часть архитектуры Optimism и Arbitrum находится на уровне 1. С обновлением Ethereum их верхний предел транзакций в секунду (TPS) увеличился с 2-4k до примерно 2w.
zkSync 2.0: По сравнению с ограничением TPS в zkSync 1.0 в несколько сотен, zkSync 2.0 предлагает значительные улучшения. Команда zkSync утверждает, что ее версия 2.0 может достичь верхнего предела в 10 Вт TPS, но большинство учреждений прогнозируют, что истинный верхний предел может составлять 1-2 Вт. Starknet: После завершения обновления до Quantum Leap в июне, его TPS теперь составляет чуть более 100 TPS.
Solana: Solana использует инновационный алгоритм консенсуса под названием Proof of History (PoH) в качестве ядра своего решения для масштабирования. Хотя Solana утверждает, что имеет до 65 000 TPS, большая часть из них на самом деле действует как связь между узлами. Истинный объем торгов может быть ограничен только 6-8 тыс. TPS. Более того, из-за централизованного механизма консенсуса Solana неоднократно сталкивалась с простоями из-за большого количества запросов, например, при минтинге NFT. Кроме того, в Solana до сих пор успешно не реализована ротация центрального узла.
Блокчейн TON разработан основателем и основной командой Telegram. Будучи одной из самых популярных социальных платформ в мире, Telegram имеет почти 900 миллионов активных пользователей в месяц, обеспечивая стабильный и бесперебойный пользовательский опыт, сохраняя при этом высокий уровень безопасности и конфиденциальности, при этом в программном обеспечении ежедневно передаются десятки миллиардов сообщений. Концепция web3 стала относительно хорошо известна, но фактические крипто-нативные пользователи по-прежнему составляют меньшинство, и большинство полагается на централизованные биржи для доступа к токену. Metamask, самый популярный в мире децентрализованный криптокошелек, в настоящее время имеет всего 30 миллионов активных пользователей в месяц. И философия дизайна TON с самого начала была основана на обслуживании миллиардов пользователей, а не только нескольких гиков web3.
Шардинг — это концепция, которая пришла из проектирования баз данных. Он относится к разделению большого логического набора данных с последующим распределением его по нескольким базам данных, которые не являются общими друг с другом, которые могут быть распределены по нескольким серверам. Говоря простым языком, шардинг предоставляет возможность горизонтального масштабирования, позволяя разбивать данные на независимые части, которые можно обрабатывать параллельно.
TON — не первый проект, который внедрил технологию шардинга в блокчейн, например, Ethereum 2.0 когда-то анонсировал фиксированные 64 шарда, а затем отказался от них из-за слишком большой сложности, в то время как протокол NEAR Night Shadow планирует достичь 100 шардов в следующем году, и в настоящее время существует 4 шарда.
В отличие от традиционных методов шардинга, TON использует стратегию бесконечного шардинга.
Однако подход TON считается продвинутым не потому, что у него больше шардов, а из-за двух уникальных особенностей:
Количество шардов не фиксировано: TON поддерживает возрастающее количество шардов в соответствии с потребностями бизнеса, до 2^60 рабочих цепочек, что практически бесконечно.
Эластичное количество шардов: TON может автоматически разделять шарды при высокой нагрузке на систему и объединять их при низкой. Это очень эффективная стратегия для решения проблемы динамического масштабирования.
В настоящее время TON состоит из двух рабочих цепочек: основной (Masterchain) для синхронизации и управления и рабочей цепочки (Workchain) для смарт-контрактов. Ниже рабочей цепочки находится шардчейн и самый нижний уровень цепочки виртуальных счетов (Accountchain)
Рабочую цепочку можно разделить на N шардов (от 1 до 256 шардов). У каждого шарда есть своя группа валидаторов. Команда рабочей цепочки отвечает за выполнение транзакций в собственных шардах. При этом он постоянно скачивает блоки из всех остальных шардов своей рабочей цепочки. В целом, блокчейн — это серия блоков, которые фиксируют изменения в своем состоянии. Для блокчейнов POS валидаторы сначала договариваются о том, как они хотят изменить состояние блокчейна, компилируя блок, содержащий список изменений. После голосования за этот блок, если набрано достаточное количество голосов, они применяют блок к состоянию блокчейна и переходят к следующему блоку.
Пропускная способность потока блока очень ограничена, потому что валидаторы должны проверять все транзакции в этом блоке, прежде чем согласиться принять его. Таким образом, в TON очень много потоков, и вы можете просто думать о них как о мини-микро-блокчейнах. Они существуют параллельно, и у каждого есть свой набор валидаторов.
Основная цепь
Основная цепочка — это основная нить блока в TON. Он используется для синхронизации всех оставшихся блоков и пересчета набора валидаторов. Когда все потоки соглашаются на новый блок, они подписывают его и регистрируют в основной цепочке. Однако валидаторы мейнчейна не проверяют валидность блока, они только проверяют, подписан ли он соответствующим валидатором. Таким образом, многие потоки могут сосуществовать параллельно. Контракты из разных потоков взаимодействуют друг с другом, отправляя сообщения.
Цепочка работ
Цепочка работы — это независимое адресное пространство, которое может быть запущено по своим правилам. Например, у них могут быть разные виртуальные машины или увеличено время публикации блоков с высокими лимитами газа. Самое главное, чтобы рабочие цепочки имели одинаковый формат очереди сообщений, чтобы они могли обмениваться сообщениями. Это также означает, что все рабочие цепочки должны иметь примерно одинаковые гарантии безопасности. Поскольку они могут обмениваться сообщениями, эти сообщения содержат сетевые токены. Теперь активны две рабочие цепочки: основная цепочка и первая рабочая цепочка обработки. Цепочка работы определяется префиксом адреса: -1:ax... 1s2 - Адрес аккаунта в основной цепочке. -1 - префикс основной цепи.
0:zx... 123 - Адрес аккаунта в первой рабочей цепочке. 0 - это первый префикс для обработки рабочей цепочки.
Цепочки шардов
Обрабатывающий поток, или цепочка шардов, — это независимый блочный поток, который обрабатывает рабочую цепочку. По умолчанию рабочая цепочка 0 имеет только один поток и одну цепочку. Валидаторы этого потока принимают внешние сообщения и обрабатывают внутренние сообщения, которые они отправляют сами или из других рабочих цепочек. Если возникает ситуация, когда поток перегружен в течение последних N блоков, поток разбивается: один поток разбивается на два, и транзакции выполняются параллельно.
Адреса начинаются с 0:00: - 0:88.. Учетная запись в начале теперь находится в потоке 1 с учетной записью 0:88: . - 0:FF.. Находится в потоке 2. Поскольку все смарт-контракты взаимодействуют друг с другом асинхронно без каких-либо сбоев, пропускная способность увеличилась в три раза. Когда нагрузка падает, потоки через некоторое время сливаются обратно. Если нагрузка продолжает увеличиваться, два потока могут быть разделены снова и снова, и так далее. В основной цепочке только одна нить.
Блоки в TON — это больше, чем просто список транзакций, которые необходимо выполнить, чтобы добиться изменения состояния. Вместо этого блок выглядит следующим образом:
Список сообщений, которые выполняют транзакцию, удаляя их из очереди входящих. Новое сообщение попадает в исходящую очередь после обработки сообщения, а затем обработка сообщения вызывает изменение состояния смарт-контракта. То есть, для того, чтобы валидатор шарда X поддерживал текущее состояние шарда Y, ему не нужно выполнять все транзакции в блоке шарда Y. Он просто загружает блок и суммирует произошедшие изменения. Происходит в очередях сообщений и состояниях смарт-контрактов.
Фундаментальное изменение мира блокчейна не может обойтись без цены. Чтобы воспользоваться этим радикальным подходом, разработчики смарт-контрактов TON должны по-другому проектировать свои контракты. Базовой атомарной единицей блокчейна TON является смарт-контракт. Смарт-контракты имеют адреса, код и единицы данных (постоянное состояние). Такие единицы называются атомарными, потому что смарт-контракты всегда имеют атомарно синхронизированный доступ ко всем своим постоянным состояниям.
Сетевая маршрутизация гиперкуба
TON создал умный механизм маршрутизации, чтобы гарантировать, что транзакции между любыми двумя блокчейнами всегда обрабатываются быстро, независимо от того, насколько велика система, а время, необходимое для отправки информации между блокчейнами TON, только логарифмически увеличивается с количеством цепочек, так что даже масштабирование до миллионов цепочек позволяет им общаться с максимальной скоростью.
В блокчейне TON Instant Hypercube Routing и Slow Routing — это два механизма маршрутизации, используемые для обработки кроссчейн-транзакций.
Instant Hypercube Routing: идея TON по ускорению маршрутизации сообщений, позволяющая выполнять межсетевые транзакции за долю времени. При традиционной маршрутизации медленного куба сообщение направляется цепочкой сегментов по сети гиперкуба в цепочку сегментов назначения. Однако во время маршрутизации сообщений валидатор, к которому принадлежит цепочка сегментов назначения, может заранее обработать сообщение, чтобы добавить его в блок, а затем предоставить доказательство Меркеля (квитанцию) и отправить квитанцию для уничтожения передаваемого сообщения. Это позволяет совершать кроссчейн-транзакции за очень короткий промежуток времени. Быстрая маршрутизация обеспечивает эффективное межсетевое взаимодействие за счет построения структуры маршрутизации куба высокой размерности. В этой структуре каждая цепочка сопоставляется с одной вершиной куба, а расстояние между цепочками выражается как количество прыжков между вершинами. При таком подходе транзакции могут быть быстро маршрутизированы по кратчайшему пути, что делает межсетевое взаимодействие эффективным. Быстрая маршрутизация позволяет выполнять кроссчейн-транзакции за считанные секунды, не дожидаясь подтверждения блока.
Медленная маршрутизация: Медленная маршрутизация — это относительно традиционный метод обработки межсетевых транзакций путем постепенного переноса транзакций из исходной цепочки в цепочку назначения. В этом методе транзакции сначала упаковываются в блок в исходной цепочке, а затем передаются в цепочку назначения через ретранслятор. Валидатор цепочки назначения проверяет действительность транзакции, а затем упаковывает ее в блок цепочки назначения. Преимущество медленной маршрутизации перед быстрой заключается в том, что она обеспечивает более высокую степень безопасности и децентрализации, поскольку кроссчейн-транзакции должны проходить полный процесс подтверждения блока. Как и в сети TCP/IP, IP-адрес назначения адресуется адресату, чтобы обеспечить надежную передачу сообщений в цепочку назначения по порядку. Для сети гиперкубов с цепочкой сегментов масштаба N должен пройти промежуточный переход цепочки сегментов = log16(N)-1. Таким образом, для поддержки миллионов цепочек шардов требуется всего 4 узла маршрутизации (промежуточные цепочки шардов).
Почему он так устроен? **
Для распределения требуются валидаторы. Если система очень большая, с десятками тысяч узлов, она слишком перегружена для масштабирования. После шардинга у каждого шарда есть set, shard0, shard1... Также необходимо добиться межшардовой коммуникации. Обмен данными может быть перекрестно-сегментированным, и переход от одного сегмента к другому означает, что для сегментов и сегментов должен существовать механизм маршрутизации. Соединение формирует маршрут, который пропускает через некоторый промежуточный узел. Каждый раз, когда сообщение маршрутизируется, это эквивалентно увеличению времени передачи на один блок.
По мере роста общего количества цепочек шардов это потребует большой вычислительной мощности и пропускной способности сети, что ограничит масштабируемость системы. В результате невозможно доставить сообщение напрямую из одного сегмента во все остальные сегменты. Вместо этого каждый сегмент «подключен» только к другому сегменту с шестнадцатеричным числом в идентификаторе сегмента (w,s). Таким образом, все цепочки шардов образуют граф «гиперкуб», а сообщения передаются по ребрам этого гиперкуба.
Если сообщение отправляется на шард, отличный от текущего, шестнадцатеричный номер идентификатора текущего шарда (детерминированно выбранного) будет заменен на соответствующий номер целевого шарда, а полученный идентификатор будет служить приблизительным адресатом для получения пересылаемого сообщения.
Основным преимуществом маршрутизации гиперкуба является условие валидности блока, при котором валидаторы, создающие блоки цепочки шардов, должны собирать и обрабатывать сообщения из выходной очереди «соседних» цепочек шардов или терять стейкинг. Таким образом, можно ожидать, что любое сообщение рано или поздно достигнет конечного пункта назначения; Сообщения не теряются при передаче и не доставляются повторно.
Маршрутизация гиперкуба приводит к некоторой дополнительной задержке и расходам из-за необходимости пересылать сообщения через несколько промежуточных цепочек сегментов. Однако количество этих промежуточных цепочек шардов растет очень медленно, что связано с log N от общего числа цепочек шардов.
Коммуникация асинхронная
Смарт-контракт на TON реализует асинхронную коммуникацию, которую можно сравнить с интернет-микросервисами. Каждая микрослужба имеет только атомарно синхронизированный доступ к своим локальным данным. Обмен данными между двумя микрослужбами включает в себя отправку асинхронных сообщений по сети.
В системной архитектуре для более крупных систем часто требуется архитектура микросервисов. Этот распределенный подход требует некоторых компромиссов для внедрения, но может принести преимущества для взаимодействия с пользователем. Современное управление системами опирается на секвенсоры, такие как Kubernetes, которые берут набор контейнерных микросервисов и автоматически запускают новые инстансы по мере необходимости (автомасштабирование) и эффективно разделяют их между компьютерами.
Если использовать аналогию с Kubernetes (Massive Cluster Management System), то это именно то, что делает TON. По мере увеличения нагрузки на конкретную цепочку шардов она разбивается на две части. Поскольку смарт-контракты являются атомарными, они никогда не делятся пополам. Это означает, что некоторые смарт-контракты, которые когда-то были в одной цепочке шардов, в один прекрасный день могут оказаться в разных цепочках шардов.
Виртуальная машина TON (TVM) применяет концепцию распределенных микросервисов к общей архитектуре, которая сравнивается с EVM Ethereum.
Децентрализация государства
Это один из самых сложных и сложных механизмов шардинга в пространстве шардинга. Вся база данных разбивается и размещается на разных шардах. Каждый шард хранит все данные в своем шарде, а не состояние всего блокчейна.
В блокчейн-шардинге TON все сервисы реализованы в виде смарт-контрактов, а данные о состоянии смарт-контрактов хранятся только в соответствующей сети шардов, чтобы добиться шардинга состояния.
Мало того, в TON контракт достиг уникального пути реализации в отрасли, где каждый пользователь может управлять состоянием токена в своем собственном контракте, по-настоящему реализуя децентрализацию из состояния блокчейна. Я подробно рассмотрю принципы этого дизайна на конкретных примерах.
Прежде всего, вам нужно разобраться в контракте Wallet и контракте кошелька Jetton. Контракт Wallet — это пользовательский смарт-контракт, который управляет токенами пользователя в блокчейне TON. Jetton (рус. Jewel) Контракт кошелька — это особый тип контракта кошелька, который предназначен для управления токенами Jetton пользователя. Эти токены можно использовать для оплаты сетевых комиссий и выполнения смарт-контрактов. У каждого пользователя есть свой контракт кошелька и контракт кошелька Jetton. Эти контракты выступают в качестве цифровых кошельков, в которых пользователи могут хранить свои токены и управлять ими. В то же время эти контракты также могут взаимодействовать с контрактами других пользователей, обеспечивая децентрализованную передачу активов и торговлю.
В этом случае предполагается, что пользователь А и пользователь Б имеют свой контракт кошелька. Пользователь А хочет передать определенное количество токенов пользователю Б. В этом случае контракт кошелька пользователя А взаимодействует с контрактом кошелька пользователя Б для осуществления перевода токенов. Весь процесс должен опираться не на один централизованный контракт, а на два децентрализованных контракта.
Все пользователи блокчейна TON имеют свои собственные контракты на управление состоянием своих активов, а это означает, что не существует единого централизованного контракта, чтобы взять на себя риск управления всеми активами. Это повышает децентрализацию системы и снижает риск возникновения единой точки отказа. Состояние активов всех пользователей управляется специальным контрактом, и злоумышленник не может повлиять на всю систему, атакуя один централизованный контракт. Транзакции с активами между пользователями также могут автоматически выполняться через смарт-контракты, избегая риска действий человека. Вы также можете настроить свой собственный контракт кошелька и контракт кошелька Jetton в соответствии с вашими потребностями, чтобы получить больше функций и сценариев применения. Это дает пользователям больше гибкости и автономии. Каждый управляет состоянием актива в своем контракте, и масштабируемость системы улучшается. По мере увеличения числа пользователей растет и количество контрактов, но это не создает чрезмерной нагрузки на всю систему, поскольку каждый контракт работает независимо.
Выше приведен мой анализ масштабируемости блокчейна TON и технической архитектуры white paper, спасибо Dr. Awesome Doge за редактирование первого черновика. Спасибо российской и украинской командам разработчиков за их настойчивость и, наконец, основателю Telegram, г-ну Николаю Дурову, за его великолепный дизайн много лет назад, и это во славу человеческого разума.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Объяснение White Paper TON: развеиваем мифы о технологии, лежащей в основе самого быстрого блокчейна в мире
31 октября 2023 года TON (ранее Telegram Open Network) установил новый мировой рекорд, достигнув ошеломляющего пика в 104 715 транзакций в секунду в своем первом публичном тесте производительности в реальном времени, выполнив в общей сложности 107 652 545 транзакций за 25 минут. Проверенная и подтвержденная Certik, эта производительность делает TON самым быстрым и масштабируемым блокчейном в мире, превосходящим скорость обработки всех блокчейнов L1 и известных централизованных платежных сетей, таких как PayPal, Visa и Mastercard.
TON, несомненно, замечательный проект. В этой статье мы подробно рассмотрим whitepaper TON, расскажем о его уникальных технических особенностях и инновациях, а также о том, почему TON является самым быстрым блокчейном в мире.
! Анализ Белой книги TON: Демистификация технологии, лежащей в основе самого быстрого блокчейна в мире
Проблемы масштабирования
Масштабируемость была огромной проблемой при разработке технологии блокчейн. Основной целью схемы масштабирования блокчейна является увеличение пропускной способности системы и снижение комиссий за транзакции, чтобы сеть блокчейн могла обрабатывать больше транзакций и лучше адаптироваться к крупномасштабным приложениям. Несмотря на то, что различные публичные сети продолжают пробовать новые проекты консенсуса и архитектуры, текущие результаты по-прежнему неудовлетворительны и стали узким местом для продвижения блокчейна к крупномасштабному применению, что трудно воплотить в жизнь наше видение TG миллиардов пользователей. В настоящее время основные решения для масштабирования можно разделить на следующие категории:
Шардинг: Разделение сети на более мелкие части, каждая из которых способна обрабатывать транзакции и смарт-контракты параллельно, значительно увеличивая пропускную способность сети. Но шардинг сопряжен с потенциальными проблемами безопасности, поскольку каждый шард может быть менее безопасным, чем вся сеть. Кроме того, взаимодействие между сегментами представляет собой техническую проблему. Показательные примеры: протоколы Ethereum 2.0 и NEAR.
Сайдчейны: Сайдчейн — это тип блокчейна, который работает независимо от основной цепи и может иметь свой собственный механизм консенсуса и параметры блока. С помощью сайдчейнов пользователи могут переводить активы между двумя цепочками, разгружая основную цепочку. Репрезентативный пример: Polygon
Решения уровня 2: Создавая еще один уровень поверх основной цепочки, L2 может обеспечить более быстрое время подтверждения транзакций и более низкие комиссии за транзакции. Возьмем, к примеру, более известные L2s, Optimism и Arbitrum: оба из них являются решениями для масштабирования, разработанными специально для Ethereum. В результате часть архитектуры Optimism и Arbitrum находится на уровне 1. С обновлением Ethereum их верхний предел транзакций в секунду (TPS) увеличился с 2-4k до примерно 2w.
zkSync 2.0: По сравнению с ограничением TPS в zkSync 1.0 в несколько сотен, zkSync 2.0 предлагает значительные улучшения. Команда zkSync утверждает, что ее версия 2.0 может достичь верхнего предела в 10 Вт TPS, но большинство учреждений прогнозируют, что истинный верхний предел может составлять 1-2 Вт. Starknet: После завершения обновления до Quantum Leap в июне, его TPS теперь составляет чуть более 100 TPS.
Solana: Solana использует инновационный алгоритм консенсуса под названием Proof of History (PoH) в качестве ядра своего решения для масштабирования. Хотя Solana утверждает, что имеет до 65 000 TPS, большая часть из них на самом деле действует как связь между узлами. Истинный объем торгов может быть ограничен только 6-8 тыс. TPS. Более того, из-за централизованного механизма консенсуса Solana неоднократно сталкивалась с простоями из-за большого количества запросов, например, при минтинге NFT. Кроме того, в Solana до сих пор успешно не реализована ротация центрального узла.
Блокчейн TON разработан основателем и основной командой Telegram. Будучи одной из самых популярных социальных платформ в мире, Telegram имеет почти 900 миллионов активных пользователей в месяц, обеспечивая стабильный и бесперебойный пользовательский опыт, сохраняя при этом высокий уровень безопасности и конфиденциальности, при этом в программном обеспечении ежедневно передаются десятки миллиардов сообщений. Концепция web3 стала относительно хорошо известна, но фактические крипто-нативные пользователи по-прежнему составляют меньшинство, и большинство полагается на централизованные биржи для доступа к токену. Metamask, самый популярный в мире децентрализованный криптокошелек, в настоящее время имеет всего 30 миллионов активных пользователей в месяц. И философия дизайна TON с самого начала была основана на обслуживании миллиардов пользователей, а не только нескольких гиков web3.
! Анализ Белой книги TON: Демистификация технологии, лежащей в основе самого быстрого блокчейна в мире
Парадигма бесконечного шардинга
Шардинг — это концепция, которая пришла из проектирования баз данных. Он относится к разделению большого логического набора данных с последующим распределением его по нескольким базам данных, которые не являются общими друг с другом, которые могут быть распределены по нескольким серверам. Говоря простым языком, шардинг предоставляет возможность горизонтального масштабирования, позволяя разбивать данные на независимые части, которые можно обрабатывать параллельно.
TON — не первый проект, который внедрил технологию шардинга в блокчейн, например, Ethereum 2.0 когда-то анонсировал фиксированные 64 шарда, а затем отказался от них из-за слишком большой сложности, в то время как протокол NEAR Night Shadow планирует достичь 100 шардов в следующем году, и в настоящее время существует 4 шарда.
В отличие от традиционных методов шардинга, TON использует стратегию бесконечного шардинга.
Однако подход TON считается продвинутым не потому, что у него больше шардов, а из-за двух уникальных особенностей:
! Анализ Белой книги TON: Демистификация технологии, лежащей в основе самого быстрого блокчейна в мире
В настоящее время TON состоит из двух рабочих цепочек: основной (Masterchain) для синхронизации и управления и рабочей цепочки (Workchain) для смарт-контрактов. Ниже рабочей цепочки находится шардчейн и самый нижний уровень цепочки виртуальных счетов (Accountchain)
Рабочую цепочку можно разделить на N шардов (от 1 до 256 шардов). У каждого шарда есть своя группа валидаторов. Команда рабочей цепочки отвечает за выполнение транзакций в собственных шардах. При этом он постоянно скачивает блоки из всех остальных шардов своей рабочей цепочки. В целом, блокчейн — это серия блоков, которые фиксируют изменения в своем состоянии. Для блокчейнов POS валидаторы сначала договариваются о том, как они хотят изменить состояние блокчейна, компилируя блок, содержащий список изменений. После голосования за этот блок, если набрано достаточное количество голосов, они применяют блок к состоянию блокчейна и переходят к следующему блоку.
Пропускная способность потока блока очень ограничена, потому что валидаторы должны проверять все транзакции в этом блоке, прежде чем согласиться принять его. Таким образом, в TON очень много потоков, и вы можете просто думать о них как о мини-микро-блокчейнах. Они существуют параллельно, и у каждого есть свой набор валидаторов.
Основная цепь
Основная цепочка — это основная нить блока в TON. Он используется для синхронизации всех оставшихся блоков и пересчета набора валидаторов. Когда все потоки соглашаются на новый блок, они подписывают его и регистрируют в основной цепочке. Однако валидаторы мейнчейна не проверяют валидность блока, они только проверяют, подписан ли он соответствующим валидатором. Таким образом, многие потоки могут сосуществовать параллельно. Контракты из разных потоков взаимодействуют друг с другом, отправляя сообщения.
Цепочка работ
Цепочка работы — это независимое адресное пространство, которое может быть запущено по своим правилам. Например, у них могут быть разные виртуальные машины или увеличено время публикации блоков с высокими лимитами газа. Самое главное, чтобы рабочие цепочки имели одинаковый формат очереди сообщений, чтобы они могли обмениваться сообщениями. Это также означает, что все рабочие цепочки должны иметь примерно одинаковые гарантии безопасности. Поскольку они могут обмениваться сообщениями, эти сообщения содержат сетевые токены. Теперь активны две рабочие цепочки: основная цепочка и первая рабочая цепочка обработки. Цепочка работы определяется префиксом адреса: -1:ax... 1s2 - Адрес аккаунта в основной цепочке. -1 - префикс основной цепи.
0:zx... 123 - Адрес аккаунта в первой рабочей цепочке. 0 - это первый префикс для обработки рабочей цепочки.
Цепочки шардов
Обрабатывающий поток, или цепочка шардов, — это независимый блочный поток, который обрабатывает рабочую цепочку. По умолчанию рабочая цепочка 0 имеет только один поток и одну цепочку. Валидаторы этого потока принимают внешние сообщения и обрабатывают внутренние сообщения, которые они отправляют сами или из других рабочих цепочек. Если возникает ситуация, когда поток перегружен в течение последних N блоков, поток разбивается: один поток разбивается на два, и транзакции выполняются параллельно.
Адреса начинаются с 0:00: - 0:88.. Учетная запись в начале теперь находится в потоке 1 с учетной записью 0:88: . - 0:FF.. Находится в потоке 2. Поскольку все смарт-контракты взаимодействуют друг с другом асинхронно без каких-либо сбоев, пропускная способность увеличилась в три раза. Когда нагрузка падает, потоки через некоторое время сливаются обратно. Если нагрузка продолжает увеличиваться, два потока могут быть разделены снова и снова, и так далее. В основной цепочке только одна нить.
Блоки в TON — это больше, чем просто список транзакций, которые необходимо выполнить, чтобы добиться изменения состояния. Вместо этого блок выглядит следующим образом:
Список сообщений, которые выполняют транзакцию, удаляя их из очереди входящих. Новое сообщение попадает в исходящую очередь после обработки сообщения, а затем обработка сообщения вызывает изменение состояния смарт-контракта. То есть, для того, чтобы валидатор шарда X поддерживал текущее состояние шарда Y, ему не нужно выполнять все транзакции в блоке шарда Y. Он просто загружает блок и суммирует произошедшие изменения. Происходит в очередях сообщений и состояниях смарт-контрактов.
Фундаментальное изменение мира блокчейна не может обойтись без цены. Чтобы воспользоваться этим радикальным подходом, разработчики смарт-контрактов TON должны по-другому проектировать свои контракты. Базовой атомарной единицей блокчейна TON является смарт-контракт. Смарт-контракты имеют адреса, код и единицы данных (постоянное состояние). Такие единицы называются атомарными, потому что смарт-контракты всегда имеют атомарно синхронизированный доступ ко всем своим постоянным состояниям.
Сетевая маршрутизация гиперкуба
TON создал умный механизм маршрутизации, чтобы гарантировать, что транзакции между любыми двумя блокчейнами всегда обрабатываются быстро, независимо от того, насколько велика система, а время, необходимое для отправки информации между блокчейнами TON, только логарифмически увеличивается с количеством цепочек, так что даже масштабирование до миллионов цепочек позволяет им общаться с максимальной скоростью.
В блокчейне TON Instant Hypercube Routing и Slow Routing — это два механизма маршрутизации, используемые для обработки кроссчейн-транзакций.
! Анализ Белой книги TON: Демистификация технологии, лежащей в основе самого быстрого блокчейна в мире
Instant Hypercube Routing: идея TON по ускорению маршрутизации сообщений, позволяющая выполнять межсетевые транзакции за долю времени. При традиционной маршрутизации медленного куба сообщение направляется цепочкой сегментов по сети гиперкуба в цепочку сегментов назначения. Однако во время маршрутизации сообщений валидатор, к которому принадлежит цепочка сегментов назначения, может заранее обработать сообщение, чтобы добавить его в блок, а затем предоставить доказательство Меркеля (квитанцию) и отправить квитанцию для уничтожения передаваемого сообщения. Это позволяет совершать кроссчейн-транзакции за очень короткий промежуток времени. Быстрая маршрутизация обеспечивает эффективное межсетевое взаимодействие за счет построения структуры маршрутизации куба высокой размерности. В этой структуре каждая цепочка сопоставляется с одной вершиной куба, а расстояние между цепочками выражается как количество прыжков между вершинами. При таком подходе транзакции могут быть быстро маршрутизированы по кратчайшему пути, что делает межсетевое взаимодействие эффективным. Быстрая маршрутизация позволяет выполнять кроссчейн-транзакции за считанные секунды, не дожидаясь подтверждения блока.
Медленная маршрутизация: Медленная маршрутизация — это относительно традиционный метод обработки межсетевых транзакций путем постепенного переноса транзакций из исходной цепочки в цепочку назначения. В этом методе транзакции сначала упаковываются в блок в исходной цепочке, а затем передаются в цепочку назначения через ретранслятор. Валидатор цепочки назначения проверяет действительность транзакции, а затем упаковывает ее в блок цепочки назначения. Преимущество медленной маршрутизации перед быстрой заключается в том, что она обеспечивает более высокую степень безопасности и децентрализации, поскольку кроссчейн-транзакции должны проходить полный процесс подтверждения блока. Как и в сети TCP/IP, IP-адрес назначения адресуется адресату, чтобы обеспечить надежную передачу сообщений в цепочку назначения по порядку. Для сети гиперкубов с цепочкой сегментов масштаба N должен пройти промежуточный переход цепочки сегментов = log16(N)-1. Таким образом, для поддержки миллионов цепочек шардов требуется всего 4 узла маршрутизации (промежуточные цепочки шардов).
Почему он так устроен? **
Для распределения требуются валидаторы. Если система очень большая, с десятками тысяч узлов, она слишком перегружена для масштабирования. После шардинга у каждого шарда есть set, shard0, shard1... Также необходимо добиться межшардовой коммуникации. Обмен данными может быть перекрестно-сегментированным, и переход от одного сегмента к другому означает, что для сегментов и сегментов должен существовать механизм маршрутизации. Соединение формирует маршрут, который пропускает через некоторый промежуточный узел. Каждый раз, когда сообщение маршрутизируется, это эквивалентно увеличению времени передачи на один блок.
По мере роста общего количества цепочек шардов это потребует большой вычислительной мощности и пропускной способности сети, что ограничит масштабируемость системы. В результате невозможно доставить сообщение напрямую из одного сегмента во все остальные сегменты. Вместо этого каждый сегмент «подключен» только к другому сегменту с шестнадцатеричным числом в идентификаторе сегмента (w,s). Таким образом, все цепочки шардов образуют граф «гиперкуб», а сообщения передаются по ребрам этого гиперкуба.
Если сообщение отправляется на шард, отличный от текущего, шестнадцатеричный номер идентификатора текущего шарда (детерминированно выбранного) будет заменен на соответствующий номер целевого шарда, а полученный идентификатор будет служить приблизительным адресатом для получения пересылаемого сообщения.
Основным преимуществом маршрутизации гиперкуба является условие валидности блока, при котором валидаторы, создающие блоки цепочки шардов, должны собирать и обрабатывать сообщения из выходной очереди «соседних» цепочек шардов или терять стейкинг. Таким образом, можно ожидать, что любое сообщение рано или поздно достигнет конечного пункта назначения; Сообщения не теряются при передаче и не доставляются повторно.
Маршрутизация гиперкуба приводит к некоторой дополнительной задержке и расходам из-за необходимости пересылать сообщения через несколько промежуточных цепочек сегментов. Однако количество этих промежуточных цепочек шардов растет очень медленно, что связано с log N от общего числа цепочек шардов.
Коммуникация асинхронная
Смарт-контракт на TON реализует асинхронную коммуникацию, которую можно сравнить с интернет-микросервисами. Каждая микрослужба имеет только атомарно синхронизированный доступ к своим локальным данным. Обмен данными между двумя микрослужбами включает в себя отправку асинхронных сообщений по сети.
В системной архитектуре для более крупных систем часто требуется архитектура микросервисов. Этот распределенный подход требует некоторых компромиссов для внедрения, но может принести преимущества для взаимодействия с пользователем. Современное управление системами опирается на секвенсоры, такие как Kubernetes, которые берут набор контейнерных микросервисов и автоматически запускают новые инстансы по мере необходимости (автомасштабирование) и эффективно разделяют их между компьютерами.
Если использовать аналогию с Kubernetes (Massive Cluster Management System), то это именно то, что делает TON. По мере увеличения нагрузки на конкретную цепочку шардов она разбивается на две части. Поскольку смарт-контракты являются атомарными, они никогда не делятся пополам. Это означает, что некоторые смарт-контракты, которые когда-то были в одной цепочке шардов, в один прекрасный день могут оказаться в разных цепочках шардов.
Виртуальная машина TON (TVM) применяет концепцию распределенных микросервисов к общей архитектуре, которая сравнивается с EVM Ethereum.
Децентрализация государства
Это один из самых сложных и сложных механизмов шардинга в пространстве шардинга. Вся база данных разбивается и размещается на разных шардах. Каждый шард хранит все данные в своем шарде, а не состояние всего блокчейна.
В блокчейн-шардинге TON все сервисы реализованы в виде смарт-контрактов, а данные о состоянии смарт-контрактов хранятся только в соответствующей сети шардов, чтобы добиться шардинга состояния.
Мало того, в TON контракт достиг уникального пути реализации в отрасли, где каждый пользователь может управлять состоянием токена в своем собственном контракте, по-настоящему реализуя децентрализацию из состояния блокчейна. Я подробно рассмотрю принципы этого дизайна на конкретных примерах.
Прежде всего, вам нужно разобраться в контракте Wallet и контракте кошелька Jetton. Контракт Wallet — это пользовательский смарт-контракт, который управляет токенами пользователя в блокчейне TON. Jetton (рус. Jewel) Контракт кошелька — это особый тип контракта кошелька, который предназначен для управления токенами Jetton пользователя. Эти токены можно использовать для оплаты сетевых комиссий и выполнения смарт-контрактов. У каждого пользователя есть свой контракт кошелька и контракт кошелька Jetton. Эти контракты выступают в качестве цифровых кошельков, в которых пользователи могут хранить свои токены и управлять ими. В то же время эти контракты также могут взаимодействовать с контрактами других пользователей, обеспечивая децентрализованную передачу активов и торговлю.
В этом случае предполагается, что пользователь А и пользователь Б имеют свой контракт кошелька. Пользователь А хочет передать определенное количество токенов пользователю Б. В этом случае контракт кошелька пользователя А взаимодействует с контрактом кошелька пользователя Б для осуществления перевода токенов. Весь процесс должен опираться не на один централизованный контракт, а на два децентрализованных контракта.
Все пользователи блокчейна TON имеют свои собственные контракты на управление состоянием своих активов, а это означает, что не существует единого централизованного контракта, чтобы взять на себя риск управления всеми активами. Это повышает децентрализацию системы и снижает риск возникновения единой точки отказа. Состояние активов всех пользователей управляется специальным контрактом, и злоумышленник не может повлиять на всю систему, атакуя один централизованный контракт. Транзакции с активами между пользователями также могут автоматически выполняться через смарт-контракты, избегая риска действий человека. Вы также можете настроить свой собственный контракт кошелька и контракт кошелька Jetton в соответствии с вашими потребностями, чтобы получить больше функций и сценариев применения. Это дает пользователям больше гибкости и автономии. Каждый управляет состоянием актива в своем контракте, и масштабируемость системы улучшается. По мере увеличения числа пользователей растет и количество контрактов, но это не создает чрезмерной нагрузки на всю систему, поскольку каждый контракт работает независимо.
Выше приведен мой анализ масштабируемости блокчейна TON и технической архитектуры white paper, спасибо Dr. Awesome Doge за редактирование первого черновика. Спасибо российской и украинской командам разработчиков за их настойчивость и, наконец, основателю Telegram, г-ну Николаю Дурову, за его великолепный дизайн много лет назад, и это во славу человеческого разума.