Комментарии 100
Николай Дуров, перелогиньтесь
Простите, но глядя на язык Fift так и хочется спросить: а вы точно не забыли поставить тег «Ненормальное программирование»?
Я так понимаю fift это нечто максимально приближенное к ассемблеру их виртуальной машины. И в него можно транслировать другие языки. Потом наверняка выкатят что-то более высокоуровневое. Разрабатывать непосредствено на fift что-то серьёзное это конечно смерть.
Впрочем возможно просто тот же Николай Дуров лично напишет 1000 контрактов, покрывающие 99.9% потребностей юзеров и потом ещё десяток эзотериков будут пилить нестандартные контракты под редкие нужды.
Впрочем возможно просто тот же Николай Дуров лично напишет 1000 контрактов, покрывающие 99.9% потребностей юзеров и потом ещё десяток эзотериков будут пилить нестандартные контракты под редкие нужды.
Тогда надо будет доверять этому чудесному автору контрактов. И будет проблема, что мало экспертов, способных проверять контракты на безопасность. А это второе правило криптографии — публичная проверка.
Мало экспертов способны проверить и самопально шифрование телеграма. Но тем не менее телеграм растёт а особых уязвимостей слышно не было. В отличии от всем доступно исходного кода кошельков парити или того смартконтракта дао для эфира.
Я понимаю, что в общем случае конечно публичный аудит всеми кем только можно рулит, но у телеграма почему-то получается нормально и без этого. Я не одобряю, но де-факто может получиться юзабельно и безопасно.
Я понимаю, что в общем случае конечно публичный аудит всеми кем только можно рулит, но у телеграма почему-то получается нормально и без этого. Я не одобряю, но де-факто может получиться юзабельно и безопасно.
Ребятам нужен был «высокоуровневый» язык, чуть человечнее голого ассемблера для стековой машины. Писать транслятор какого-нибудь JS в ASM виртуальной машины — нужно много времени, опыта и компромиссов (привет «undefined is not a object» или проблемы с округлением чисел когда нужно перевести 0.1 условных BTC, которые на самом деле 0.100000001490116119384765625 согласно IEEE 754)
Forth с точки зрения реализации интерпретатора прост как палка и пишется за пару вечеров. Чтобы начать под него писать нужно знать всего 2 вещи:
1) Можно вводить в язык новые слова
2) Положи на стек данные и запусти слово которое их прожуёт
Всё!
Взяли парадигму Forth, адаптировали для блокчейна, получили Fift. Да, это похоже на ненормальное программирование, равно как и Prolog, Haskel, Erlang или любой другой язык который не такой как <язык в парадигму которого я умею>, но они выполняют свою работу лучше в той или иной области.
Forth с точки зрения реализации интерпретатора прост как палка и пишется за пару вечеров. Чтобы начать под него писать нужно знать всего 2 вещи:
1) Можно вводить в язык новые слова
2) Положи на стек данные и запусти слово которое их прожуёт
Всё!
Взяли парадигму Forth, адаптировали для блокчейна, получили Fift. Да, это похоже на ненормальное программирование, равно как и Prolog, Haskel, Erlang или любой другой язык который не такой как <язык в парадигму которого я умею>, но они выполняют свою работу лучше в той или иной области.
По поводу использования стековой машины. Кто нибудь проводил исследования насколько они быстрые или медленные?
Расскажу о своем опыте:
В далеком 2002-2003 годах я решил создать свой аналог популярной тогда одной бухгалтерской платформы и там был интерпретируемый язык программирования. Как потом оказалось он был стековый. Но я об этом не знал и поэтому запилил как умел — прочел книгу по основам интерпретаторов и компиляторов, сделал интерпретацию байт-кода на основе switch/case. Оказалось в 17 раз быстрее оригинала. Видимо за счет лучшей встроенной оптимизации компилятора C/C++. Но сейчас это все равно очень медленно по сравнению с JIT компиляцией.
P.S.
Кстати, я не нашел слово JIT в указанной выше документации TON…
Расскажу о своем опыте:
В далеком 2002-2003 годах я решил создать свой аналог популярной тогда одной бухгалтерской платформы и там был интерпретируемый язык программирования. Как потом оказалось он был стековый. Но я об этом не знал и поэтому запилил как умел — прочел книгу по основам интерпретаторов и компиляторов, сделал интерпретацию байт-кода на основе switch/case. Оказалось в 17 раз быстрее оригинала. Видимо за счет лучшей встроенной оптимизации компилятора C/C++. Но сейчас это все равно очень медленно по сравнению с JIT компиляцией.
P.S.
Кстати, я не нашел слово JIT в указанной выше документации TON…
Непонятно только, почему нельзя было обойтись обычным Фортом.
Внезапно и BitCoin использует Форт подобный язык программирования.
P.S. Для примера и в гиковском проекте TTL компьютера Gigatron (без микропроцессора)
сделан системный язык GTL с элементами Форт дизайна
P.S. Для примера и в гиковском проекте TTL компьютера Gigatron (без микропроцессора)
сделан системный язык GTL с элементами Форт дизайна
НЛО прилетело и опубликовало эту надпись здесь
Всегда удивляла потребность архитектора (-ов?) Телеграма в велосипедах. Нужен шифрованный канал! TLS? Нет, он придуман не нами, у нас будет свой MTProto, со своим языком описания типов TL (различные тьмы IDL-ов, WSDL, OpenAPI, и иже с ними, наверное тоже недостаточно идеальны).
Ладно, много чейнов вместо одного видимо должны ускорить процессинг транзакций.
Но ёшкин кот. Ладно вы о пользователях не думаете — у них будет мимимишный кошелечек в тележеньке. Почему о разрабах то не подумать? Сделать язык синтаксически близким к JS (как Solidity), или к C — зачем?
АдЪ!
Ладно, много чейнов вместо одного видимо должны ускорить процессинг транзакций.
Но ёшкин кот. Ладно вы о пользователях не думаете — у них будет мимимишный кошелечек в тележеньке. Почему о разрабах то не подумать? Сделать язык синтаксически близким к JS (как Solidity), или к C — зачем?
АдЪ!
В защиту выступлю — то, что представлено, это не конечный язык, это некоторый промежуточный ассемблер. Вот если показать IRL, но без 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 — не оправдание.
Практически все, что нужно для построения мессенджера — уже придумано и реализовано. Надо только собрать в кучку. Напомню, на дворе 2011 год, когда это все начиналось.
Транспорт — да, TLS/DTLS, не надо выдумывать велосипеды. Криптографией там занимается не один десяток человек. Но нет, костылим свое, в итоге рукалицо, когда в исходниках находят, что облачный пароль хэшируется по SHA256.
Структура данных и контракты вызовов? Вот честно, как по мне, так сопровождение вменяемой документации (а документацию в виде TL вменяемой не назовешь) плюс байндинги на нескольких популярных языках заняло бы сильно меньше времени, чем сопровождение единого языка описания и транспайлеров в нужный синтаксис.
Нету требований и альтернатив, чтобы при проектировании мессенджера костылить эпическую инфраструктуру. Это просто мессенджер. Система асинхронного обмена текстом и кое-какими файлами.
И даже то, что так делает WhatsApp — не оправдание.
Да зачем? Можно же было взять, например, lua в качестве языка контрактов.
А их TL и MTProto — отдельная пейсня, с кучей костылей даже внутри себя.
А их TL и MTProto — отдельная пейсня, с кучей костылей даже внутри себя.
Можно также вспомнить KPHP, ещё времён Вконтакта, собственную версию PHP с обрезанным ООП. На более высоком уровне к счастью всё попроще. Например, API для ботов Телеграма на удивление простой и приятный для использования.
Про KPHP: vk.com/wall1_45561
к JS
или к C
Ужас какой
Пытаюсь собрать по инструкциям, на Debian.
Получаю:
Получаю:
/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
cd tl
make
cd…
cmake --build. --target test-lite-client
После solidity, wasm, vyper — этот вариант с Fifth… Даже не знаю, как выразить эмоции. Жуткий что ли.
Погодите, вы смешали все в кучу.
— Солидити — да, скриптовый, компилируеться в регистровую VM
— VASM — промежуточный абстрактный язык, в которой компилируеться все, дальше просто бекенд для llvm, минимум одна команда уже делает это.
— Vyper — интересно, но пока на этапе концепции
— Солидити — да, скриптовый, компилируеться в регистровую VM
— VASM — промежуточный абстрактный язык, в которой компилируеться все, дальше просто бекенд для llvm, минимум одна команда уже делает это.
— Vyper — интересно, но пока на этапе концепции
Языки для написанаия смартконтрактов решают двк принципиально важные задачи.
1. Хранение данных в блокчейне стоит дорого, невероятно дорого! Каждый байт комманд и данных кем то оплачивается.
2. Виртуальные машины блокчейнов запускаются на тысячах нод в сети. Каждая из них выполняет код всех контрактов, для того что бы обеспечить независимую валидацию всей цепочки. Выполнение даже простейшего кода требует расхода огромного количество вычислительных ресурсов.
Использование более эффективных языков одновременно снижает стоимость использования смарт-контрактов для коннечных пользователей и увеличивает производительность сети.
Очень многие критикую блокчейн технологию имеено за высокую стоимость и низкую производительность, поэтому очередная попытка написать еще одну лучшую систему имеет хорошие шансы на успех.
1. Хранение данных в блокчейне стоит дорого, невероятно дорого! Каждый байт комманд и данных кем то оплачивается.
2. Виртуальные машины блокчейнов запускаются на тысячах нод в сети. Каждая из них выполняет код всех контрактов, для того что бы обеспечить независимую валидацию всей цепочки. Выполнение даже простейшего кода требует расхода огромного количество вычислительных ресурсов.
Использование более эффективных языков одновременно снижает стоимость использования смарт-контрактов для коннечных пользователей и увеличивает производительность сети.
Очень многие критикую блокчейн технологию имеено за высокую стоимость и низкую производительность, поэтому очередная попытка написать еще одну лучшую систему имеет хорошие шансы на успех.
От вида консенсуса и типов клиентов зависит. Может и на части нод исполняться. И да, невероятно дорого — вы уверены? 1k обойдется в 640k газа или 1.7 usd. Контракт живет долго, деплоить его каждый лень не надо.
Невероятно дорого с точки зрения задействованных ресурсов (вычислительного времени, электричества и т.п.), а не денег.
И что там невероятно дорогого? Мы ведь про хранение контрактов говорим.
То, что весь блокчейн хранится на каждом узле сети (при отсутствии шардинга).
Так. Ну хранится на каждой ноде с полным стейтом. Как из этого следует "невероятно дорого"?
Блокчейн как цепочка блоков никем не должен храниться. Хранится стейт, который при правильных комиссиях маленький, в бтс это 3гб. То что «блокчейн должен всеми храниться» не более чем байка.
Смарт апдейты решают проблему новой функциональности эффективнее — habr.com/ru/post/430734
А в чем инновация если конкретно? Как воркчейны решают проблему масштабирования?
Воркчейны решают другую задачу: возможность иметь несколько независимых блокчейнов с разными конфигурациями.
Проблема масштабирования решается следующим уровнем: дроблением воркчейнов на шардчейны. Каждый шардчейн ответственнен за хранения состояния своего диапазона аккаунтов (подобно шардированию в обычных БД).
Проблема масштабирования решается следующим уровнем: дроблением воркчейнов на шардчейны. Каждый шардчейн ответственнен за хранения состояния своего диапазона аккаунтов (подобно шардированию в обычных БД).
Ладно, и как они решают проблему компрометации одного шарда? Шард взломан и доставляет неверную информацию наверх и другим. Как правило все лайт клиенты полагаются на merkle пруфы, а шарды это те же лайт клиенты.
А что значит шард «взломан»? Ваш аккаунт находится в определенном шарде, транзакцию которую вы отправили проверит группа валидаторов, которая отвечает за ваш шард. Если транзакция не валидная, то валидаторы ее не включат в следующий блок. То что валидаторы могут быть malicious решается тем, что они потеряют свой stake если пропустят не валидную транзакцию
Допустим шардом заведуют 4 валидатора из общих 100. Если из этих 4 трое взломаны, то они могут включить любую транзакцию и создать любого рода merkle proof. Тем самым привести к атаке на миллионы долларов. В то время как их стейк будет в 100 раз меньше, например.
В этом концептуальная проблема защиты с помощью депозита — почти любую атаку можно сделать дороже чем депозит который сгорит.
В этом концептуальная проблема защиты с помощью депозита — почти любую атаку можно сделать дороже чем депозит который сгорит.
Да со взломанными валидаторами это отдельная тема. Как минимум, как указали ниже — есть механизм отката постфактум. Допустим есть плохие валидаторы, если у другого участника сети есть доказательство, что подписали неверные транзакции, то плохие валидаторы теряют стейк, остальные валидаторы вносят правку — откатывают невалидные транзакции и те которые зависят от них, а тот кто указал на зловредных валидотров получает приз, часть от потерянного стейка
Ну а атака то привела к 100 раз большему ущербу чем размер стейка. Задепозитили на 100 разных бирж по 100 тыщ долларов и слили через другие системы. Если финальность шарда нарушена, финальность всей системы нарушена так же. Либо создать аналог кредит лимитов и не доверять некому шарду на более чем какой то volume, но тогда система становится неюзабельной и медленной.
А кто будет валидировать, что валидаторы пропускают не валидные транзакции?
В документации описана отдельная роль для этого — fisherman. По идее любой участник сети может этим заниматься
Если А) с ним будут делиться блоками Б) у него есть достаточно инсентива чтобы годами пропускать через себя 1000 тпс в надежде на стейк. Очень сомнительная бизнес модель.
А как происходит шардирование? Если в один шард попадет много malicious пользователей — это не скажется на чейне?
Есть общая группа валидаторов, которые занимаются подтверждением блоков в мастерчейне. Для шардов раз в определенный промежуток времени псевдорендомно выбираются подгруппы из этой общей группы. Валидаторы из подгрупп выполняют две работы, валидация блоков в шарде и валидация блоков в мастерчейне. Блоки генерируются раз в 5 секунд (это ожидаемое время разработчиков), но при этом между блоками шардов и мастерчейна есть свдиг в одну секунду. В блок мастерчейна записываются хеши последних блоков всех шардчейнов. Примерно так описывается процесс в документации.
Меня смущает другой момент. В этой системе встроен инструмент отката данных в блоках. Каждый блок на самом деле не блок, а как его называют в документации, «вертикальный блокчейн», который содержит разные вариации этого блока, и если блок окажется вдруг «плохим», то его помечают флагом, а потом выбирают другой вариант из предложенных в этом «вертикальном блокчейне». И вот это все как-то не особо применимо к определению «блокчейн». Что в целом авторы проекта в документации и указывают.
Меня смущает другой момент. В этой системе встроен инструмент отката данных в блоках. Каждый блок на самом деле не блок, а как его называют в документации, «вертикальный блокчейн», который содержит разные вариации этого блока, и если блок окажется вдруг «плохим», то его помечают флагом, а потом выбирают другой вариант из предложенных в этом «вертикальном блокчейне». И вот это все как-то не особо применимо к определению «блокчейн». Что в целом авторы проекта в документации и указывают.
Еще большой вопрос а как кто либо узнает что блок стал плохим. При высоком tps, ни у кого нет мотивации быть фул нодой некого шарда. И допустим если 4 валидатора этого шарда стали плохими то вообще никто помочь не может, и они начинают создавать ассеты из воздуха.
Тут не идет речь о реалтайм детектрировании. Это интрумент — альтернатива rolling back в существующих системах, когда в случае серьезного факапа приходится откатывать всю сеть, удалив неугодные блоки, как было с эфиром при TheDAO. Поэтому понять, что что-то пошло не так, может пострадавшая сторона например.
По поводу желание быть нодой шарда. У валидатора нет выбора быть ему валидатором шарда или не быть. Есть раунды когда определяются роли, и если ты попал в список подгруппы, то либо валидируешь и мастерчен и шард и получаешь за это награду, либо нет. К тому же, тут алгоритм консенсуса это обычный PoS, чтобы стать валидатором нужно стекнуть какую-то часть средств, и в случае «плохого» поведения эту часть у валидатора забирают.
По поводу желание быть нодой шарда. У валидатора нет выбора быть ему валидатором шарда или не быть. Есть раунды когда определяются роли, и если ты попал в список подгруппы, то либо валидируешь и мастерчен и шард и получаешь за это награду, либо нет. К тому же, тут алгоритм консенсуса это обычный PoS, чтобы стать валидатором нужно стекнуть какую-то часть средств, и в случае «плохого» поведения эту часть у валидатора забирают.
>У валидатора нет выбора быть ему валидатором шарда или не быть
В предложении «ни у кого нет мотивации быть фул нодой некого шарда» я не говорил про валидаторов, я говорил про кого угодно. Те же фишермены или просто big economic nodes. Валидаторов выбирает алгоритм, это нам известно.
>и в случае «плохого» поведения эту часть у валидатора забирают.
Заберут копейки а атака обошлась людям/биржам/продавцам недвижимости в 100 раз дороже. Нарушение финальности в любой подсистеме шардинга = невозвратный факап уровня даблспента в главной сети. Либо нужно ставить требование финальности для шарда в 2 дня например (убедиться что всех все устроило), но тогда ктож этим будет пользоваться.
В предложении «ни у кого нет мотивации быть фул нодой некого шарда» я не говорил про валидаторов, я говорил про кого угодно. Те же фишермены или просто 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 транзакции что успели сгенерится. За это время даже через атомик свопы в биткоин не успеют вывести украденные средства, не говоря уже про биржи.
Валидаторов в пике будет всего 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.
Мы ведь должны иметь ни много, ни мало, а 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.
Каждый шардчейн включает в себя блоки в которые входят транзакции на адреса этого шардчейна (адреса начинающиеся с определенного префикса). Но валидатор этого шардчейна должен как то проверить источник приходящих средств, а источник средств это другой адрес и его обслуживает другой шардчейн. Получается что валидатор должен сделать сетевой запрос в другой шардчейн о наличие средств на адресе-источнике и отсутствии двойной траты и поверить этому ответу на слово, так как не имеет собственной доказательной базы. Как это работает?
Смею предположить — как у и любого другого inter blockchain communication, например cosmos. cosmos.network Две системы знают наборы валидаторов друг друга и обмениваются merkle пруфами.
Господа программисты, Форт и фортоподобные языки на порядки превосходят по быстродействию и компактности всякие джаваскрипты и прочее — спросите у тех, кто программировал глубоководные контроллеры в 80x, где и памяти и быстродействия — кот наплакал.
Как выше уже заметили — на блокчейне хранение данных стоит ОЧЕНЬ дорого и вычисления тоже стоят ОЧЕНЬ дорого.
Так что применение на блокчейне чего-то подобного Форту — не прихоть левой пятки, а вполне себе обоснованное дизайн-решение, ИМХО. Другое дело, что в 21 веке мы, наверное, стали слишком ленивы для Форта, т.к. надо перестраивать образ мышления.
И да, перелогиниваться не советуйте — я не Николай Дуров :)
Как выше уже заметили — на блокчейне хранение данных стоит ОЧЕНЬ дорого и вычисления тоже стоят ОЧЕНЬ дорого.
Так что применение на блокчейне чего-то подобного Форту — не прихоть левой пятки, а вполне себе обоснованное дизайн-решение, ИМХО. Другое дело, что в 21 веке мы, наверное, стали слишком ленивы для Форта, т.к. надо перестраивать образ мышления.
И да, перелогиниваться не советуйте — я не Николай Дуров :)
Кстати, числа тут — внезапно — 257-битные целыеНу, я уже чувствую быстродействие.
>на порядки превосходят по быстродействию и компактности всякие джаваскрипты и прочее — спросите у тех, кто программировал глубоководные контроллеры в 80х
Сейчас я протестирую это утверждение используя какую нибудь прикладную программу на Форте с нормальной современной функциональностью. Хм, а их нет. Нет смысла сравнивать воображаемую программу с настоящей.
Сейчас я протестирую это утверждение используя какую нибудь прикладную программу на Форте с нормальной современной функциональностью. Хм, а их нет. Нет смысла сравнивать воображаемую программу с настоящей.
."Hello world"Согласен, Fift может быть довольно нечитабельным, но вот с лаконичностью у него вроде проблем нет :)
Разве не
"Hello world" .?
Тоже допустимый вариант, но на один символ длиннее :)
Слово ." берёт последующую за ним строку (до закрывающей кавычки) и сразу же выводит его в стандартный вывод. Посмотрите в примере кода (в статье) — там есть использования этой конструкции.
Спасибо, увидел.
Раз ." это слово, а не специальный синтаксис, то не должно ли оно отделятся пробелом, как в форте?
." Hello, world!"
Это тестовый блокчейн или уже основной?
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-инструкции уже не так полетят.
Скомпилировалось. Запускается. Connection refused…
На убунте кто-нибудь сталкивался с таким?
Сталкивался. Решение:
1. Откройте файл lite-client/crypto/vm/cells/CellUsageTree.h.
2. Найдите строчку 48.
3. Внесите исправления в код и сохранить файл.
У меня потом также вылезала следующая ошибка:
Тут в комментариях описана эта ошибка и её решение:
https://habr.com/ru/post/453714/#comment_20208282
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`
А сколько у вас заняло времени обработка нового блока для пополнения кошелька с testgiver? У меня далеко не сразу пришли граммы…
Вроде все собралось, но не могу запустить на винде, не распознает .\test-lite-client -C ton-lite-client-test1.config.json. В чем проблема?
Уже жду следущую статью.
Я сам поднимал и настраивал тестовый тон клиент.
Будет интерестно почитать не только то что есть в доке к проекту. а и то что вы сами сделаете.
Я ваш колега. Дерзайте.
Я сам поднимал и настраивал тестовый тон клиент.
Будет интерестно почитать не только то что есть в доке к проекту. а и то что вы сами сделаете.
Я ваш колега. Дерзайте.
Не нашёл валидацию покупателем получения товара/услуги.
Кроме как работы с виртуальной машиной и кошельками TON язык Fift не может.
Видимо основную логику смарт-контракта придётся писать по старинке на стороне веб-приложения, которое будет запускать соответствующие процедуры на языке Fift.
Может я конечно в документации Fift что-то не углядел и там есть возможность создавать условия и временные тайминги, при невыполнении которых смарт-контракт аннулируется или пролонгируется. Но в Fift даже нет типа данных DateTime, не говоря про POSIX UNIX TIME.
Кроме как работы с виртуальной машиной и кошельками TON язык Fift не может.
Видимо основную логику смарт-контракта придётся писать по старинке на стороне веб-приложения, которое будет запускать соответствующие процедуры на языке Fift.
Может я конечно в документации Fift что-то не углядел и там есть возможность создавать условия и временные тайминги, при невыполнении которых смарт-контракт аннулируется или пролонгируется. Но в Fift даже нет типа данных DateTime, не говоря про POSIX UNIX TIME.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестовый клиент TON (Telegram Open Network) и новый язык Fift для смарт-контрактов