Первое знакомство с TON Blockchain Lite Client

admin

Administrator
Команда форума
Сообщения
650
Реакции
190
Первое знакомство с TON Blockchain Lite Client

  • Система поставляется в виде исходного кода C++ со всеми необходимыми библиотеками. Всё собирается без проблем, бинарники запускаются без особых нюансов.
  • Пользователь, запустив клиент, оказывается в интерактивном режиме командной строки с подсказками. Команд пока доступно мало и работают не все из них. Я хотел посмотреть таблицу пиров, но не смог - команда status, хоть и есть в хелпе, пока не воспринимается интепретатором;
  • Скорость: межблочный интервал составляет около 1 секунды, а это для децентрализованных систем очень хороший показатель. Для сравнения, в Ethereum интервал между блоками 15-25 секунд.
  • Но сказать, что TON смог эффективно решить трилемму масштабируемости (Scalability Trilemma) пока, к сожалению, нельзя. Сегодня это чисто клиент-серверное решение, без намёков на децентрализацию и даже на распределённость. Клиент подключается к единственному серверу по TCP и пассивно "висит" на сокете.
  • При запуске клиента нет попыток найти других пиров и установить с ними отношения. Постойте, а как же он находит сервер, к которому подключиться? А очень просто - его адрес задан в конфигурационном файле. "ip": 1137658550 соответствует ip-адресу 67.207.74.182.
  • Несмотря на то, что блоки возникают раз в секунду, лёгкий клиент о них не узнаёт, и лишь при вводе команды last он обращается к серверу и забирает подготовленный для него статус. Не уверен, что это хорошая идея, но буду разбираться, может я чего недопонял.
  • Протокол ADNL весьма компактный - раз в 10 секунд возникает 80 байтный запрос и прилетает ответ такой же длины. Не представляю как в эти сообщения можно сериализовать содержимое блоков. Их как-никак за 10-секундный интервал возникает около 10. Получается 8 байт на блок? Скорее всего речь идёт не о революции в компрессии, а просто лёгкий клиент не получает блоки. Пока это выглядит как весьма спорное решение.
  • В качестве транспорта используется TCP. Формат - бинарный (похоже сообщения шифруются полностью) и отчётливых сигнатур, по которому DPI могут классифицировать трафик для съёма или блокировки я сходу не увидел. Между тем, сам паттерн стрима явно демаскирующий - фиксированные длины запросов и ответов и статически заданный порт.
  • А где же история? Cейчас наблюдаю блок 113001, следовательно сеть существует около 31 часа. Но тестирование длится далеко не первый день, поэтому возникает закономерный вопрос - а где же все накопленные до этого состояния?
Пока можно констатировать, что предложенная сетевая архитектура не является сильной стороной новой платформы. Несколько разочарован, что клиент представлен с конфигом, имеющим всего лишь один сервер, без дискаверинга, без fault tolerance. В ближайшее время погружусь более детально и постараюсь оценить особенности логики аккаунтов и виртуальной машины.


(с) Кирилл Варламов https://www.facebook.com/kirill.varlamov.12
 
Сверху