гольян
гольян
@pmartynov Конечно же демон умеет валидировать, распаковывать и обрабатывать старые транзакции. И именно это является процессом валидации. Вопрос о том, нужен ли инструмент подписания формата транзакций, который никогда более не будет использоваться, для конкретной API библиотеки остается за разработчиком этой библиотеки.
@t3ran13 Одноуровневая модель подписи транзакций на примерах. Пусть есть транзакция А, которую должны подписать Alice (weight := 20%), Bob (weight := 80%). Вес их голоса не зависит ни от чего извне.
Иерархическая модель подписи транзакций на примерах.
Пусть есть транзакция А, которую должны подписать Alice (weight := 20%), Bob (weight := 80%). Но теперь вес голоса Bob зависит от того, как за эту транзакцию проголосуют пользователи Charlie (weight := 50% от Bob.weight) и пользователь Nagibator228 (weight := 50% от Bob.weight).
Более подробно очень неплохо расписано в документации к BitShares: https://bitshares.org/technology/dynamic-account-permissions/
@t3ran13 Похоже, мне нужно объяснить, как базы данных, подобные нашей (вы их называете модным словом блокчейны), работают. Ребята, @vvk @t3ran13, @capitain, цепочка, по-сути, лишь набор инструкций для репликации состояния базы. Это совсем не то, что вы храните на своих жестких дисках, на своих жестких дисках вы храните последнее состояние хранилища базы. Будем до конца честными, у нас и данные о транзакциях (цепочке) волей одного очень известного, но крайне безграмотного человека, хранятся в том же хранилище, куда распаковываются данные, но это ненадолго. По-хорошему, для них нужно отдельное хранилище.
Теперь что касается "переписывания всех блоков". Блок - это просто одна из структур данных, использующихся для формализации протокола репликации. И его содержимое подписано. Так что "Переписывание всех блоков" на самом деле - это формально называется "грубое нарушение протокола распаковки инструкций репликации с игнорированием их подписи как гарантии неизменности". Этого не происходит и на такое я не пойду, ведь это единственный механизм позволяющий нам быть уверенными, что приходящие инструкции для репликации - именно те данные, что хотел записать в базу пользователь. Именно потому ни о каком переписывании блоков речи не идет.
Что касается имен операций. Такое понятие как "Имена операций" существует лишь в рамках структур данных протокола репликации (строго формально понятие имени операции пропадает после сопоставления номера операции ее имени из приходящей транзакции). Имена операций имеют смысл лишь при распаковке инструкций протокола репликации для проверки корректности подписи. Для всей остальной базы такого понятия не существует. А потому нет никакой разницы, как называются структуры данных. задающие этим операции, главное, как они запаковываются и распаковываются для передачи по сети. И это корректно обработано в protocol/operations.cpp, как следствие никакой "потери корректности подписи" и "приписывания чего-бы то ни было в конец имени операции" быть не может. Написание такого - грубейшая ошибка, признак не понимания самой базовой криптографии.
Теперь что касается EventSourcing. Я крайне рад, что среди нашего сообщества есть люди, хоть как-то близкие к разработке ПО и надеюсь, что упоминание этого паттерна не является бравированием нововыученным словом из Вики, как это делает со словами WebAssembly и IPFS довольно известный, но крайне безграмотный человек, ранее уже мной упомянутый. Предлагаемые изменения полностью удовлетворяют этому паттерну проектирования API потому, что отмену поддержки корректной распаковки данных сформированных по-старому транзакций никто не отменял (в ином случае демон не смог бы поддерживать обратную совместимость). Я лишь огородил возможность их корректной распаковки для того, чтобы разработчики фронтендов не путались и не проводили в демона новой версии старые операции без поддержки длинных имен ассетов (ведь мы позиционируемся как платформа для разработчиков).
Я уже упоминал в соответствующем issue, что, да, в угоду удобству разработчиков приложений было несколько пожертвовано удобством тех, кто анализирует всю цепочку. Но и в этом нет ничего страшного - официально поддерживаемые библиотеки умеют читать и писать данные во всех доступных версиях протокола бизнес-логики.
И еще кое-что. Знаете почему вы вообще заметили это исключительно технологическое изменение? Просто потому, что, благодаря особенностям рефлекшена от одного известного, но крайне безграмотного человека, было накладно по времени написать никак не отличающуюся от старой сериализацию структуры данных протокольного ассета.
Резюмируем. Так называемых "Проблем с подписями" нет и быть не может. Смена версии протокола взаимодействия - это не беспредел, а нормальная ситуация для всего мира и не следует отвергать это просто потому, что она появилась у нас впервые. "Имена операций" - нет такого понятия. "Переписывание блоков" - нет такого понятия.
P.S. Ничего личного, в этом комментарии я хотел задеть только одного очень известного, но крайне безграмотного человека и более никого.
@t3ran13 Я уже объяснял, что подобное изменение никак не повлияет на данные цепочки в том же самом issue. Совместимость не ломается. Подписи остаются валидными. И EventSourcing здесь ни при чем - построенная конструкция удовлетворяет ему полностью. Прошу проверить весь процесс перехода самостоятельно на данных тестовой сети.
@yudina-cat Удаление майнинга, по моему мнению, не имеет под собой практической ценности по целому ряду причин. @primus очень развернуто описал их в своем посте (https://golos.io/ru--golos/@primus/o-maininge-golosa-zamovlyu-slovo-3-prichiny-pochemu-pow-sleduet-ostavit-na-golose-i-pochemu-reshenie-o-maininge-ne-dolzhno-vlyat) и в целом, я с постом согласен.
Самое важное, почему майнинг не убирается - возможность анонимной регистрации аккаунтов без внесения залога за нового пользователя. Эту историю на Steemit сейчас выставляют как большое достижение, хотя, на деле, майнинг в нашем текущем виде - это абсолютно то же самое.
@primus Распараллеливание API, и вообще, смена механизма многопоточности на лучшие практики индустрии (взамен доставшейся из Graphene безграмотной самоделки), поможет ускорить обработки входящих транзакций и вызовов API, что по большей части решит проблемы с недоступностью API при высокой нагрузке на демона. На протокол это никак не повлияет.
@t3ran13 Совершенно верно. И это проблема не протокола, а, скорее, фундаментальные недостатки архитектуры демона, фундаментальные физические ограничения и отсутствие более сложного роутинга и сетевого консенсуса, чем "Флуд все всем".
На практике при хорошем сетевом канале и текущих параметрах протокола, при полном графе топологии тестовой сети (что порождает сильную зашумленность) я выбивал около 380-ти нод. Однако, надо понимать, что граф топологии сети далеко не всегда полный (я бы сказал, его полнота - вырожденный случай), а это значит, что сеть способна выдержать столько нод, сколько потребуется при условии расчетливого построения графа сети сообществом.
Решение с автоматизированным технологическим и экономическим решением проблемы роутинга я представлю в рамках другого проекта, на который предположительно (только предположительно) перейдет Голос. Но подробней об этом чуть позже.