Комментарии 100
Впрочем возможно просто тот же Николай Дуров лично напишет 1000 контрактов, покрывающие 99.9% потребностей юзеров и потом ещё десяток эзотериков будут пилить нестандартные контракты под редкие нужды.
Тогда надо будет доверять этому чудесному автору контрактов. И будет проблема, что мало экспертов, способных проверять контракты на безопасность. А это второе правило криптографии — публичная проверка.
Я понимаю, что в общем случае конечно публичный аудит всеми кем только можно рулит, но у телеграма почему-то получается нормально и без этого. Я не одобряю, но де-факто может получиться юзабельно и безопасно.
А может и не получиться
Forth с точки зрения реализации интерпретатора прост как палка и пишется за пару вечеров. Чтобы начать под него писать нужно знать всего 2 вещи:
1) Можно вводить в язык новые слова
2) Положи на стек данные и запусти слово которое их прожуёт
Всё!
Взяли парадигму Forth, адаптировали для блокчейна, получили Fift. Да, это похоже на ненормальное программирование, равно как и Prolog, Haskel, Erlang или любой другой язык который не такой как <язык в парадигму которого я умею>, но они выполняют свою работу лучше в той или иной области.
Расскажу о своем опыте:
В далеком 2002-2003 годах я решил создать свой аналог популярной тогда одной бухгалтерской платформы и там был интерпретируемый язык программирования. Как потом оказалось он был стековый. Но я об этом не знал и поэтому запилил как умел — прочел книгу по основам интерпретаторов и компиляторов, сделал интерпретацию байт-кода на основе switch/case. Оказалось в 17 раз быстрее оригинала. Видимо за счет лучшей встроенной оптимизации компилятора C/C++. Но сейчас это все равно очень медленно по сравнению с JIT компиляцией.
P.S.
Кстати, я не нашел слово JIT в указанной выше документации TON…
P.S. Для примера и в гиковском проекте TTL компьютера Gigatron (без микропроцессора)
сделан системный язык GTL с элементами Форт дизайна
Ладно, много чейнов вместо одного видимо должны ускорить процессинг транзакций.
Но ёшкин кот. Ладно вы о пользователях не думаете — у них будет мимимишный кошелечек в тележеньке. Почему о разрабах то не подумать? Сделать язык синтаксически близким к JS (как Solidity), или к C — зачем?
АдЪ!
Вы рассуждаете крайне предвзято, при этом исходя из предположения, что использование собственных разработок в TG — это потребность и рассуждая с точки зрения того, что есть сейчас. Совсем не учитывая ни иные предпосылки, ни какие-либо рациональные предположения.
В некоторых статьях из блога ВК на хабре авторы упоминали использование TL схемы. Следовательно, можно предположить, что сам язык был разработан ещё в эти времена. Не факт, что именно в таком виде, как используется в TG, но тем не менее.
Даже если это не так, вполне возможно, что именно такой формат описания подходит для ИХ задач лучше, чем любой существовавший в те дни, когда разрабатывался TG (или ВК, если это верная мысль). Различные тьмы могли либо не существовать, либо не удовлетворять требованиям плотности упаковки, скорости сериализации и т.д. Тем более, что ставить OpenAPI в один ряд с TL не совсем корректно.
Точно так же, как и TLS сравнивать с MTProto довольно глупо. TLS — это протокол для всех, который возможно использовать для многих задач, и соответственно, это привносит ему некоторые недостатки в виде оверхеда, довольно медленного обмена ключами и прочим вещам, которые могли быть критичны (TLS 1.3 был примерно нигде в то время).
MTProto — это узкоспециализированный протокол, который разрабатывался с определенной целью, чтобы удовлетворять определенным требованиям, и альтернатив, которые бы могли полностью покрыть возможности, вполне могло не существовать.
Отмечу специально, что я не оправдываю решения идти путём изобретения подобных вещей (но и не считаю, что это удивительно, либо неправильно). Тем не менее, это не значит, что была необходимость сделать велосипед.
Это ничем не хуже пути, по которому пошли разработчики WhatsApp, например, перекостылив ejabberd, сделав из XMPP дикого полу-текстового полу-бинарного монстра Франкенштейна.
Вы рассуждаете крайне предвзято, при этом исходя из предположения, что использование собственных разработок в TG — это потребность и рассуждая с точки зрения того, что есть сейчас
С достаточной уверенностью, даже с учетом тех лет, можно утверждать, что таки да, именно потребность — но в основном психологического свойства.
Различные тьмы могли либо не существовать, либо не удовлетворять требованиям плотности упаковки, скорости сериализации и т.д. Тем более, что ставить OpenAPI в один ряд с TL не совсем корректно.
Уже существовал как минимум Google Protobuffers. Не то что бы он мне нравился, но даже и с плотностью упаковки у него лучше, чем у TL. А уж эти костыли с флагами… вообще, о костылях в нём можно говорить много. Наконец, вот вроде бы это была попытка сделать нечто строго типизированное с целью проверок на ошибки, с закосом под типы в функциональных языках типа того же Haskell… и что? В схеме нет возможности ни указать, скажем, допустимые границы диапазона значений для целых, ни банальный enum, ни даже Vector<> из самой системы не выводится — все открытые реализации Telegram реализуют его вручную, сбоку.
Что уж говорить о таких приятных плюшках имеющихся других языков описаний схем, как комментарии/документация (даже в JSON-схеме это есть). Впрочем, с документацией у этой команды всегда было плохо.
Точно так же, как и TLS сравнивать с MTProto довольно глупо. TLS — это протокол для всех, который возможно использовать для многих задач, и соответственно, это привносит ему некоторые недостатки в виде оверхеда, довольно медленного обмена ключами и прочим вещам, которые могли быть критичны (TLS 1.3 был примерно нигде в то время).
Единственное, с чем здесь можно согласиться — только скорость обмена ключами. Но это не требовало ни самодельного IGE, ни ряда других решений, на которые плевался умеющий в криптографию товарищ, который пытался реализовать протокол с нуля. Довеском отличная характеристика способностей этих «олимпиадников» — как всего через пару лет пришлось делать MTProto 2.0, потому что ВНЕЗАПНО оказалось, что использованный SHA-1 давно протух. Но нет, заранее изучить, что умные люди придумали, ЧСВ мешало, наверное.
Это ничем не хуже пути, по которому пошли разработчики WhatsApp, например, перекостылив ejabberd, сделав из XMPP дикого полу-текстового полу-бинарного монстра Франкенштейна.
Да у обоих вышло отвратно. Неизбежная проблема рынка — выходишь первый в нишу, возьмут любое говно.
Практически все, что нужно для построения мессенджера — уже придумано и реализовано. Надо только собрать в кучку. Напомню, на дворе 2011 год, когда это все начиналось.
Транспорт — да, TLS/DTLS, не надо выдумывать велосипеды. Криптографией там занимается не один десяток человек. Но нет, костылим свое, в итоге рукалицо, когда в исходниках находят, что облачный пароль хэшируется по SHA256.
Структура данных и контракты вызовов? Вот честно, как по мне, так сопровождение вменяемой документации (а документацию в виде TL вменяемой не назовешь) плюс байндинги на нескольких популярных языках заняло бы сильно меньше времени, чем сопровождение единого языка описания и транспайлеров в нужный синтаксис.
Нету требований и альтернатив, чтобы при проектировании мессенджера костылить эпическую инфраструктуру. Это просто мессенджер. Система асинхронного обмена текстом и кое-какими файлами.
И даже то, что так делает WhatsApp — не оправдание.
А их TL и MTProto — отдельная пейсня, с кучей костылей даже внутри себя.
к JS
или к C
Ужас какой
Получаю:
/root/lite-client/crypto/../validator/interfaces/validator-full-id.h:4:29: fatal error: auto/tl/ton_api.h: No such file or directory
#include "auto/tl/ton_api.h"
^
compilation terminated.
crypto/CMakeFiles/ton_block.dir/build.make:134: recipe for target 'crypto/CMakeFiles/ton_block.dir/block/mc-config.cpp.o' failed
make[3]: *** [crypto/CMakeFiles/ton_block.dir/block/mc-config.cpp.o] Error 1
CMakeFiles/Makefile2:3302: recipe for target 'crypto/CMakeFiles/ton_block.dir/all' failed
make[2]: *** [crypto/CMakeFiles/ton_block.dir/all] Error 2
CMakeFiles/Makefile2:101: recipe for target 'CMakeFiles/test-lite-client.dir/rule' failed
make[1]: *** [CMakeFiles/test-lite-client.dir/rule] Error 2
Makefile:162: recipe for target 'test-lite-client' failed
make: *** [test-lite-client] Error 2
Компилятор не видит заголовочного файла ton_api.h, наверное, надо ему подсказать.
У меня файл "auto/tl/ton_api.h" сгенерировался на одном из предыдущих этапов сборки, вот этот кусок лога:
Видимо, у вас на этапе tl_generate_common что-то пошло не так.
cd tl
make
cd…
cmake --build. --target test-lite-client
После solidity, wasm, vyper — этот вариант с Fifth… Даже не знаю, как выразить эмоции. Жуткий что ли.
— Солидити — да, скриптовый, компилируеться в регистровую VM
— VASM — промежуточный абстрактный язык, в которой компилируеться все, дальше просто бекенд для llvm, минимум одна команда уже делает это.
— Vyper — интересно, но пока на этапе концепции
1. Хранение данных в блокчейне стоит дорого, невероятно дорого! Каждый байт комманд и данных кем то оплачивается.
2. Виртуальные машины блокчейнов запускаются на тысячах нод в сети. Каждая из них выполняет код всех контрактов, для того что бы обеспечить независимую валидацию всей цепочки. Выполнение даже простейшего кода требует расхода огромного количество вычислительных ресурсов.
Использование более эффективных языков одновременно снижает стоимость использования смарт-контрактов для коннечных пользователей и увеличивает производительность сети.
Очень многие критикую блокчейн технологию имеено за высокую стоимость и низкую производительность, поэтому очередная попытка написать еще одну лучшую систему имеет хорошие шансы на успех.
От вида консенсуса и типов клиентов зависит. Может и на части нод исполняться. И да, невероятно дорого — вы уверены? 1k обойдется в 640k газа или 1.7 usd. Контракт живет долго, деплоить его каждый лень не надо.
Невероятно дорого с точки зрения задействованных ресурсов (вычислительного времени, электричества и т.п.), а не денег.
То, что весь блокчейн хранится на каждом узле сети (при отсутствии шардинга).
Так. Ну хранится на каждой ноде с полным стейтом. Как из этого следует "невероятно дорого"?
Если все хранят стейт, а единицы полный — то это угроза для децентрализации.
Проблема масштабирования решается следующим уровнем: дроблением воркчейнов на шардчейны. Каждый шардчейн ответственнен за хранения состояния своего диапазона аккаунтов (подобно шардированию в обычных БД).
В этом концептуальная проблема защиты с помощью депозита — почти любую атаку можно сделать дороже чем депозит который сгорит.
А человек которого «взломали» разве не заинтересован найти виновного как можно быстрее? Ему то видно как из кошелька деньги пропадут.
А как происходит шардирование? Если в один шард попадет много malicious пользователей — это не скажется на чейне?
Меня смущает другой момент. В этой системе встроен инструмент отката данных в блоках. Каждый блок на самом деле не блок, а как его называют в документации, «вертикальный блокчейн», который содержит разные вариации этого блока, и если блок окажется вдруг «плохим», то его помечают флагом, а потом выбирают другой вариант из предложенных в этом «вертикальном блокчейне». И вот это все как-то не особо применимо к определению «блокчейн». Что в целом авторы проекта в документации и указывают.
По поводу желание быть нодой шарда. У валидатора нет выбора быть ему валидатором шарда или не быть. Есть раунды когда определяются роли, и если ты попал в список подгруппы, то либо валидируешь и мастерчен и шард и получаешь за это награду, либо нет. К тому же, тут алгоритм консенсуса это обычный PoS, чтобы стать валидатором нужно стекнуть какую-то часть средств, и в случае «плохого» поведения эту часть у валидатора забирают.
В предложении «ни у кого нет мотивации быть фул нодой некого шарда» я не говорил про валидаторов, я говорил про кого угодно. Те же фишермены или просто big economic nodes. Валидаторов выбирает алгоритм, это нам известно.
>и в случае «плохого» поведения эту часть у валидатора забирают.
Заберут копейки а атака обошлась людям/биржам/продавцам недвижимости в 100 раз дороже. Нарушение финальности в любой подсистеме шардинга = невозвратный факап уровня даблспента в главной сети. Либо нужно ставить требование финальности для шарда в 2 дня например (убедиться что всех все устроило), но тогда ктож этим будет пользоваться.
Валидаторов в пике будет всего 1000, больше не позволит текущий консенсус, без значительного снижения производительности сети.
Капитализация сети в которой наконец-то можно будет реальные приложения и fog сервисы, и которая имеет массадопшен со старта благодаря готовой аудитории первого приложения — Телеграма в 200M+, будет очень скоро измеряться сотнями миллиардов. Соответственно конкуренция за роль валидатора будет очень жесткой.
Все кандидаты в валидаторы что пролетели на выборах на следующий месяц могут чтобы не простаивало железо рыбачить, не только чтобы заработать на штрафах, но чтобы поскорее выбить существующих валидаторов у которых оказалась недостаточно хорошая защита.
Помимо этого можно легко заложить в протокол «подкормку» рыбаков, подкидывая время от времени фейковый штраф который берется просто из эмиссии и никого реально не штрафует, тогда еще и коллаторам будет иметь смысл перепроверять блоки помимо простого хранения и подготовки кандидатов. (я не знаю заложат ли разрабочики TON его или нет, но в принципе ничего не мешает)
Если будет застейкано в среднем 60% всего капитала сети, разделенного на 1000 валидаторов плюс-минум равномерно (там будет ограничение на разницу в обьеме стейка между первым и последним валидатором чтобы избежать централизации), капитализация будет предположим $200B, то получается в среднем на одного валидатора придется 200B * 60% / 1000 = $120M стейка.
Предположим в рабочей группе валидаторов из 20 нод оказалось 14 malicious которые получили больше 2/3 силы и задаблспендили какую-нибудь крупную транзакцию себе на счет. Получается они потеряли ~$1.6B стейка (ну или часть от него) и репутацию, то есть сразу вылетели из бизнеса, что будет стоить тоже очень недешево. И теперь вопрос — какой экономический смысл быть malicious?
Тем более что через несколько секунд рыбаки/коллаторы нажалуются, общий пул всех валидаторов перепроверит и откатит эти 1-2 транзакции что успели сгенерится. За это время даже через атомик свопы в биткоин не успеют вывести украденные средства, не говоря уже про биржи.
Мы ведь должны иметь ни много, ни мало, а verifiable distributed source of randomness.
The algorithm uses pseudorandom numbers embedded by validators into each masterchain block (generated by a consensus using threshold signatures) to create a random seed, and then computes for example Hash(CODE(w).CODE(s).validator_id.rand_seed) for each validator. Then validators are sorted by the value of this hash, and the first several are selected, so as to have at least 20/T of the total validator stakes and consist of at least 5 validators.
Как выше уже заметили — на блокчейне хранение данных стоит ОЧЕНЬ дорого и вычисления тоже стоят ОЧЕНЬ дорого.
Так что применение на блокчейне чего-то подобного Форту — не прихоть левой пятки, а вполне себе обоснованное дизайн-решение, ИМХО. Другое дело, что в 21 веке мы, наверное, стали слишком ленивы для Форта, т.к. надо перестраивать образ мышления.
И да, перелогиниваться не советуйте — я не Николай Дуров :)
Кстати, числа тут — внезапно — 257-битные целыеНу, я уже чувствую быстродействие.
Сейчас я протестирую это утверждение используя какую нибудь прикладную программу на Форте с нормальной современной функциональностью. Хм, а их нет. Нет смысла сравнивать воображаемую программу с настоящей.
."Hello world"
Согласен, Fift может быть довольно нечитабельным, но вот с лаконичностью у него вроде проблем нет :)
Разве не
"Hello world" .
?
Тоже допустимый вариант, но на один символ длиннее :)
Слово ."
берёт последующую за ним строку (до закрывающей кавычки) и сразу же выводит его в стандартный вывод. Посмотрите в примере кода (в статье) — там есть использования этой конструкции.
Спасибо, увидел.
." Hello, world!"
Это т.н. префиксное слово (которое обращается к последующему за ним тексту); для таких слов — нет, пробельный символ не нужен.
."
или ."Hello
? В форте слово — последовательность любых непробельных символов, и слова всегда отделяются пробелами.adnl/adnl-ext-connection.cpp:
auto data_size = td::narrow_cast<td::uint32>(data.size()) + 32 + 32;
S.copy_from(td::Slice(reinterpret_cast<const td::uint8 *>(&data_size), 4));
Когда забыл про эндианесс))
Пока не нашёл ответа на вопрос, в чём прикол использования int257? Подозреваю, что с архитектурной точки зрения это вроде как знаковое int256, но как это вообще сочетается с хранением? Понятно, что виртуальная машина своя и там можно хоть тернарную арифметику использовать, но реально ведь код будет исполняться на обычных и разные там SIMD-инструкции уже не так полетят.

1. Откройте файл lite-client/crypto/vm/cells/CellUsageTree.h.
2. Найдите строчку 48.
3. Внесите исправления в код и сохранить файл.
- std::array<td::uint32, CellTraits::max_refs> children{0};
+ std::array<td::uint32, CellTraits::max_refs> children{{0}};
У меня потом также вылезала следующая ошибка:
fatal error: auto/tl/ton_api.h: No such file or directory
Тут в комментариях описана эта ошибка и её решение:
https://habr.com/ru/post/453714/#comment_20208282
[ 1][t 0][1559502959.109194040][fift-main.cpp:147] Error interpreting standard preamble file `Fift.fif`: cannot locate file `Fift.fif`
Я сам поднимал и настраивал тестовый тон клиент.
Будет интерестно почитать не только то что есть в доке к проекту. а и то что вы сами сделаете.
Я ваш колега. Дерзайте.
Кроме как работы с виртуальной машиной и кошельками TON язык Fift не может.
Видимо основную логику смарт-контракта придётся писать по старинке на стороне веб-приложения, которое будет запускать соответствующие процедуры на языке Fift.
Может я конечно в документации Fift что-то не углядел и там есть возможность создавать условия и временные тайминги, при невыполнении которых смарт-контракт аннулируется или пролонгируется. Но в Fift даже нет типа данных DateTime, не говоря про POSIX UNIX TIME.
Тестовый клиент TON (Telegram Open Network) и новый язык Fift для смарт-контрактов