Перейти к основному содержимому

Различия блокчейнов

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

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

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

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

Архитектура блокчейна​

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

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

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

Модель счетов (Ethereum) и Акторная модель (TON)​

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

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

  • Externally-owned accounts (EOAs) – внешние управляемые счета, управляются пользователем с помощью публичных и приватных ключей. Публичный ключ позволяет другим отправлять платежи на этот счет.
  • Contract Accounts — это счета, управляемые кодом смарт-контракта, а не приватными ключами. Поскольку у них нет приватного ключа, счета-контракты самостоятельно не могут инициировать транзакции.

Когда пользователь Ethereum создает кошелек, внешний счет добавляется в глобальное состояние на всех узлах децентрализованной сети при проведении первой транзакции или получении средств. Развертывание умного контракта создает счет-контракт, способный хранить и распределять средства программно в зависимости от определенных условий. Все типы счетов имеют балансы, личное хранилище и могут инициировать транзакции, вызывая функции в других счетах. Подобная структура позволяет Ethereum по сути быть программируемой валютой.

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

Теперь давайте разберемся что же представляет собой акторная модель.Акторная модель – это метод параллельной и распределенной обработки, где основным элементом является Актор — независимый исполняемый блок кода.Изначально разработанная для кластерного вычисления, эта модель широко используется в микросерверных архитектурах из-за её способности к масштабированию, а также умению обеспечить параллелизм и надежность при работе с современными распределенными системами.Акторы принимают и обрабатывают сообщения, а далее, на основании логики принимаемого сообщения, могут произвести либо локальные изменения, либо запросить действия в ответ. Более того они могут создавать других акторов или направлять сообщения далее.Они являются потокобезопасными и рекурсивно вызываемыми, что позволяет избежать блокировок и упрощает параллельную обработку задач. Эта модель идеальна для построения масштабируемых и надежных серверных решений, предоставляя эффективный контроль одновременного доступа и поддерживая как синхронные, так и асинхронные сообщения.

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

  • Контракт изменяет свои свойства code, data, balance
  • Контракт опционально генерирует исходящие сообщения
  • Контракт переходит в режим ожидания до тех пор, пока не произойдет следующее событие

Результат скриптов всегда является созданием транзакции. Сами же транзакции асинхронны, что означает, что система может продолжать обрабатывать другие транзакции, не дожидаясь завершения прошедших транзакций.Это обеспечивает большую гибкость при обработке сложных операций. Иногда для одной транзакции требуется выполнение нескольких вызовов смарт-контрактов в определенной последовательности. Поскольку эти вызовы асинхронны, разработчикам проще проектировать и реализовывать сложные потоки транзакций, которые могут включать несколько параллельных операций.Разработчик, переходящий с Ethereum, должен учесть, что смарт-контракты в блокчейне TON могут обмениваться данными только в асинхронном режиме. Это означает, что при запросе данных из другого контракта вы не можете надеяться на получение немедленного ответа.Вместо этого get-методы должны вызываться клиентами снаружи сети. Это подобно тому как в Ethereum кошельках используются узлы RPC, такие как Infura, для запроса состояния смарт-контрактов.Это важное ограничение по нескольким причинам. Например, flash loans — это вид транзакций, которые должны быть выполнены в рамках одного блока, рассчитывая на возможность проведения заема и возврата в рамках одной транзакции. Это требование соответствует синхронной природе EVM Ethereum, но в TON асинхронность всех транзакций делает выполнение flash loan невозможным.Также Оракулы, которые предоставляют смарт-контрактам внешние данные, имеют в TON более сложный процесс проектирования. Что такое Оракулы и как их использовать в TON можно найти здесь.

Отличия кошельков​

Ранее мы уже обсуждали, что в Ethereum кошелек пользователя генерируется на основе его адреса, который находится в отношении 1 к 1 с его открытым ключом.В свою очередь в TON все кошельки являются смарт-контрактами, которые должны быть развернуты самим пользователем. Поскольку смарт-контракты могут быть настроены по-разному и иметь различные функции, существует несколько версий кошельков, о которых вы можете прочитать здесь.В связи с тем, что кошельки являются смарт-контрактами, у пользователя может быть несколько кошельков с разными адресами и начальными параметрами. Чтобы отправить транзакцию, пользователь должен подписать сообщение своим закрытым ключом и отправить его в свой контракт кошелька, который, в свою очередь, пересылает его в смарт-контракт конкретного приложения DApp. Такой подход значительно повышает гибкость в проектировании кошелька, и разработчики могут добавлять новые версии кошелька в будущем.В Ethereum на данный момент разработчики активно используют мультиподписные кошельки, смарт-контракты, типа gnosis и только начинают внедрять так называемые \`account-abstractions' типа ERC-4337, где кошельки наполнены таким функционалом, как отправка транзакций без собственного токена, восстановление счета после его потери и т.д.Однако важно отметить, что счета кошельков TON гораздо дороже в использовании с точки зрения комиссий за газ в сравнении с EOA в Ethereum.

Сообщения и транзакции​

Мы называем сообщением любое событие происходящее между двумя смарт-контрактами, по сути оно является отправкой небольшого количества токенов и произвольного набора данных на указанный адрес. Когда сообщение достигает контракта, оно обрабатывается кодом контракта, состояние контракта обновляется, и он опционально отправляет новое сообщение. Все эти действия в контракте записываются как транзакции.Давайте представим пример: у нас есть цепочка сообщений от контракта A к контракту B, а затем от контракта B к контракту C.В этом случае у нас будет два сообщения и три транзакции. Однако изначально, чтобы изменить состояние блокчейна, нам потребуется внешний сигнал. Чтобы вызвать смарт-контракт, необходимо отправить внешнее сообщение, которое маршрутизируется к валидаторам, и уже они применяют его к смарт-контракту.Мы уже обсуждали в последнем подразделе, что кошелек является смарт-контрактом, поэтому это внешнее сообщение обычно сначала отправляется в смарт-контракт кошелька, который его записывает как первую транзакцию, и эта первая транзакция обычно содержит внутреннее сообщение для целевого контракта.Когда смарт-контракт кошелка получает это сообщение, он обрабатывает его и передает его целевому контракту (в нашем примере контракт A может быть кошельком, и когда он получает внешнее сообщение, у него будет первая транзакция).Последовательность подобных транзакций образует цепочку. Таким образом, вы можете видеть, что каждый смарт-контракт имеет свои собственные транзакции, что в свою очередь означает, что каждый контракт имеет свой собственный микро-блокчейн – вы можете узнать больше об этом здесь. Именно поэтому сеть может обрабатывать транзакции в полной независимости друг от друга.

Отличия в системе газа​

В Ethereum стоимость транзакции измеряется в газе, что отражает количество вычислительных ресурсов, требуемых для выполнения транзакции. Стоимость газа делится на базовую плату, установленную протоколом, и приоритетную плату, которую пользователь добавляет, чтобы ускорить обработку транзакций валидаторами. Общая стоимость будет равна = использованным единицам газа * (базовая плата + приоритетная плата).Кроме того, хранение данных на Ethereum по сути бесплатное, что означает, что после того, как данные были сохранены в блокчейне, больше не возникает затрат на их содержание.

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