Server sync... Block time in database: 1664360757, server time: 1664360927, offset: 170

Разбор технических ньюансов перехода на EOS



У многих пользователей возникают вопросы по разнообразию направлений в связи с предложением команды Golos•Core. осуществить переход на кодовую базу EOS. Данный пост не является попыткой дать ответы на все вопросы, он выполняет функцию одной из вводных частей. Количество частей на данный момент предсказать достаточно сложно, так как количество вопросов может увеличиваться по мере освещения всех деталей переезда на новую платформу.

Важно отметить, что сейчас мы находимся в стадии исследования EOS. Представленный сообществу план базировался на той информации, с которой нам удалось разобраться. Однако, не все вопросы технического плана являются проработанными. Давайте обо всем по порядку.

Исследование перехода на EOS

В целях изучения вариантов дальнейшего развития проекта Голоса несколько недель назад стартовало исследование по EOS, инициированное командой Golos•Core (о своем желании сделать это мы упоминали на дискорде с делегатами и в своем посте), потому что это родственный проект, являющийся более функциональным, чем Голос. Изначальная цель заключалась в изучении и, возможно, частичном импортировании технических улучшений в код блокчейна Голос.

В ходе изучения стало понятно, что при форке EOS и внесении определенных изменений можно осуществить переезд на свежую платформу, предоставив сообществу абсолютно новые возможности. Нельзя не упомянуть об определенном экономическом эффекте, касающемся того, что команда Golos•Core сможет сосредоточится на расширении возможностей блокчейна, а не на постоянных изменениях, необходимых для отображения информации в клиентах блокчейна.

В целях исследования мы разделили текущую архитектуру Голос на следующие подсистемы и проанализировали пересечения с платформой EOS :

  • Встроенная база данных в разделяемой памяти
  • Сетевая подсистема
  • Подсистема проверки транзакций с иерархической системой авторизации
  • Подсистема бендвича
  • Весомая надстройка над БД с рутинами и индексами консенсуса
  • Набор операций и обработчиков операций
  • Набор плагинов для дополнительной обработки информации, поступающей в блокчейн
  • Прослойка API для выдачи информации из стейта блокчейна и из базы подписанных блоков

Существующие операции и их обработчики мы разделили на следующие подгруппы:

  • Аккаунты (профиль, ключи, восстановление, authority)
  • Посты и комментарии (создание, редактирование, удаление, бенефициарство)
  • Голосование за посты
  • Market (трансферы, конвертации с учетом ограничений, накладываемых на переводы между 3 видами активов: GBG, делегирование и т.д.)
  • Делегаты (голосование, изменение параметров, майнинг)
  • Пропозал транзакции
  • Кастом операции для плагинов

В коде EOS мы выделили следующие подсистемы для анализа:

  • БД в разделяемой памяти, аналогичная Голос
  • Сетевая подсистема
  • Подсистема проверки транзакций с иерархической системой авторизации
  • Подсистема учета бендвича
  • Производители блоков
  • Виртуальная машина WebAssembler для смарт-контрактов
  • Слой бизнес-логики, связывающий аккаунты, бендвич и смарт-контракты на виртуальной машине
  • Библиотека смарт-контрактов

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

Для целостного восприятия считаем необходимым проговорить их заново. При переходе на новую платформу Голос могут быть унаследованы следующие подсистемы от EOS:

  • Встроенная база данных (пояснение ниже)
  • Сетевая подсистема
  • Адаптация системы аккаунтов под требования, необходимые для миграции пользователей Golos
  • Подсистема проверки транзакций с иерархической системой авторизации и с необходимыми изменениями для платформы Голос
  • Подсистема учета бендвича
  • Производители блоков с рядом изменений, часть из которых была озвучена в посте Николая Штефана
  • Подсистема market в смарт-контрактах
  • Пропозал транзакции в смарт-контрактах

Концентрат текущей экономики Голос может быть реализован в виде смарт-контрактов:

  • Профили пользователей
  • Создание/редактирование/удаление постов/комментариев, голосование за посты.
  • Правила конвертации токена в вестинг, эмиссия токена

В блокчейн Голоса на базе EOS через смарт-контракты могут быть добавлены:

  • Институт модераторов приложений, определяющих законы эмиссии токенов приложений и ее распределения, правила подключения новых пользователей к общему бендвичу приложений
  • Институт воркеров приложений, развивающих кодовую базу приложений

В этом посте мы подробно опишем некоторые из предлагаемых изменений. Однако, не по всем направлениям исследовательская работа доведена до конца. Соответственно, мы будем искренне рады анализу от сообщества/комментариям от сообщества в части указанных выше пунктов. То, что анализируется нами, будет публиковаться по мере формирования видения относительно возможной технической реализации.

Предлагаем нашему сообществу подключиться к проработке институтов модераторов и воркеров в новом приложении, которые мы опишем в ближайших постах. Не менее важными темами, которые необходимо согласовать с сообществом, мы считаем подсистему учета бендвича, и вопросы, связанные с производителями блоков. Также считаем важным отметить, что основной массив информации по EOS проанализирован, и команда Golos•Core при согласовании деталей перехода с делегатами и сообществом может приступать к плану перехода на EOS (ниже) с учетом предложения по базе данных, озвученного ниже, после завершения текущего софтфорка.

По нашим оценкам, команда Golos•Core из 7 С++ программистов может реализовать предложенный план переезда на кодовую базу EOS в течение 6 месяцев.

Техническое несовершенство Голоса

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

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

Обременительное наследование
Во-первых, текущий код Голоса перегружен условными операторами, необходимыми для поддержания перехода экономики из одного состояния в другое. Все хардфорки, которые происходили в Голосе и были унаследованы от Стима, оставили свои следы в коде. Эти условные операторы усложняют добавление новой функциональности. Их можно переработать (отрефакторить, так это называется в мире IT), и это чисто техническое улучшение, но оно потребует большого количества ресурсов, а также не даст новые функциональные возможности.

Вариантов переработки кода с избавлением от перегруженности кода множество. У каждого есть свои плюсы и минусы.

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

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

Это уже существенно уменьшает объем кода, который будет необходимо перенести.

Неэффективная база данных
Во-вторых, демон Голоса в текущий момент выполняет массу задач: от синхронизации данных по сети до выдачи информации по запросам от клиентов блокчейна. Для каждого слоя используется свой набор технологий. Проблема, на которой нам хотелось бы заострить внимание - это подсистема хранения данных, позволяющая хранить стейт системы (по факту база данных внутри демона). Реализация построенная на boost::multi_index очень сильно упрощает бизнес-логику внутри приложения. Но база данных - это не только удобство в реализации бизнес-логики. Чтобы база данных эффективно выполняла свои функции, необходимо реализация массы других подсистем.

В данный момент эти подсистемы отсутствуют в демоне. При достаточном количестве оперативной памяти демон имеет прямой доступ к данным без каких-либо посредников.
Но не стоит забывать о деталях. Чтобы демон обладал возможностью выдавать информацию, а не только ее модифицировать, в коде существует один-единственный mutex, разрешающий множество запросов на чтение и полностью блокирующий доступ к данным, когда необходимо эти данные изменить. Это приводит к тому, что выполняющиеся запросы на чтение блокируют выполнение транзакций из вновь прибывшего по сети блока. При поступлении в блокчейн новых транзакций на изменение данных происходит полная блокировка запросов на чтение. У того множества баз данных, что существуют в мире IT, есть масса стратегий по блокировке как отдельных таблиц, так и точечной блокировке отдельных записей. В демоне Голоса реализована лишь одна стратегия - глобальной блокировки доступа ко всем данным.

Если посмотреть на историю коммитов то можно обнаружить, что команда Golos•Core перерабатывала систему блокировок, вводила новые механики, позволяющие хоть как-то улучшить существующую ситуацию. Результатом стала не только отзывчивость демона, но и целостность данных. Для сравнения, в коде Стима, да и ЕОС, до сих пор существуют баги, приводящие к повреждению данных при определенных условиях. Возможно, некоторые из вас помнят ошибку, когда при старте демона, наталкивались на заблокированное состояние. Или то, что чтобы решить эту проблему, требовалось удалять файл shared_memory.meta (которого сейчас кстати и нет совсем).

Работа демона напрямую связана с отзывчивостью системы в целом. Чтобы решить проблему отзывчивости, существующие клиенты Голоса экспортируют данные во внешние базы данных и используют их возможности для выдачи ответов на запросы. И это еще не все. Все уже привыкли к необходимости запускать реплей цепочки при выходе новой версии демона, хотя изменилась лишь пара полей в неконсенсусной составляющей данных.

Все это заставляет задуматься, чем обоснована необходимость хранить стейт системы в том формате, который используется сейчас?

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

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

Для реализации слоя API в демоне есть множество плагинов, каждый со своей бизнес-логикой, которая никак не участвует в консенсусе. Любой новый клиент для блокчейна вынужден подстраиваться под текущий API. Это нонсенс в современном мире IT. Как результат блокчейн уже давно является блокчейном одного приложения.

А команда Golos•Core проводит много времени за переработкой и фиксами багов в API и плагинах, что, по большому счету, делается для поддержания функциональности одного клиента. И для реализации какой-то новой функциональности клиент - Голос Ио - вынужден ждать выпуска нового софтфорка.

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

Можно продолжить список, но описанного уже достаточно, чтобы осознать, что Голос с технической точки зрения пытается быть распределенной базой данных, с очень толстым и при этом очень жестким слоем API. Избавление от API с его набором функций позволяет существенно уменьшить объем переносимого кода но новую платформу.

Совершенствуя несовершенство

Чем подкупает EOS? Если заглянуть туда, то можно обнаружить ту же самую систему хранения данных, что в Голосе и Стиме. Но при этом есть существенное отличие, которое называется EOS RAM. Стоимость хранения данных в EOS такова, что переезд Голоса в нее становится крайне дорогостоящей процедурой. Для того, чтобы интегрировать возможности доступа к данным из смарт-контрактов в коде EOS существует одна большая хеш-таблица, ключами в которой являются имя пользователя, имя смарт-контракта, имя таблицы, id ключа в таблице. А в качестве значения используется сериализованная строка таблицы смарт-контракта. Именно это позволяет вести учет потребляемой пользователем RAM.

Внешняя база данных
Соответственно, решение которое мы выдвигаем - экспорт данных во внешнюю БД для превращения нового блокчейна в контроллер поверх БД.

В коде Голоса есть плагин, умеющий экспортировать данные в MongoDB, однако, это не то решение, которое позволит сделать доступ к данным гибким. План заключается в более глубокой интеграции блокчейна с внешней БД и состоит он из следующих этапов:

  1. Создать интерфейс доступа из библиотеки boost::multi_index к внешнему источнику данных
  2. Создать слой кеширования данных в оперативной памяти демона
  3. Написать драйвер для доступа к MongoDB.

Блокчейн будет хранить свой стейт во внешней БД, а не во внутреннем формате данных. EOS RAM в нашем блокчейне перестанет существовать в своем классическом понимании, а превратиться в слой кеширования данных, бендвич доступа к которому будет осуществляться по тем же правилам, по которым сейчас в EOS происходит учет бендвича для сетевой подсиcтемы и подсистемы CPU.

Разделение архитектуры хранения данных на несколько слоев предоставляет возможность в будущем добавить драйвера для других типов баз данных, которые могут лучше подходить для разного типа нод. Например, использование в качестве БД RocksDB или LevelDB может позволить держать ноду без внешних зависимостей с меньшими требованиями на ресурсы системы. Такой тип хранилища может лучше подойти для seed или делегатских нод.

У данного подхода есть ряд преимуществ:

  • Гибкий доступ к данным благодаря мощи современных БД
  • Высокая скорость обработки запросов на чтение
  • Наличие инструментов для бекапа данных
  • Наличие инструментов для расширения структуры данных без необходимости процедуры реплея
  • Возможность масштабировать хранилище данных средствами современных БД

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

Одна из возможных проблем - это увеличенное время доступа к данным, поскольку это внешнее хранилище. Этот пункт достаточно важен, поскольку нода блокчейна должна успевать обрабатывать блоки. И на это накладывается то, что время между блоками в классическом EOS составляет всего полсекунды. Ситуацию немного спасает то, что нода при хранении данных во внешней БД перестает обрабатывать запросы на выдачу информации, и ей необходимо осуществлять лишь несколько точечных запросов на изменение при обработке транзакции. Даже если этого будет недостаточно в форке EOS можно увеличить время на обработку каждого блока.

Следующая проблема - это целостность данных при остановке ноды блокчейна. Она не стоит достаточно остро, поскольку блокчейн уже имеет встроенный механизм сессий для отката блоков при форках системы и отката транзакций при приеме нового блока. Этот механизм замечательно интегрируется с механизмом транзакций БД. Наличие цепочки блоков с транзакциями, являющегося основой блокчейна, позволяет восстанавливать стейт системы с любой точки остановки.

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

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

Ниже представлен имеющийся у нас план создания и тестирования возможности переноса данных во внешнюю БД.

  • 1 этап реализации.
    • Реализация интерфейса на уровне boost::multi_index для доступа к внешнему хранилищу данных.
    • Реализация интерфейсов интеграции объектов сессий chainbase в транзакции внешних хранилищ данных
    • Реализация драйвера для хранения данных в MongoDB
  • 1 этап тестирования
    • Снятие замеров времени необходимых для полного реплея цепочки с одинаковым набором плагинов на одинаковом оборудовании с внутренним и внешним хранилищем данных.
    • Написание нагрузочных тестов с разнородным набором транзакций в блоках.
    • Снятие замеров времени необходимых для выполнения разных типов транзакций.
  • 2 этап реализации
    • Добавление механизмов верификации данных во внешнем хранилище данных.
  • 2 этап тестирования
    • Повторное снятие замеров при включенном механизме верификации данных.
  • 3 этап реализации
    • Добавление слоя кеширования данных в оперативной памяти из внешнего хранилища.
  • 3 этап тестирования
    • Повторное снятие замеров с включенным режимом кеширования данных и с включенным/выключенным механизмом верификации данных.
  • Выпуск в продакшн версии блокчейна Голос с хранением данных в MongoDB.

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

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

Каналы коммуникации с Golos•Core

  • https://t.me/goloscoretc (решение технических вопросов, связанных с работой блокчейн, нод, api и др.)
  • https://t.me/golos_tools (решение вопросов по различным интерфейсам и дополнительным инструментам, создаваемым Golos•Core)
  • https://t.me/goloscore_analytics (решение вопросов по работе экономики блокчейн, статистическим экономическим данным, аналитике данных)
  • https://t.me/goloscoretech (новостной канал, с актуальной информацией от Golos•Core)

Мы будем очень рады, если вы поддержите делегата @goloscore. Заходите на страничку /~witnesses и проголосуйте за делегата Golos•Core

Спасибо за внимание и хорошего дня!
С уважением,
Команда Golos•Core @korpusenko, @andreypf, @maslenitsa, @epexa, @muhazokotuha, @timurku, @zxcat, @mariadia, @annaeq, @anazarov79, @rostislav.vel, @kaynarov, @s-medvedev


Comments 76


(глубой выдох)

24.07.2018 14:30
0

В техвопросах крока плавает...но зато у него есть атличный пример ребят, которые уже реализовали смарт-контрактную систему, потратили дофигища бабла инвесторов и ...уперлись в то, что проект не полетел....
/goldvoice/@mimocrocodil/khalyava-na-stimite-i-mysli-o-smart-kontraktakh-v-formate-temy-nedeli
теперь они на оставшиеся денежки плотно ззадумались о маркетинге и пиаре.

Ну и стоит почитать обзорный пост слоника, с мыслями камрадов по поводу переезда на ЕОСю....
/goldvoice/@slon21veka/tema-nedeli-slon21veka-obzor-23pro-eos-ilx-ne-eos
хороший такой, сытнявый фидбек, собранный за деньги независимых инвесторов без участия "дрымтимы".

24.07.2018 14:31
0

Зачем всё это? Почему бы не направить ресурсы на увеличение пользователей блокчейна, популярности блокчейна? (сейчас этим никто не занимается, вообще). До этого убивали пользователей, разгоняли новичков, выгоняли инвесторов используя Робингуда, вокс попули, проекты еее, культуру голоса и прочие проекты заточенные убивать количество пользователей. Всё получилось, разогнали людей, молодцы, отлично, всё прекрасно. Ведь всё получилось, правда? Людей ведь смогли разогнать потратив кучу ресурсов, ведь в этом была цель, несомненно, молодцы. Все вы довольны результатом, отлично.

Из всего написанного в посте можно сделать вывод, что вам хочется поиграть в блокчейн, вот у меня описан разговор техника, который в бирюльки играет и гуманитария, который пытается достучаться до техника, что надо делать что-то полезное, а не фигнёй страдать /goldvoice/@ili/tekhnik-i-gumanitariij-na-golose

Но ведь не всех смогли разогнать, верно? Ведь есть ещё подлецы остались, что бы придумать, чтобы и их выгнать из блокчейна? О! Бинго, а давайте потратим полгода на херню, которая пользователям не нужна, прикольно ведь, можно поиграть в бирюльки, несколько десятков технарей будут писать кипятком от счастья, заодно допилим все ресурсы и разгоним пользователей, так? Я вам отвечу, именно так. Вы либо специально убиваете и разгоняете пользователей, либо непроходимые невежды в вопросах организации социальной составляющей блокчейна, а она важнее любых технологических изысков. Ну если сами не умеете ничего полезного в этом направлении сделать, то консультируйтесь с теми кто понимает, как и что работает. Или вы думаете, что технический продукт будет работать потому, что вам так хочется? Да никогда так не было. Всю цену биткоину сделали пиарщики, весь смысл биткоину дали пользователи.

Ну вот представьте, всё у вас получилось, перешли на еос, всё замечательно, никаких багов, фантастика просто, но блокчейном никто не пользуется, вы именно к этому ведёте, нахрена можно узнать? В чём кайф сделать блокчейн, которым не будут пользоваться? Может объясните для гуманитариев...

24.07.2018 14:46
0

Добрый день! Плюсы перехода мы попытались детально описать и донести. Одна из потребностей сообщества, о которой говорят уже достаточно давно - это комьюнити токены. Объясните пожалуйста, почему вы считаете, что "но блокчейном никто не пользуется". Случаев, когда пользователи блокчейн и внешние бизнесы, желающие создавать на блокчейне свои различные сервисы и проекты, имея свои токены и готовую экономику, очень много. К нам ранее приходили с подобными вопросами. Исходя из большого количества запросов становится очевидно, что есть высокая потребность в функционале, который предоставляет платформа EOS и которую достаточно долго и сложно реализовывать на текущем блокчейне.

24.07.2018 15:07
0

"Одна из потребностей сообщества, о которой говорят уже достаточно давно - это комьюнити токены." - кто говорит-то ? Распильщики вокс попули? Еее? Кто говорит-то ? Создатели проектов, которые убивали пользователей?

"К нам ранее приходили с подобными вопросами. Исходя из большого количества запросов становится очевидно, что есть высокая потребность в функционале, который предоставляет платформа EOS и которую достаточно долго и сложно реализовывать на текущем блокчейне" - вы меня не слышите вообще, по ссылке в первом комменте пример разговора техника с гуманитарием, гляньте. Людей нет на Голосе, людей, а не функционала и от функционала люди не нарастают.

24.07.2018 15:17
0

У вас же Миша написал весь код для токенов, @creat0r обещал, что Миша за январь-фераль напишет для своего кода документацию и тогда сообществу будет представлен ХФ с токенами после хорошего тестирования. Почему этот код выкинут в корзину?

24.07.2018 15:26
0

Вам нечем заняться? Вы маетесь без дела? Я могу вам сказать, что нужно. Нужна фиговина, которая позволит человеку без регистрации в блокчейне, через публикацию в соответствующем аккаунте блокчейна, специально для этого предусмотренном, размещать контент и далее иметь возможность получать заработанные на Голосе токены. Это не сложно сделать технически. Таким образом можно резко расширить круг людей пользующихся токеном Голос и можно будет хоть с чем-то подходить к серьёзным блогерам. Необходимая фиговина должна, при заключении договора с блогером, самостоятельно вынимать с его сайта(ЖЖ, вконтакте, фб) контент и публиковать его на Голосе. Вот это, как воздух нужно. Но такие ведь проекты неинтересны, верно? Никакого попила, никакого разгона пользователей, наоборот, о ужас, бесплатная реклама блокчейна и увеличение пользователей, ужас-ужас, лучше пойдём на еос пилить, это прикольней и пользователям не нужно.

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

24.07.2018 15:49
0

Я правильно понял, вы хотите за свои токены голоса покупать контент у блоггеров ЖЖ и публиковать на голосе? Кто вам сейчас мешает это делать?

24.07.2018 17:18
0

Конечно неправильно. У меня всё ясно написано, не надо даже ничего додумывать.

И не надо мне писать про мешает и не мешает, я знаю, как и что надо делать, а вы нет и даже неспособны понять элементарный текст моего комментария, так что свой сарказм оставьте при себе.

24.07.2018 17:25
0

Я же технарь ))) пытаюсь понять ход мысли гуманитария. Я так понял вы хотите каким то образом передавать токены голоса людям, не зарегистрированным на голосе. Это как слать письма бездомным. И откуда вы будете брать токены голоса для блогеров ЖЖ?

24.07.2018 19:28
0

Ради очистки совести я вам разжую. Условно создаётся аккаунт фигня1 на блокчейне. Есть отдельный сайт, куда заходит блогер (причём это блогер с одним "г") где он может указать свой блог и выразить желание публиковаться для получения токенов. Желание блогера реализует фигня, которая автоматически вытаскивает его контент с его ресурса и (тадам!) публикует на аккаунте фигня1. Как только блогеров или контента становится больше 4 в день возникает аккаунт фигня2, который заполняется аналогично. Одновременно при выплате за пост на этом сайте заполняется таблица с количеством голосов, которые были получены за пост каждым таким блогером с указанием успехов за всё время, за неделю и месяц, как в свободные Голоса, так и в СГ. Далее может быть несколько вариантов работы с этими голосами, которые принадлежат данному блогеру, подробно расписывать не буду, как и разжёвывать модерацию. В этой схеме нет места для распила, поэтому вам вряд ли будет интересно.

24.07.2018 17:36
0

Как то вы с предубеждением ко мне относитесь. От чего такое отношение? Вот теперь намекаете, что я с ошибками пишу. Почему вы так пренебрежительно относитесь к технарям?

Объяснение я понял. А почему блогер с одной Г не может сам зарегистрироваться и копировать тексты на голос? Все таки оформляются тексты по разному. В прошлом году помню многие так и делали. Просто сбегали, так как тексты тут все равно мало кто читает, только пишут, потому блогеры с одной Г но с большой Б не получали заработок.

24.07.2018 19:37
0

"Вот теперь намекаете, что я с ошибками пишу." - вообще на это не намекал. "Почему вы так пренебрежительно относитесь к технарям?" - я нормально отношусь к любым людям, пока они не начинают принимать решения в сферах, в которых не разбираются.

"А почему блогер с одной Г не может сам зарегистрироваться и копировать тексты на голос?" - я где-то написал, что он этого не может?

Хотите поговорить, можно прямо сейчас это сделать в скайпе или телеграм, разговор значительно экономит время.

24.07.2018 19:43
0

image.png

25.07.2018 05:08
0

@ili

Желание блогера реализует фигня, которая автоматически вытаскивает его контент с его ресурса и (тадам!) публикует на аккаунте фигня1

Тадам, приходит очередная Культура Голоса и начинает флаговать за копипасту или требовать подтвердить права.

Условно создаётся аккаунт фигня1 на блокчейне.

Кстати, а кем создаётся аккаунт? И как его можно создать условно?

26.07.2018 04:00
0

@goloscore

ункциональность клиентов жестко ограничена набором функций и малейшие изменения в API приводят к необходимости переписывать клиентов

В настоящий момент, по крайней мере мне, известны не более десятка активных разработчиков сервисов для Голоса и не более 3 альтернативных клиентов.
При смене платформе есть не нулевая вероятность, что они не начнут переписывать клиентов под совершенно новую платформу, вместо корректировки нескольких функций API, а просто забьют на это дело. Как и разбегутся разработчики, не видя перспектив с таким неопределённым будущем.
А вот то, что прийдут новые, далеко не факт, при общей тенденции упадка Голоса.

26.07.2018 04:13
0

Почему бы не направить ресурсы на увеличение пользователей блокчейна, популярности блокчейна?

Зачем? Задачи такой не стоит, стоит задача прожрать бабки.

24.07.2018 15:25
0

Это первоочередная задача.

24.07.2018 15:36
0

назовите ники предполагаемых модераторов пжл. остальное несущественно-все равно токен не вырастет от ваших действий.

24.07.2018 15:02
0

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

24.07.2018 15:23
0

цензурируемый блокчейн???? вы серьезно?

24.07.2018 18:57
0

Поясните, где мелькнуло слово "цензура"?

24.07.2018 19:59
0

а модераторы, что в их обязанности входит? один из переводов moderator - регулятор=)

24.07.2018 20:02
0

Их роль регулировать параметры экономики, и подключение новых пользователей к бендвичу приложения. Поэтому они модераторы.

25.07.2018 03:09
0

отлично, хотя бы в комментах мы узнали кто такие модераторы) а то 2 поста прошло и до сих пор не изветно было)

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

25.07.2018 07:12
0

А ты не фантазируешь сейчас ли? Описания как будут работать модераторы пока нет. Думаю, в этом вопросе надо будет достигать консенсуса.

25.07.2018 07:59
0

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

25.07.2018 10:59
0

Пользователь вправе пользоваться бендвичем приложения, либо пользоваться своим бендвичем. Модератор не вправе закрыть доступ к БЧ, модераторы определяют правила подключения к общему бендвичу. Подробнее про это позже.

25.07.2018 09:20
0

ок, быть может и не все так плохо, как может быть.

25.07.2018 11:01
0

...модераторы будут ...

как бы синоним. То есть если кто-то (или некая группа) решает, не учитывая мнения сообщества - это уже централизация. А зачем модераторам его учитывать?

24.07.2018 20:17
0

Они регулируют правила экономики сообщества и выбираются сообществом. Сообщество вправе забрать права у модераторов, если они не учитывают их мнение.

25.07.2018 03:11
0

@andreypf, тогда надо с терминами сразу определится. Называйте их регуляторами. Чтобы не было пересечения понятий общепринятых с техническими.

26.07.2018 03:45
0

В ходе изучения стало понятно, что при форке EOS и внесении определенных изменений можно осуществить переезд на свежую платформу, предоставив сообществу абсолютно новые возможности. Нельзя не упомянуть об определенном экономическом эффекте, касающемся того, что команда Golos•Core сможет сосредоточится на расширении возможностей блокчейна, а не на постоянных изменениях, необходимых для отображения информации в клиентах блокчейна.

как это поможет решить текущие проблемы?
вы хоть пять рук приделайте к каждому, но проблемы экономики так и останутся)
Ну вот переедим мы на новый БЧ, кто-то купит токенов. поднимит цены (хотя я очень сомневаюс) и через некоторое время все начнется по второну кругу. у нас не получилось быть достойным клоном стиме, а еоса и подавно не выйдет)

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

о да, вы так рады критике что начинаете писать в личку=)))

Их можно переработать (отрефакторить, так это называется в мире IT), и это чисто техническое улучшение, но оно потребует большого количества ресурсов, а также не даст новые функциональные возможности.

никто не вкурсе резюме нашей команды голос коре, и как понять что в новом БЧ ребята из команды не сделают хуже? ну озвучте вы уже опыт команды!

Высокая скорость обработки запросов на чтение

по бд вообще интересно, как она будет поспевать за БЧ и почему у нее будет высокая скорость? вот не понимаю, хоть убей! но следом вы пишите

Одна из возможных проблем - это увеличенное время доступа к данным, поскольку это внешнее хранилище.

вы уж определитесь, либо высокая скорость обработки запросов, либо увеличение времени доступа к данным. как вообще технари могли написать текст и одним предложением противоречить другому? жесть, ну как эти люди нас перевезут на ГЕОС?

И пожалуй, последнее техническое ишью - это доверие ноды блокчейна к данным, хранящимся во внешнем хранилище.

ага, проблема синхронизации данных лежащих во внешней БД? как решать будем?

Для сравнения, в коде Стима, да и ЕОС, до сих пор существуют баги, приводящие к повреждению данных при определенных условиях.

но нам все равно нужно туда переехать, нам нужно больше багов и проблем! :сарказм

А команда Golos•Core проводит много времени за переработкой и фиксами багов в API и плагинах, что, по большому счету, делается для поддержания функциональности одного клиента. И для реализации какой-то новой функциональности клиент - Голос Ио - вынужден ждать выпуска нового софтфорка.

забавно, но именно это называется развитие, и именно под это собирались деньги на ИКО голоса)

Подтверждение теории практикой

Вы забываете, что придется еще заново разработать клиент голосио, иначе нехрена перезд на БЧ, которым текущие пользователи не смогут пользоваться?

На реализацию описанного выше планируется отвести 2 месяца.

ага, нам @mariadia обещала ХФ каждый месяц, но за пол года их всего 2 вышло. т.е. вы и сроки неадекватно оцениваете еще и можно умножать на 3.

24.07.2018 15:08
0

Любые предложения от команды Голос Кор выдвигаются на обсуждение. Где обсуждение, там и критика, однако, хотим напомнить, что у всего есть разумные границы. Критика не исключение. Мы усердно работаем, готовим статьи, аналитику и репорты - поэтому и ожидаем некого уважения и такта в ответ.
Касаемо опыта команды - можно заглянуть хотя бы в самый последний пост о новых сотрудниках Core. Все открыто и прозрачно. У некоторых из наших разработчиков опыт более 15 лет, более того, к любому сотруднику при большом желании можно обратиться лично и задать вопросы, которые вас тревожат - все открыты к обратной связи.
Сроки хардфорка могут меняться, но любые задержки или отклонения от плана всегда освещаются и доводятся до сведения сообщества.

24.07.2018 15:41
0

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

я у тим лида спрашивал про его опыт и его команды, спрашивал у вашего менеджера. ноль по фазе. так что сказанное вами не соответсвует действительности.

Мы усердно работаем, готовим статьи, аналитику и репорты - поэтому и ожидаем некого уважения и такта в ответ.

а где вас, бедненьких, уже оскарбили, и чем?
вот я так от команды в своих постах по поводу переезда так и не дождался комментариев, видимо не потому что критика плохая или хорошая, а потому что бестактаная???

24.07.2018 16:24
0

самый последний пост о новых сотрудниках Core.

нет, ну это не серьезно. где вы такие резюме видели?

24.07.2018 19:29
0

вы усиленно работаете- это похвально, только вот результаты этой усиленной работы как-то не очень убедительны. Значит ли это, что ваша работа - это сизифов труд или просто результат этой самой усиленной работы направлен совсем не на те цели, которые ставит сообщество?

24.07.2018 20:21
0

но любые задержки или отклонения от плана всегда освещаются

это да, только новые сроки переносятся по 10 раз, а иногда даже вообще не указываются.

24.07.2018 20:22
0

Высокая скорость обработки запросов на чтение

по бд вообще интересно, как она будет поспевать за БЧ и почему у нее будет высокая скорость? вот не понимаю, хоть убей! но следом вы пишите

Высокая скорость ответов на API запросы без участия БЧ.

Одна из возможных проблем - это увеличенное время доступа к данным, поскольку это внешнее хранилище.

вы уж определитесь, либо высокая скорость обработки запросов, либо увеличение времени доступа к данным. как вообще технари могли написать текст и одним предложением противоречить другому? жесть, ну как эти люди нас перевезут на ГЕОС?

Скорость доступа к данным из БЧ увеличится. Но благодаря отсутствию API запросов к БЧ, то времени на обработку транзакций у БЧ будет больше.

ага, проблема синхронизации данных лежащих во внешней БД? как решать будем?

Блок-лог - это журнал всех транзакций. Запустим синхронизацию с места на котором остановились.

Остальное вроде как сарказм.

24.07.2018 16:29
0

Остальное вроде как сарказм.

там где сарказм я не поленился указать, и меня как инвестора ико интересует коментарий даже и на сарказм)

Давай я просто процитирую два сообщения, а ты сам догадаешься где ты сам себе противоречишь

Высокая скорость обработки запросов на чтение
Одна из возможных проблем - это увеличенное время доступа к данным, поскольку это внешнее хранилище.

а теперь ты написал пояснения

Высокая скорость ответов на API запросы без участия БЧ.
Скорость доступа к данным из БЧ увеличится. Но благодаря отсутствию API запросов к БЧ, то времени на обработку транзакций у БЧ будет больше.

Т.е. сперва мы говорили о внешней бд, а потом ты свел разговор к работе БЧ? вот те раз
вопрос прямой, про доступ к данным во внешней БД - так будет "увеличинаная скорость ответов" или "увеличенное время доступа"? это одно другому противоречит.

Блок-лог - это журнал всех транзакций. Запустим синхронизацию с места на котором остановились.

опять ответ не в попад. смотри внимательно вопрос

проблема синхронизации данных лежащих во внешней БД?

Причем тут остановка? У тебя работает, скажем, 60 нод, у них транзакции храняться в БЧ, а тело постов во внешней БД. Вот создается транзакция и рассылается по БЧ, а вот как тело поста к другим нодам попадет? Как это децентрализованно будет хранится и распростроняться? Да еще с такой скоростью, чб небыло ситуаций когда в БЧ пост создан, а содержимое я получить еще 5 минут не могу.

24.07.2018 18:43
0

Т.е. сперва мы говорили о внешней бд, а потом ты свел разговор к работе БЧ? вот те раз
вопрос прямой, про доступ к данным во внешней БД - так будет "увеличинаная скорость ответов" или "увеличенное время доступа"? это одно другому противоречит.

Не противоречит.

Мы хотим сделать из БЧ контроллер, который вносит изменения во внешнюю БД. Это запросы на обновление данных. При обновлении данных нужно будет ходить в БД, и тут будет увеличение времени на доступ к данным. Э

Мы хотим убрать у БЧ роль обработчика ответов на API запросы, и перенести эту роль на сторону внешней БД, которая с этим справляется значительно лучше, так как внутри БЧ недоделанная БД. Это запросы на чтение, и здесь будет увеличение скорости ответов.

Блок-лог - это журнал всех транзакций. Запустим синхронизацию с места на котором остановились.

опять ответ не в попад. смотри внимательно вопрос

БЧ вносит изменения во внутреннюю БД, используя сущность session. Это аналог транзакций в классических СУБД. Это позволяет БЧ принимать отдельные подписанные транзакции и накладывать их на текущий стейт и безболезненно их откатывать. Точно также это позволяет откатывать целиком подписанные блоки при форках сети.

Задача сводится к тому, чтобы интегрирровать session с транзакциями СУБД, и вносить изменения во внешнюю СУБД транзакциями СУБД. То есть синхронизация будет происходить по блок-логу, представляющему из себя журнал транзакций для внешней СУБД, которую будет транслировать контроллер в лице БЧ.

там где сарказм я не поленился указать, и меня как инвестора ико интересует коментарий даже и на сарказм)

Это видимо про это:

ага, нам @mariadia обещала ХФ каждый месяц, но за пол года их всего 2 вышло. т.е. вы и сроки неадекватно оцениваете еще и можно умножать на 3

Чтобы принятие ХФ случалось один раз в месяц, разработка должна уложится в 1 неделю. Потом 1 неделя на тестирование, и 2 недели на переезд биржи. И того в ХФ можно включить очень ограниченное количество функциональности.
Передо мной ставилась задача разработать ХФ за 1 месяц. И оно так и происходило. Еще один месяц уходил на тестирование и согласование переезда биржи.

Вы забываете, что придется еще заново разработать клиент голосио, иначе нехрена перезд на БЧ, которым текущие пользователи не смогут пользоваться?

Голос ИО тоже планирует переезд.

25.07.2018 03:03
0

При обновлении данных нужно будет ходить в БД, и тут будет увеличение времени на доступ к данным. Э

т.е. мало того что операция записи сама по себе медленнее чем чтение, так еще и дополнительно тормоза от архитектуры?
Я вообще не понимаю, зачем жертвовать голосу производительностью и скоростью, ему на плохом своем графене быстрее чем на ГЕОС будет)

Мы хотим убрать у БЧ роль обработчика ответов на API запросы, и перенести эту роль на сторону внешней БД, которая с этим справляется значительно лучше, так как внутри БЧ недоделанная БД. Это запросы на чтение, и здесь будет увеличение скорости ответов.

Далеко не фак что тут будет выше скорость работы. Все зависит от внешней бд, от структуры бд и индексов) Вы еще ничего не сделали, а смело заявляете что она будет шустрее. на основании каких данных? тех что минули БЧ? ну так бч не влияет на скорость, он скорее на блокиеровки к доступу данных влияет.

Передо мной ставилась задача разработать ХФ за 1 месяц. И оно так и происходило. Еще один месяц уходил на тестирование и согласование переезда биржи.

сколько времени переноса под ключь? т.е. полностью все работает и без косяков, это по прежнему пол года? или перед тобой не ставилась задача выкатить полностью рабочий ГЕОС и дапп голос рабочими и без багов?

Голос ИО тоже планирует переезд.

ярад, но они при этом слабое звено, и если они не справятся за пол года, то и вы не справитесь. Должен быть не просто код написан, а все апп перенесено, и люди должны почить блоги на выходе. именно под это деньги и тратились.

Задача сводится к тому, чтобы интегрирровать session с транзакциями СУБД, и вносить изменения во внешнюю СУБД транзакциями СУБД. То есть синхронизация будет происходить по блок-логу, представляющему из себя журнал транзакций для внешней СУБД, которую будет транслировать контроллер в лице БЧ.

т.е. ГЕОС будет разруливать еще и синхронизацию внешних БД от дапп блогов? какая уж тут производительность и ускорение чтения и работы с внешней бд при такой архитектуре?
Мало того что сам пишешь о тормозах на чтение, так еще это все придется гонять по сети ГЕОС, которая и так будет забита.

Ну и какой профит от этого будет сети ГЕОС? вы сожрете все ресурсы сети, это приведет к удорожанию сети, и отсутствию конкурентности с ЕОС. тогда ГЕОС как платформа не будет нужен не одному апп, какой смысл тогда от переезда?=)))))))))

25.07.2018 07:05
0

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

Мы компенсируем одно другим. Есть технические сложности, но непреодолимые препятствия, и предлагается их решить. В результате мы получаем ряд преимуществ.
А так чтобы существовала универсальная серебрянная пуля - такое не бывает.

Я вообще не понимаю, зачем жертвовать голосу производительностью и скоростью, ему на плохом своем графене быстрее чем на ГЕОС будет)

Результирующая производительность вырастет.

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

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

У внешней БД есть возможности для тюнингования и масштабирования. Чтобы добавить подобное в БЧ - это начать разрабатывать БД.

сколько времени переноса под ключь? т.е. полностью все работает и без косяков, это по прежнему пол года? или перед тобой не ставилась задача выкатить полностью рабочий ГЕОС и дапп голос рабочими и без багов?

Часть вещей планируется делать на Голосе. А не уйти в глубокую разработку на полгода и вернутся с блестящим мерседесом. В первом посте указаны сроки на реализацию этапов, которые можно будет отслеживать поэтапно. Естественно, что между этапами будут свои мероприятия.

т.е. ГЕОС будет разруливать еще и синхронизацию внешних БД от дапп блогов? какая уж тут производительность и ускорение чтения и работы с внешней бд при такой архитектуре?
Мало того что сам пишешь о тормозах на чтение, так еще это все придется гонять по сети ГЕОС, которая и так будет забита.

Я пишу о технических сложностях, которые нужно решить, а не о непреодолимых препятствиях.

25.07.2018 09:10
0

Результирующая производительность вырастет.

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

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

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

У внешней БД есть возможности для тюнингования и масштабирования. Чтобы добавить подобное в БЧ - это начать разрабатывать БД.

Если это будут какие-то отдельные масштабируемые сервисы на отдельном железе... ну далеко не факт что все будет так хорошо.
Опять же, неверное создание индексов или написание запросов выборки может очень сильно влиять на производительность системы, не говоря о выборе самой БД. Хотело бы видеть БД и описание того, как будет настроена, что выбрано, и какое время между блоками потянет эта бд. пока если считать 0,5 секунды. я в это не верю. У нас блоки по сети стоько распростроняются иногда, а иногда и больше.

Часть вещей планируется делать на Голосе. А не уйти в глубокую разработку на полгода и вернутся с блестящим мерседесом.

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

Я пишу о технических сложностях, которые нужно решить, а не о непреодолимых препятствиях.

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

25.07.2018 11:13
0

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

Про это и пост. Предложение - отладить технологию на Голосе. И проверить как это будет работать.

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

У comment_operation 7 полей.... Там больше логики вокруг - можно обновлять на таком хардфорке или нельзя, сколько постов день можно делать на таком то хардфорке....В этом плане код лучше документации. ... Перенести необходимо ограниченное количество операций - все что касается блог-платформы. Маркет: escrow, limit_order, transfer, feed_publish, .... Майнинг: pow2 ... , Пользователи: account_create, account_update, account_recovery, ... - Ничего этого переносить не нужно.

пока если считать 0,5 секунды. я в это не верю.

Время блока с большой долей вероятности увеличим.

25.07.2018 11:57
0

Про это и пост. Предложение - отладить технологию на Голосе. И проверить как это будет работать.

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

Хочется видеть "проблема->решение" для технарей, а не для красного словца.

У comment_operation 7 полей.... Там больше логики вокруг - можно обновлять на таком хардфорке или нельзя, сколько постов день можно делать на таком то хардфорке....В этом плане код лучше документации. ... Перенести необходимо ограниченное количество операций - все что касается блог-платформы. Маркет: escrow, limit_order, transfer, feed_publish, .... Майнинг: pow2 ... , Пользователи: account_create, account_update, account_recovery, ... - Ничего этого переносить не нужно.

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

25.07.2018 14:30
0

Планы конечно грандиозные, по крайней мере текст располагает так думать.

Вот что интересно, сделаете вы/мы новый блокчейн общего назначения, а что с голосом? Мне кажется вы не учитываете, что golos.io придется тоже радикально переделывать. Ну понаделаете вы смартконтрактов для учета постов, отданных голосов, и будет пара методов, что бы получить такие же рудиментарные данные, по выплатам, по голосам итп? А где будет golos.io хранить текстовые данные и самое главное, как он будет их извлекать? Как я сейчас вижу, вся убогость golos.io произрастает из убого API к внутреней базе данных. Нормальную информационную систему с такой базой данных не постоишь. golos.io всего лишь браузер данных блокчейна + редактор, не более. Гигабайты текстов в блокчейне, а изхвлечь их от туда не получается. И мне кажется, что внешняя база данных в этом не поможет. golos.io, если они хотят стать блог платформой рано или поздно придут к тому, что бы хранить данные в нужном для golos.io виде, а переход на EOS только подтолкнет к этому. Но вот я почему то не уверен, что пара программистов или сколько их там, сможет за полгода мигрировать на новую парадигму.

Насчет замены внутренней базы, на внешнию само по себе отличная идея, я раньше об этом говорил и предлагал, но со временем я охладел к этому. Оно нам надо? Сейчас shared_memory файл уже больше 72 Gig. Если заменить на обычную базу данных, размер от этого не уменьшится. Но самое интересное, что из этих 72G только ~5-6G консенсусные, а остальное вода для плагинов и в основном история по пользователям. Причем эти данные в большинстве своем никому не нужны. Вряд ли кто то смотрит посты про "красный понедельник" годичной давности. Мне кажется вместо этого надо а) облегчить написание плагинов, что бы снизить порого вхождения дла программистов, что бы им было проще поднять свою ноду и написать свой плагин. б) проработать механизм, что бы плагины могли сами складывать данные в свои базы данных, в тот же mongodb, в нужном для плагина виде. с) проработать упомянутый механизм консистентности данных, что бы плагины могли автоматически откатывать отброшенные цепочки.

Если программистам будет проще писать приложения под блокчейн, не заботясь о нудном, то и публичной ноде не нужны будут 72Гига памяти. Если ограничить хранение данных последними тремя месяцами, то потребление упадет до каких нибудь 30-40 гиг, для golos.io будет проще содержать кластер нод.

И вообще, надо вынести плагины в отдельный проект.

Ну а переход на кодовую базу EOS. Оно само по себе интересно, но я сомневаюсь в человеках. Возможно пара человек понимают, что делают, как работает блокчейн, но остальных надо еще натаскивать. Тот же плагин mongodb пилили, если не ошибаюсь 4-5 месяцев. Уже месяц мне сыпятся маилы по поводу рефакторинга системы ошибок. И это уже хорошо знакомый голос. Не получится ли правда как в песне


Тот был умней, кто свой костер сберег -
он обогреть других уже не мог,
Но без потерь дожил до теплых дней.
А ты был не прав, ты все спалил за час,
и через час большой огонь угас,
Но в этот час стало всем теплей.
24.07.2018 15:33
0

Сейчас shared_memory файл уже больше 72 Gig. Если заменить на обычную базу данных, размер от этого не уменьшится. Но самое интересное, что из этих 72G только ~5-6G консенсусные, а остальное вода для плагинов и в основном история по пользователям. Причем эти данные в большинстве своем никому не нужны.

Большинство плагинов сейчас агрегируют какие либо данные, чтобы можно было выдавать ответы на API запросы. При переезде на хранение в БД, необходимость во многих плагинах отпадет.

Причем эти данные в большинстве своем никому не нужны. Вряд ли кто то смотрит посты про "красный понедельник" годичной давности.

Это будет в ближайшем софтфорке.

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

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

Тот же плагин mongodb пилили, если не ошибаюсь 4-5 месяцев.

Человек, который пилил монго-плагин почти 3 месяца и засыпал github коммитами в попытке найти ошибку "методом тыка", в команде уже не работает. Остальное доделывалось между делом для сбора статистики, так как по принятию дел, стало понятно, что это был тупиковый путь.

Уже месяц мне сыпятся маилы по поводу рефакторинга системы ошибок.

Чтобы переделать систему генерации ошибок приходится перешерстить весь код. Но делается это осознано, а не "методом тыка" как было в случае с монгой. Большую часть кода отрефакторили, осталась переферия - плагины, кли-валлет.

24.07.2018 16:57
0

Большинство плагинов сейчас агрегируют какие либо данные, чтобы можно было выдавать ответы на API запросы. При переезде на хранение в БД, необходимость во многих плагинах отпадет.

Вряд ли. Сейчас агрегируемые плагинами "данные" теряются "во глубине сибирских руд". Раз в месяц люди спрашивают, почему get_discussion не выдает данные. Сделаете вы базу данных общего вида, как описано в тексте key/value, как приложение должно фильтровать данные? Это будет нетривиальная задача имея только value фильтровать данные. Тем более разные приложения, разные структуры данных, по разному агрегированные данные. Я не уверен, что база данных решит все эти проблемы.

24.07.2018 17:04
0

key/value сейчас в EOS. И этого как раз и хочется избежать, сделав БД с полями.

24.07.2018 17:38
0

Key/Value нормальное решение, что бы хранить состояние ноды, состояние и балансы аккаунтов. Работает быстро и просто. Я и думаю, что возможно это не совсем верный путь, заменить эту базу, нормальной базой. ТОлько усложнит все, когда сопутсвующие данные можно писать напрямую в обычную базу данных. Блокчейн должен оставаться достаточно простым, быстрым и тонким контроллером. Тексты в самом блокчейне не обязательно хранить, только если содержание к примеру влияет на выплаты или что там. Но это можно обойти записывая в блоки хэш текста. Выплачивая из той же эмиссии хранителям текстов. И тексты можно было бы проще индексировать и вообще, не только тексты хранить.

Как то так

24.07.2018 20:30
0

Да, мы и хотим сделать из БЧ контроллер, а не универсальный комбайн, которым он пытается быть сейчас.

25.07.2018 03:04
0

Большинство плагинов сейчас агрегируют какие либо данные, чтобы можно было выдавать ответы на API запросы. При переезде на хранение в БД, необходимость во многих плагинах отпадет.

при нормальной архитектуре апп ее и сейчас нет) сырых блоков достаточно)

Человек, который пилил монго-плагин почти 3 месяца и засыпал github коммитами в попытке найти ошибку "методом тыка", в команде уже не работает. Остальное доделывалось между делом для сбора статистики, так как по принятию дел, стало понятно, что это был тупиковый путь.

а где гарантия что с другими членами комнды не повториться история? только они накосячат уже в боевом проекте, а это так себе перспектива. на такую работу нужно идти с "проверенными"

Чтобы переделать систему генерации ошибок приходится перешерстить весь код. Но делается это осознано, а не "методом тыка" как было в случае с монгой. Большую часть кода отрефакторили, осталась переферия - плагины, кли-валлет.

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

24.07.2018 18:55
0

при нормальной архитектуре апп ее и сейчас нет) сырых блоков достаточно)

Мы и хотим сделать, чтобы БЧ обрабатывал блоки, остальное не его задача.

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

Если посмотреть, что происходит при рефакторинге обработки ошибок, то там код перешерстили вдоль и поперек.

25.07.2018 03:06
0

Мы и хотим сделать, чтобы БЧ обрабатывал блоки, остальное не его задача.

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

Если посмотреть, что происходит при рефакторинге обработки ошибок, то там код перешерстили вдоль и поперек.

вот к чему это написано? Молодцы что перешерстили, а быстро умееете шерстить? сам же написал что не умеете, и это наврядли возможно, все причины написаны тобой лично выше.
А сама задача переноса в другой бч уже подразумевает шерстить код, поскольку у голоса 0 документации)

25.07.2018 07:10
0

Гигабайты текстов в блокчейне, а изхвлечь их от туда не получается. И мне кажется, что внешняя база данных в этом не поможет. golos.io, если они хотят стать блог платформой рано или поздно придут к тому, что бы хранить данные в нужном для golos.io виде, а переход на EOS только подтолкнет к этому. Но вот я почему то не уверен, что пара программистов или сколько их там, сможет за полгода мигрировать на новую парадигму.

вот я тоже пытаюсь это понять!
без клиента для блоков заниматься разработкой это маразм. передем на БЧ без блогов по факту)

24.07.2018 18:47
0

Насчет замены внутренней базы, на внешнию само по себе отличная идея, я раньше об этом говорил и предлагал, но со временем я охладел к этому. Оно нам надо? Сейчас shared_memory файл уже больше 72 Gig. Если заменить на обычную базу данных, размер от этого не уменьшится. Но самое интересное, что из этих 72G только ~5-6G консенсусные, а остальное вода для плагинов и в основном история по пользователям. Причем эти данные в большинстве своем никому не нужны.

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

24.07.2018 18:48
0

В БЧ есть еще правила обработки операций в блоках, поэтому для апп не хватит только парса блоков.

25.07.2018 03:51
0

моим апп хватает=) почти все боты этим и обходятся
если ты клонишь что придется и записывать, то это и не вопрос к чтению данных

25.07.2018 07:17
0

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

24.07.2018 15:51
0

А чем опорочена наша репутация? И можно ли подкрепить свою точку зрения личными и конкретными доводами, почему это негативно повлияет на проект?

24.07.2018 20:07
0

как минимум многократным несоблюдением сроков ХФ. Это как минимум. Но и этого более чем достаточно, чтоб напрочь убить доверие пользователей. Ну а как максимум - очень мутный распил бюджета. Молчу уже о полной неспособности организовать эффективную работу команды

24.07.2018 20:27
0

Последние полгода сроки соблюдаются.

25.07.2018 03:11
0

потеряв девственность невозможно снова стать невинным. Репутация испорчена, доверия нет и вряд ли оно так быстро сможет восстановиться

26.07.2018 04:45
0

Вам сколько вообще лет? По разговору и незамутненности сознания не более 22.

Токены сообществ были обещаны и не реализованы даже в рамках стимовского блокчейна. Не негативно повлияет - убъет то, что осталось. Уже приводил метафору - вы просто разгоните переделками и нестабильностью пользовательскую базу. EOS еще очень сырой продукт. Как бы вы отнеслись с точки зрения удобства пользователя если бы протокол биткоина менял алгоритм майнинга каждые 3 месяца? Другое дело, что вы можете создать новый проект и дать пользователям право выбора, форкнув балансы туда Лишь в качестве альтернативы основному решению. Будут использовать то, что удобнее.

25.07.2018 08:07
0

В двух словах.
Практически все пользователи против.
Те кто воздерживаются, не верят в команду тех, кто хочет это делать.
Те кто хочет это сделать, это сама команда.

И так в каждой дискуссии.
Моё мнение как редового пользователя и не знакомого с глубокой технической составляющей.
Мне не важно, на чём или как это работает. Мне нужны пользователи, эксклюзивный материал и дискуссии под постами с живыми людьми.
Я устал смотреть на посты ботов, которые постят, потом просят ставить "лайки" других ботов.
Я устал от рекламных статей из одного обзаца с ссылками на сторонний ресурс с полной статьёй.
Я устал от рекламы скамов, айдропов, Баунти написанных по шаблону, но с разной ссылкой.

Переосмыслите само понятие этой площадки, а не старайтесь её изменить под себя.

24.07.2018 23:14
0

План заключается в более глубокой интеграции блокчейна с внешней БД и состоит он из следующих этапов:
Создать интерфейс доступа из библиотеки boost::multi_index к внешнему источнику данных

Я правильно понял, что это будет форкнутый boost с доработкой multi_index?

25.07.2018 07:42
0

boost multi_index предоставляет удобные возможности. Настолько удобные, что команда EOS сделал реализацию для смарт-контрактов.

Да, мы хотим сделать кастомную реализацию boost multi_index с необходимой функциональностью.

25.07.2018 09:28
0

нюансов, а не ньюансов

Это не от слова "new" )

25.07.2018 07:53
0

По нашим оценкам, команда Golos•Core из 7 С++ программистов может реализовать предложенный план переезда на кодовую базу EOS в течение 6 месяцев

А вы можете как нибудь быстрее свалить с нашей платформы?

25.07.2018 09:13
0

Если технари и инвесторы за переход то идея однозначно здравая. Зачем использовать кодовую базу стима когда имеется более совершенный EOS? У стима все что могли уже взяли.

Те же например бустеры на смарт-контрактах - это будет прогресс, рождение конкуренции и экономия на сторонних серверах.

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

25.07.2018 14:07
0

@arturio777 какие бустеры на смарт-контрактах? они же сейчас как-то иначе же работают, да?

и надо немного вчитаться в описание перехода, модераторы будут распределять пул, а не ценник инвестора

25.07.2018 14:14
0

@arturio777, тут ввели термин: ГЕОС (это как скрестить ежа со змеёй). Не факт, что на него будет хорошая документация. Стимит не дозрел до документации или комментариев в коде, на момент форка в Голос.

26.07.2018 03:55
0

@goloscore, Поздравляю!
Ваш пост был упомянут в моем хит-параде в следующей категории:

  • комментарии - 1 позицию - 69 комментарии
26.07.2018 05:59
0