В последние несколько месяцев всё внимание мирового блокчейн-сообщества было приковано к запуску одного из самых масштабных криптовалютных проектов — Telegram Open Network (TON).
Что на самом деле представляет из себя блокчейн TON? Является ли сеть TON действительно децентрализованной? Каковы её реальные возможности масштабирования? Как стать валидатором сети?

Ответы на эти и другие вопросы попыталась найти команда проекта Mercuryo, которая является активным участником тестовой сети с начала сентября 2019 г.

15 ноября 2019 сервисы Telegram переехали на testnet 2 и стартовала третья очередь тестирования. Наша команда продолжила участие в тестировании, став первыми валидаторами в сети после TON.

Для участия в процессе валидации, от пользователя требуется не только иметь достаточное количество монет (токенов GRAM), но и постоянно запущенный полный узел сети (TON Blockchain Full Node).

Теоретически любой пользователь может стать валидатором при соблюдении условия, что он владеет минимально необходимой долей актива (в монетах Gram) в мастерчейне, но на практике возникает ряд вопросов, на которые ответит в данной статье наша команда.

Кроме этого, мы хотим поделиться опытом по использованию tonlib-cli, т.к. в данный момент практически отсутствует задокументированная информация в отличие от базового варианта, подробно описанного в HowTo.

TON Blockchain

Основным компонентом Telegram Open Network является гибкая система блокчейнов, именуемая в дальнейшем TON Blockchain, которая, по утверждению самих разработчиков, способна обрабатывать миллионы транзакций в секунду, поддерживать полные по Тьюрингу смарт-контракты (Turing Complete Smart Contracts), обновляемые официальные блокчейн-спецификации, мультивалютные переводы, а также каналы микроплатежей для офф-чейн (Off-Chain) платежных сетей.

“Архитектура TON Blockchain является уникальной так как обладает такими специфическими особенностями, как механизм “самовосстанавливающейся” вертикальной цепочки блоков (“self-healing” vertical blockchain mechanism) и мгновенная маршрутизация в гиперкубе (Instant Hypercube Routing), которые позволяют блокчейну быть одновременно быстрым, надежным, масштабируемым и устойчивым.”

Как уже говорилось выше, TON Blockchain – это условное название децентрализованной сети (совокупности цепочек блоков) или 2D-блокчейн, состоящий из трёх основных типов блокчейнов.

Master blockchain или Masterchain (Мастерчейн) – единственная в своём роде цепочка блоков, содержащая общую информацию о протоколе и текущих значениях его параметров, набор валидаторов и их долей, набор активных в данный момент воркчейнов и их «шардов», а также набор хэшей последних блоков мастерчейнов и шардчейнов.

Working blockchains или Workchains (Воркчейны) — множество (до 232 ) блокчейнов, которые являются «рабочими лошадками», содержащими транзакции по перемещению активов и смарт-контракты. При этом отдельные воркчейны могут иметь свои собственные «правила», форматы адресов аккаунтов, форматы транзакций, различные виртуальные машины (ВМ) для смарт-контрактов, разные базовые токены или криптовалюты и т.д. Но все они должны удовлетворять некоторым основным критериям функциональной совместимости для обеспечения относительно простого взаимодействия между собой. Таким образом, TON Blockchain по своей сути является гетерогенным, также как блокчейны EOS и Polkadot.

Shard blockchains или Shardchains (Шардчейны) – подмножество блокчейнов (до 260) внутри множества воркчейнов, обеспечивающее работу системы шардинга и имеющее те же правила и формат блоков, что и у воркчейнов. Шардчейны содержат только подмножество аккаутнов, в зависимости от нескольких первых (наиболее значимых) битов адреса каждого конкретного аккаунта. Поскольку все шардчейны имеют общий формат и правила построения блоков, цепочка блоков TON в этом отношении является гомогенной и отвечает требованиям, описанным в одном из предложений по масштабированию Ethereum.



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

Алгоритмы консенсуса и механизм защиты сети

TON предлагает блокчейн на основе Infinite Sharding Paradigm (парадигма бесконечного шардинга), использующий традиционный механизм доказательства владения (Proof of Stake или PoS). Согласно документации разработчика:

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

Подход TON к шардингу основан на принципе «снизу вверх», заключающемся в том, что исходный блокчейн уже является предельно масштабируемым, а каждый отдельный шардчейн содержит только один аккаунт или смарт-контракт. На следующем уровне у нас есть огромное количество «цепочек аккаунтов», каждая из которых описывает переходы между состояниями только одного аккаунта и посылает друг другу сообщения, содержащие информацию о транзакциях. При этом нецелесообразно иметь сотни миллионов блокчейнов, обновления (т.е. новые блоки) в каждом из которых появляются довольно редко, поэтому, для их более эффективной реализации, мы сгруппировали эти «цепочки аккаунтов» в «шардчейны», каждый блок которого по сути представляет собой совокупность блоков цепочек аккаунтов, которые были привязаны к данному конкретному шарду. Таким образом, «цепочки аккаунтов» на самом деле являются всего лишь виртуальными или логическими блоками внутри реально существующих «шардчейнов». Этот механизм проливает свет на многие из проектных решений блокчейна TON и мы называем его «Парадигмой бесконечного шардинга» (Infinite Sharding Paradigm)».

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



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

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

Номинаторы предоставляют свои активы (токены Gram) валидаторам взаймы с целью получения прибыли. Фактически номинаторы не входят в инфраструктуру валидаторов, а только разделяют свою крупную первоначальную долю актива между ними в обмен на пропорциональный процент от общего вознаграждения. Таким образом, схема и размер вознаграждения, которое получают номинаторы, полностью зависит от результатов работы валидаторов, при этом номинаторы «голосуют» за валидаторов, предоставляя им взаймы токены Gram. В роли номинаторов могут выступать как индивидуальные владельцы токенов, так и пулы, которые управляют средствами отдельных пользователей TON и одновременно выступают в роли валидаторов, действуя как делегаты посредством смарт-контракта TON. При этом суммарное вознаграждение такого пула распределяется между его участниками пропорционально их вкладам.

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

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

Далее валидаторам необходимо достигнуть консенсуса на основе алгоритма BFT (Византийский протокол отказоустойчивости), аналогичного протоколу pBFT или Honey Badger BFT. Затем, после достижения консенсуса, создается новый блок, при этом комиссии за транзакции распределяются между валидаторами.

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

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

TON Testnet: практический опыт работы в Telegram Open Network

Команда проекта Mercuryo является активным участником тестовой сети, с сентября 2019 г., и за время тестирования у нас накопился некоторый опыт, которым мы бы хотели с вами поделиться.

Способы доступа к сети

Взаимодействие с сетью TON, так или иначе, сводится к использованию TL спецификаций, которые описывают способы взаимодействия по API. Файлы спецификаций доступны по ссылке.

Существует три типа API:

ton_api — для взаимодействия с Full Node validator-engine-console
lite_api — для работы с lite-client
tonlib — здесь собрано всё, что касается кошелька и это единственный доступный публично API tonlib-cli

Создание кошелька

Самый простой способ создать кошелёк — это использовать Test Gram Wallet, который доступен на официальном сайте для операционных систем Windows, macOS и Linux.




Также существует несколько способов взаимодействия через интерфейс командной строки: базовый и при помощи tonlib-cli. К сожалению, на данный момент совместимости между ними нет.

Здесь мы будем рассматривать только те инструменты, которые предлагают сами разработчики TON. Если базовый вариант подробно задокументирован в HowTo, то информация по использованию tonlib-cli практически отсутствует.

Как упоминалось выше, в TON существует 3 API для разных задач. За функции, связанные с работой кошелька, отвечает tonlib.

Для начала работы с tonlib-cli, помимо самого интерфейса командной строки, необходимо иметь файл конфигурации для подключения к публичному liteserver сети TON, который доступен по ссылке.

Подключение осуществляется командой

tonlib-cli -c ton-lite-client-test1.config.json -v 0

где -v 0 — параметр, отвечающий за вывод отладочной информации.

Список команд:

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

Список ключей

Команда keys выводит список ключей. Для дальнейших операций при выполнении других команд необходимо использовать их порядковый номер, т.е. для первого ключа будет id 0.

Инициализация адреса

После создания адреса, его нужно зарегистрировать в сети. Для этого его необходимо сначала пополнить. Первоначально для этого использовался специальный смарт-контракт — testgiver, но сейчас проще и удобней использовать специального бота в телеграмме @test_ton_bot.

Сразу после пополнения, статус аккаунта определяется как uninited_accountState и изменится только после того, как вы отправите с этого адреса тестовые токены GRM.

Если у вас уже есть токены на балансе и вам требуется активировать другой кошелек, то можно воспользоваться командой transferf и тогда вместе с пополнением кошелька произойдёт его инициализация.



Узнать состояние кошелька можно при помощи команды getstate 0.



Получить историю транзакций можно посредством команды

gethistory <num_of_key>

где <num_of_key> — порядковый номер ключа

Основа сети

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

Для запуска полной ноды в тестовой сети TON достаточно 8 производительных ядер, 4-8 GB оперативной памяти, на момент написания статьи данные занимали порядка 50GB жесткого диска, но лучше иметь запас хотя бы до 100GB. Необходимо отметить, что лучше использовать SSD диск, т.к. требуется большое количество IOPS на запись, иначе синхронизация с сетью будет очень медленной.

В качестве рабочей ОС лучше всего использовать Ubuntu 18.04, т.к. большая часть тестов сообщества проводится именно на ней.

Сcылки на гайды по установке

README.txt
FullNode-HOWTO.txt
Validator-HOWTO.txt

Система валидаторов

Известно, что блокчейн TON состоит из блоков шардчейна (shardchain) и мастерчейна (masterchain), которые создаются и проверяются специальными назначенными узлами, называемыми валидаторами. Валидаторы получают некоторое вознаграждение за свою «работу»: поддержание работоспособности блокчейна TON, при этом доход распределяется внутри сообщества валидаторов пропорционально.

На первый взгляд все понятно, но на практике в связи с этим возникает ряд вопросов:

• Существует ли ограничение сети на максимальный стейк валидатора?

Ограничение на размер доли для одного валидатора всегда можно проверить командой getconfig 17, которая покажет актуальные размеры допустимых стейков:



На скриншоте видно, что в данный момент минимальный размер доли составляет 10 000 GRAM. Однако в случае, если за раунд голосования у валидатора не набирается больше 100 000 GRAM, то он не имеет права участвовать в выборах. При этом максимальное количество токенов на одного валидатора не может превышать 10 000 000 GRAM и для того, чтобы голосование состоялось, минимальный размер общего стейка должен превышать 1 000 000 GRAM.

• Как выбираются валидаторы?

Для подачи заявки на участие в процессе валидации, необходимо иметь минимум 10000 GRAM. Алгоритм процесса выборов подробно описан в смарт-контракте elector-code.fc
Скорее всего, в основной сети контракт будет другим, поэтому текущая версия применима только для тестовой сети.

Доля в размере 10000 GRAM ещё не означает, что вы сможете стать валидатором, т.к. получение тестовых токенов можно было легко автоматизировать запросами к testgiver.

На данный момент практически все валидаторы при участии в голосовании выставляют max-factor в размере 2.7 и стейк в размере 120000 GRAM, поскольку таких ставок большинство, то из-за их веса минимальный стейк поднимается до 120000 / 2.7 = 45 000 GRAM (в отличие от 100 000 по официальной документации). Но и с таким минимальным стейком ваши шансы практически нулевые, так как три топовых валидатора имеют max-factor равный 2, что поднимает минимальную долю до 60000 GRAM, которая позволяет стать валидатором в тестнете.

Если бы все текущие валидаторы увеличили свой макс-фактор или уменьшили размер стейка, то можно было стать валидатором и с минимальным стейком, при учете того, что не будет превышено максимальное количество валидаторов (1000 узлов).

• Если система валидаторов централизована, то и весь блокчейн тоже?

Проверок нет, т.е. никто централизовано не контролирует валидаторов, номинаторы сами определяют риски при выборе валидатора.

• Какие виды штрафов предусмотрены для валидаторов?

В данный момент нет никакой информации, скорее всего будет в документе с описанием консенсус механизма, потому что в тестнете даже рассинхронизированные ноды получали награды.

• Смарт-контракты

Для создания смарт-контрактов TON, используется два специальных языка программирования: Fift и FunC. Если у Fift существует хотя бы общая документация, то найти информацию про FunC практически невозможно (даже в условиях конкурса на разработку указано, что её можно получить только при анализе его исходного кода).

Во время тестирования удалось выяснить, что кодовая база FunC не такая объёмная (по сравнению с Fift) и позволяет изучить её гораздо быстрее, поэтому работать с FunC намного проще, чем с Fift.

• Актуальные/Насущные/Открытые вопросы

Медленная синхронизация
https://github.com/ton-blockchain/ton/issues/100

Права доступа к validation-engine
+0 = usual lite-client queries
+1 = full node statistics queries
+2 = full code configuration modification queries
+4 = potentially dangerous queries (such as private key export or signing arbitrary strings)
+8 = reserved for future extensions (does nothing at the moment)

• Как заставить PIPE работать с lite-client?

По умолчанию вывод lite-client отправляется в stderr, поэтому для его обработки сначала необходимо перенаправить вывод из stderr в stdout:

$ lite-client 2> >(grep …)

• Какие существуют варианты программного доступа к сети?

https://github.com/ton-blockchain/ton/issues/76

• Какая конфигурация сервера требуется для валидатора?

Официально рекомендуется использование двухпроцессорного сервера (минимум 8 ядер на каждый процессор). Программное обеспечение не очень требовательно к оперативной памяти, поэтому вполне достаточно 16 GB. В качестве основного диска необходимо использовать SSD, минимальный рекомендуемый объем которого составляет 512 GB. Для хранения архивных данных достаточно 8TB HDD.

Обязательно наличие высокоскоростного интернет-подключения: при прогнозируемой средневзвешенной нагрузке 100 Mbit/sec, необходимо иметь возможность обрабатывать пиковую нагрузку до 1Gbit/sec.

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

• Как узнать, что нода синхронизировалась?

В логе будет completed sync сообщение или при помощи validator-engine-console -c «getstats» unixtime и masterchainblocktime должны быть почти одинаковыми.

• Сколько валидаторов может быть в сети?

Getconfig 16
max_validators:1000 max_main_validators:100 min_validators:5

• Как узнать текущих активных валидаторов?

Getconfig 34

Предыдущий набор валидаторов getconfig 32

• Время на которое выбираются валидаторы?

В whitepaper указывается, что валидаторы выбираются на месяц, но в тестнете это время гораздо меньше и узнать его можно из конфига getconfig 15.

После перезапуска testnet, временные интервалы для валидаторов изменились:

ConfigParam(15) = ( validators_elected_for:65536 elections_start_before:32768 elections_end_before:8192 stake_held_for:32768)

Из чего следует, что группа валидаторов выбираются на 65536 секунд.

• Как происходит выбор валидаторов для следующего раунда?

Процесс подачи заявки подробно описан в Validator-HOWTO. Валидаторы выбираются при помощи смарт-контракта, актуальный адрес которого всегда можно найти с помощью команды getconfig 1. Затем необходимо отследить начало голосования.



Если в ответе result: [ 0 ], то значит голосование не активно, если же в ответе указан timestamp, то можно подавать участие на заявку. Даже если вы не собираетесь участвовать, заявки других участников отбора всегда можно посмотреть:

> runmethod -1:A4C2C7C05B093D470DE2316DBA089FA0DD775FD9B1EBFC9DC9D04B498D3A2DDA participant_list

• Можно ли заблокировать TON?

Несмотря на сложную конструкцию сетевого стека на основе оверлейных сетей, в качестве транспортных протоколов TON по-прежнему используются UDP и TCP. Известно, что сегодня блокировки Telegram остаются достаточно безуспешными, т.к. есть возможность менять IP адреса, использовать прокси и обновлять настройки через пуш. Однако TON не будет иметь таких возможностей: быстро переместить ноды не представляется возможным, при этом валидаторы не захотят рисковать своими долями. Поэтому, скорее всего, в ближайшем будущем разработчики Telegram представят новые решения для обхода блокировок, например, при помощи ADNL Proxy.

Ниже представлен трафик одного полного узла после обработки 10 млн. пакетов. Список из 159 IP-адресов, на которых запущены полные ноды тестнета, выглядит следующим образом:

126 DIGITAL OCEAN (предположительно серверы под управлением TON)
13 AMAZON
4 GOOGLE
3 HETZNER
3 ALIBABA CLOUD
2 OVH
2 SELECTEL
2 ONLINE.NET
1 LINODE
1 hosteurope.de
1 contabo.de
and 1 person possibly hosting it at home in Italy telecomitalia.it

Следовательно для регулятора это не составит труда получить список IP-адресов основы сети. Впрочем, это проблема не только TON, но и любого другого интернет-сервиса.

По сути, Telegram Open Network представляет собой попытку реализовать независимый децентрализованный интернет на основе концепции WEB 3.0 внутри существующей глобальной сети, взаимодействие с которой осуществляется посредством уже созданной информационной инфраструктуры мессенджера Telegram.

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

• исходный код проекта написан высокопрофессиональными разработчиками, которые глубоко понимают все тонкости технологии блокчейн;
• созданы свои собственные низкоуровневые языки для написания смарт-контрактов (Fift и FunC), дающие возможность эффективно использовать все возможности виртуальной машины и использовать отладку;
• запущена тестовая сеть, в которой активно работает сообщество сторонних разработчиков;
• работают telegram-боты, облегчающие взаимодействие с экосистемой TON;

Реальные возможности масштабирования блокчейна TON

Парадигма бесконечного шардинга (Infinite Sharding Paradigm) звучит впечатляюще, но она нуждается в тщательной проверке на практике, т.к. по мере увеличения количества шардов, вырастет и количество кроссчейнов, что, вполне вероятно, приведёт к снижению скорости обработки транзакций, таким образом, на самом деле существует эффективный верхний предел пропускной способности. TON планирует использовать то, что сами создатели называют «мгновенной маршрутизацией в гиперкубе» для маршрутизации кроссчейнов и блоков между шарчейнами. Однако, хотя путь маршрутизации может быть найден эффективно, это не является окончательным решением основной проблемы масштабирования блокчейна TON и увеличения пропускной способности.

В то время, как нельзя однозначно говорить о том, что шардинговый подход TON не увенчается успехом, тем не менее необходимо отметить, что «Парадигма бесконечного шардинга» немного вводит в заблуждение, и количество шардчейнов, скорее всего, должно оставаться в разумных пределах.

Децентрализация и консенсус

Фактически, чтобы получить право на участие в достижении консенсуса, узлы TON должны иметь на депозите определенную долю актива (токенов Gram). Недостатком такой модели является то, что она может привести к тому, что богатые станут ещё богаче, поскольку доля актива является единственным определяющим фактором и соответственно TON предоставляет богатым людям средства для финансирования управления узлами PoS, что означает, что только крупные организации с достаточным финансированием будут получать вознаграждение от большинства узлов без усилий и технического ноу-хау.

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

Grams Wallet — приложение для хранения токенов Gram

В свете недавно опубликованного свода правил по использованию блокчейн-сервиса для хранения нативных токенов TON Grams Wallet, который будет интегрирован непосредственно в мессенджер Telegram, у многих участников блокчейн-сообщества возникли опасения, что руководство компании Telegram FZ-LLC намерено блокировать подозрительные аккаунты и безоговорочно выполнять любые указания регуляторов во всех юрисдикциях (даже авторитарных стран).

Однако, при более детальном изучении документа, становится понятно, что данное Пользовательское соглашение не содержит подобных мер или ограничений, а лишь то, что пользователь должен быть старше 18 лет и не планирует использовать приложение в целях, которые нарушают правовые нормы, условия регулирования и предписания, действующие в конкретных юрисдикциях и в случае нарушения этих норм и правил, компания Telegram FZ-LLC не несёт ответственность за действия таких пользователей.

Таким образом, этот документ представляет собой стандартный отказ от ответственности, который можно встретить при использовании любого другого открытого ПО (напр. дистрибутива Linux). При этом, особое внимание следует обратить на один очень важный раздел (р. 4, п. 4.3), в котором речь идёт о том, что компания не управляет блокчейном Telegram Open Network:

«Мы не контролируем TON Blockchain и не в силах аннулировать или изменить данные уже совершённых транзакций».

Our open source

Go-binding library

Как уже упоминалось, единственным способом для взаимодействия с сетью TON является использование библиотеки TONLIB.

Поскольку всю разработку проект Mercuryo ведет на языке Go, то мы решили поделиться с сообществом своими наработками, опубликовав библиотеку-обертку, которую используем сами.
https://github.com/mercuryoio/tonlib-go

Спецификация tonlib api еще далека от своего финального состояние, но уже сейчас с её помощью можно выполнять практически любые действия, связанные с функционалом кошелька:

• Операции с ключами(создание/удаление/экспорт/импорт/смена пароля);
• Отправка сообщений/gram/boc-файлов в транзакции;
• Получение состояния кошелька и информации о нем;
• Получение списка транзакций по кошельку;
• Tongo легковесная утилита для работы с кошельком;

На текущий момент приоритетом в развитии библиотеки являются:

• Мониторинг сети. Возможность получать информацию по каждой транзакции из всех блоков сети. Очень ждем поддержки со стороны самого tonlib;
• Взаимодействия с контрактами. Работа уже ведется;
• Расширение функционала консольного помощника tongo. Стараемся добавить что-нибудь новое с каждым релизом;
• Генерация структур интерфейса по tl спецификации. Позволит нам быть мобильнее и выпускать обновления с минимальными задержками;

Мы продолжим серию постов о тестировании Telegram Open Network, Grams Wallet и будем делиться своими наблюдениями.