Список предлагаемых к реализации изменений с учётом поступивших идей и текущих медицинских технических показаний :)
Добавка функционала конвертации токенов GOLOS в GBG по среднему 3.5 дневному курсу котировок (перевернутый вариант текущей конвертации + 5%). Процент наценки будет делегатским параметром.
Доработка в части начисления процента держателям токенов GBG - будет осуществляться только на сейф-балансе.
Сейчас, если делегатский параметр sbd_interest_rate
>0 владельцы всех GBG получают процент.
- Создание event-плагина к ноде, что базово позволит получать виртуальные операции для уведомлений и иных целей разработки (напр. по действиям с внутренней биржей или мессенджером).
В последующем возможно расширение функционала событий блокчейна и их стриминга.
Обновление базы данных Tarantool до стабильной версии в сервисе Golos Notify и переезд с базы данных MySQL на Tarantool в веб-клиенте блогов.
Основа для единой кодовой базы библиотеки golos-js и других библиотек, используемых веб-клиентами для работы с блокчейном Golos и сервисами на нём.
В дальнейшем это упростит перенос основных функций на другие языки программирования, а также дополнит оптимальными реализациями имеющихся алгоритмов криптографии (для авторизации в сервисах, мессенджера, отправки операций и пр.).
Изменение срока понижения Силы Голоса аккаунтов с 8 до 4 недель.
Исправление бага с отменой всех ордеров на внутренней бирже при автоконвертации GBG.
Исправление бага внутренней биржи в части округления цен и отображения их на веб-клиенте.
Исправление бага с
dynamic_global_properties
, который нередко приводит к частотности reed-locks возникающих на АПИ-нодах.
Кроме того, с учётом недавнего сбоя в сети блокчейна из-за ситуационной ошибки медианных параметров:
Доработка для фиксации в логах докера ноды стектрейса и своевременной локализации ошибок.
Доработка логики в делегатских параметрах распределения эмиссии по пулам (в целях снижения скачков медианы).
Восстановление устаревших и написание дополнительных выборочных тестов на ноде по изменениям.
Описываемый список не включает все правки, по ходу работ возникают дополнительные, которые также исправляются воркером, если они не требуют особых временных затрат.
Реализация описанных задач оценивается воркером @aerostorm1 минимум в 2900$.
Так как несколько месяцев назад один из стекхолдеров проекта обменял свои токены эквивалентом 1150$ и передал их в поддержку развития разработки, считаю разумным использовать их сейчас. Поэтому в заявке запрашивается 1750$, что по биржевому курсу составляет ~1 млн. 100 тыс. токенов.
В случае согласия сообщества оплатить эту работу - токены будут отправлены на аккаунт @lex-escrow и переведены воркеру после передачи результата/кода в открытый репозитарий сообщества и проверки его на тестовой сети.
Своё решение по этой заявке можно выразить здесь, проголосовав с выбранным процентом от запрашиваемой суммы за или против.
@lex-escrow
Помню, что и я предлагал это. Но, я предлагал это с учётом того, что нужно сделать конвертацию возможной, с каким-то ограничением. Чтобы один человек не мог сконвертить все ликвидные голоса в GBG выев тем самым весь долг системы.
Какие вообще ограничения планируется реализовать для такой конвертации, никаких? Тогда я против, так тут требуется серьезный анализ возможных манипуляций курсами и стеками.
Вообще считаю, что процент на золотой надо отменить как класс. И так у нас он должен играть роль защитного актива, не должно быть на него процента вообще.
Сейчас прибегут люди и скажут, что даже на металлических считах есть процент. Есть, но это не золото. И вы несете риски банка, где у вас есть металический счет. Если вы хотите именно иметь золото на хранении, никакого процента не будет.
В общем, эти вопросы требуют более детального обсуждаения ДО принятия решения о реализации.
@litrbooh, @lex
в hive это реализовано немного интереснее, если тебе надо допустим сконвертировать 100 hive в hbd, то
это происходит так:
Мне прямо очень понравилась такая реализация.
@svamiva, я видел их вариант https://gitlab.syncad.com/hive/hive/-/issues/129, но усложнять сейчас мы не очень готовы, а переворот обкатанной конвертации доступнее (и проще покрыть тестами).
Ну и мгновенность в отсутствии торгуемого во внешке стейбла не так востребована кмк.
@litrbooh, защита от долга системы с другой стороны это автоконвертация при >20%
А ограничение, делегаты у нас (на Хайв этого нет) смогут менять %, тот что по дефолту 5% (будет делегатский параметр и хоть заградительные 200% туда пихай). Приближение к долгу? Вот можно и менять делая конвертацию менее выгодной.
По поводу серьезного анализа, в чём вопрос - сделай. Многим думаю достаточно обсуждений и опыта внедрения функциональности на Хайв в прошедшем ХФ (https://golos.id/ru--blokcheijn/@docsait/hive-hardfork-uzhe-v-puti-30-iyunya), процент на сейф там же, как альтернатива DeFi на минималках.
По проценту, также выбор за делегатами. ставить ли его в параметре sbd_interest_rate и какой, правка лишь оптимизирует чтобы он не шёл по спящим GBG (только на GBG в сейфе).
@lex, куда деваются defi проекты мы уже знаем. многие - пропадают с баблом? Или я не в теме? Я не понимаю физически откуда у GOLOS бабки на процент по вкладам в золоте.
А какие ставки держут у нас делегаты даже во время дефолта все видели.
@litrbooh, с этим не поспоришь, но правка не есть включение, правка чтобы если вдруг - было не через ж 😂
@lex-escrow, большинство правок хорошие и полезные, я за) 😎 👍️
@lex-escrow, ...я тут подумал, что неплохо бы еще одно нововведение привнести с ХФ...вот сейчас при публикации поста можно выбрать три разных способа оплаты: 100% в СГ; 50% в СГ, а 50% в голоса; без оплаты. Первые два способа никак не отражаются на выплатах голосующих за публикацию автора, а вот третий не дает возможности кураторам получить свой гешефт от голосования. Может быть имеет смысл при публикации автором поста "без оплаты" где-то в заголовке поста, или в информационной строке поста указывать отдельным графическим символом, или значком, что этот пост автор публикует "без оплаты", чтобы все читатели знали об этом заранее и уже их дело, голосовать за этот пост поддерживая репутацию автора, или нет...
@smotritelmayaka, посмотрю, для этого не нужен ХФ...
@lex-escrow,
Вроде бы и интересно, но боюсь сделают как нибудь. Есть какие то наметки, как это будет работать? Я явист, и может можно еще что то предложить, как лучше реализовать, что бы не только питонщиков или джаваскриптистов удовлетворяло? К примеру сделать теми же websockets. Типа как по следущей ссылке, только не просто блоки с пользовательскими операциями, а аналог get_ops_in_block. Имею ввиду set_block_applied_callback.
https://golos.id/ru--golos/@vik/preimushestva-novogo-websocket-api-golosa-podpiska-setblockappliedcallback-teper-soderzhit-tranzakcii
Будут только виртуальные операции или и нормальные тоже? Без последних смысла не будет думаю.
И некоторые виртуальные операции стоило бы почистить, там иной раз бесполезные данные в операциях. К примеру comment_payout_update_operation, вообще непонятно к чему она. Еще что то видел, кажется comment_reward, указывается в GBG, хотя выплата идет в GESTS.
@bitwheeze, нет, в данной заявке речь только о виртуальных операциях к которым даже для целей веб-клиентов сейчас не обойтись без накопления блоков и анализа отдельными скриптами. Т.е. только то что нам нужно для уведомлений, мессенджера, операций на внутренней бирже и прочего.
Однако когда-то плагин возможно приобретет тот функционал о котором ты пишешь, чтобы мог отдавать нужные операции без необходимости дергать их по АПИ или копить блоки в своей базе....
@lex, не пойму почему такое ограничение, если в плагины все равно все операции стримятся. Я видел есть mongodb плагин, там уже все есть. Просто направить в нужный поток.
Но я так понимаю, все уже обговорено, так что не буду путать. Я все же без году неделя на голосе. Вам лучше знать, что требуется
@bitwheeze, mongodb есть, только скажем так, она не очень в форме и хорошо себя чувствует, если с ней начать работать )
@lex, спасибо за предупреждение, я уже хотел попробовать как альтернативу get_ops_in_block каждые 3 секунды 😎
@bitwheeze, нет, в текущем виде это плохая альтернатива.
Тут либо отдельный более шустрый стриминг делать, либо дорабатывать плагин ивентов примерно как ты и описал.
@bitwheeze, там далеко не
Но в любом случае вопросы лишними не бывают, фидбек на что есть спрос, получен 👍️
@lex, ну понятно, что все не так просто. Я имею ввиду, что если не будет пользовательских операций, то придется и дальше дергать каждые 3 секунды get_block или get_ops_in_block, что бы получить к примеру transfer или vote операции. А если есть возможность в event плагин посылать virtual operations. то и обычные можно, без каких то особых дополнительных трудозатрат.
@lex-escrow,
А что это конкретнее, а то я потратил 2 недели своей жизни на написание библиотеки для java и может зря ))
@bitwheeze, ну почему зря, здесь речь немного о другом
на предмет замены тяжелых частей JS, в том числе и по криптографии на WebAssembly (или иной вариант) для улучшения быстродействия базы для либ
Ну а обертки уже разными языками делать, кому что...
Многое не понял, но интересно 😂
@mrarturs, спрашивай, комменты на что 😂
Лень расписывать, если мало кому интересны прям детали...
@lex, моё дело маленькое, я пользователь, мне только чтобы читать, писать и кнопка "бабло" хорошо работала 😂
@mrarturs, читать и писать сделаем точно ))
@lex, а на кнопку "бабло" вывести мне в личный профиль, нужно отдельно заявку подавать? 😂 кто возьмёться 😂
@lex-escrow, В golos-js, кстати, было бы неплохо еще пофиксить косяки, например до сих пор не работает interest_rate в делегировании, видимо до сих пор не обновили метод.
@leva64, JS "исторически" обновляется когда что-то нужно в веб-клиенте 😂
Хотим её актуализировать до этого момента, получим дополнительные затраты. Если не в курсе, либа нуждается в правках и по части оптимизаций (сравнивая с тем же Хайв по тестам многое видно), обновить компоненты + быстродействие.
Это есть в планах, и отчасти задача по "JS vs WebAssembly" в этой заявке начало пути улучшений.
По
interest_rate
правка нужна вместе с изменением веб-клиента, чтобы делегирование с % было для всех, а не только скриптами в консоли. Ну либо я таки доберусь разобраться с писарем (кто может обновить https://github.com/gropox/sign, велкам), чтобы работало отсюда https://props.golos.today/delegator@lex, Я тут немного поспешила ругаться. В методах оно всё таки есть, нашла методом проб, ошибок и такой-то матери.
Работает либо вот так:
var payout_strategy = 0;
golos.broadcast.delegateVestingSharesWithInterest(wif, delegator, delegatee, vesting_shares, interest_rate, payout_strategy, function(err, result) { console.log(err, result, vesting_shares); });
либо так:
golos.broadcast.delegateVestingSharesWithInterest(wif, delegator, delegatee, vesting_shares, interest_rate, Array(0), function(err, result) { console.log(err, result, vesting_shares); });
Но никто не удосужился внести метод в мурзилку по golos-classic-js
@leva64, а кто удосужится, ты на гитхаб взгляни от кого есть пулреквесты и коммиты вообще ))
Документацию требовать нужно было в моменты когда писался код, сейчас это на уровне либо платить тому кто опишет, либо просить (что часто и делаю с воркерами).
@lex, вот вроде как и понимаешь что надо это всё сделать, но как подумаешь о том что за это какому-то специалисту снова придется токенов отсыпать на 800 баксов и с большой вероятностью они польются по стакану - уже ничего не хочется. Сцуко, почему нам не даёт никто бабла так как в свое время насыпали Киберфонду?
@leva64, насчет стакана ты заблуждаешься, большая часть того что там бывает и появилось ради продолжения разработки.
С инвесторами тоже надо разговаривать, мы не такие большие как Стим/Хайв чтобы все происходило само собой...
@leva64, меньше, но сути твоего вопроса это не меняет, да. Печально лишь то что эти вещи не были сделаны когда команды получали 70-80к $ ежемесячно, а ведь кроме документации нужны и тесты, чтобы прогоняя при каждой сборке ловить все нестыковки с изменениями и не иметь багов в продакте.